MB4: SWP I – Software-Projekt im SS 2014 im FB VI der Beuth-HfT Berlin,
Prof. Knabe, 2014-03-20
| V | K | Plenum im SU | Ablieferung (V=Vorlesungswoche für uns, K=Kalenderwoche,
Okt, Nov,
Dez, Jan,
Feb bzw. Apr, Mai, Jun, Jul) in Ü |
|---|---|---|---|
| 1 | 14 | 12:00-14:00 Einführung, Teameinteilung, Projektstudie. PH-Zielbestimmung. Finden von Anwendungsfällen. AF-Granularität. | Vorbesprechung zur Themenfindung |
| 2 |
15 |
12:00-13:30 Finden von Fachklassen; Anwendungstypen, Basistechniken |
Projektstudie, Teamprofil |
| 3 |
16 |
12:00-13:30 Finden von Operationen; Versionsverwaltung mit git, git-Vortrag, Zugriff mit ssh | Zielbestimmung |
| 4 |
17 |
12:00-13:30 Vorstellung der OO-funktionalen Sprache Scala |
Fachklassendiagramm, Technik-Einarbeitungsplan |
| - |
18 |
----- |
[Feiertag "Tag der Arbeit"] |
| 5 |
19 |
Build- und Dependency-Management mit Maven | Operationsnamen, git-Leerprojekt |
| 6 |
20 |
[Testen mit JUnit, Testsuites] |
Technik-Prototypen |
| 7 |
21 |
Objektverwaltung; 3-Schichten-Architektur (Skript); Rich/Anemic Domain Model |
Build-Werkzeug |
| - |
22 |
----- |
[Himmelfahrt] |
| 8 |
23 |
Transaktionen, Datenzugriffs-API |
|
| 9 |
24 |
Programmierstil |
Objektverwaltung-UI |
| 10 |
25 |
||
| 11 |
26 |
Persistenzschicht, Technikfassaden |
|
| 12 |
27 |
||
| 13 |
28 |
Objektverwaltung, Technikeinbindung |
|
| 14 |
29 |
Abnahme |
|
| 15 |
30 |
12:00 bis 14:00 Abschlussbesprechung | |
| Meilensteininhalte: auf Papier besprechungsfertig ausgedruckt! Alle Diagramme müssen zwecks Skalierbarkeit als Vektorgrafik (.eps, .svg, .tif, .wmf), nicht Pixelgrafik (.jpg, .gif, .bmp) erstellt und nach PDF konvertiert werden! Gewährleisten Sie, dass die kleinen Schriften auch bei Vergrößerung 500% noch treppenfrei sind. Beispiele für einige Meilensteininhalte finden Sie unter http://public.beuth-hochschule.de/~knabe/fach/swp-i/lehrkraftnews/ |
|||
| Projektstudie, Teamprofil: Wie im Fallbeispiel „Lehrkraftnews“ |
|||
| Zielbestimmung: Einleitende Abgrenzung im Pflichtenheft: Muss-, Soll-, Kann-Ausbaustufen, ca. 2 Seiten |
|||
| Fachklassendiagramm: Klassennamen, Attribute, Assoziationen, Kardinalitäten Technik-Einarbeitungsplan: Welche Technik wofür (z.B. Oberfläche, Persistenz, Verteilung) einsetzen; Wer arbeitet sich in welche ein. |
|||
| Operationsnamen im Fachklassendiagramm; git-Leerprojekt: Leeres Projekt mit git-Versionierung, Ticketing und pull/push-Zugriff durch jedes Mitglied vorführen, z.B. bei Bitbucket (akademisch kostenlos), Assembla, hostedredmine.com. | |||
| Technik-Prototypen: Voneinander unabhängige Technische Prototypen je Mitgliedszuständigkeit, z.B. für GUI, Persistenz, Verteilung | |||
| Build-Werkzeug: Projekt(module) in Maven-Form. Testsuite in IDE und Maven ausführbar. Fortan müssen alle API-Klassen in der Testsuite getestet werden. | |||
| Objektverwaltung-UI: Technischer Oberflächenprototyp für Objektverwaltung einer Klasse in Maven-Form |
|||
| Persistenzschicht: Entscheidung Anemic
vs. Rich Domain Model (Wohin Attribute der Fachklassen). Persistenzschicht für eine Fachklasse (meist Benutzer) mit zugehörigen Testtreibern vorführbar. Datenbankentwurf: Abbildungsregeln Klassen → Tabellen, Tabellendefinitionen. |
|||
| Technikfassaden: Kapselung der anderen eingesetzten Techniken (z.B. zur Verteilung) hinter projektspezifischen Fassaden |
|||
| Objektverwaltung
(Durchstich): CRUD-Funktionalität zweier Fachklassen (die erste meist
„Benutzer“) mit den Operationen Erfassen, Ändern, Löschen, Suchen
Einzelobjekt, Suchen Objektmenge, jedoch ohne Verbindungsverwaltung,
inklusive Oberfläche und Maven-Build. Namenskonvention: Jeder
Klassenname beginnt mit dem Schichtkürzel, Bsp.: Aus der OOA-Klasse
Konto wird UiKonto für die Darstellung an der Oberfläche, LgKonto für
die Fachlogik eines Kontos und DbKonto für Konto-bezogene
Persistenzdienste, Technikeinbindung: Beispielhafte Einbindung der weiteren, eingesetzten Techniken in die Oberfläche |
|||
| Abnahme: Reihenfolge gemäß Rücksprachenzeit, tauschbar. Je Team und zusätzlich je Mitglied 20 Minuten. Abgabepflicht gemäß getrenntem „Kriterienformular“ zur Projektabnahme. Die Teile müssen namentlich gekennzeichnet sein und in der Rücksprache verteidigt werden können. Um bestehen zu können, muss das System als Ganzes funktionieren, nicht nur einzelne Klassen. Insbesondere müssen alle Schichten beteiligt sein! Kein Plenum! | |||
| Abschlussbesprechung. Schlussbewertung (eigene Schwierigkeiten, Verbesserungsvorschläge, Kritik an mir. Was hat Ihnen gut gefallen?). Notenbekanntgabe. | |||