Software Engeering

Weil klassische Modelle oft aufwendig sind, viel Zeit kosten und umfangreiche Dokumentation erfordern. Agile Methoden setzen auf schnelle, flexible Entwicklung mit bewährten Praktiken.

Work in Progress (WIP) bezeichnet die Anzahl der gleichzeitig bearbeiteten Aufgaben, die begrenzt werden sollte.

Kaizen steht für kontinuierliche Verbesserung, die in Kanban durch regelmäßige Meetings und Prozessoptimierungen angestrebt wird.

Durch die Begrenzung der Aufgaben pro Spalte wird sichergestellt, dass nicht zu viele Arbeiten gleichzeitig begonnen werden und Engpässe erkannt werden können.

Kanban hat weniger feste Regeln als Scrum, setzt auf kontinuierliche Verbesserungen und erlaubt eine flexible Arbeitsweise ohne festgelegte Rollen oder Zeitintervalle.

1. Es werden klare Regeln definiert.

2. Der Arbeitsablauf wird visualisiert.

3. Der Arbeitsablauf wird verwaltet.

4. Die Menge der Aufgaben wird beschränkt.

5. Es wird nach kontinuierlicher Verbesserung gestrebt.

Beim Holprinzip fordert ein nachgelagerter Arbeitsschritt erst dann Material von einem vorgelagerten Arbeitsschritt an, wenn es benötigt wird.

1. Dort beginnen, wo man sich aktuell befindet.

2. Inkrementelle und evolutionäre Änderungen anstreben.

3. Bestehende Prozesse, Rollen und Verantwortlichkeiten respektieren.

4. Führungsverantwortung fördern.

Aufgaben werden durch ein Kanban-Board visualisiert, das die Entwicklungsphasen wie "Start", "In Bearbeitung" und "Erledigt" darstellt.

Der Kanban-Ansatz stammt aus der Produktionssteuerung und wurde 1947 von Taiichi Ohno bei Toyota entwickelt.

David Anderson hat Kanban im Jahr 2007 auf die IT-Welt übertragen.

Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospektive, Product Backlog Refinement.

Eine Liste mit allen Anforderungen an die Software, die regelmäßig aktualisiert wird.

Eine Liste mit den Aufgaben, die im aktuellen Sprint umgesetzt werden sollen.

Die Summe aller fertiggestellten Backlog-Einträge nach einem Sprint, also der aktuelle Stand des Produkts.

Agile Prozesse sind flexible Methoden zur Softwareentwicklung, die schnelle Anpassungen an sich ändernde Anforderungen ermöglichen. Beispiele sind Extreme Programming (XP), Scrum und Kanban.

Extreme Programming (XP) ist eine agile Entwicklungsmethode, die auf kleinen, schnellen Entwicklungszyklen basiert. Sie wurde von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt.

Kommunikation, Einfachheit, Feedback, Mut, Respekt.

Menschlichkeit, Wirtschaftlichkeit, beidseitiger Vorteil, Verbesserungen, Vielfältigkeit, Reflexion, Fluss, Fehlschläge hinnehmen, Gelegenheiten wahrnehmen, akzeptierte Verantwortung, Qualität, Redundanzen vermeiden, kleine Schritte.

Paarprogrammierung, testgetriebene Entwicklung, Refactoring, Planungsspiel, einfaches Design, kurze Iterationen mit kleinen Releases, Einbeziehen des Kunden, ständige Integration, kollektives Eigentum, feste Programmierrichtlinien, keine Überstunden.

t: Scrum ist ein agiles Vorgehensmodell mit iterativen Entwicklungszyklen (Sprints), die maximal 30 Tage dauern. Es gibt feste Rollen, Artefakte und Meetings zur Organisation des Prozesses.

Product Owner, Scrum Master, Entwicklungsteam.

Product Backlog, Sprint Backlog, Product Increment.

Sie beschreiben Anforderungen aus Anwendersicht in einfacher Sprache, um die Bedürfnisse des Nutzers klarzustellen.

**Als **** möchte ich ****, damit ich **.

Beispiel: Als Kunde möchte ich Restaurants suchen können, damit ich weiß, welche in meiner Nähe sind.

Mögliche Blockaden durch unpassende Partnerwahl, längere Entwicklungsdauer, ungleiche Wissensstände können hinderlich sein.

Der Test wird zuerst erstellt. Erst danach wird der Code geschrieben, bis der Test bestanden wird.

1. Test schreiben (der Test schlägt fehl)

2. Code schreiben und anpassen (bis der Test bestanden wird)

3. Code aufräumen (Refactoring) (ohne neue Funktionalität hinzuzufügen)

Führt zu weniger Fehlern, verständlicherem Code, ermöglicht schnelle Rückmeldung und kontinuierliche Verbesserung.

Das Erreichen des Ziels, nicht das Abarbeiten eines festen Plans. Agile Methoden sollen den Aufwand in einem Prozess möglichst gering halten.

Zwei Programmierer arbeiten gemeinsam an einem Rechner. Einer (Driver) schreibt den Code, der andere (Observer/Navigator) überprüft ihn und denkt über das Problem nach. Die Rollen wechseln regelmäßig.

Bessere Software-Qualität, weniger Fehler, schnellerer Wissensaustausch, höhere Teamstimmung.

Beim Refactoring wird der Code strukturell verbessert, ohne seine Funktionalität zu verändern, um Lesbarkeit, Wartbarkeit und Erweiterbarkeit zu optimieren.

Beim Code Review wird der Code auf Fehler geprüft. Dabei liegt der Fokus nicht auf der Struktur (wie beim Refactoring), sondern auf der Fehlererkennung.

• Mehrfach vorhandener Code

• Nicht genutzter Code

• Zu umfangreiche oder zu kleine Klassen

• Klassen ohne Funktionalität

• Zu enge Verflechtungen zwischen Klassen

• Änderungen an einer Stelle erzwingen Änderungen an anderen Stellen

• Nichtssagende oder zu lange Namen

• Tiefe Verschachtelungen

• Übermäßige Kommentare als Indiz für unklaren Code

Unit-Tests überprüfen einzelne Module (Units) einer Software und werden oft im Rahmen der testgetriebenen Entwicklung eingesetzt.

• Java: JUnit (https://junit.org/junit5/)

• PHP: PHPUnit (https://phpunit.de/)

• Höhere Software-Qualität durch sofortige Fehlererkennung

• Vermeidung von Wissensmonopolen

• Förderung des Lernens innerhalb des Teams

• Verbesserung der Teamstimmung (sofern die Partner harmonieren)

TDD ist eine Methode, bei der zuerst Tests für eine noch nicht existierende Funktionalität geschrieben werden. Erst danach wird der Code entwickelt, bis der Test erfolgreich ist.

1. Erstellen des Tests – Ein Test für die noch nicht existierende Funktionalität wird geschrieben.

2. Erstellen und Anpassen des Codes – Minimaler Code wird geschrieben, um den Test zu bestehen.

3. Aufräumen des Codes – Der Code wird verbessert, ohne neue Funktionalität hinzuzufügen.

• Höhere Code-Qualität

• Weniger Fehler

• Bessere Wartbarkeit

• Schnellere Entwicklung durch frühzeitige Fehlererkennung

Agile Methoden sind Techniken, die den Entwicklungsaufwand gering halten und das Erreichen des Ziels priorisieren, statt starr einem Plan zu folgen.

Agile Methoden beziehen sich auf spezifische Techniken wie Paarprogrammierung oder testgetriebene Entwicklung, während agile Prozesse (z. B. Scrum oder Extreme Programming) umfassendere Rahmenwerke zur Softwareentwicklung sind.

Bei der Paarprogrammierung arbeiten zwei Entwickler an einem Rechner. Einer schreibt den Code (Driver), der andere überprüft ihn und denkt über Verbesserungen nach (Observer). Die Rollen wechseln regelmäßig.

as Sponsoringkonzept dient der Ansprache und Akquise von Kooperationspartnern und Sponsoren. Es definiert die Erwartungen der Partner und legt fest, was diese an Geld- und/oder Sachmitteln liefern.

1. Aufstellung der Gelder (Stadt, Handel, Sponsoren)

2. Identifikation von Refinanzierungsmöglichkeiten

3. Detaillierte Budgetplanung und Ressourcenaufteilung

Stadt(teil)-Marketing ist ein Teil des Marketingmix, der das Ziel hat, die Infrastruktur zu gestalten und den Standort für Wirtschaft, Bürger und Besucher attraktiver zu machen. Es geht nicht nur um Werbung, sondern um das Binden von verschiedenen Akteuren.

Kreativität hilft dabei, spannende Projekte zu entwickeln, die das Interesse der Bürger und Besucher wecken. Es geht darum, innovative Konzepte zu finden, die die Werte und Visionen der Stadt widerspiegeln.

1. Abstimmung mit vielen Beteiligten

2. Sicherheitskonzepte für Großveranstaltungen

3. Wetterrisiken und Besucherströme steuern

4. Budgetierung und Sponsorenfindung

Stadtmarketing ist langfristig angelegt. Einzelne Events können Aufmerksamkeit generieren, aber eine nachhaltige Positionierung erfordert kontinuierliche Maßnahmen und eine durchdachte Strategie.

Die Situationsanalyse. Sie umfasst die Sammlung von Statistiken, Bürgerbefragungen, Standortbewertung, Imagebewertung und die Analyse des Entwicklungspotenzials der Stadt/Region.

1. Sammlung von Statistiken und Bürgerbefragungen

2. Standortbewertung und Imagebewertung

3. Analyse des Entwicklungspotenzials der Stadt/Region

4. Analyse erfolgreicher vergangener Projekte und Events

1. Definition der Zielsetzung (kurz-, mittel-, langfristig)

2. Künftige Positionierung der Stadt/Region

3. Abgrenzung gegenüber benachbarten Städten

4. Erstellung einer Themenliste und Festlegung der Schwerpunkte

5. Erstellung eines Projektplans für den Gesamtkommunikationsmix (Werbung, Events, Pressearbeit)

1. Politik

2. Verwaltung

3. Unternehmen

4. Einzelhandel

5. Dienstleister

6. Relevante Verbände/Organisationen

1. Einwohner: Identifikation mit der Stadt stärken

2. Unternehmen: Standort attraktiv halten

3. Externe Besucher: Touristen, Investoren, Veranstaltungsteilnehmer

• Sie schaffen neue kulturelle Ereignisse

• Sie ziehen Publikum an und stärken die Kaufkraft

• Sie vermitteln Botschaften (z. B. Umweltbewusstsein, Stadtleitbild)

• Sie fördern Sympathie für die Stadt

1. Situationsanalyse (Statistiken, Wettbewerbsanalyse)

2. Strategie- und Konzeptphase (Ziele, Maßnahmen, Budget)

3. Umsetzungsphase (Veranstaltungen, Kommunikation)

4. Ergebniskontrolle (Erfolgsmessung, Strategieanpassung)

oftware wird in kurzen Zyklen weiterentwickelt. Jede Iteration liefert eine funktionierende Version des Produkts.

Karte 7

Sie sind wichtig, aber zweitrangig im Vergleich zu funktionierender Software und Zusammenarbeit.

Schnelle, flexible Entwicklung mit kurzen Feedbackschleifen und enger Zusammenarbeit.

Stadtmarketing ist ein strategischer Ansatz zur gezielten Gestaltung und Vermarktung einer Stadt. Es basiert auf Kundenorientierung und dient der Steigerung der Lebensqualität der Bürger sowie der Attraktivität der Stadt im Standortwettbewerb.

Politik, Verwaltung, Unternehmen, Vereine, Kulturschaffende, Sponsoren, Stadtteil- und Straßenwerbegemeinschaften sowie Bürger.

1. Produktmix: Städtische Angebote, Dienstleistungen, Ambiente

2. Distributionsmix: Informationsverbreitung, Verkehrsanbindung

3. Kontrahierungsmix: Preispolitik, Steuern, Subventionen

4. Kommunikationsmix: Werbung, PR, Events

Die Hardware – wörtlich übersetzt „Eisenwaren“ – umfasst sämtliche Geräte der elektronischen Datenverarbeitung.

• Alpha-Version: Frühzeitige, unfertige Entwicklungsstufe für interne Tests.

• Beta-Version: Fortgeschrittene Testversion für eine größere Gruppe von Testern.

• Release Candidate (RC): Fast fertige Version zur finalen Fehlerbehebung.

• RTM (Ready to Manufacturing): Endgültige Version, die veröffentlicht wird.

1. Patch: Allgemeine Fehlerkorrektur oder essenzielle Ergänzung.

2. Hotfix: Schnelle Fehlerkorrektur für kritische Probleme.

3. Update: Behebt Fehler oder bringt kleinere Verbesserungen.

4. Upgrade: Fügt größere neue Funktionen hinzu.

Werkzeuge unterstützen unter anderem bei:

• Anlegen neuer Versionen

• Zuordnung von Versionsnummern

• Automatischem Vergleich und Zusammenführen von Änderungen

• Dokumentation von Unterschieden zwischen Versionen

Beispiel für ein solches Werkzeug: RCS (Revision Control System)

Eine Versionsnummer besteht aus drei Zahlen:

• Hauptversion (z. B. 2) → Große Neuerungen oder grundlegende Änderungen

• Größere Änderungen (z. B. 1) → Wichtige Anpassungen oder neue Funktionen

• Kleinere Änderungen (z. B. 6) → Kleine Fehlerkorrekturen oder Verbesserungen

Versionsnummern unter 1.0 (z. B. 0.1.2) kennzeichnen in der Regel Testversionen, die sich noch in der Entwicklungs- oder frühen Testphase befinden.

1. Geplante Wartung: Änderungen werden systematisch geplant, priorisiert und in eine zukünftige Version integriert. Es gibt einen Zeitplan.

2. Schnellschuss: Eine kurzfristige, ungeplante Korrektur eines schwerwiegenden Fehlers, die sofort umgesetzt wird.

Eine Versionsverwaltung ist notwendig, um Änderungen an einer Software nachvollziehbar zu machen, parallele Entwicklungen zu ermöglichen und Fehler durch das Überschreiben von Code zu vermeiden. Sie stellt sicher, dass ältere Versionen erhalten bleiben und Änderungen gezielt dokumentiert werden.

Eine Version einer Software umfasst nicht nur den Quellcode, sondern auch:

• Dokumentationen

• Diagramme

• Testfälle

• Weitere relevante Dateien

1. Regressionstests sind Tests, die nach einer Änderung erneut durchgeführt werden, um sicherzustellen, dass keine neuen Fehler entstanden sind.

2. Diese Tests sind besonders wichtig, werden aber oft aus Zeitgründen vernachlässigt.

1. Die Wartbarkeit der Software kann über die Zeit abnehmen, wenn Wartungsmaßnahmen nicht gründlich durchgeführt werden.

2. Mit zunehmendem Aufwand für Wartung steigen auch die Kosten und der Bedarf an qualifiziertem Personal.

1. Fehlerkorrekturen müssen schnell durchgeführt werden, um die Software in Betrieb zu halten.

2. Oft werden nur die Symptome des Fehlers behoben, nicht die Ursache.

3. Regressionstests werden aus Zeitgründen ausgelassen, was zu neuen Fehlern führen kann.

4. Die Dokumentation der Korrekturen wird häufig vernachlässigt, was die Dokumentation unbrauchbar machen kann.

– Der "Titanic-Effekt"

• Entwickler unterschätzen Wartung und Fehler, weil das System grundsätzlich funktioniert.

• Änderungen können unerwartete Auswirkungen auf das gesamte System haben.

• Der „Titanic-Effekt“: Leichtsinn führt zu unvorhergesehenen Problemen, ähnlich der Katastrophe der Titanic.

• Bezeichnet die Leichtsinnigkeit, Wartung als weniger wichtig zu erachten.

• Ähnlich dem Verhalten vor dem Untergang der Titanic: „Das System ist stabil, es kann nichts passieren.“

• Kann dazu führen, dass Änderungen die Software verschlechtern, anstatt sie zu verbessern.

– Fehlende Entwickler im Wartungsteam

• Entwickler, die die Software erstellt haben, sind oft nicht mehr im Wartungsteam.

• Wartung wird von Personen ohne Detailkenntnisse durchgeführt.

• Neue Fehler können leicht entstehen, die ebenfalls behoben werden müssen.

1. Wartung: Behebung von Fehlern und Optimierung der Software.

2. Pflege: Anpassungen und Erweiterungen der Software.

3. Oft wird der Begriff „Wartung“ verwendet, um beide Tätigkeiten zu beschreiben.

1. Präventive Wartung: Vorbeugung von Fehlern.

2. Korrigierende Wartung: Behebung von Fehlern.

3. Adaptierende Wartung: Anpassungen und Änderungen an neue Anforderungen.

4. Perfektionierende Wartung: Optimierung der Software.

5. Wertsteigernde Wartung: Weiterentwicklung des Systems mit neuen Funktionen.

1. Der Wartungsaufwand wird oft unterschätzt.

2. Nach dem Übergang in den Realbetrieb wird die Wartung als abgeschlossen betrachtet, aber sie erfordert oft noch 30-80% des gesamten Projektaufwands.

3. Komplexe Software erfordert viel Wartung über die Jahre hinweg.

1. Fehler, die erst im Realbetrieb entdeckt werden.

2. Tests decken nicht alle Fehler auf, besonders bei komplexen grafischen Benutzeroberflächen.

3. Fehler können durch unzählige Kombinationen von Benutzereingaben entstehen, die schwer alle zu testen sind.

1. Software kann theoretisch unendlich lange leben, aber aufgrund von Änderungen in der Umgebung und den Einsatzbedingungen muss sie regelmäßig angepasst werden.

2. Beispiele: Jahrtausendwechsel, Euroeinführung, neue Betriebssystemversionen.

3. Auch kleine Änderungen (z.B. neue Rechtsvorschriften) erfordern Anpassungen.

• Software führt durch Weiterentwicklungen oft zu neuen Wünschen der Anwender.

• Diese Änderungswünsche können die Software immer weiter anpassen und zu einer „Alterung“ der Anwendung führen, wenn sie nicht regelmäßig gepflegt wird.

Spiegelung bezeichnet das Erstellen einer 1:1-Kopie von Daten aus einem alten System in das neue System, um sicherzustellen, dass beide Systeme gleichzeitig aktuelle Informationen enthalten.

Der Parallelbetrieb erhöht den Aufwand erheblich, da beide Systeme gleichzeitig betrieben und verwaltet werden müssen und zusätzliche Hardware erforderlich ist.

Nach der Auslieferung erfolgt bei Individualsoftware eine Installation, anschließend Tests und die Einführung der Software beim Kunden.

In der Zusammenfassung wird betont, dass nach dem Abschluss der Entwicklung die Software ausgeliefert wird, bei Individualsoftware jedoch nach der Installation Tests und eine Einführung beim Kunden erfolgen.

Die Aufgaben zur Selbstüberprüfung umfassen Fragen zur Übergabe von Quelltexten, zu Tests bei der Abnahme, zur Verantwortung des Abnahmetests, zum Rollout und zur Übernahme von Daten bei der Einführung einer neuen Software.

Der Realbetrieb beginnt, wenn die Software produktiv gesetzt wird, d.h., sie wird nach den Schulungen und der Datenübernahme tatsächlich genutzt.

Bei der direkten Ablösung wird das alte System nach der Datenübernahme stillgelegt, während im Parallelbetrieb beide Systeme eine Zeitlang parallel laufen, sodass bei Problemen auf das alte System zurückgegriffen werden kann.

Bei der direkten Ablösung wird das alte System nach der Datenübernahme stillgelegt, während im Parallelbetrieb beide Systeme eine Zeitlang parallel laufen, sodass bei Problemen auf das alte System zurückgegriffen werden kann.

Bei der direkten Ablösung können neue Fehler auftreten, die Datenverluste verursachen oder betriebliche Abläufe blockieren. Eine Rückkehr zum alten System ist schwierig, da zwischenzeitlich neue Daten im neuen System erfasst wurden.

: Images werden eingesetzt, wenn auf vielen Computern eine Erstinstallation durchgeführt oder Rechner regelmäßig auf eine Standardinstallation zurückgesetzt werden sollen, z.B. nach einem Seminar in einem Schulungszentrum.

Bei der Installation über ein Image werden alle bestehenden Dateien überschrieben, was dazu führt, dass alle Einstellungen und Dokumente auf dem Zielrechner verloren gehen.

Eine Mischform besteht darin, zunächst eine Grundinstallation des Betriebssystems über ein Image abzubilden. Dieses Image wird auf weitere Computer übertragen, wo eine individuelle Installation, oft über ein Skript, durchgeführt wird.

Die Verteilung funktioniert ohne größere Probleme, wenn sich die Zielrechner nicht oder nur geringfügig unterscheiden.

Eine Mischform besteht darin, zunächst eine Grundinstallation des Betriebssystems über ein Image abzubilden. Dieses Image wird auf weitere Computer übertragen, wo eine individuelle Installation, oft über ein Skript, durchgeführt wird.

Die Verteilung funktioniert ohne größere Probleme, wenn sich die Zielrechner nicht oder nur geringfügig unterscheiden.

Der Realbetrieb beginnt, wenn die Software produktiv gesetzt wird, d.h., sie wird nach den Schulungen und der Datenübernahme tatsächlich genutzt.

Images werden eingesetzt, wenn auf vielen Computern eine Erstinstallation durchgeführt oder Rechner regelmäßig auf eine Standardinstallation zurückgesetzt werden sollen, z.B. nach einem Seminar in einem Schulungszentrum.

Bei der Installation über ein Image werden alle bestehenden Dateien überschrieben, was dazu führt, dass alle Einstellungen und Dokumente auf dem Zielrechner verloren gehen.

Branchensoftware ist eine Mischung zwischen Standardsoftware und Individualsoftware. Sie ist speziell für die Anforderungen einer bestimmten Branche entwickelt, jedoch nicht auf die Bedürfnisse eines einzelnen Unternehmens zugeschnitten.

EULA steht für "End User License Agreement" (Endanwenderlizenzvereinbarung). Es regelt die Nutzungsrechte der Software und ist eine vertragliche Vereinbarung zwischen dem Softwareanbieter und dem Nutzer.

Die Installation erfolgt oft automatisch oder halbautomatisch mit speziellen Installationsroutinen. Diese ermöglichen es, die Software an einem bestimmten Ort zu installieren und gegebenenfalls bestimmte Teile der Software auszuwählen. Bei komplexer Software kann auch eine manuelle Installation erforderlich sein.

Nach der Installation führt der Kunde Tests wie Akzeptanztests, Funktionstests und Lasttests durch. Diese Tests überprüfen, ob die Software unter realen Bedingungen funktioniert und die Anforderungen erfüllt.

Im Abnahmeprotokoll werden entweder aufgetretene Fehler dokumentiert oder die Software wird vom Kunden freigegeben. Es ist wichtig, die Abnahme schriftlich zu bestätigen, um spätere Streitigkeiten zu vermeiden.

Zur Einführungsphase gehören die Schulung der Anwender und Administratoren, die Übernahme von Altdaten und gegebenenfalls die Installation der Software auf allen Arbeitsplatzrechnern.

: Stammdaten sind langlebige Informationen wie Kundendaten oder Artikeldaten. Bewegungsdaten sind eher kurzlebige Informationen, die Vorgänge wie Kundenanfragen oder Rechnungen betreffen.

Ein Software Management System wird verwendet, um Software automatisch auf mehreren Arbeitsplatzrechnern zu installieren. Dabei wird eine Referenzinstallation durchgeführt und alle Änderungen in einem Skript festgehalten, das dann auf alle Rechner verteilt wird.

Klonen bedeutet, eine 1:1-Kopie eines Systems zu erstellen. Diese Kopie wird dann auf andere Computer verteilt, sodass alle Rechner identische Software und Einstellungen haben.

Nachdem die Software alle Tests beim Produzenten bestanden hat und die Fehler korrigiert wurden, ist die Entwicklung abgeschlossen. Die Software wird dann an den Kunden ausgeliefert. Es erfolgt jedoch noch eine schrittweise Einführung und Tests durch den Kunden.

Bei Standardsoftware erhält der Käufer Datenträger mit dem ausführbaren Programm und allen notwendigen Dateien sowie eine Dokumentation. In einigen Fällen erfolgt die Auslieferung über das Internet, z.B. als Download oder in der Cloud.

Standardsoftware ist für einen breiten Markt und allgemeine Funktionen (z.B. Textverarbeitung) entwickelt und ist nicht an eine Branche oder spezielle Unternehmensfunktionen gebunden. Individualsoftware wird speziell für einen Auftraggeber entwickelt und ist auf dessen Bedürfnisse zugeschnitten.

Um sicherzustellen, dass die Korrektur keine neuen Fehler verursacht hat und frühere Funktionalität erhalten bleibt.

Aus Zeit- und Kostengründen werden oft nur die direkt betroffenen Testfälle geprüft, was das Risiko unerkannt neuer Fehler erhöht.

: Es dokumentiert Fehler, hilft bei deren Analyse und dient als Grundlage für die Fehlerkorrektur.

1. Sammlung und Bewertung – Prüfung, ob es sich um einen bekannten Fehler oder Änderungswunsch handelt.

2. Weiterleitung an Programmierer – Fehler wird im Quelltext gesucht und behoben.

3. Nachtest – Überprüfung, ob der Fehler tatsächlich behoben wurde.

4. Abschluss – Falls behoben, wird die Fehlermeldung geschlossen.

Ein erneuter Test nach der Fehlerkorrektur, um zu prüfen, ob der Fehler wirklich behoben wurde.

Ein Werkzeug, das den Quelltext zeilenweise ausführt und die aktuellen Inhalte von Datenobjekten anzeigt, um Fehler zu lokalisieren.

Der Begriff stammt aus den Anfangszeiten der Computertechnik, als ein Insekt („bug“) einen Kurzschluss verursachte.

in Platzhalter, der fehlende Teilsysteme simuliert und bei der Top-Down-Strategie verwendet wird.

Ein Programm, das ein Testobjekt mit Daten versorgt, häufig in der Bottom-Up-Strategie genutzt.

Tests, die sicherstellen, dass frühere Funktionalitäten nach Änderungen weiterhin korrekt funktionieren.

: Die Korrektur von in Tests gefundenen Fehlern, um die Software fehlerfrei und funktionsfähig zu machen.

1. Ort des Fehlers – In welcher Komponente, Klasse oder Eingabemaske?

2. Auswirkungen des Fehlers – Was ist passiert?

3. Schwere des Fehlers – Hat er den Testablauf unterbrochen?

4. Beteiligte Testfälle – Welche Daten führten zum Fehler?

5. Reproduzierbarkeit – Tritt er immer oder nur unter bestimmten Bedingungen auf?

✅ Kein Aufwand für Dummies, da untere Ebenen vollständig vorhanden sind.

❌ Das Gesamtverhalten des Systems wird erst spät getestet, sodass größere Änderungen nachträglich nötig sein können.

1. Wichtige Teilsysteme werden zuerst integriert.

2. Danach werden schrittweise weitere Teile ergänzt.

3. Nach jeder Erweiterung erfolgen Regressionstests.

✅ Kein schrittweises Testen nötig.

❌ Fehler schwer zu lokalisieren, da das gesamte System getestet werden muss.

❌ Hoher Aufwand zur Fehlerbehebung.

1. Zuerst werden die oberen Teilsysteme integriert.

2. Fehlende untergeordnete Teilsysteme werden durch Dummies (Teststümpfe) simuliert.

3. Danach erfolgt die Integration der unteren Ebenen.

1. Die unteren Teilsysteme werden zuerst integriert.

2. Testtreiber simulieren den Aufruf aus übergeordneten Schichten.

3. Danach erfolgt die Integration der oberen Ebenen.

Der Integrationstest prüft das Zusammenspiel verschiedener Teilsysteme und Komponenten eines Systems nach deren Zusammenführung.

Häufig bestehen Abhängigkeiten zwischen Teilsystemen, die noch in der Entwicklung oder Testphase sind und daher nicht vollständig geprüft werden können.

1. Big Bang – Alle Teile werden gleichzeitig integriert und getestet.

2. Top-Down – Die oberen Ebenen werden zuerst integriert, fehlende untere Ebenen durch Dummies ersetzt.

3. Bottom-Up – Die unteren Ebenen werden zuerst integriert, Testtreiber simulieren fehlende obere Ebenen.

4. Inkrementelle Strategie – Wichtige Teile werden zuerst integriert, nach und nach weitere ergänzt.

Beim Testen einer Klasse wird eine Instanz der Klasse erstellt, dann werden alle Methoden getestet, die den Zustand nicht verändern, gefolgt von denen, die den Zustand verändern. Zum Schluss werden abhängige Methoden getestet.

• Ein Testling ist das System oder Programm, das getestet wird.

Eine Äquivalenzklasse ist eine Menge von Eingabewerten, die das gleiche Verhalten eines Programms erwarten lassen, sodass nur ein Wert aus dieser Klasse für einen Test benötigt wird.

Strukturorientierte Testverfahren können keine fehlenden Funktionalitäten im Code aufdecken, da sie nur bestehende Strukturen testen.

• Die Kantenüberdeckung kann nicht feststellen, ob z.B. eine Schleife korrekt durchlaufen wird oder ob der Wert einer Variablen korrekt verändert wird, wie bei einem Fehler in der Schleifenbedingung.

• Bedingungsüberdeckung und Pfadüberdeckung. Bei der Bedingungsüberdeckung muss jede Teilbedingung einmal „wahr“ und einmal „falsch“ sein. Bei der Pfadüberdeckung muss jeder mögliche Weg durch das Kontrollflussdiagramm durchlaufen werden.

• Jede Teilbedingung einer Kontrollflussbedingung muss mindestens einmal den Wert „wahr“ und einmal den Wert „falsch“ annehmen.

• Bei der Pfadüberdeckung muss jeder mögliche Weg durch das Kontrollflussdiagramm mindestens einmal durchlaufen werden, was in komplexen Systemen jedoch oft kaum möglich ist.

Funktionsorientierte Tests prüfen das Verhalten des Systems aus der Sicht des Benutzers und berücksichtigen keine internen Abläufe, während strukturorientierte Tests sich auf die interne Struktur und den Code konzentrieren.

Zuerst werden funktionsorientierte Tests durchgeführt, um das Verhalten des Systems zu prüfen, und anschließend werden strukturorientierte Tests durchgeführt, um interne Fehler im Code zu finden, die bei den ersten Tests übersehen wurden.

1. Strukturorientierte Tests konzentrieren sich auf die interne Logik und den Ablauf des Testobjekts.

2. Der Quelltext des Programms muss bekannt sein, da Testfälle auf der Grundlage des Codes und seiner Logik erstellt werden.

3. Dies wird auch als „white box“ bezeichnet.

• Ein Kontrollflussdiagramm visualisiert den Ablauf einer Funktion oder Methode.

• Es zeigt, wie die einzelnen Anweisungen des Codes miteinander verbunden sind und welche Entscheidungen getroffen werden.

• Solche Diagramme werden genutzt, um kontrollflussbasierte Tests zu erstellen und sicherzustellen, dass alle Pfade im Code abgedeckt sind.

1. 
   

2. Antwort: Ein Kontrollflussdiagramm stellt den Ablauf eines Programms dar, indem es die verschiedenen Zustände und Übergänge (Knoten und Kanten) visualisiert.

• Antwort: Der Testdeckungsgrad C1 (Kantenüberdeckung) bedeutet, dass jede Kante im Kontrollflussdiagramm mindestens einmal ausgeführt werden muss.

Antwort: Bei der Anwendungsüberdeckung muss jeder Knoten im Kontrollflussdiagramm mindestens einmal ausgeführt werden.

• Antwort: Jede Kante im Kontrollflussdiagramm muss mindestens einmal durchlaufen werden.

• : Bei der Anwendungsüberdeckung wird jeder Knoten mindestens einmal ausgeführt, während bei der Kantenüberdeckung jede Kante mindestens einmal durchlaufen wird. Kantenüberdeckung schließt Anwendungsüberdeckung ein.

1. Äquivalenzklassen fassen ähnliche Testfälle zusammen, die zu denselben Ergebnissen führen.

2. Sie ermöglichen es, die Anzahl der notwendigen Testfälle zu reduzieren, indem nur representative Fälle ausgewählt werden.

3. Beispiel: Für eine Eingabe, die Zahlen von 0 bis 99 akzeptiert, wären nur vier Testfälle nötig, um alle wesentlichen Eingaben zu testen.

1. Grenzwertanalysen suchen nach Fehlern, die an den Übergängen zwischen gültigen und ungültigen Eingabebereichen auftreten (z.B. Off-by-one-Fehler).

2. Beispiel: Für eine Funktion, die Zahlen ab 10 akzeptiert, müssen die Testfälle die Werte 9, 10 und 11 prüfen.

• Dynamische Testverfahren arbeiten mit der echten Anwendung und testen die tatsächliche Einsatzfähigkeit des Systems.

• Im Gegensatz zu statischen Tests, die sich auf Dokumente konzentrieren, werden beim dynamischen Testen Testobjekte ausgeführt oder deren Ausführung simuliert.

• Es gibt zwei grundlegende Verfahren:

  1. Funktionsorientierte Testverfahren (black box)

  2. Strukturorientierte Testverfahren (white box)

1. Funktionsorientierte Tests betrachten das Testobjekt von außen, ohne sich um die interne Struktur zu kümmern.

2. Es wird überprüft, ob die Ausgabedaten mit den erwarteten Ergebnissen übereinstimmen, die das System liefern soll.

3. Beispiel: Ein Test für eine Funktion, die den größeren Wert aus zwei Zahlen zurückgibt.

4. Wird auch als „black box“ bezeichnet, weil das Innenleben des Testobjekts keine Rolle spielt.

• Unsystematische Tests führen oft zu Fehlinterpretationen und unvollständigen Ergebnissen.

• Ein Beispiel aus der Praxis: Wenn ein Tester Eingabedaten nicht dokumentiert, kann er keine reproduzierbaren Ergebnisse liefern.

1. Testfälle beschreiben spezifische Eingaben und die erwarteten Ausgaben.

2. Sie sind notwendig, um die Funktionsweise und die Fehleranfälligkeit des Systems gezielt zu testen.

3. Testfälle sollten auch ungültige Eingaben und Grenzwerte abdecken, um Fehler unter verschiedenen Bedingungen zu entdecken.

Sie erkennen hauptsächlich syntaktische Fehler, können aber keine inhaltlichen (semantischen) Fehler finden. Eine manuelle oder dynamische Prüfung ist nötig.

Verfahren, bei denen Software-Tools Quelltexte nach vordefinierten Regeln analysieren, z. B. Programmcode-Analysatoren.

: Typische Programmierfehler wie:

• Nicht initialisierte oder ungenutzte Variablen

• Falsche Einrückungen im Code

Eine unstrukturierte Prüfung, bei der der Autor das Dokument präsentiert und Gutachter Fragen stellen. Fehlerkorrekturen liegen allein beim Autor.

✅ Einfach durchführbar, nützlich für kleine Projekte.

❌ Zeitaufwendig, hohe Fehleranfälligkeit durch Konzentrationsverlust.

• Inspektion: Strukturierte Prüfung durch ein Team nach festgelegten Regeln.

• Review: Ähnlich wie Inspektion, aber weniger formal, ohne feste Vorgehensweise.

• Walkthrough: Der Autor präsentiert das Dokument, Gutachter geben direkt Feedback.

• Schreibtischtest: Prüfer geht Quelltext Zeile für Zeile durch.

1. Freigabe durch den Autor.

2. Eingangsprüfung durch den Moderator.

3. Einführungsveranstaltung für Gutachter.

4. Individuelle Prüfung durch Gutachter.

5. Gemeinsame Sitzung zur Besprechung der Ergebnisse.

6. Entscheidung: Freigabe oder Überarbeitung.

Eine Inspektion folgt festen Regeln und hat einen strukturierten Ablauf mit offizieller Freigabe. Eine Review ist weniger formal, ohne feste Vorgehensweise und ohne offizielle Freigabe.

Das Finden von Fehlern, nicht der Nachweis der Fehlerfreiheit.

1. Verifikation prüft, ob die Software korrekt umgesetzt wurde.

2. Validierung stellt sicher, dass die Software den Nutzeranforderungen entspricht.

1. Warum wird der Test durchgeführt?

2. Was wird getestet?

3. Wie und womit wird getestet?

4. Wer führt den Test durch?

5. Wann beginnt und endet der Test?

6. Wann gilt der Test als erfolgreich?

Qualitätssicherung umfasst nicht nur den Code, sondern auch Benutzerfreundlichkeit, Effizienz und Zuverlässigkeit der Software.

Aufgrund der hohen Komplexität von Software gibt es unendlich viele mögliche Abläufe, die nicht alle getestet werden können.

Weil er von der Korrektheit seiner Arbeit überzeugt ist und Fehler daher oft nicht erkennt. Externe Prüfer sind notwendig.

1. Komponententest – Test einzelner Software-Komponenten.

2. Teilsystemtest – Prüfung eines bestimmten Teilsystems.

3. Integrationstest – Überprüfung des Zusammenspiels aller Komponenten.

4. Abnahmetest – Test durch den Kunden zur finalen Freigabe.

Die Qualitätsprüfung identifiziert Fehler in Produkten, um deren Qualität zu verbessern. Ein gezieltes Suchen nach Fehlern führt zu besseren Ergebnissen als nur die Überprüfung auf Fehlerfreiheit.

Entwickler sind konstruktiv und glauben an die Korrektheit ihres Produkts. Prüfer müssen hingegen destruktiv denken und gezielt nach Fehlern suchen.

Der Glaube, dass ein Produkt Fehler hat, führt dazu, dass diese gefunden werden. Entwickler gehen oft von der Korrektheit ihrer Arbeit aus und übersehen daher Fehler.

Sie dient nicht dem Aufbau, sondern dem gezielten Suchen und Finden von Fehlern.

1. Komponententests – Test einzelner Module oder Klassen

2. Teilsystemtests – Test bestimmter Software-Teilsysteme

3. Integrationstests – Test des Zusammenspiels aller Komponenten

4. Abnahmetests – Prüfung durch den Kunden

Sie helfen, typische Fehler durch geeignete Methoden und Werkzeuge von vornherein zu vermeiden.

• Entwickler sind oft überzeugt, dass ihr Produkt fehlerfrei ist.

• Eine unabhängige Prüfung ist objektiver und deckt mehr Fehler auf.

Fehler, die früh erkannt werden, sind leichter und kostengünstiger zu beheben. Ohne kontinuierliche Prüfung können sich Fehler durch das gesamte Projekt ziehen.

Es beschreibt vier Faktoren der Software-Entwicklung: Qualität, Quantität, Dauer und Kosten. Änderungen an einem Faktor beeinflussen automatisch einen anderen.

1. ROFOC (Rate of Failure Occurrence): Quote des Fehlervorkommens

2. MTBF (Mean Time Between Failures): Mittlere Zeit zwischen Fehlern

ber 80 % der Fehler entstehen in frühen Phasen (Analyse & Entwurf), nicht in der Codierung.

1. Qualitätsziele müssen vorher eindeutig und möglichst messbar festgelegt werden.

2. Qualität muss kontinuierlich geprüft werden.

3. Qualitätssicherung muss konstruktive Maßnahmen enthalten.

4. Qualität sollte von unabhängigen Dritten geprüft werden.

Messbare Qualitätsziele ermöglichen eine objektive Prüfung der Qualität, was insbesondere in der Software-Entwicklung schwierig sein kann (z. B. Benutzerfreundlichkeit).

Qualitätssicherung überprüft, ob die festgelegten Qualitätsmerkmale eines Produkts oder einer Leistung erreicht wurden. Falls nicht, werden Maßnahmen zur Verbesserung der Qualität ergriffen.

Ohne strukturierte Qualitätssicherung entstehen oft Fehler, da Qualität nicht automatisch durch gute Absichten erreicht wird.

Die Reaktion eines Programms auf bestimmte Eingaben oder Ereignisse, z. B. Mausklicks oder Tastatureingaben.

Es gibt keine feste Regel, aber Kommentare sollten sparsam und gezielt eingesetzt werden.

1. Gut strukturierte Einrückungen.

2. Sinnvolle Variablennamen.

3. Logische Trennung von Codeblöcken durch Leerzeilen.

Gut formatierter Code ist leichter zu lesen, zu verstehen und zu warten.

1. Sequenz: Anweisungen werden der Reihe nach ausgeführt.

2. Selektion: Bestimmte Anweisungen werden je nach Bedingung ausgeführt (if-else).

3. Iteration: Anweisungen werden wiederholt ausgeführt (Schleifen).

Damit der Code auf dem Monitor und beim Ausdruck übersichtlich bleibt.

Sie erschwert das Verständnis des Codes. Eine switch-case-Struktur ist oft besser lesbar.

1. Schlüsselwörter farblich hervorheben.

2. Maximal 80 Zeichen pro Zeile verwenden.

3. Wenig Schachtelung bei Bedingungen und Schleifen.

Kurze Namen wie „x“ oder „y“ sagen nichts über ihre Bedeutung aus. Aussagekräftige Namen helfen, den Code schneller zu verstehen.

Standardnamen wie „textbox1“ sind wenig aussagekräftig und erschweren die Übersicht in größeren Programmen.

Sie können den Datentyp angeben, z. B. „i“ für Integer oder „c“ für char.

1. Jede Anweisung in eine eigene Zeile schreiben.

2. Einrückungen für bessere Strukturierung nutzen.

3. Klare Abstände zwischen logischen Einheiten einhalten.

Durch Doppelklick auf ein Element im Formular; Visual Studio generiert dann den Methodenrumpf.

Durch vordefinierte Schnittstellen (Datenquellen), die mit einem Assistenten in das Programm eingefügt werden.

Sie erleichtern das Verständnis des Codes, indem sie Abläufe und Besonderheiten erläutern.

Wenn der Quelltext geändert wird, müssen auch die Kommentare aktualisiert werden. Vergessene oder falsche Kommentare können Verwirrung stiften.

ommentare sollen gezielt für komplexe oder unerwartete Anweisungen eingesetzt werden, aber nicht jede einzelne Zeile erklären.

Weil sich viele Anweisungen selbst erklären. Überflüssige Kommentare blähen den Code auf und erschweren die Wartung.

Wenn der Code geändert wird, müssen auch die Kommentare aktualisiert werden. Falsche oder veraltete Kommentare können zu Verwirrung führen.

Kommentare sollten gezielt für komplexe oder ungewöhnliche Anweisungen sowie für größere Codeblöcke und Methodenbeschreibungen genutzt werden.

Eine Beschreibung der Methode, ihre Wirkung, erwartete Argumente und die Rückgabe.

Sie machen den Code auch ohne Kommentare verständlich und erleichtern das Lesen und Verstehen.

1. Schleifen mit Bedingungsprüfung vor der Ausführung

2. Schleifen mit Bedingungsprüfung nach der Ausführung

3. Schleifen mit fester Wiederholungsanzahl

Programme reagieren auf externe Ereignisse wie Mausklicks oder Tasteneingaben, anstatt Befehle in einer festen Reihenfolge abzuarbeiten.

Die automatische Generierung von Klassendefinitionen und teilweise Methoden aus Diagrammen, um Entwicklungszeit zu sparen.

Sie liefert meist nur ein Gerüst; die eigentliche Funktionalität muss manuell ergänzt werden.

Klassendefinitionen, Attribute und Methodengerüste.

Durch das Platzieren von Bedienelementen (z. B. Schaltflächen) auf einem Formular mithilfe der Maus.

Die Umsetzung der Entwurfsergebnisse in ein ablauffähiges Programm.

Sie hat an Bedeutung verloren, da viele Strukturen bereits durch Analyse und Entwurf festgelegt werden und teilweise automatisiert generiert werden können.

Programmiersprachen dienen dazu, Anweisungen für die Lösung eines Problems in eine für den Computer verständliche Form zu bringen.

C++, Java, C# und Visual Basic.

Sie müssen zuerst in ein für den Computer verständliches Format übersetzt werden, oft durch einen Compiler.

Es bedeutet „zusammentragen“ und bezeichnet die Übersetzung von Quelltext in ausführbaren Code.

1. Die Folge (Sequenz)

2. Die Auswahl (Verzweigungen)

3. Die Wiederholung (Schleifen)

Eine Auswahlstruktur erlaubt die bedingte Ausführung von Anweisungen, z. B. durch einfache, alternative oder Mehrfachverzweigungen.

Ein Attribut oder eine Attributkombination, die einen Datensatz eindeutig identifiziert (z. B. Kundennummer).

Ein Fremdschlüssel stellt eine Verbindung zwischen zwei Tabellen her, indem er auf den Primärschlüssel einer anderen Tabelle verweist.

Durch Fremdschlüssel, die auf den Primärschlüssel einer anderen Tabelle verweisen.

• Kunde (Kundennummer, Name, Adresse, Telefon)

• Vertrag (Vertragsnummer, Ausleihdatum, Rückgabedatum, Kundennummer als Fremdschlüssel)

• Medium (Mediennummer, Titel, Typ, Standort)

• Reservierung (Reservierungsnummer, Gültigkeit, Medien- und Kundennummer als Fremdschlüssel)

Weil er dort mehrfach vorkommen kann (z. B. wenn ein Kunde mehrere Verträge hat). In dieser Tabelle wird er stattdessen als Fremdschlüssel genutzt.

Nein, ein Datenbankmodelldiagramm ist eine eigene Darstellung zur Strukturierung von Tabellen und Beziehungen.

DBMS ermöglichen eine strukturierte Speicherung von Daten und erlauben schnellen, direkten Zugriff auf Informationen.

Ein Modell, das Daten in Tabellenform speichert. Diese Tabellen nennt man Relationen.

1. Spalten (Attribute): Beschreiben die Eigenschaften der Daten (z. B. Name, Vorname, Straße).

2. Zeilen (Tupel): Enthalten die Werte der Attribute und repräsentieren einen vollständigen Datensatz.

1. Unstrukturierte Speicherung in einer Datei

2. Strukturierte Speicherung in einer Datenbank

✅ Vorteil: Sehr flexibel, da beliebige Informationen in nahezu beliebiger Größe gespeichert werden können.

❌ Nachteil: Umständlicher Zugriff auf einzelne Informationen, da die gesamte Datei durchsucht werden muss.

Entwurfsmuster sind wiederverwendbare Lösungen für häufig auftretende Probleme in der Software-Entwicklung.

Durch eine 1..*-Assoziation, die zeigt, dass ein Vertrag mit mehreren Medien verbunden sein kann.

1. public (+) → für alle sichtbar

2. private (-) → nur für die Klasse sichtbar

3. protected (#) → für die Klasse und Unterklassen sichtbar

4. package (~) → innerhalb des gleichen Pakets sichtbar

Multiplizitäten geben an, wie viele Instanzen einer Klasse mit einer anderen Klasse in Beziehung stehen können (z. B. 1..5, 0..*).

"Pattern" ist ein anderes Wort für Entwurfsmuster und beschreibt bewährte Lösungsansätze für häufige Software-Probleme.

Wenn sie nur innerhalb der eigenen Klasse genutzt wird.

Eine Generalisierung wird durch einen Pfeil mit einer geschlossenen Spitze dargestellt, der zur übergeordneten Klasse weist.

Eine Aggregation beschreibt, dass eine Klasse in einer anderen enthalten ist, aber auch eigenständig existieren kann. Sie wird durch eine nicht ausgefüllte Raute dargestellt.

Eine Komposition ist eine strengere Form der Aggregation, bei der eine Klasse nur existiert, wenn die übergeordnete Klasse existiert. Sie wird durch eine ausgefüllte Raute dargestellt.

Bei einer Aggregation können die beteiligten Klassen auch unabhängig existieren. Bei einer Komposition hängt die Existenz der enthaltenen Klasse von der übergeordneten Klasse ab.

Die Methode wird folgendermaßen dargestellt:+ suchen(Nr: Integer): RückgabetypDas + steht für öffentliche Sichtbarkeit.

Durch = Wert nach der Typangabe, z. B. sucheKunde(kNr: Integer = 0).

private (-), um direkten Zugriff von außen zu verhindern.

Durch : Typ nach den runden Klammern, z. B. sucheKunde(kNr: Integer): Boolean.

private (-), public (+), protected (#), package (~).

Es werden Methoden präzisiert, Sichtbarkeiten von Attributen und Methoden festgelegt sowie Klassenbeziehungen genauer untersucht.

Methoden werden im unteren Teil des Rechtecks einer Klasse aufgeführt und durch runde Klammern () von Attributen unterschieden.

Dadurch können Methoden flexibler und einfacher genutzt werden, indem sie mit Daten „gefüttert“ werden.

In runden Klammern hinter dem Methodennamen in der Form name: typ.

Die Deklaration legt fest, welche Argumente verarbeitet werden können, der Aufruf übergibt konkrete Werte.

Mit einem Rechteck, das oben rechts das Symbol «component» trägt.

Die Verteilung der Software-Komponenten auf verschiedene Rechner.

1. Zentrale Datenhaltung sichert eine einheitliche Datenbasis.

2. Änderungen an der Applikationsschicht müssen nur am Server durchgeführt werden.

1. Entfernte Datenhaltung

2. Entfernte Präsentation

3. Dreistufiges Konzept

4. Mehrstufiges kooperatives Client-Server-Computing

Daten sind zentral verfügbar, und Änderungen an der Applikation müssen nur am Server vorgenommen werden.

• Dicker Client: Führt Präsentations- und Applikationsschicht lokal aus.

• Dünner Client: Führt nur die Präsentationsschicht aus und nutzt Server für Berechnungen.

Präsentationsschicht, Applikationsschicht, Datenhaltungsschicht

Damit alle Nutzer mit denselben aktuellen Daten arbeiten und Dateninkonsistenzen vermieden werden.

Pakete werden durch ein Rechteck mit einem kleineren Rechteck in der oberen linken Ecke dargestellt.

Durch gestrichelte Linien mit Pfeilspitzen, die auf das abhängige Paket zeigen.

Eine Abhängigkeit bedeutet, dass Änderungen an einem Paket möglicherweise Änderungen an einem anderen Paket erfordern.

Große Software-Systeme werden in Teilsysteme zerlegt, um die Übersichtlichkeit zu verbessern, Verantwortlichkeiten klar zu definieren und parallele Entwicklung durch verschiedene Teams zu ermöglichen.

Pakete sind Teilsysteme eines Software-Systems, die eng zusammenarbeiten und eine logische oder funktionale Einheit bilden.

Klassendiagramme helfen dabei, funktional zusammenhängende Klassen zu identifizieren, die in gemeinsamen Paketen gebündelt werden können.

Man fasst thematisch verwandte Klassen in Pakete zusammen, z. B. die Klassen „Vertrag“ und „Reservierung“ in einem Paket „Verträge“.

Eine paketübergreifende Assoziation liegt vor, wenn eine Klasse aus einem Paket eine Beziehung zu einer Klasse in einem anderen Paket hat.

1. Entwicklerperspektive: Pakete wie „Verträge“, „Kunden“ und „Medien“.

2. Anwenderperspektive: Pakete wie „Verwaltung“, „Ausleihe“ und „Rückgabe“.

3. Prioritätsbasierte Sichtweise: Pakete für Kernfunktionen, Zusatzfunktionen und Komfortfunktionen.

Untergeordnete Pakete können in übergeordnete Pakete integriert oder durch Verbindungslinien dargestellt werden.

Das Entwurfsmodell beantwortet die Frage „Wie?“ und liefert eine detaillierte Beschreibung der technischen Umsetzung der Software.

Die Methoden der Klassen werden präzisiert, die Sichtbarkeiten der Attribute und Methoden festgelegt und die Klassenbeziehungen genauer untersucht.

Methoden stehen im unteren Bereich einer Klasse und werden durch runde Klammern () hinter dem Methodennamen von Attributen unterschieden.

Ein Argument wird innerhalb der runden Klammern als name: typ angegeben, z. B. sucheKunde(kNr: Integer).

Parameter werden in der Methodendeklaration definiert, während Argumente konkrete Werte sind, die beim Aufruf übergeben werden.

Der Rückgabetyp steht hinter den runden Klammern und wird durch einen Doppelpunkt getrennt, z. B. sucheKunde(kNr: Integer): Boolean.

1. private (-): Nur innerhalb der Klasse sichtbar

2. public (+): Für alle sichtbar

3. protected (#): Für die Klasse und Unterklassen sichtbar

4. package (~): Für Klassen innerhalb desselben Pakets sichtbar

Damit Datenkapselung gewährleistet ist. Attribute sollten nur über Methoden geändert oder gelesen werden.

: Eine Methode, bei der ein Standardwert für ein Argument definiert ist, z. B. sucheKunde(kNr: Integer = 0).

Durch eine Methode setzeAusgeliehen(status: Boolean), die den Wert des Attributs ausgeliehen setzt.

Sie ermittelt die letzte vergebene Mediennummer und erhöht sie um 1 für das nächste Medium.

Attribute werden automatisch auf private, Methoden auf public gesetzt.

Eine Assoziation ist eine Beziehung zwischen Klassen oder Objekten.

Die Multiplizität wird an den Enden der Assoziationslinie notiert und gibt an, wie viele Objekte einer Klasse mit Objekten einer anderen Klasse verbunden sein können.

Ein Objekt der ersten Klasse kann mit mindestens einem und beliebig vielen Objekten der zweiten Klasse in Beziehung stehen.

1. Generalisierung (Vererbung)

2. Aggregation (schwache Ganzes-Teil-Beziehung)

3. Komposition (starke Ganzes-Teil-Beziehung)

Durch einen Pfeil mit einem nicht ausgefüllten Dreieck, das zur übergeordneten Klasse zeigt.

• Aggregation: Die enthaltene Klasse kann auch unabhängig existieren.

• Komposition: Die enthaltene Klasse kann nur existieren, wenn die übergeordnete Klasse existiert.

• Aggregation: Nicht ausgefüllte Raute

• Komposition: Ausgefüllte Raute

Wiederverwendbare Lösungsansätze für häufig auftretende Probleme in der Softwareentwicklung.

Sie ermöglichen eine effiziente und bewährte Lösung für wiederkehrende Probleme, ohne das Rad neu erfinden zu müssen.

• Analysemodell: Beantwortet die Frage „Was?“ und stellt das System aus Sicht des Anwenders dar.

• Entwurfsmodell: Beantwortet die Frage „Wie?“ und beschreibt das System aus Sicht des Entwicklers unter technischen Gesichtspunkten.

• Umsetzung der Klassen mit Attributen und Methoden

• Notwendige zusätzliche Methoden

• Zerlegung des Systems in Teilsysteme

• Verteilung des Systems auf mehrere Rechner

• Speicherung der Anwendungsdaten

1. Schutz der Daten vor unbefugtem Zugriff (z. B. Benutzeranmeldung)

2. Schutz gegen Datenverlust (z. B. automatische Backups)

3. Anforderungen an die Ausführungsgeschwindigkeit

4. Anforderungen an die Ausfallsicherheit (z. B. redundanter Aufbau)

Ein detaillierter Bauplan für die Software – die Software-Architektur.

Das Pflichtenheft liefert die Grundlage für das Entwurfsmodell. Beispielsweise werden Klassendiagramme übernommen und um technische Details erweitert.

Prototypen der grafischen Oberfläche werden in der Regel von den Anwendern sehr viel leichter verstanden als UML-Diagramme und sprachliche Beschreibungen.

Die Reihenfolge der Elemente ist sehr ungewöhnlich. Damit wird gegen die Erwartungshaltung des Anwenders verstoßen. Er geht davon aus, dass die Statusleiste unten im Fenster angezeigt wird.

Hier eignen sich Optionsfelder. Sie geben mehrere Möglichkeiten vor, erlauben aber nur die Auswahl einer Möglichkeit gleichzeitig

Nein, ein Schieberegler eignet sich nicht. Er hat einen minimalen sowie einen maximalen Wert und erlaubt auch nur die Auswahl auf einer festen Skala. Optimal für eine freie Eingabe ist ein Eingabefeld geeignet.

Eine Menüleiste enthält Befehle in einer Liste, die erst nach einem Klick sichtbar wird. Eine Symbolleiste zeigt ständig Symbole für häufig genutzte Funktionen an.

: Dialogfenster dienen zur Eingabe von Informationen oder zur Auswahl von Einstellungen. Beispiele sind Speichern- und Druckdialoge.

1. Schaltfläche – Startet eine Aktion per Klick.

2. Eingabefeld – Ermöglicht die Eingabe von Daten.

3. Listenfeld – Zeigt eine Liste mit auswählbaren Werten.

4. Optionsfelder – Erlauben eine einzige Auswahl aus mehreren Optionen.

5. Kontrollkästchen – Erlauben das Aktivieren mehrerer Optionen.

Ein GUI-Generator ist ein Werkzeug zur Erstellung von grafischen Benutzeroberflächen. Er erlaubt das Einfügen und Anordnen von Elementen per Maus und kann Prototypen direkt ausführbar machen.

• Einfaches Erstellen von Prototypen ohne Programmieraufwand

• Intuitive Gestaltung der Benutzeroberfläche

• Wiederverwendbarkeit des Designs für die spätere Programmierung

Ein Prototyp sollte die wichtigsten Bedienelemente und Eingabefelder enthalten, aber keine echte Funktionalität implementieren.

Die Oberfläche sollte sich an die Gestaltungsmerkmale des Betriebssystems anpassen, um die Erwartungen der Nutzer zu erfüllen und eine intuitive Bedienung zu ermöglichen.

Software-Ergonomie befasst sich mit der Anpassung von Software an den Menschen, um die Nutzung möglichst einfach und effizient zu gestalten.

Titelleiste (enthält Name der Anwendung und Steuerungssymbole)

• Menüband (Befehle und Funktionen nach Gruppen geordnet)

• Statusleiste (zeigt Zusatzinformationen, z. B. Fehlermeldungen)

Es basiert auf dem Analysemodell bzw. dem Pflichtenheft, das durch technische Details erweitert wird (z. B. Klassendiagramme).

Durch Klassendiagramme, die um technische Details ergänzt werden.

Grafische Prototypen helfen Anwendern, sich eine konkrete Vorstellung von einer Anwendung zu machen, da UML-Diagramme und abstrakte Beschreibungen oft schwer verständlich sind.

1. Schutz der Daten vor unbefugtem Zugriff

2. Maßnahmen gegen Datenverlust (z. B. automatische Backups)

3. Einhaltung von Antwortzeiten für Performance

4. Ausfallsicherheit durch Redundanz

Ein detaillierter Bauplan für die Anwendung, also die Software-Architektur.

Das Analysemodell beschreibt das System aus Sicht des Anwenders und liefert die Antwort auf die Frage „Was?“.

Das Entwurfsmodell beschreibt das System aus Sicht des Entwicklers und liefert die Antwort auf die Frage „Wie?“.

1. Umsetzung der Klassen mit Attributen und Methoden

2. Zusätzliche Methoden für die Umsetzung

3. Zerlegung des Systems in Teilsysteme

4. Verteilung auf mehrere Rechner

5. Speicherung der Anwendungsdaten

Das Entwurfsmodell bildet ein System aus technischer Sicht ab

Als Ergebnis liefert das Entwurfsmodell einen detaillierten Bauplan der Software – die Software-Architektur.

Die Fragen sind:

1. „Was?“ – Beantwortet durch das Analysemodell (Sicht des Anwenders).

2. „Wie?“ – Beantwortet durch das Entwurfsmodell (Sicht des Entwicklers).

Hier eignen sich Optionsfelder. Sie geben mehrere Möglichkeiten vor, erlauben aber nur die Auswahl einer Möglichkeit gleichzeitig.

Nein, ein Schieberegler eignet sich nicht. Er hat einen minimalen sowie einen maximalen Wert und erlaubt auch nur die Auswahl auf einer festen Skala. Optimal für eine freie Eingabe ist ein Eingabefeld geeignet.

Ein GUI-Generator ist ein Werkzeug zum Erstellen grafischer Oberflächen mit der Maus. Vorteile:

• Erleichtert die Erstellung von Prototypen.

• Prototypen können für die spätere Kodierung wiederverwendet werden.

Prototypen der grafischen Oberfläche werden in der Regel von den Anwendern sehr viel leichter verstanden als UML-Diagramme und sprachliche Beschreibungen.

Die Reihenfolge der Elemente ist sehr ungewöhnlich. Damit wird gegen die Erwartungshaltung des Anwenders verstoßen. Er geht davon aus, dass die Statusleiste unten im Fenster angezeigt wird.

1. Titelleiste (enthält Systemmenü, Dokument- und Anwendungsname, Steuerungssymbole)

2. Menüband (Registerkarten mit Befehlen)

3. Statusleiste (zeigt zusätzliche Informationen oder Fehlermeldungen)

1. Menüband: Enthält Registerkarten mit Befehlen, die erst nach Auswahl angezeigt werden.

2. Symbolleiste: Zeigt Symbole für häufig verwendete Funktionen dauerhaft an.

1. Anwendungsfenster: Zeigen die Hauptinhalte der Anwendung.

2. Dialogfenster: Ermöglichen Nutzereingaben oder Einstellungen (z. B. Speichern-Dialog).

1. Schaltflächen: Starten Aktionen.

2. Eingabefelder: Ermöglichen die Eingabe von Daten.

3. Kombinationsfelder: Lassen Nutzer aus einer Liste wählen.

4. Listenfelder: Zeigen mehrere auswählbare Einträge.

5. Drehfelder: Verändern Werte schrittweise.

6. Optionsfelder: Erlauben die Auswahl von genau einer Option.

7. Kontrollkästchen: Erlauben die Auswahl mehrerer Optionen.

8. Schieberegler: Stellen Werte auf einer Skala ein.

✔️ Zur Verfeinerung von Prozessen mit mehreren Schritten

✔️ Wenn die Reihenfolge von Aktionen wichtig ist

✔️ Um Bedingungen und Entscheidungen in Prozessen darzustellen

✔️ Besonders nützlich für komplexe Abläufe

Weil sie es Laien erleichtern, sich die Anwendung vorzustellen, und die wichtigsten Anwendungsfälle visuell darstellen.

➡️ Ein UML-Diagramm zur Darstellung von Aktivitäten in einem Prozess.

➡️ Zeigt die Reihenfolge von Aktionen durch Pfeile.

➡️ Aktionen werden durch Rechtecke mit abgerundeten Ecken dargestellt.

Es handelt sich um ein Objektdiagramm. Bei einem Klassendiagramm würde der Name fett und nicht unterstrichen dargestellt.

Es gibt drei wesentliche Techniken: • Übernahme aus den Produktdaten im Lastenheft,

• Dokumentanalyse und

• Analyse der Produktbeschreibung.

Eine Assoziation ist eine Beziehung zwischen Klassen

Nein, ein Objektdiagramm muss nicht in jedem Fall erstellt werden.

Im ersten groben Klassendiagramm werden nur die Attribute dargestellt.

Ein konzeptuelles Datenmodell beschreibt die Daten, die ein System verarbeiten soll, und deren Beziehungen zueinander – ohne sich um die konkrete Speicherung (z. B. in einem Datenbanksystem) zu kümmern.

1. Ermittlung von Objekt-/Klassenkandidaten

2. Bestimmung der Beziehungen (Assoziationen) zwischen den Klassen

3. Festlegung der Attribute der Klassen

4. Darstellung in UML-Diagrammen (z. B. Klassendiagramm)

1. Konkrete Gegenstände (z. B. ein Buch)

2. Abstrakte Begriffe (z. B. Adresse)

3. Personen und Rollen (z. B. Kunde, Mitarbeiter)

4. Schriftliche Dokumente (z. B. Verträge)

5. Ereignisse (z. B. ein Unfall)

6. Transaktionen (z. B. Bezahlung)

1. Kunde

2. Medium

3. Vertrag

4. Reservierung

Die Dokumentanalyse hilft, relevante Klassenkandidaten und deren Attribute zu identifizieren, indem man bestehende Dokumente (z. B. alte Leihverträge) genau analysiert, um festzuhalten, welche Daten verarbeitet werden müssen.

Durch Markierung der Substantive in der Produktbeschreibung erhält man eine erste Liste von Klassenkandidaten und Hinweisen auf mögliche Attribute, die anschließend durch Zusammenstreichen und Sortieren verfeinert wird.

Im ersten groben statischen Modell konzentriert man sich ausschließlich auf die Erfassung der Daten (Attribute) und deren Beziehungen. Die Methoden werden zu einem späteren Zeitpunkt ergänzt.

1. Nummer

2. Titel

3. Typ (zur Unterscheidung des Medientyps)

4. Standort (Position in der Bücherei)

5. ausgeliehen (Status, ob gerade verliehen)

6. Präsenzbestand (ob es überhaupt ausgeliehen werden kann)

1. Klassen: Werden als Substantive im Singular benannt; erster Buchstabe wird groß geschrieben.

2. Attribute: Werden meist als Substantive oder Adjektive benannt; erster Buchstabe klein, und bei zusammengesetzten Namen wird die Großschreibung zur Trennung genutzt (CamelCase).

Ein Objektdiagramm zeigt konkrete Instanzen (Objekte) und deren aktuelle Attributwerte – es ist eine Momentaufnahme der realen Objekte, während das Klassendiagramm die abstrakte Struktur (Klassen, Attribute, Beziehungen) des Systems darstellt.

1. Ist eine Klasse Bestandteil einer anderen Klasse?

2. Benutzt eine Klasse eine andere Klasse?

3. Verweist eine Klasse auf eine andere Klasse?

4. Besitzt eine Klasse eine andere?

5. Kommuniziert eine Klasse mit einer anderen?

Der Medientyp wird als Attribut (z. B. „Typ“) in der Klasse Medium erfasst, sodass alle Medientypen in einer einzigen Klasse zusammengefasst werden.

Das konzeptionelle Datenmodell beschreibt die Daten, die ein System verarbeiten soll, und ihre Beziehung untereinander.

• Klassendiagramm: Zeigt abstrakte Klassen mit Attributen und Beziehungen.

• Objektdiagramm: Zeigt konkrete Objekte mit spezifischen Attributwerten.

• Analyse vorhandener Formulare und Dokumente (z. B. Leihverträge).

• Analyse der Produktbeschreibung durch Markierung relevanter Substantive.

1. Ein Kunde hat einen Leihvertrag.

2. Ein Leihvertrag verweist auf mindestens ein Medium.

3. Ein Kunde kann eine Reservierung vornehmen.

4. Eine Reservierung verweist auf mindestens ein Medium.