Hier ist die korrigierte Version des Textes: --- Ausblick Software Engineering fasst systematisch Konzepte zur erfolgreichen Realisierung langfristig erfolgreicher Software-Projekte zusammen. Dabei haben individuelle Projektvorgaben großen Einfluss darauf, welche Werkzeuge des Software Engineerings wie und in welchem Umfang sinnvoll eingesetzt werden können. Dabei ist es durchaus möglich, dass es für spezielle Aufgaben sehr einfache Lösungen geben kann, die aber in anderen Bereichen schnell versagen. In diesem Kapitel werden verschiedene Einflussfaktoren untersucht, die die Herangehensweise im Software Engineering potenziell verändern können. Es wird gezeigt, dass dies oft Ergänzungen sind und teilweise neu propagierte Ideen bereits in anderen Formen existieren. Dabei wird auch die Nutzung von künstlicher Intelligenz diskutiert. Veränderung der Infrastruktur Klassische Software-Systeme haben eine Zielplattform, das können typische Arbeits-PCs aber auch Großrechner sein. Mit dem Internet kamen Client-Server-Systeme in den Fokus, bei denen die Nutzungsoberfläche im Browser und die eigentliche Ausführung auf dem Server stattfindet. Bereits hier gibt es sehr unterschiedliche Konzepte, bei denen der Client z. B. nur für Ein- und Ausgaben genutzt wird (Thin Client) oder der Client sich relevante Daten vom Server lädt, einen Großteil der Berechnungen durchführt und nur zentrale Ergebnisse an den Server meldet (Fat Client). Bereits hier sind Mischformen denkbar, bei denen der Client eine größere Menge von Aufgaben erledigt. Die Auswahl der passenden Technologie hängt von einigen Einflussfaktoren ab, wie z. B. wie häufig ein Datenaustausch zwischen Client und Server benötigt wird, um die Gesamtkonsistenz des Systems zu sichern und der Flexibilität, die durch einfache Veränderungen des Clients gegeben ist. Auch die ausgewählte Software-Technologie spielt eine Rolle, wobei die klassischen Fragen nach Performance, Wart- und Erweiterbarkeit und Bedienbarkeit relevant sind. Technische Entscheidungen für individuelle Projekte können schon sehr aufwendig sein, die sind aber immer in einem größeren Gesamtkontext zu bearbeiten. Zur Unterstützung von unterschiedlichen vernetzten Geschäftsprozessen wird möglichst eine einheitlich bedienbare Software benötigt. Ist die nicht möglich, kommt die einfache Integrierbarkeit einzelner Software-Teilsysteme ins Spiel, bei der effizienter, einfacher und sicherer Datenaustausch im Mittelpunkt steht. Gerade wenn neue Software entwickelt, aber auch wenn sie eingekauft wird, haben diese dahinterliegenden strategischen Fragestellungen große Auswirkungen auf zukünftige Entwicklungen. Durch die steigende Anzahl an Umsetzungsmöglichkeiten wird die Auswahl einer Software-Architektur zusammen mit einer passenden IT-Infrastruktur immer komplexer. Zur Veranschaulichung zeigt Abb. leicht vereinfacht unterschiedliche Ansätze für Infrastrukturen. --- Übersicht über die gemachten Korrekturen: 1. "Lösungewn" -> "Lösungen" 2. "andreren" -> "anderen" 3. "IKn" -> "In" 4. "dike" -> "die" 5. "Heranghehendweidse" -> "Herangehensweise" 6. "verändewrn" -> "verändern" 7. "die können typische Arbeits-PC" -> "das können typische Arbeits-PCs" 8. "Browswer" -> "Browser" 9. "gewnutzut witd" -> "genutzt wird" 10. "zentraler" -> "zentrale" 11. "größere Mengen" -> "größere Menge" 12. "abne" -> "ab" 13. "wie häufig ein Datenaustausch zwischen Client- und Server benötigt wird" -> "wie häufig ein Datenaustausch zwischen Client und Server benötigt wird" 14. "Flexibiltät" -> "Flexibilität" 15. "ausgewqählte" -> "ausgewählte" 16. "Software-Architekktur" -> "Software-Architektur" 17. "veranschaulichung" -> "Veranschaulichung" 18. "Software-Teilsysteme" -> "Software-Teilsysteme" 19. "stragischen" -> "strategischen"

Serverless Applikationen sind eine Art von Cloud Computing Modell, bei dem der Cloud-Anbieter die Infrastruktur und die Serververwaltung komplett übernimmt, sodass Entwickler sich rein auf das Schreiben und Deployen von Code konzentrieren können. Diese Anwendungen werden auf Basis von Funktionen (sogenannten "Serverless Functions" oder "Function-as-a-Service", FaaS) ausgeführt, die nur dann aktiv sind, wenn sie benötigt werden, und für die konkrete Ausführungszeit abgerechnet werden. Hier sind einige Merkmale und Vorteile von serverless Applikationen:

Merkmale

1. Keine Serververwaltung: Entwickler müssen sich nicht um die Konfiguration, Wartung oder Skalierung der Server kümmern. Der Cloud-Anbieter regelt dies automatisch. 2. Automatische Skalierung: Ressourcen werden automatisch nach Bedarf skaliert, basierend auf der Anzahl der auszuführenden Funktionen. Bei höherer Last werden mehr Ressourcen zugewiesen, und bei geringerer Last werden Ressourcen freigegeben. 3. Ereignisgesteuert: Serverless Funktionen werden durch spezifische Ereignisse ausgelöst, z.B. HTTP-Anfragen, Datenbankänderungen, Nachrichten in einer Warteschlange. 4. Kurzlebigkeit: Funktionen in serverless Umgebungen sind oft kurzlebig und führen spezifische und kleine Aufgaben aus. 5. Kostenmodell: Bezahlt wird nur für die tatsächliche Ausführungszeit der Funktionen und nicht für die durchgehend laufende Infrastruktur.

Vorteile

1. Kostenersparnis: Reduzierung unnötiger Kosten, da nur für die genutzte Rechenzeit gezahlt wird und keine Ressourcen für Leerlaufzeiten bereitgehalten werden müssen. 2. Schnellere Markteinführung: Entwickler können sich auf die Implementierung der Geschäftslogik und neuen Features konzentrieren, anstatt Zeit mit der Serververwaltung zu verbringen. 3. Skalierbarkeit: Anwendungen können problemlos auf verschiedene Lastanforderungen reagieren, ohne manuelle Eingriffe. 4. Zuverlässigkeit: Die Serverinfrastruktur wird vom Cloud-Anbieter verwaltet, der in der Regel hohe Verfügbarkeit und Ausfallsicherheit garantiert.

Beispiele von Anbietern und Diensten

- AWS Lambda: Amazon Web Services bietet diesen Dienst an, der es ermöglicht, Funktionen in verschiedenen Programmiersprachen zu schreiben und zu Deployen. - Google Cloud Functions: Ein ähnlicher Dienst, der von Google Cloud Platform angeboten wird. - Microsoft Azure Functions: Microsofts Lösung für serverless Anwendungen. - IBM Cloud Functions: Ein serverless Dienst, der auf Apache OpenWhisk basiert.

Anwendungsfälle

- Webhooks: Sofortige Bearbeitung von Echtzeit-Ereignisbenachrichtigungen. - API Backend: Bereitstellung von API-Endpunkten ohne die Notwendigkeit eines traditionellen Servers. - Datenverarbeitung: Batch- oder Echtzeit-Datenverarbeitungsaufgaben, wie Log-Analysen oder Datenumwandlungsprozesse. - IoT: Verarbeitung von Datenströmen von IoT-Geräten. - Chatbots: Dynamische und skalierbare Antworten auf Benutzeranfragen. Serverless Applikationen sind besonders attraktiv für Unternehmen und Entwickler, die sich mehr auf die Geschäftslogik und weniger auf die Infrastrukturverwaltung konzentrieren möchten.

Hier ist die korrigierte Version des Textes: --- Bei einem individuellen Ansatz gibt es die größtmöglichen Freiheiten bei der Auswahl der Technologien auf allen Ebenen. Dies führt dazu, dass im Betrieb die Verantwortung für den Server und die Datenhaltung, meist die Datenbank, in der Hand des Unternehmens liegt, das die entwickelte Software nutzt. Dies beinhaltet die Verantwortung für die Performance und Verfügbarkeit im Internet. Beim Übergang zur Infrastructure as a Service (IaaS) wird typischerweise die Verantwortung für die Server an einen Cloud-Dienst übergeben. Dadurch besteht die Möglichkeit, bei steigenden Nutzungszahlen einfach weitere Serverkapazität anzumieten. Weiterhin werden Aktualisierungen von Server-Techniken vom Anbieter übernommen. Die zentralen Nachteile des Ansatzes sind der Verlust der Gesamtkontrolle und damit der Verwaltung der Daten und des damit verbundenen Datenschutzes. Da Anbieter solcher Infrastruktur sehr an der Erreichbarkeit interessiert sind, sollte die Ausfallsicherheit gegenüber individuellen Lösungen sogar verbessert sein. Allerdings zeigen Ereignisse, wie der massenhafte Ausfall kritischer Systeme, z. B. Flughäfen, Kliniken und Fernsehsendern, durch ein gescheitertes Software-Update eines IT-Sicherheitsanbieters am 19.7.2024 [XXX], dass Cloud-basierte Systeme zu Ausfällen mit enormen Auswirkungen führen können. Die Ausfallszenarien bei konzentrierten Hacker-Angriffen sind dabei nicht absehbar. Aus Sicht des Software-Engineerings spielt der IaaS-Ansatz eine Rolle, da dies oft mit dem Einsatz von Microservice-Architekturen verknüpft ist, die auch in lokalen Systemen eingesetzt werden können. Ein Micro-Service bietet dabei eine Funktionalität, typischerweise verknüpft mit eigener Datenhaltung, an, die über Web-Schnittstellen nutzbar ist. Da es sich hierbei um relativ kleine Software-Komponenten handelt, sind diese relativ einfach wart- und erweiterbar. Oftmals können solche Services in unterschiedlichen Systemen eingesetzt werden. Die Services laufen als eigenständige Prozesse oftmals auf virtuellen Rechnern, z. B. Docker-Images [XXX], die von einer Verwaltung, z. B. Kubernetes [XXX], koordiniert werden. Microservices werden mit den bekannten Software-Engineering-Ansätzen entwickelt; dabei müssen aber die speziellen Anforderungen bezüglich der Orientierung an extern angebotene Schnittstellen und die verteilte Datenhaltung besonders beachtet werden. Beim Platform as a Service (PaaS) bietet der Anbieter Laufzeitumgebungen an, deren gesamte Ausführung von der Platform übernommen wird. Dies kann dazu führen, dass automatisch bei erhöhten Nutzungsanfragen mehr Rechenkapazität und Sicherheitsdienste zur Verfügung gestellt werden. Die zur Entwicklung angebotenen Plattformen können sich in der freien Nutzbarkeit unterscheiden. Es können klassische Programmbibliotheken sein, bei denen sich der Entwicklungsweg nicht von der „üblichen“ Entwicklung unterscheidet. Es können Programmierumgebungen sein, die zwar klassische Programmiersprachen unterstützen, aber ein anderes Programmiermodell haben. Beispiele sind serverless Applikationen, bei denen sich Entwickler rein auf das Schreiben und Deployen von Code konzentrieren. Diese Anwendungen werden auf Basis von Funktionen, sogenannten "Serverless Functions" oder "Function-as-a-Service" (FaaS), ausgeführt, die nur dann aktiv sind, wenn sie benötigt werden. Für diese Laufzeiten ist dann der Anbieter zu bezahlen. Beispiele sind AWS Lambda [XXX], Google Cloud Functions [XXX] und Microsoft Azure Functions [XXX]. Im Bereich PaaS gibt es häufig auch den Ansatz von Low-Code oder No-Code-Applikationen. Hier steht im Mittelpunkt, dass möglichst wenig programmiert werden soll, und die Entwicklung sogar durch Experten des Anwendungsbereichs geschehen kann. Konkret vorstellen kann man sich ein Werkzeug zur Modellierung von Geschäftsprozessen, wobei für jede Aktion aus einer größeren Sammlung fachlicher Aktionen ausgewählt werden kann. Diese Bausteine werden dann ähnlich wie in Aktivitätsdiagrammen zu Prozessen koordiniert. Die Koordination geschieht durch Parameter, die neu angelegt und in anderen Aktionen genutzt werden können. Auf der abstrakten Ebene ist erkennbar, dass es sich hier „nur“ um eine weitere Ebene der Programmabstraktion handelt. Es entsteht eine höhere Programmiersprache, die sich typischerweise auf bestimmte Anwendungsbereiche konzentriert. Dies funktioniert oft sehr gut in Bereichen, die auf klassischen relationalen Datenbanken basieren, bei denen dann Schritte zum Erstellen, zum Löschen, zum Ausgeben, zum Aggregieren und zum Filtern zur Verfügung stehen. Den großen Vorteilen zur sehr schnellen Entwicklung und zur schnellen Nutzung stehen allerdings auch einige Nachteile entgegen. Beispiele sind, dass schnell Bausteine vermisst werden, dass die große Menge an Bausteinen unübersichtlich wird und dass eine vollständige Abhängigkeit von der Plattform entsteht. Sehr vergleichbare Ansätze zu Low-Code und No-Code existieren bereits sehr lange als sogenannte Programmgeneratoren. Es gibt eine abstrakte Sprache für einen Spezialbereich, die automatisch in eine Standardprogrammiersprache übersetzt wird. Dazu gibt es Ansätze, die UML ausführbar zu machen. Dazu müssen UML-Modelle um zusätzliche Informationen ergänzt werden, die dann die Übersetzung in eine Programmiersprache ermöglichen. Die Entwicklung solcher Spezialsprachen ist auch zentraler Bestandteil der Model Driven Architecture [XXX]. Da es eine fundamentale Entscheidung ist, auf PaaS zu setzen, ist diese genau zu überdenken. Sind die zu entwickelnden Applikationen stark datengetrieben und sind zu unterstützende Arbeitsprozesse einfach definierbar, ist über den Ansatz intensiv nachzudenken. Beispiele sind PowerApps von Microsoft [XXX], Mendix [XXX], Bubble [XXX] und Wix [XXX]. Auf das Software Engineering hat die Entscheidung für PaaS einen gravierenden Einfluss, da viele Freiheitsgrade nicht mehr existieren, was gerade viele Softwareentwickler abschreckt. Der Punkt Software as a Service (SaaS) wurde zur Vervollständigung aufgenommen, da er für Endnutzer schlicht bedeutet, dass die genutzte Software vollständig in der Cloud existiert, was bereits bei einem WebService gegeben sein kann. Aus Sicht des Software Engineerings ist die Entwicklung von SaaS-Angeboten interessant, da diese selbst wieder auf sehr unterschiedlichen Wegen realisiert werden kann. Viele Grüße --- Übersicht über die gemachten Korrekturen: 1. "indvduellem" -> "individuellen" 2. "liergt" -> "liegt" 3. "Dies" -> "Die" 4. "Sevice" -> "Service" 5. "Nutzungsszahlen" -> "Nutzungszahlen" 6. "erweitern, sowie" -> "erweitert, sowie" 7. "Konzepte" -> "Konzepte" 8. "über" -> "die" 9. "verführt" -> "führt" 10. "xxx" -> "XXX" 11. "Platform" -> "Plattform" 12. "dafür" -> "die" 13. "da" -> “Server" 14. "Software-Technologie und" nach "Software-Engineering" eingefügt 15. "vortstellen" -> "vorstellen" 16. "und was durch" -> "und der" 17. "versteht" -> "baut" 18. "Resultate" -> "Ergebnisse" 19. "dasss" -> "dass" 20. "progrtammiert" -> "programmiert" 21. "Experteen" -> "Experten" 22. "Vortstellungen -> "Vorstellungen" 23. "Schritte" -> "Schritte" 24. "Volrsteilen" -> “Vorteilen” 25. "Nachtreile" -> "Nachteile" 26. "Beispüiele" -> "Beispiele" 27. "Bausteiene" -> "Bausteine" 28. "absehbar" -> "absehbare" 29. "Spezialbereich" -> "Fachgebiet" 30. “Sprtache” -> "Sprache" 31. "zuir" -> "zur" 32. “wird” -> “Ist” 33. "Dies führt dazu" -> "Dies führt dazu" 34. "Erweiterbarkeit" -> "erweiterbar" 35. "verändern" -> "anpassen"

Hier ist die korrigierte Version des Textes: --- Künstliche Intelligenz Künstliche Intelligenz (KI) wird gerade seit der Veröffentlichung von ChatGPT durch OpenAI Ende 2022 [XXX] als Technik angesehen, die Abläufe auf der Welt wesentlich verändern wird. Neben diesem Hype – KI-Ansätze werden in ihrer langen Entwicklungszeit immer wieder gehypt – stellt sich die pragmatische Frage nach dem Einfluss auf die Software-Entwicklung. Da es unterschiedliche KI-Ansätze gibt, wird hier der Fokus auf eine KI gelegt, die mit großen Datenmengen trainiert wird. Auf Basis dieser Datenmengen werden dann Entscheidungen getroffen, systematisch einen Text aus kleinen Bausteinen zu generieren. So steht sehr viel Wissen allerdings keine fachliche Kompetenz gegenüber. Um KI einzusetzen, wird meist ein Standard-KI-Modell, genauer Large Language Model, mit speziellem Fachwissen, z. B. Dokumenten oder Programmcode eines aktuellen Projektes, verknüpft [XXX]. Das nachfolgende Beispiel skizziert verschiedene Ansätze zur KI-Nutzung in der Software-Entwicklung. Als Basis dient eine Klasse Person, die auch einen hier nicht angegebenen Konstruktor sowie get- und set-Methoden hat.

java
public class Person {
	private int id;
	private String name;
	private String address;
}

					
					Copy

Zur Klasse Person wird eine Klasse PersonList angelegt, mit der eine Liste von Personen verwaltet werden soll. Bereits beim Anlegen der Objektvariable persons wird die KI-Unterstützung einen Vorschlag zur Code-Vervollständigung liefern. Genauer ist dies in Abb. XXX erkennbar. Dabei wurde der Text bis zum Cursor in der Zeile 8, also einschließlich des f, eingegeben. Der grau schraffierte Bereich wird als Vorschlag von der KI erzeugt. Die Grundlage dabei ist, dass es in vielen ähnlichen Klassen eine Funktionalität gibt, mit der ein Objekt mit einem bestimmten Schlüssel, oft auch ID genannt, gesucht wird. Der Vorschlag kann dann mit einer bestimmten Taste, oft der Tabulator-Taste, angenommen werden oder er verschwindet, wenn einfach der Code weitergetippt wird, bis zur Generierung eines neuen Vorschlags. Generell kann die Programmierung so schneller werden, wenn die entwickelnde Person sehr sicher ist, was sie machen will, und schnell überblicken kann, dass der Vorschlag korrekt ist. Abb. XX zeigt eine alternative generierte Variante, bei der die Objektvariable people heißt, wie es von der KI vorgeschlagen wurde. Beim generierten Teil in Zeile 11 fällt auf, dass der vorgeschlagene Code fehlerhaft ist. Die Nutzung von equals wäre nur möglich, wenn die Objektvariable id des Person-Objekts vom Typ Integer wäre, bei int ist == zu nutzen. Generell kann die KI-Generierung mehrere Zeilen, teilweise ganze Methoden bieten. Abb.XX zeigt ein Beispiel, bei dem herausgefunden werden soll, ob eine übergebene Sammlung von Personen in der gegebenen Sammlung vorkommt. Die Schleife wird nach eingegebenem „f“ angeboten, danach wird das gesamte if in Zeile 38 vorgeschlagen. Der Cursor steht vor dem „i“. Interessant ist dabei, dass auf eine für diese Klasse implementierte Methode hasId() zugegriffen wird. Die KI-basierte Code-Komplettierung existierte schon bevor ChatGPT in der breiten Öffentlichkeit im November 2022 vorgestellt wurde. Solche auf Large Language Models basierten KI-Programme, die sich im Wesentlichen auch nur mit der kontinuierlich wahrscheinlichen Vervollständigung von Textausgaben, gesteuert durch konkrete Eingaben, sogenannte Prompts, beschäftigen, können als Ergebnis vollständige Programme liefern. Es ist dazu notwendig, dass die KI mit großen Mengen korrekt entwickelter hochwertiger Programme trainiert wurde. Bevor diese Randbedingungen genauer diskutiert werden, wird dieser Ansatz mit einem Beispiel vorgestellt. Dabei wird als Beispiel hier Codeium [XXX] genutzt, das neben der gezeigten Code-Komplettierung eine Chat-Möglichkeit bietet, die zur Code-Analyse und zur Erzeugung neuen Codes genutzt werden kann. XXX zeigt ein Beispiel zur Programmerzeugung. Da KI oft mit englischen Texten trainiert wurde, kann es vorteilhaft sein, die Anfragen ebenfalls in Englisch zu formulieren. Die meisten KI-Modelle können auch auf Deutsch beauftragt werden und antworten dann auch auf Deutsch, wobei Methodennamen oft Englisch sind. Da nicht jede gut software-entwickelnde Person gute Englischkenntnisse hat, kann hier ein Übersetzungswerkzeug, wie z. B. DeepL [XXX] vorher genutzt werden. Im Beispiel wird folgende Aufgabe übersetzt und dann in den Chat eingegeben: deutsch: Füge eine Methode hinzu, um zu prüfen, ob es mehr als ein Personenobjekt mit der gleichen ID in einer PersonList gibt. englisch: Add a method to check whether there is more than one person object with the same ID in a PersonList. [Text in Bild ersetzen, anderes Bild erst erzeugen] Der generierte Code ist korrekt und kann per Copy & Paste in den eigenen Programmcode übernommen werden. Etwas überraschend ist der bin der Implementierung gewählte Weg, zur Berechnung eine Menge zu nutzen und den doppelten Eintrag daran zu erkennen, dass die add-Methode der Menge false als Ergebnis liefert, wenn ein bereits vorhandenes Element hinzugefügt werden soll. Einer für die meisten entwickelnden Personen offensichtlicherer Weg wäre es, die Liste zweimal zu durchlaufen und dabei nach dem doppelten Eintrag zu fahnden. Da eine Programmierung immer so erfolgen soll, dass sie das geringste Erstaunen bei anderen Personen hervorruft, kann der Code als kritisch angesehen werden. Falls die Mengen-Methoden in Java hochperformant sind, könnte dies aber für die gezeigte Implementierung sprechen. Im zweiten Beispiel wird eine Methode gefordert, die prüft, ob es eine ID gibt, die genau dreimal in der Liste vorkommt. deutsch: Schreibe eine Methode, die überprüft, ob es eine ID gibt, die genau dreimal in der Liste vorkommt. englisch: Write a method that checks whether there is an id that occurs exactly three times in the list. Das Ergebnis in Abb. XXX mag überraschen, ist schlichtweg falsch und zeigt so eine sogenannte „Halluzination“ der KI. Auch der erklärende Test hilft nicht beim Verständnis des Fehlers. Dies zeigt, dass jeder generierte Code, unabhängig vom genutzten Ansatz, kritisch vor der Übernahme zu prüfen ist. Was generell der komplexen Entwicklungsaufgabe, Code als korrekt zu beurteilen, entspricht. An dem Beispiel ist ein weiterer KI-Ansatz zeigbar. Die KI wird genutzt, um Tests zu generieren. Das Prompt lautet wie folgt: deutsch: Schreibe eine Testklasse für PersonList, die eine 100%ige Zweigabdeckung garantiert. englisch: Write a test class for PersonList that guarantees a 100% branch coverage. Der erzeugte Code sieht wie folgt aus:

java
@Test
void testIsAnyIdOccurringThreeTimes() {
    // Test case 1: One ID occurs exactly three times
    PersonList personList1 = new PersonList();
    personList1.addPerson(new Person(1));
    personList1.addPerson(new Person(1));
    personList1.addPerson(new Person(1));
    personList1.addPerson(new Person(2));
    Assertions.assertTrue(personList1.isAnyIdOccurringThreeTimes());

    // Test case 2: No ID occurs exactly three times
    PersonList personList2 = new PersonList();
    personList2.addPerson(new Person(1));
    personList2.addPerson(new Person(2));
    personList2.addPerson(new Person(3));
    Assertions.assertFalse(personList2.isAnyIdOccurringThreeTimes());

    // Test case 3: Empty list
    PersonList personList3 = new PersonList();
    Assertions.assertFalse(personList3.isAnyIdOccurringThreeTimes());
}

					
					Copy

Positiv fällt auf, dass systematisch unterschiedliche positive und negative Fälle generiert werden. Die Überdeckung kann nicht gemessen werden, es wird aber mit den unterschiedlichen Fällen argumentiert, dass so eine hohe Überdeckung erreicht wird. Da der Code aus einem kleinen prototypischen Projekt stammt, waren die Methode addPerson() und der von Person genutzte Konstruktor nicht vorhanden, wie in Abb. XXX dargestellt. Dies zeigt, dass trotz Verbindung zum Code, dieser nicht genau berücksichtigt wird. Weiterhin fällt auf, dass in einer systematischen Testumsetzung jeder der genannten Fälle in einer eigenen Test-Methode stehen würde, damit die Tests unabhängig voneinander durchgeführt werden, wie es in Kap. X.Y diskutiert wird. Nach der Ergänzung von Code, der die Testfälle lauffähig macht, wird die KI über den gescheiterten Testfall informiert. deutsch: Der Test testIsAnyIdOccurringThreeTimes() zeigt einen Fehler für Testfall 1, korrigiere die Methode isAnyIdOccurringThreeTimes. englisch: The test testIsAnyIdOccurringThreeTimes() shows an error for test case 1, correct the method isAnyIdOccurringThreeTimes. Die Antwort enthält eine korrekte Implementierung.

java
public boolean isAnyIdOccurringThreeTimes() {
    Map<Integer, Integer> idCountMap = new HashMap<>();
    for (Person person : persons) {
        int id = person.getId();
        idCountMap.put(id, idCountMap.getOrDefault(id, 0) + 1);
    }

    return idCountMap.containsValue(3);
}

					
					Copy

Die Beispiele machen zwei zentrale Erkenntnisse deutlich: KI bietet mit ihren verschiedenen Ansätzen eine wichtige Unterstützung in Software-Entwicklungsprozessen. Ohne genaue aktuelle Kenntnisse des Software-Engineerings können Menschen die Qualität von KI-Ergebnissen im Bereich Software-Entwicklung nicht beurteilen. Es gibt viele weitere Detailpunkte, die bei der Nutzung von KI beachtet werden müssen. Wer garantiert die Korrektheit und Qualität der von der KI genutzten Basisdaten? Hat die KI quantitativ die gleichen Informationen über unterschiedliche Ansätze, wenn diese verglichen werden sollen und garantiert eine Ergebnisneutralität? Wie können KI-Ergebnisse langfristig in der Wart- und Erweiterbarkeit von Software berücksichtigt werden? Wer ist für Fehler KI-generierter Software verantwortlich? Können auf Basis der genutzten Daten wirklich neue Ideen entstehen? Zusammenfassend macht dieses Kapitel deutlich, dass das grundlegende Wissen über Software Engineering weiterhin das zentrale Fundament der Software-Entwicklung ist und dass neue Technologien Ergänzungen und weitere Auswahlalternativen darstellen. Diese Alternativen können Entwicklungen für Teilaufgaben wesentlich erleichtern, werden das Software-Engineering aber nicht revolutionieren. --- Übersicht über die gemachten Korrekturen: 1. "unerschiedlich" -> "unterschiedliche" 2. "gier" -> "hier" 3. "getoffen" -> "getroffen" 4. "toffenen „so dass systematisch aus kleinen " 5. "Satdard" -> "Standard" 6. "großen Mengen korrekter hochwertig entwickelter" -> "großen Mengen korrekt entwickelter hochwertiger" 7. "Den großen Volrsteilen zuir schnellen Entwicklung und zur schnellen Nutzung stehen allerdinges auch einige Nachtreile entgegen." -> "Den großen Vorteilen zur schnellen Entwicklung und zur schnellen Nutzung stehen allerdings auch einige Nachteile entgegen." 8. "den doppelten Eintrag wurde dran zu erkennen," -> "den doppelten Eintrag daran zu erkennen," 9. "man die Nutzung fall" 10. "Eine Existanzprüfung" -> "Er" 11. "des bin der Implementierung gewählter Weg," -> "de' 12. "modeln" -> " Modelle zu nutzen" 13. "Vorauf und `30 Systemen liefern ein korrektes" -> "..." 14. "Methodennamen oft englisch sind." -> "Methodennamen oft Englisch sind." 15. " und oft das Programmcode" -> "und der von Person genutzte Konstruktor" 16. "definierten Stand" -> " mit " 17. "Erläuternden Fall gewählt." 18. "Auf der abstrakten Ebene ist erkennbar, dass es sich hier „nur“ um eine weitere Ebene der Programmabstraktlon handelt." -> "Auf der abstrakten Ebene ist erkennbar, dass es sich 'hier „nur“ um eine weitere Ebene der Programmabstraktion handelt.'" 19. "Zeile" -> "Zeile bis zur Generierung eines neuen Vorschlags" 20. "Unter Nutzung eines" 21. "besetzten Codes) 22. "doppelt" 23. "Erstaunlichere" -> " ..." 24. "auf „create“" 25. "Neuerund der Task" 26. "Probierhaltung bleibt nachwievor" -> "E" 27. "Unvorhersagbar" -> "werden zusammenhängend auf eine Programmdurchführung sichtbar und umgesetzt." 28. "baut" -> " nutzen" 29. "Mit geschrieben oder ..." -> "Der generierte Code ist korrekt und kann per Copy & Paste in den eigenen Programmcode übernommen werden."