Softwareengineering

Entwicklungsmodelle

Im Projektmanagent gibt es verschieden Modelle. Jedes davon hat seine Stärken und Schwächen. Meist versuchen sie das Risiko gering zu halten oder die Flexibilität zu erhöhen. Je weiter ein Projekt vortgeschritten ist um so höher sind die Kosten einer Änderungen.

Wasserfall

Es werden keine Schritte zurück gemacht. Eine Phase folgt auf die andere. Sehr realitätsfremd da sich die Anforderungen ständig ändern. Stark Dokumente getrieben.

  1. Aufnehmen der Anforderungen. Zusammentragen in einem Pflichtenheft. Risikoanalyse.
  2. Modellieren des Systems, Evaluation der Technologie. Risikoanalyse
  3. Eigentliche Entwicklung/Umsetzung sowie die Überprüfung davon.
  4. Integrationstests und Testberichte
  5. Deployment und Abnahmeprotokolle

Sprialmodell

Ein Projekt wird in Teile (Unterprojekte) aufgesplitet und die einzelnen Teile werden separat getestet. Ziel ist es das Risiko zu minimieren. Es besteht aus vielen kleinen Wasserfall-Modellen.

  1. Ziele definieren
  2. Evaluierung, Risikoabschätzung
  3. Entwicklung
  4. Planung der nächsten Phasen

V-Modell

Zu jeder Definition gehört auch ein passender Test. Sehr aufwändig und kostenintensiv. Ermöglicht jedoch grosse Stabilität.

1. Systemanforderungen System 8. Systemtest
2. Bereichsanforderungen Bereich 7. Integrationstests
3. Modellierung Baugruppe 6. Modultest
4. Entwurf Bauteil 5. Detailtest

Prototyping

Es werden Prototypen erstellt um die Funktion simulieren zu können um die Sachen etwas handfester zu machen.

Laborprototyp
schauen ob etwas funktional wäre
Demoprototyp
Vorführmodell -> Klickdummy, sieht gut aus kann aber nichts.
Horizontale Prototypen
Fokus auf eine Ebene. z.Bsp. GUI. etwa Klickdummy
Vertikale Prototypen
Die Funktionen die es gibt funktionieren bereits auf allen Ebenen. Etwa um spezifische Funktionen zu testen.

Scrum

Der Kunde kann immer neue Anforderungen einbringen welche dann nach und nach abgearbeitet werden. Gearbeitet wird in 30 Tagessprints und in Daily Sprints. Idealerweise mit 3 Leuten oder mehr. Beim Daily Sprint werden von den Entwicklern drei Fragen beantwortet:

  • Was habe ich gestern gemacht?
  • Was hat mich dabei behindert?
  • Was werde ich heute machen?

Die Schwierigkeit ist die Sprint Backlogs richtig zu wählen. Enthalten sie zu viele Tasks führt das zu einer sehr grossen Belastung des Teams und wenn sie zu wenig enthalten ist das Team nicht ausgelastet. Die Tasks im Sprint Backlog sind verbindlich und müssen wirklich auch nach 30 Tagen erledigt sein.

Scrum Ablauf

  1. Product Backlog (Sammlung von Anforderungen)
  2. Sprint Backlog (Tasks welche im Sprint umgesetzt werden.)
  3. Sprint
  4. Working Software

Hermes

Ist die Projektmethode des Bundes.

  1. Initialisierung
  2. Konzept
  3. Realisierung
  4. Einführung

Testing

Static

Code-Reviews, Dokumentation es wird nicht die Applikation/Funktion getestet sondern etwa der Code angeschaut oder die Dokumenation kontrolliert.

Black Box

Functional Testing. Es wird hauptsächlich der Output getestet. Wenn ich etwas eingebe erhalte ich das richtige Resultat? Wie es passiert ist nebensächlich.

White Box

Man kennt die genaue Funktion und kontrolliert auch ob sie intern richtig umgesetzt wird. Structural Testing.

Arten

Manuelles Adhoc Testen
Jemand testet drauf los. Keine Dokumentation vorhanden. Ist eine leichtere Variante von Explorativem Testen.
Strukuriertes Manuelles Testen
Es wird anhand von Test Cases manuell getestet. Reproduzierbar.
Strukuriertes automatisiertes Testen
Automatisiert Tests, etwa Unit Tests.
Exploratives Testen
Die User können die Anwendung benutzen und testen wie sie möchten. Ohne jegliche Vorgaben. Wobei es hier mehr um das Verhalten der User geht.

OOP

  • Klassen sind Baupläne für Objekte.
  • Methoden sind die Funktionen die den Objekten zur Verfügung stehen.
  • Klassen können vererbt werden. Dies bedeutet das die abgeleitete Klasse alle Eigenschaften und Methoden der zuvorhergehenden Klasse hat.
OOP Konzepte

OOP Konzepte

Abstraktion

Jedes Objekt ist ein abstraktes Modell eines Akteurs und muss nicht offenlegen, wie seine Fähigkeiten implementiert sind.

Kapselung

Verbergen von Implementierungsdetails, Zugriff über Schnittstellen.

Vererbungen

Abgeleitete Klassen besitzen die gleichen Methoden und Properties wie die Basisklasse.

Klassen

Abstraktes Modell. Oft auch eines physikalischen Objekts. Klassen sind Baupläne für Objekte

Objekte

Sind konkrete Instanzen von Klassen.

Polymorphie

Fähigkeit eines Objekts, abhängig von seiner Verwendung unterschiedliche Datentypen anzunehmen. GibLaut(Miau)/GibLaut(Wuff)

C#

.NET Code wird zu IL kompiliert. Ist immer noch relativ gut lessbar und sehr einfach zu dekompilieren. IL Code wird dann schlussendlich zu Maschinen Code kompiliert.

  • Ohne Framework nicht lauffähig
  • Sprache macht fast keinen Unterschied -> IL Code
  • Ressourcen Verwaltung wird vom Framework übernommen.

Diagramme

  • UML Standartisierte Darstellung

Strukurierdiagramme

  • Klassendiagramm
  • Kompositionsstrukturdiagramm
  • Komponentendiagramm
  • Verteilungsdiagramm
  • Objektdiagramm
  • Paketdiagramm
  • Profildiagramm

Verhaltensdiagramme

  • Aktivitätsdiagramm
  • Anwendungsfalldiagramm
  • Interaktionsübersichtsdiagramm
  • Kommunikationsdiagramm
  • Sequenzdiagramm
  • Zeitverlaufsdiagramm
  • Zustandsdiagramm

Use Case

Sollte immer aktiv gezeichnet werden. Ein Use Case ist eine Aktion welche ein User ausführen kann. Use Cases können meist auch gleich zu Test Cases werden. Ein Use Case Diagramm definiert die System Grenzen. Als erstes sollten immer die Akteuere definiert werden.

Klassen

Statische Sicht, ähnlich wie ein ERM aber nicht normalisiert.

Assozation
Es besteht eine Verbindung.
Aggregation
Klasse A enthält Klasse B
Komposition
Klasse A besteht aus Klasse B (mindestens eine der Klassen ist abhängig von der anderen).

Vorgehen

  1. Klassen identifizieren (Rechnung, User, Fahrzeug)
  2. Eigenschaften identifizieren, TIPP: Attribute schrittweise verfeinern.
  3. Kategorien bilden.

Typen

Abstrakte Klassen
Wird mit "{abstract}" gekennzeichnet. Sind Klassen welche nicht direkt iniziert werden können. Etwa wenn man Mitarbeiter erfassen möchte und die Klasse Mensch nicht im Programm verwendet wird.
Sealed Klassen
Es sind keine Vererbungen mehr möglich. Unterste mögliche Stufe.
Static Klassen
Statische Klassen können nicht instanziert werden. Sie werden oft als Hilfsklassen verwendet. Etwa um etwas zu berechnen.

Sichtbarkeiten

Zeichen Bedeutung
+ Public
# Protected
- Private
~ Package (internal)

Objekt

Ein Objektdiagramm ist eine Momentaufnahme eines Objekts. Es müssen nicht alle Eigenschaften der Klasse abgebildet werden sondern nur die, die für den Moment gerade relevant sind. Kann gut beim Testing verwendet werden.

Aktivitäts

Beschreibt Akivitäten sprich Funktionen. Wichtig immer prüfen ob:

  1. Ende vorhanden
  2. Start vorhanden
  3. Bedingungen vollständig

Zustands

Beschreibt den momentanen Zustand eines Systems. Ähnlich wie Aktivitätsdiagramm aber die Zustände sind die Blasen und die Aktivitäten sind die Pfeile dazwischen. Können oft auch Loops zwischen Start und Exit enthalten.

Sequenz

Sequenzdiagramme werden immer von oben nach unten ausgeführt. Sie dienen dazu um etwas Kommunikationen abzubilden. Innerhalb des Sequenzdiagramms gibt es zwei Arten von Nachrichten:

Synchrone
Die Anwendung macht erst weiter wenn der Task abgeschlossen ist.
Asynchrone
Der Task läuft im Hintergrund weiter und meldet sich wenn er fertig ist.

Vorgehen beim Zeichen

  • relevante Szenarien aus Use-Case
  • Stichworte
  • beteiligte Akteure festlegen
  • beteiligte Klassen als Kommuniktaionsparter
  • Ablauf und Strukurierung festlegen
  • Diagramm entwerfen

Verteilungsdiagramm

Systemumgebung aufzeigen. Zeigt auf wo die Applikation(Artifakt) deployed wird und welche Ressourcen benötigt werden. Betriebsinfrastruktur designen.

Deployment-Spe -> Artefakt -> Knoten \newpage

Use Cases

Beschreibt Use Cases im Detail um zusätzliche Informationen zur Verfügung zu stellen.

Test Cases

Delegates

Delegates erlauben es einem Methoden als Parameter zu übergeben. Dies bedeutet das man im Code dynamisch die Methode ändern kann die ausgeführt werden soll. Dadurch kann man etwa diverse generische Methoden definieren und die Daten dann durch die entsprechende Methode schicken ohne das man dies fix auscodieren müsste. Man spricht bei Delegates von Referenzen auf Methoden.

Events

Dienen dazu Änderungen in Daten oder Inputs an andere Klassen oder Objekte zu übermitteln.

Publisher
Sendest das Ereignis.
Subscriber
Empfängt das Ereignis von einem abonnierten Publisher und können darauf reagieren.

Die Methoden der Subscriber werden nacheinander abgearbeitet.

Interfaces

Definieren wie die Signature einer Klasse zu sein hat. Sie sehen zwar ähnlich aus wie Klassen, erhalten jedoch keinerlei Logik. Eine Klasse kann mehr als ein Interface implementieren.

Design Patterns

Singleton

Singleton werden dazu verwendet um sicherzustellen das nur eine einzige Instanz einer Klasse vorhanden ist. Alternativ könnte dies auch mit einer statischen Klasse realisiert werden. Allerdings sind statische Klassen nicht wirklich OOP und können keine Interfaces implementieren.

Lazy
Lazy kommt daher das die Instanz erst beim ersten Aufruf erstellt wird. Lazy singletons haben noch das Problem das sie per default nicht Thread safe. Dies kann über einen lock behoben werden. Der Performance Impact ist jedoch sehr hoch.
Eager
Eager bedeutet das die Instanz bereits beim Ausführen der Anwendung erstellt wird.

Proxy

Proxys sind Stellvertreter Klassen welche anstelle des eigentlichen Objekts aufgerufen werden. Dies kann etwa dazu verwendet werden um Code zu "verstecken", für Performance Optimierung oder um zusätzliche Funktionen hinzuzufügen welche in der Subject Klasse nicht vorhanden oder notwendig sind.

Mediator

Ein Mediator ist ein Vermittler zwischen zwei Objekten. Die Objekte können dem Mediator jeweils eine Nachricht zukommen lassen. Der Mediator kann auch wieder eine Nachricht an die Objekte schicken. Die Objekte müssen dabei jeweils keine Kenntnisse von einander haben.

Observer

Dieses Pattern erlaubt es einem Objekt ein anderes Objekt zu "beobachten" und von diesem über Änderungen informiert zu werden. Dieses Pattern basiert auf Events. Es ist etwa dann sinnvoll wenn verschiedene Code Teile einen Status eines Objektes wissen müssen. Anstatt immer zu schauen welchen Status es hat, informiert das Objekt von sich aus wenn es seinen Status ändert.

ORM

Objekt Relationales Mapping bezeichnet den Vorgang Objekte in Tabellen zu speichern. 1:n Beziehungen oder Vererbungen stellen dabei besondere Herausforderungen dar. Im Idealfall ist dabei jede Zeile in einer Tabelle ein Objekt und jedes Attribut wird über eine Spalte abgebildet. Die Datenbank verhält sich für die Applikation dann wie eine OO-Datenbank. Die Relationale Basis wird abstrahiert.

Vererbungen in Datenbanken

TPH

Alle Attribute ausser ID und Discriminator müssen "nullable" sein. Alle Attribute der Klassen werden direkt in einer einzigen Tabelle gespeichert. Über den Discriminator wird angegeben welche Klasse die Zeile abbildet.

Vorteil

  • Sehr schnell

*Nachteil*

  • Kein Richtiges Datenmodell
  • Alle Attribute der Child Klassen werden abgebildet egal ob sie von den meisten Childs benötigt werden oder nicht.

TPT

Pro Daten Typ wird eine Tabelle erstellt welche über einen Foreign Key auf ihre "Parent" Tabelle verweist. Entspricht der dritten Normalform.

Vorteile

  • Normalisiert, wenn man etwas ändert gilt die Änderung für alle Datentypen.
  • Vermeidet Redundante Daten

*Nachteil*

  • Benötigt viele Joins um ein Objekt darzustellen
  • Nicht so schnell

TPC

Jeder Daten Typ wird komplett abgebildet. Vorteile

  • Sehr schnell

*Nachteile*

  • Führt zu sehr vielen redundanten Daten. Da geteilte Attribute immer wieder neu abgebildet werden.

Entity Framework

Entity Framework ist das ORM von CSharp.

Models

Navigation Properties

Navigation Properties werden dazu verwendet das man die jeweiligen "Partner" einer Objekt Beziehung direkt verwenden kann im Code. Dies jeweils auch in beide Richtungen.

Lösungsansätze

Model First

Bei Model First wird zuerst das Datenmodell "gezeichnet". Sprich man erstellt zuerst ein ERM. Aus diesem ERM wird dann automatisch ein Datenbank Schema sowie die Klassen für die Applikation generiert.

Funktioniert eher dürftig und in der Regel muss man dann trotzdem noch von Hand nachhelfen.

Database First

Bei Database First programmiert man zuerst die Datenbank "von Hand" in der jeweiligen Sprachen. Visual Studion generiert dann aus der bestehenden Datenbank die Klassen.

Wir in der Regel dann verwendet wenn man mit einer bestehenden Datenbank arbeiten muss.

Code First (New Database)

Man erstellt zuerst die Klassen und Mappings. Anschliessend erstellt einem Visual Studio die Datenbank daraus. Änderungen an den Klassen werden über Migrations an die Datenbank weitergegeben. Dies hat teilweise das Problem das wenn man einen Wert hat der nicht null sein darf man bei allen bestehenden Datensätzen einen Wert ergänzen muss.

Code First (Existing Database)

Man erstellt die Klassen und Mappings in Visual Studio passend zur bereits bestehenden Datenbank. Sehr Aufwändig.

SOA

Aufgaben welche an mehreren Orten verwendet werden können gut in einen Service ausgelagert werden.

Vorteile

  • Komplexitätsreduktion
  • höhere Wiederverwendbarkeit
  • Einfachere Wartbarkeit
  • Kostenreduktion
  • bessere Flexibilität und Skalierbarkeit
  • Paralelle Entwicklung wird vereinfacht da die Teams unabhängig voneinander arbeiten können.

*Nachteile*

  • Abhängigkeit, ein Service wird von mehreren Projekten benutzt
  • Sicherheit, bietet eine zentrale Angriffsmöglichkeit
  • komplexe Architektur -> mehr Schnittstellen
  • höhere Verfügbarkeit notwendig

Grundsätze

  • Ein Service ist autark
  • Ist im Netzwerk verfügbar
  • Ist in einem Verzeichnis auffindbar
  • Hat eine definierte Schnittstelle
  • Ist plattformunabhängig

Kopplungen

Feste Kopplung
Der Service ist immer am gleichen Ort erreichbar.
Lose Kopplung
Es werden mehrere Orte gleichzeitig angefragt. Der Service der die Anforderung erfüllen kannn und am schnellsten Antwort gibt wird verwendet.

SOA Triangel

SOA Stolpersteine

  • Know How nicht vorhanden
  • Komplexität wird unterschätzt
  • SOA wird möglichst billig eingebaut
  • Wird für Probleme verwendet wo es nicht nötig ist.

Verteile Anwendungen

Ein verteiltes System ist eine Menge autonomer Computer welche über Nachrichten kommunizieren und aneinander gekoppelt sind. Darüber lassen sich dann verteilte Anwendungen realisieren.

Ein Ausfall eines Rechners ist für das System in Regel nicht weiter relevant da die Aufgabe von einem anderen Rechner übernommen werden kann. Einzelne Rechner sehen in der Regel nur einen Teil des Systems.

Eigenschaften

  • skaliert sehr gut
  • erlaubt es viele Aufgaben gleichzeitig auszuführen
  • Offenheit durch definierte Schnittstellen

WCF

  • Standard in .NET
  • unterstützt alle gängigen Standards, etwa SOAP
  • Kann über diverse Kanäle kommunizieren und als Webserver, Windows Service oder manuell (.exe) gestartet werden.

3-Modelle

Programming Model
Soap Service, HTTP Service, Data Service, etc.
Service Model
Data Contract, Service Contract, Service Behaviour
Channel Model
Format(JSON, XML), Transport(HTTP, TCP), Protocol (SOAP, HTTP, Open Data Protocol)

Unterschiede zu Webservice

Webservice WCF-Service
Kommunikation über HTTP Kommunikation, TCP, MSMQ
Request-Response, Simplex Simplex, Request-Response, Duplex
Stateless (Webserver) Webserver, Windows Service, self-hosted (.exe)

ABC-Model

Das ABC-Model beantwortet die folgenden Fragen:

  • Wo befindet sich der Service?
  • Wie kann ein Client darauf zugreifen?
  • Welche Funktionen bietet der Service an?
(A)ddress
Gibt die URI an.
(B)inding
Definiert die Protokolle, Nachrichten Format, Encoding, etc.
(C)ontract
Definiert die Schnittstelle des Service.

Kommunikationsarten

Request-Response

Der Client startet eine Anfrage an den Server welcher dann eine Antwort zurück gibt. Der Client macht immer den Anfang. Dies wäre wohl REST.

Simplex

Die Kommunikation geht nur in eine Richtung. Es werden keine Antworten gesendet.

Duplex

Client und Server können gleichberechtigt kommunizieren. Also sowohl Anfragen starten wie auch Antworten senden.

DataContract

Klassen welche über den Service verschickt werden sollen. Werden mit [DataContract] markiert. Die Properties die auch übertragen werden sollen werden mit [DataMember] markiert. Dies ermöglicht mit den Klasse auf dem Client zu arbeiten ohne das man sie noch einmal spezifisch definieren müsste.

Discovery

Managed Discovery

Der Client schickt eine "probe" an diverse Service Provider. Entspricht ein Service den Anforderungen ("prope match") verbindet sich der Client darauf. Läuft immer über einen Discovery Service der als "Telefonbuch" funktioniert.

Ad-hoc

Die Kommunikation läuft direkt zwischen dem Client und dem Service. Führt zu einer höheren Last im Netzwerk. Läuft über Multicast und UDP.

Layers

  • UI
  • Business Layer
  • Data Layer
  • Data Base

Die Aufteilung in Schichten erlaubt es einem die UI auszutauschen. Die Problematik ist jedoch das die verschiedenen Layers die Klassendefinition kennen. Um dieses Problem zu lösen gibt es den sogenannten Common Layer. Die Layers haben auch den Vorteil dann das man die Änderung nur an einem Ort machen muss.

Parallel Programming

Parallelität-im-Netzwerk

Bedeute das gleichzeitige rechnen in einem Netzwerk. Etwa beim Seti Projekt.

Vorteile

  • Spart Zeit und Geld
  • Grössere Probleme abarbeiten
  • Mehrere Probleme gleichzeitig berechnen
  • Bessere Ausnutzung der Leistung

Nachteile

  • Kompliziert
  • Concurrency, gemeinsame Ressource müssen verwaltet werden.
  • Kann zu aufwendig sein.
  • Schwierig zu debuggen.

Lock

Locked eine Ressource für den aktuellen Thread. Locks können auch in nested Loops vorkommen.

Monitor

Lock ist eigentlich ein Wrapper um Monitor. Für erweiterte Applikation ist es allenfalls nötig den Monitor selber zu implementieren. Für den normalen Gebrauch ist Lock föllig genügend.

Mutex

Wird dazu verwendet um Prozess gegeneinader zu sperren. Etwa um zu verhindern das eine Applikation mehrfach ausgeführt wird.

Semaphore

Beschränkt die mögliche Anzahl Threads.

Parallel.Invoke

Gute und einfache Möglichkeit um mehrere Methoden parallel auszuführen. Bietet einem jedoch nicht wirklich eine Kontrolle. Der Code darf also keine Konflikte haben.

Tasks

Tasks sind auch eine Möglichkeit um Parallelisierung zu erreichen. Sie sind etwas weniger Ressourcen intensiv als Threads da sie vom TPL automatisch verwaltet werden.

Tasks vs. Invoke

Invoke synchronsiert die ausgeführten Methoden. Heisst sie fährt im Code erst weiter wenn alle Methoden ausgeführt wurden.

Die Taks laufen einfach durch und achten nicht darauf ob einer früher oder später fertig ist.

Glossary

<>
Objekt Relationales Mapping
<>
Service Oriented Architecture
<>
Table Per Hierarchy
<>
Table Per Type
<>
Table Per Concret Type
<>
Windows Communication Foundation
No Comments
Back to top