Applikationen und Schnittstellen objektorientiert modellieren, implementieren, testen und dokumentieren.
Paul Kuster erhält eine Beschreibung der zu erstellenden Applikation, sucht in der Beschreibung nach Klassenkandidaten und entnimmt mögliche Attribute aus der Beschreibung. Anschliessend fasst er Eigenschaften der Klassenkandidaten zusammen und erstellt eine Situationsbeschreibung in der Form eines Klassendiagrammes.
Paul Kuster sucht nach der wesentlichen Funktionalität der Software und abstrahiert diese. Er modelliert den Aufbau der Software mit Hilfe von Klassendiagrammen und ihm bekannten Entwurfsmustern. Das Zusammenspiel der Klassen zeigt Paul Kuster mit Hilfe von Sequenzdiagrammen. Während der Implementierung verwendet Paul Kuster ein Software-Dokumentationswerkzeug (z.B. JavaDoc) und dokumentiert die Klassen und die Methoden gemäss den Dokumentationsrichtlinien (z.B nur die public-Methoden und Class-Header) der Firma.
Paul Kuster interpretiert das UML Klassendiagramm und implementiert die entsprechenden Klassen und dessen Beziehungen und Interaktionen. Er kennt die Implementationsmuster für die verschiedenen Arten von Beziehungen (z.B. Assoziation, Multiplizität, Vererbung). Paul Kuster kann dabei die Konzepte der Polymorphie anwenden.
Paul Kuster implementiert seinen Quellcode entsprechend einer Code-Konvention und benutzt Dokumentationswerkzeuge, um den Quellcode ergänzend zu kommentieren. Paul Kuster kann mittels Code-Reviewsitzungen die Qualität seines Codes einschätzen lassen und verbessern. Der vollständige Code wird durch vorgegebene Tests von ihm auf dessen Qualität überprüft.
| Kompetenzband: | HZ | Grundlagen | Fortgeschritten | Erweitert |
|---|---|---|---|---|
| Objektorientiertes Design erstellen | 1 | A1G: Ich kann aus einer einfachen Situationsbeschreibung auf mögliche Klassenkandidaten, Attribute und Methoden schliessen. | A1F: Ich kann unter Berücksichtigung von Delegation mögliche Klassenkandidaten, Attribute und Methoden aus einer einfachen Situationsbeschreibung eruieren und diese abbilden. | A1E: Ich kann komplexere Situationsbeschreibungen analysieren und Klassenkandidaten, Attribute und Methoden definieren und diese in einer Vererbungshierarchie abbilden. |
| Objektorientiert modellieren | 2 | B1G: Ich kann den Aufbau einer Applikation auf Grund vorhandener Unterlagen interpretieren und erkläutern (z.B. anhand von UML Diagrammen) | B1F: Ich kann den Aufbau einer Software modellieren. (z.B. Klassen-, Aktivitäten- und Sequenzdiagramm) | B1E: Ich kann das Modell einer Software analysieren, kritische Punkte erkennen und Korrekturen vorschlagen. (z.B. statische und dynamische Aspekte, Vererbung, Assoziationen) |
| Objektorientiert implementieren | 1,2,3 | C1G: Ich kann Klassen unter der Verwendung von Konstruktoren und Methoden definieren und Objekte instanziieren. | C1F: Ich kann ein- und zweiseitige Beziehungen gemäss dem statischen Entwurf implementieren. | C1E: Ich kann Interaktion zwischen den Objekten unter Berücksichtigung des dynamischen Entwurfs umsetzen. (Delegation) |
| Objektorientiert mit Vererbung implementieren | 1,2,3 | D1G: Ich kann Klassen und deren Super-Klassen implementieren und deren Objekte instanziieren. | D1F: Ich kann Methoden in den Sub-Klassen ergänzen oder überschreiben, um so die Fähigkeiten der Klasse zu erweitern oder anzupassen. | |
| 1,2,3 | D2G: Ich kann eigene Klassen unter Nutzung von Interfaces und abstrakten Klassen aus Bibliotheken implementieren. (z.B. AbstractList, Comparator, Comparable) | D2F: Ich kann eigene abstrakte Klassen oder Interfaces gemäss Entwurf implementieren. | D2E: Ich kann Lösungsansätze für komplexe Problemstellungen durch Anwendung der Polymorphie effizient umsetzen. | |
| Qualitätssicherung | 4 | E1G: Ich kenne Code Konventionen und kann den Quellcode dementsprechend implementieren. | E1F: Ich kann Code in einer Codereviewsitzung auf dessen Qualität überprüfen. | E1E: Ich kann Code mit vorgegebenen, automatisierten Tests (junit) überprüfen. |
| 2 | E2G: Ich kann erklären wozu ein Software- dokumentationswerkzeug (z.B. JavaDoc) dient und wie man es einsetzt (Anwenden von Tags, generieren der Dokumentation). | E2F: Ich kann Software mit Hilfe von einem Softwaredokumentations-werkzeug dokumentieren.(z.B. JavaDoc, anwenden von Tags, generieren der Dokumentation) | E2E: Ich kann die Kommentare in einer Software hinterfragen und Vorschläge zur Verbesserung machen. (z.B. Vermeiden von Kommentaren durch bessere Struktur, anwenden von Clean-Code Regeln) |
Die Handlungsziele erwähnen Exceptions und Exceptionhandling nicht, die Autoren der Kompetenzmatrix erachten dieses Thema allerdings als wichtig.
| Kompetenzband: | HZ | Grundlagen | Fortgeschritten | Erweitert |
|---|---|---|---|---|
| Exceptionhandling | nicht vorhanden | X1G: Ich kann bei der Benutzung von Methoden Exceptions abfangen und behandeln. | X1F: Ich kann in meinen Implementierungen im Fehlerfall geeignete Exceptions werfen. | X1E: Ich kann für eine Applikation die Fehlerbehandlung einheitlich umsetzen. |
Diese Stufe ist als Einstieg ins Thema gedacht. Der Fokus liegt hier auf dem Verstehen von Begriffen und Zusammenhängen.
Als Richtungshinweis: Wer alle Kompetenzen in dieser Stufe erfüllt, hat die Noten 3.5.
Diese Stufe definiert den Pflichtstoff, den alle Lernenden am Ende des Moduls möglichst beherrschen sollen.
Als Richtungshinweis: Wer alle Kompetenzen in dieser Stufe erfüllt, hat die Noten 4.75
Diese Lerninhalte für Lernende gedacht, die schneller vorankommen und einen zusätzlichen Lernanreiz erhalten sollen.
Als Richtungshinweis: Wer alle Kompetenzen in dieser Stufe erfüllt, hat die Noten 6
Link zum Fragekatalog