SWTPRA VL1 Motivation-Aufgabenstellung · PDF fileSoftware(technik)praktikum: Vorlesung 1 Eric...

Software(technik)praktikum: Vorlesung 1

Eric Bodden Christopher Gerking, Johannes Geismann, Philipp Schubert

Software(technik)praktikum SS 2016

Betreuung des Softwaretechnik- und Software-Praktikums 2015

■ Leitung ■ Prof. Dr. Eric Bodden

■ Organisation ■ Christopher Gerking, Johannes Geismann, Philipp Schubert ■ E-Mail: swtpra-org@lists.upb.de

■ Tutoren ■ Paul Börding, Julian Heinovski, Roman Kober, Ralph Menne, Jan-Hendrik Schwarz

■ Programmierberatung ■ Mario Treiber

3Software(technik)praktikum: Vorlesung 1

Die Aufgabenstellung und Organisatorisches werden zum Ende der heutigen Vorlesung bekanntgegeben.

1. Eigenschaften von Software

2. Herausforderungen der Softwareentwicklung

3. Ziele des Praktikums

Einführung

Programm vs. Software

Software >> Programm

Ist sehr viel mehr als

Ist sehr sehr viel mehr als

Softwareentwicklung >>> Programmierung

Analogie bzgl. Programm vs. Software

ProgrammProgrammiererProgrammieren

Software SoftwareentwicklerSoftwareentwicklungWenn jemand nur Hütten bauen

kann, würden wir ihn keinen Wolkenkratzer bauen lassen. Wenn jemand dagegen programmieren kann, lassen wir ihn oft bedenkenlos Software entwickeln.

Softwareentwicklung ist …

■ … deutlich mehr als Programmierung

■ … analytische und konzeptuelle Arbeit

■ … ein sozialer Prozess

■ … eine Disziplin mit bewährten Konzepten, Methoden, Notationen und Werkzeugen

■ … und immer wieder neuen Technologien

Software ist komplex!

■ Software kann heute nicht mehr von einer einzelnen Person „programmiert“ werden

■ Software kann nicht mehr nur von einer einzelnen Person in ihrer Gesamtheit verstanden werden!

■ In vielen Projekten und Produkten ist die Entwicklung der Software ein maßgeblicher Kostenfaktor ■ Entwicklungsaufwände von 10 oder 100 Personenjahren (PJ) sind keine Seltenheit.

Software ist komplex!■ Softwaresysteme müssen mehr und mehr Aufgaben erfüllen

■ aufgrund von Kundenwünschen bzw. Marktanforderungen ■ Software ist heute oft maßgeblicher Innovationstreiber

■ Software-Systeme sind miteinander vernetzt ■ Plattform-Interoperabilität (z.B. Smartphone & PC) notwendig

■ Softwaresysteme bestehen typischerweise aus einer Vielzahl von Komponenten ■ Komponenten sind oft verteilt ■ Kommunizieren über komplexe Protokolle

9 8Software(technik)praktikum: Vorlesung 1

Software ist komplex!■ Softwareprojekte sind heute meist interdisziplinär

■ Eingebettete Systeme / Mechatronik ■ Betriebliche Informationssysteme (Bank, Produktion, Logistik)

■ Software muss oft sicherheitskritische Aufgaben erfüllen ■ in Transportsystemen ■ in medizinischen Geräten ■ im Finanzbereich

■ Ausführliche Analysen werden wichtiger & zugleich aufwändiger ■ Manuelles Testen ■ Automatisches Testen (JUnit) ■ Automatische Schwachstellenanalysen ■ Automatisches Beweisen (Model Checking)

Charakteristika der Softwareentwicklung

■ Software unterliegt häufigen Änderungen

■ Re-Engineering notwendig

■ Software unterliegt hohen Qualitätsmaßstäben (Angriffssicherheit, Korrektheit, Robustheit, Wartbarkeit, Interoperabilität, ...)

■ Softwareproduktion ist ein industrieller Prozess

■ Kosten/Nutzen-Abschätzung sehr wichtig

■ Eingesetzte Techniken

■ Objektorientierter Entwurf

■ Qualitätssicherung durch

■ Standardisierten Prozess und zugehörige Dokumente

■ Versions-/Konfigurationsverwaltung (z.B. Git)

■ Änderungskontrolle (z.B. Trac)

■ (Code-) Reviews

■ Kosten-/Nutzen Analyse durch systematische Aufwandserfassung

Software ist nie fertig

Problem • Software lebt lange (Jahr-2000-Problem, Banksoftware > 40 Jahre)

und muss permanent gewartet werden bei stets hoher Qualität • Wissen über die ausgelieferte Software (& deren Technologien)

Idee • Softwareprodukt: guter Programmcode + explizites Wissen • Entwicklungsprozesse sorgen für die systematische Persistenz

Konsequenz • Wartbarkeit bereits bei der Entwicklung beachten

• Ausführliche Dokumentation (nachverfolgbare Anforderungen, Systemkontext, Entwurfsentscheidungen, Architektur)

• Sauberer Code und Code-Kommentare • Testfälle

Software erfordert Erfahrung

■ Softwareentwicklung erfordert viel Erfahrung!

■ Diese Erfahrung ■ ... muss man selbst machen! ■ ... wird im Software(technik)praktikum vermittelt!

■ Unser Praktikum ist eine Kombination aus: ■ Projektorientiertem Lernen ■ Unterstützt durch Vorlesung(en)

Analogie bzgl. Erfahrung sammeln

Die Erfahrung eines großen, komplexen und verteilten Projektes kann nicht durch viele kleine Projekte erreicht werden.

SoPraGP1-, GP2-Aufgaben SWTPra

Erfahrung anderer nutzen

■ Prozess- bzw. Vorgehensmodelle ■ sind die „zusammengeronnenen“

Erfahrungen erfolgreicher Softwareprojekte

■ Beispiel: V-Modell ■ Beschreiben zweckmäßiges Vorgehen

& passende Dokumente ■ Ermöglichen Wiederholbarkeit und

Kontrollierbarkeit ■ Wann ist ■ was ■ wie zu tun?

Bekannt aus der Vorlesung

Softwareentwurf

Fähigkeiten von Softwareentwicklern

■ Heutige Entwickler müssen sehr gut ausgebildet sein und viele Fähigkeiten besitzen

■ Wir unterscheiden in

■ Hard-Skills

■ Fachkompetenzen

■ Benötigt um selbstständig und eigenverantwortlich zu arbeiten

■ Soft-Skills

■ Soziale Kompetenzen

■ Wichtig zur Interaktion mit dem Team und dem Kunden

Notwendige Hard-Skills

Programmieren Abstrahieren & Modellieren

Konzepte erarbeiten & anwenden, Alternativen bewerten

Lösungen dokumentieren und

Notationen einsetzen

Technologien kennen und schnell in

neue Technologie einarbeiten

Kosten und Aufwände

abschätzen

Hard-Skills haben Sie zum Teil bereits in GP1, GP2, GPS, DuA und SE erlernt. Im Praktikum werden Sie diese vertiefen.

Notwendige Soft-Skills zur Interaktion mit Kollegen & Kunden

Zuhören und Probleme verstehen

Probleme/Lösungen kommunizieren

(auch in Form von Dokumenten)

Argumentieren und Kompromisse finden

Eigeninitiative ergreifen &

Verantwortung übernehmen

Eigene Stärken kennen, einsetzen

und reflektieren

Stärken von anderen erkennen und nutzen

Soft-Skills wollen wir im Praktikum trainieren.

Softwareentwicklung ist Teamarbeit

Problem • Software kann nicht von Personen entwickelt werden, die

Experte für alles sind • Einzelne Personen können die Gesamtheit der Software nicht

mehr verstehen

Idee • Aufgabenaufteilung auf mehrere Personen (Rollen) • Jede Person muss nur Experte für ihre Aufgabe sein

Vorteil • Komplexität wird handhabbar & Produkt ist schneller entwickelt

Herausforderung • Missverständnisse, Soft-Skills, Unvollständiges Wissen, ...

Konsequenz • Software-Management (Zeit und Qualität) und

Entwicklungsprozesse einführen

Einige beteiligte Rollen

Projektmanager verfolgt und leitet Projektverlauf

Domänen-analyst

nimmt Kunden-anforderungen auf und verfolgt deren Ein-haltung

Software-architekt

konzipiert das Gesamt-system

Software-entwickler

programmiert einzelne Komponenten der Software

Tester

erstellt Testfälle und führt diese aus

Plattform-experte

konfiguriert die Software für die jeweilige Plattform

Kunde stellt (sich wechselnde ☺) Anforderungen und nimmt das fertige Produkt ab

Kommunikation zwischen den Rollen ist wichtig

Mögliche Rollenverteilung im V-Modell

Domänenanalyst

Softwarearchitekt

Softwareentwickler

Tester

Plattformexperte

Domänenanalyst

Im Praktikum sollen Sie möglichst viele Rollen trainieren.

Fazit: Ziele des SWTPra / SoPra■ Hard- und Soft-Skills in der Softwareentwicklung lernen und

verbessern

■ Entwicklung eines Softwaresystems im Team ■ Anwendung des Gelernten aus GP1, GP2, GPS, SE und DuA ■ Ausführung eines Softwareentwicklungsprozesses von der

Anforderungsdefinition bis zur Realisierung ■ Projektmanagement ■ Sammeln von Programmiererfahrung ■ Erstellen von sinnvollen Modellen und Dokumenten ■ Einsatz von Technologien und Werkzeugen ■ Qualitätssicherung

Organisatorisches & Aufgabenstellung

Aufgabenstellung

■ Entwicklung eines verteilten Quarto-Brettspiels

Aufgabenstellung

■ Entwicklung eines verteilten Quarto-Brettspiels

■ „Erweiteres“ Quarto-Spiel ■ mehr Spielsteine ■ komplexeres Spielfeld

■ Verteilte Anwendung ■ Client-Server Architektur

■ Konfigurationsmöglichkeiten ■ Spielfeld ■ Anzahl / Aussehen der Steine

Aufgabenstellung

Zur Erstellung der Spielkonfigurationen

• Mensch spielt via Smartphone

• Künstliche Intelligenz spielt vollautomatisch

Spielverlauf lässt sich via PC & Smartphone beobachten

• Leitet das Spiel • Verwaltet Clients • Überwacht Ein-haltung der Regeln

2707.04.2015

Aufgabenstellung

Komitee bestimmt die Interfaces

2807.04.2015

Vorgaben bzgl. Technologien und Entwicklungswerkzeuge

Entwicklungsprozess & Rollen

■ Das System wird nach dem V-Modell entwickelt ■ Das Orga-Team ist der Kunde ■ Sie übernehmen alle weiteren Rollen

Artefakte und Ereignisse während des Praktikums

TurnierAbschlusspräsentation

Angebot

Pflichtenheft

Lastenheft

Analyse- & Entwurfsdokument inkl. Interfacedefinition

ImplementierungsabgabeAbschlussdokumentation

Erhalten Sie diese Woche.

Interface-Komitee

■ Ziel ■ Definition der Interfaces zwischen

■ Spielkonfigurator & Spiel-Engine ■ Server & Clients

■ Teilnehmer ■ je Team ein Mitglied

■ Mehrheitsentscheidung ■ Vorsitzender (leitet Komitee, von Beauftragten gewählt)

■ Berater des Komitees: Programmierberater ■ Versionen

■ 1.0: erste vorläufig finale Fassung für Analyse- & Entwurfsdokumente ■ 2.0: für Änderungen während der Implementierungsphase

■ Endabgabe und Turnier halten sich an Version 2.0

Ereignis: Messe

■ SWTPra- und SoPra-Gruppen tauschen kostenlos Komponenten ■ SWTPra-Gruppen geben ihren Spielkonfigurator und den PC-Beobachter ab ■ SoPra-Gruppen geben ihren Smartphone-Beobachter ab

33 Software(technik)praktikum: Vorlesung 1

Ereignis: Turnier

■ KI-Spieler der Teams treten gegeneinander an ■ Dazu kommen auch Spiel-Engine und Beobachter zum Einsatz

34 Software(technik)praktikum: Vorlesung 1

Wöchentliche Meetings

■ Jedes Team hat ein wöchentliches, zweistündiges Meeting ■ Es besteht Anwesenheitspflicht ■ Anfangszeitpunkte PAUL entnehmen

Mo Di Mi Do Fr

9:00 -11:00SWTPra 1

N3.211 Roman

SoPra 1 N5.235

Jan-Hendrik

11:00-13:00SWTPra 8

N3.211 Roman

14:00-16:00SWTPra 5

D1.312 Roman

16:00-18:00SWTPra 2

O1.252 Paul

SoPra 4 O1.258

Jan-Hendrik

SWTPra 3 O1.252 Julian

SWTPra 7 N2.228 Roman

SWTPra 4 NW1.701

SoPra 3 N1.101 Ralph

SWTPra 6 H3.223 Julian

18:00-20:00SoPra 2 E0.143 Ralph

Aufgabe der Tutoren

■ Jedes Team hat einen Tutor, der bei den wöchentlichen Meetings dabei ist und per Mail erreichbar ist

■ Nicht die Aufgabe des Tutors ■ die Arbeit machen (das macht das Team) ■ die Gruppe leiten, das Meeting vorbereiten & moderieren (das macht der

Projektleiter) ■ der Kunde sein (das ist das Orga-Team) ■ Technikprobleme lösen (hierfür berät Sie der Programmierberater)

■ Aufgabe des Tutors ■ ein Berater und Coach sein (Consultant) ■ Fragen klären ■ ggf. auf Probleme hinweisen & Zwischenreviews durchführen

Entwicklerrollen der Teams

Projektmanager Koordiniert Aufgabenverteilung, Projektplan, Agenda (bei 12er Teams: 2 Rollen)

Domänenanalyst & Architekturmanager

Koordiniert Pflichtenheft sowie Analyse und Entwurf (bei 11er/12er Teams: 2 Rollen)

Modellierungsexperte Experte für Metamodellierung, EMF, OCL, Entwurfsmuster, Architekturmuster

Technologieexperte Experte für Eclipse PDE, GEF/Graphiti, Android, JSON

Implementierungsmanager Koordiniert Teilproduktimplementierung & Integration zum Gesamtprodukt

Qualitätsmanager Koordiniert Dokument- & Code-Reviews, betreut Bugtracker

Testmanager Koordiniert Erstellung und Ausführung manueller und automatischer Tests

Produktmanager Koordiniert Abschlusspräsentation, Webseite, Messe

Werkzeugbeauftragter Experte im Umgang mit Eclipse, Latex, Git, Trac

Dokumentationsmanager Koordiniert Endabgabe, Javadoc, Handbuch

Programmierberater und bereitgestellte Technik

■ Neben den Tutoren gibt es einen Programmierberater ■ Dieses Jahr: Mario Treiber ■ Berät Sie bei Programmierproblemen ■ Wöchentliche Sprechstunde auf Anfrage ■ Sonst nur über das Kommunikations-Forum Koala erreichbar ■ Bitte immer konkrete Fragen stellen ■ Bei Problemen bitte immer den problematischen Code und ggf. Fehlermeldungen

und Stacktraces angeben

■ Jedes Team bekommt folgende Technik bereitgestellt ■ eigenes Versionsverwaltungssystem (Git)

■ inkl. Bug- & Feature-Tracker und Wiki ■ eigenen Mailverteiler

Nr. Task Name Anfang Ende Dauer

1 Software(technik)praktikum Mon 11.04.16 Fre 29.07.16 80 Tage2 Beginn der Vorlesungszeit Mon 11.04.16 Mon 11.04.16 1 Tag3 Vorlesung (4 Termine) Mon 11.04.16 Don 14.04.16 4 Tage4 Kick-Off der Teams Mon 18.04.16 Fre 22.04.16 5 Tage5 Abgabe Angebot Fre 29.04.16 Fre 29.04.16 1 Tag6 Abgabe Pflichtenheft Mon 16.05.16 Mon 16.05.16 1 Tag7 Abgabe Interfaces Mon 23.05.16 Mon 23.05.16 1 Tag8 Abgabe Analyse- & Entwurfsdokument Mit 01.06.16 Mit 01.06.16 1 Tag9 Abgabe Implementierung (Messeversion) Mit 15.06.16 Fre 17.06.16 3 Tage10 Messe Mon 20.06.16 Mon 20.06.16 1 Tag11 Abgabe Implementierung (Turnierversion) Fre 15.07.16 Fre 15.07.16 1 Tag12 Endabgabe Mon 18.07.16 Mon 18.07.16 1 Tag13 Abschlusspräsentationen Mon 18.07.16 Fre 22.07.16 5 Tage14 Ende der Vorlesungszeit Fre 22.07.1615 Turnier Mon 25.07.16 Mon 25.07.16 1 Tag16 Klausur Fre 29.07.16 Fre 29.07.16 1 Tag

29.0416.05

23.0501.06

17.0620.06

15.0718.07

25.0729.07

11 18 25 02 09 16 23 30 06 13 20 27 04 11 18 25Apr '16 Mai '16 Jun '16 Jul '16

Abgabeplan SWTPra/SoPra 2015

■ Abgabeplan definiert harte Deadlines

Abgabeplan

Deadlines / Meilensteine

Anmeldung

■ Alle Teilnehmer mussten sich in PAUL zur Veranstaltung anmelden ■ Prüfungsanmeldung erfolgt in PAUL bzw. im jeweiligen Prüfungssekretariat

■ Gruppeneinteilung erfolgte ebenfalls über PAUL ■ Ort der Meetings ist in PAUL einzusehen ■ Ziel: Gleichmäßig große Gruppen

■ Voraussetzung für die Teilnahme ■ Modul l.1.1 bzw. E1721: Programmiertechnik

■ Grundlagen der Programmierung 1 und 2 (GP1 und GP2) ■ Modul l.1.2 bzw. E1722: Softwaretechnik

■ Softwareentwurf (SE)

Gruppeneinteilung Aktueller Stand

■ SWTPra ■ 78 Teilnehmer

■ SoPra ■ 45 Teilnehmer

Gruppe Termin Teilnehmer

SWTPra 1 Mo, 9-11 8

SWTPra 2 Mo, 16-18 10

SWTPra 3 Mi, 16-18 10

SWTPra 4 Do, 16-18 10

SWTPra 5 Fr, 14-16 8

SWTPra 6 Do, 16-18 9

SWTPra 7 Mi, 16-18 10

SWTPra 8 Mo, 11-13 9

SWTPra 9 —- 4

SoPra 1 Mo, 9-11 11

SoPra 2 Di, 18-20 10

SoPra 3 Do, 16-18 11

SoPra 4 Mo, 16-18 11

SoPra 5 —- 2

Bestehen der Veranstaltung

■ Der Veranstalter kann Zwischenprüfungen mit einzelnen Studenten durchzuführen, falls Zweifel an der erfolgreichen Teilnahme an der Veranstaltung bestehen.

■ Voraussetzung für das Bestehen ■ Aktive Teilnahme an der Projektarbeit ■ Anwesenheitspflicht bei den Gruppenmeetings eingehalten ■ Einhaltung der Abgabetermine ■ Klausur bestanden

■ Termin TBA ■ Ggf. bestandene Zwischenprüfung

à Die Veranstaltung ist die Prüfung

Softwaretechnik

Häufig gestellte Fragen & häufig gegebene Antworten

■ Das Praktikum unterscheidet sich von den „üblichen“ Lehrveranstaltungen die sie bereits kennen.

■ Es erfordert daher eine andere Herangehensweise und Mentalität.

■ Legen Sie neue Maßstäbe an!

Softwaretechnik

Häufig gestellte Fragen & häufig gegebene Antworten (1)

Das V-Modell ist nicht mehr zeitgemäß, da es bei Google nicht zur Anwendung kommt.

Google verfolgt ein grundverschiedenes Geschäftsmodell.

Das V-Modell ist industrieller Standard für die Entwicklung sicherheitskritischer Softwaresysteme.

Softwaretechnik

Können wir nicht einfach Dropbox benutzen?

Der Umgang mit einem Versionsverwaltungssystem ist industrieller Alltag und daher Lehrinhalt des Praktikums.

Softwaretechnik

Warum gibt es Seitenlimits?

Viel zu schreiben ist doch gut.

Seitenlimits gehören zum Tagesgeschäft (z.B. bei der Einreichung wissenschaftlicher Veröffentlichungen).

Sich knapp und präzise auszudrücken ist eine Kunst die es zu lernen gilt.

Softwaretechnik47

Manuell zu programmieren ist doch viel einfacher als Framework X zu benutzen.

Das Praktikum ist auch eine Lehrveranstaltung.

Es heißt Softwaretechnikpraktikum und nicht Programmierpraktikum.

Softwaretechnik bedeutet ingenieurmäßiges Vorgehen bei der Softwareentwicklung.

Softwaretechnik

Wir müssen unbedingt die neuartige Technologie X benutzen, denn die hat viele Vorteile.

Wissen wir in der Regel ☺ Für das Praktikum nutzen wir marktübliche Technologien.

Kundenwünsche schließen oft eine Abwärtskompatibilität ein. Mit gegebenen Mitteln zurecht zukommen ist industrieller Alltag.

Softwaretechnik

Der Programmierberater ist unfähig, denn er konnte unser Problem nicht lösen.

Der Programmierberater zeigt nur Lösungsmöglichkeiten auf.

Lösungsmöglichkeiten müssen selbstständig exploriert werden, ohne Garantie auf Erfolg.

Softwaretechnik

Der Programmierberater ist unfair, denn er gibt die Musterlösung nicht heraus.

Wir führen ein Projekt durch.

Es gibt in der Regel keine Musterlösung!

Softwaretechnik

In der Abschlusspräsentation zeigen wir unser wahres Gesicht und geben der Orga zurück was sie uns angetan hat!

Keine gute Idee.

Die Präsentation dient als Projektabschluss und wird entsprechend bewertet.

Softwaretechnik

In der Abschlusspräsentation weisen wir uns gegenseitig die Schuld zu.

Keine gute Idee.

Selbstreflexion ist nur ein Bestandteil der Präsentation!

Softwaretechnik

Der Zeitaufwand ist viel höher als bei Vorlesung X.

Ja. Siehe ECTS.

Der tatsächliche Aufwand ist stark abhängig von der Selbstorganisation innerhalb der Gruppe.

Webseite

https://www.hni.uni-paderborn.de/swt/lehre/softwaretechnik-softwarepraktikum-ss-2016/

• Fragen und Diskussionen im Koala

• Regelmäßig besuchen • Regelmäßig E-Mails lesen

IMT-Einstellungen

Muss aktiviert sein, um Zugang zu den Repositories und Mailverteilern zu erhalten

https://benutzerverwaltung.uni-paderborn.de/

GitLab

https://git.cs.uni-paderborn.de/

Erstmaliger Login aktiviert Dienstnutzung

Viel Spaß beim diesjährigen Software(technik)-Praktikum! ☺

… und bis morgen um 9 Uhr!

SWTPRA VL1 Motivation-Aufgabenstellung · PDF fileSoftware(technik)praktikum: Vorlesung 1 Eric...

Documents

Software: FEM - Tutorial - Elektrostatisches Feld · PDF fileSoftware: FEM - Tutorial - Elektrostatisches Feld Aus OptiYummy ↑ ← → 3. Komplex im FEM-Tutorial Elektrostatisches

Grundpraktikum A2 Frank-Hertz Versuchpeople.physik.hu-berlin.de/~julien/praktika/gp1/A2 Frank-Hertz Versuch.pdf · 6 QUELLEN 6 Quellen 1. Script zum Grundpraktikum (Formeln, Versuchsbeschreibung)

Kapitel 6: Anweisungen - groups.uni-paderborn.degroups.uni-paderborn.de/fg-karl/lehre/ws1819/gp1/vorlesung/ch6-statements/ch6... · • Semantik: die angegebene Folge von Anweisungen

Understanding elementary steps in methanol-to-olefins ... · Acknowledgements II Philipp Buck, Philipp Fritsch, Thomas Steiner, Tobias Bruhm, Tyll Bodden, Vinzenz Luidl and Wolfgang

Orts- und Informationsbroschüre - glowe.de · einem kleinen Fischerdorf. Die Tradition der Fischerei wird auch heute noch von orts- ... Meer und Bodden - mit vielen Gesichtern vor

rmesssung - gp1.rogp1.ro/subz/nestle/cataloage/Katalog-2006.pdfArtikel die Genehmigung zur Herstellerprüfung unter Aufsicht der Eichbehörde erhalten. Anfang 1990 haben wir mit der

Progressives T2DM-Management und nicht nur ... · Pg.6 Progressives 2Danagement und nicht nur Glkämiekontrolle Wo passen die GP1 in den ehandlungsalgorithmus Zunächst gehen wir

Neuen- See See NSG Der Greifswalder Bodden in deiner Hand · Viele Naturschutzgebiete sind gleichzeitig Teil des Natura 2000- Netzes und genießen so einen doppelten Schutz. Willkommen

Kapitel 9: Objektorientierung, Vererbunggroups.uni-paderborn.de/fg-karl/lehre/ws1617/gp1/vorlesung/ch9-oo/ch9-oo.pdf · Kapitel 9: Objektorientierung, Vererbung Grundlagen der Programmierung

Schwierigkeiten bei der Verwendung deutscher Präpositionen ... fileSoftware-Rezension: Hexaglot Sprachkurs EuroPlus+ Flying Colours 1 ©Redaktion LINSE (Linguistik-Server Essen);

Software: FEM - Tutorial - 3D-Mechanik - ifte.de · PDF fileSoftware: FEM - Tutorial - 3D-Mechanik - MP - Beispiel Aus OptiYummy ↑ ← → Gummipuffer zur Schwingungsdämpfung Mittels

Salzhaff, Greifswalder Bodden, Darß-Zingster Boddenkette ... 09/RMB-09... · 7 Nahrungsnetz verhindert das offenbar die zu starke Anreicherung von organischem Material im Sediment

KITELIFE SPOTGUIDE 117 SPOTVIELFALT · 2020. 7. 20. · KITELIFE SPOTGUIDE SPOTVIELFALT OHNE GEZEITEN lachwasserspots, endlos wirkende Bodden mit Stehbereichen und durchaus das eine

LKW-Hydraulik · LKW-Hydraulik Serie GPA, GP1, F1, F2, T1, VP1 Konstantes und variables Verdrängungs-volumen Pumpen, Motoren und Zubehör

LISTA · PDF filesoftware LISTA Script 2. Drucken n Etiketten auf perforierte A4-Bögen drucken und in der gewünschten Grösse abtrennen 3. Einlegen

ГЕНЕРАЛЬНЫЙ ПЛАН СЕЛЬСКОГО …ershovskoe-sp.ru/downloads/genplan_i_zastroika/2019/gp1.pdfГенеральный план сельского поселения

Kapitel 17: Objektorientierung in Javagroups.uni-paderborn.de/fg-karl/lehre/ws1617/gp1/vorlesung/ch17-java... · Array-Objekt; bei diesem Array wurde der zweite Eintrag verändert

auf Rügen Rügischer (55 km) Hbf S Bodden Ostsee · PDF fileLassan Ducherow Nowe Warpno Wrangels-burg Peene-münde Neuen-dorf Mellenthin Rankwitz ... Richtlinien des ADFC zertifiziert

r Bodden in deiner Hand GLSB - wwf.de · Für die Navigation nicht verwenden! STRALSUND Parow STRUCK ... (Vögel) Kartenbearbeitung: ... Weg der Freiwilligkeit und Einsicht erfolgreich

Proseminar Datenkompression Thema : Arithmetische Kodierung 18.03.2002Eric Bodden, Malte Clasen, Joachim Kneis1 Arithmetische Kodierung