SE

Requierments Engineering

Begriff von RE:

• Bedingung oder Eigenschaft, die ein System benötigt,
  • um ein Problem zu lösen oder
  • um ein Ziel zu erreichen oder
  • um einem Vertrag, Standard oder Ähnlichem zu genügen

Probleme

Kunden

• Kunden wissen nicht, was sie wirklich wollen
• Kunden benutzen ihre eigene Fachsprache
• Politische und organisatorische Faktoren können Anforderungen beeinflussen

Widersprüche

• Verschiedene Stakeholder können widersprüchliche Anforderungen haben
• Neue Stakeholder mischen sich ein Evolution
• Requirements always evolve
• Daher wichtig: plan forchange

4 Schritte des Requierments Engineering

1. Anforderungsermittlung
   • Sammeln von Anforderungen
   • z.B. durch Anwendergespräche, Dokumenten-Studium
2. Anforderungsanalyse
   • Klassifizierung, Bewertung, Vergleich und Prüfung
   • z.B. Kosten-/Nutzen-Aspekte, Konsistenz, Vollständigkeit
3. Anforderungsbeschreibung
   • Beschreibung in einheitlicher Form (z.B. als Anwendungsfälle)
4. Anforderungsrevision – Erneute Prüfung/Änderung von Anforderungen
   • ggf. nur in formellem Änderungsverfahren

Anforderungsermittlung

• Stakeholder-basiert
  • Vorteil: Anforderungen werden nach Personen gebündelt aufgenommen
  • Nachteil: Nutzen/Sinn/Ziel des Systems tritt in den Hintergrund
• Szenario-basiert
  • Vorteil: Anforderungen orientieren sich an den „normalen“ Abläufen des Systems
  • Nachteil: Seltene Abläufe oder indirekt betroffene Institutionen werden leichter vergessen

usecase

ist die Spezifikationvon einer Sequenz von Aktionen, einschließlich Varianten, dass ein System, interagierend mit Aktorendes Systems, ausführen kann”.

Szenario

ein bestimmter Pfad von auftretenden Aktionen, startend von einem bekannten, initialen Zustand

Anforderungsanalyse

• Funktionale Anforderungen: Szenario-basiert
• Nicht-funktionale Anforderungen: Stakeholder-basiert

Präzise Metriken

Eigenschaft|Metrik –|–: Performanz|Processed transactions/second User/Event response time Screen refresh time Größe|K Bytes; Number of RAM chips Handhabbarkeit|Training time/Rate of errors made by trained users Zuverlässigkeit|Mean time to failure/Probability of unavailability/Rate of failure occurrence Robustheit|Time to restart after failure/Percentage of events causing failure/Probability of data corruption on failure Portabilität|Percentage of target dependent statements/Number of target systems

Anforderungsbeschreibung

Anforderungen müssen systematisch und einheitlich beschrieben werden Gute Anforderung:
Korrekt

• Eindeutig
• Vollständig
• Konsistent
• GewichtetnachWichtigkeitund Stabilität
• Überprüfbar
• Modifizierbar
• Nachvollziehbar

  Volere

  5 Hauptkategorien：

  1. Project Drivers
  2. Project Constraints
  3. FunctionalRequirements
  4. Non-FunctionalRequirements
  5. Project Issues

Anforderungsdefinition bestehen gewöhnlich aus natürlicher Sprache mit zusätzlichen Diagrammen und Tabellen (z.B. UML)
3 Arten von Probleme:

• Lack ofclarity: Schwierig präzise und gleichzeitig leicht-verständliche Dokumente zu schreiben
• Requirementsconfusion: Funktionale und nicht-funktionale Anforderungen sind oft vermischt
• Requirementsamalgamation: Mehrere unterschiedliche Anforderungen werden zusammen ausgedrückt.

Anforderungsrevision

ErneutePrüfung und ggf. Anpassung der Anforderungen:

• Validität
• Konsistenz
• Vollständigkeit
• Realisierbarkeit

Die Herausforderungen in der Entwicklung heutiger softwarebasierter Systeme bestehen in der Komplexität der Anwendungen und ihren vielfältigen Verhaltens-,Qualitäts- und Integrationsanforderungen. Dem Requirements Engineering kommt hier eine Schlüsselaufgabe zu.
EN:RE is the most important phase of the Software Development Life Cycle. The specifications act as the contract between the software users and the developers. Therefore the importance of Requirement Engineering is enormous to develop effective software and in reducing software errors at the early stage of the development of software

Responsibility-Driven Design

Warum

is a design technique in object-oriented programming, which improves encapsulation by using the client–server model. It focuses on the contract by considering the actions that the object is responsible for and the information that the object shares.

DE:Responsibility-DrivenDesign ist eine (Analyse- und) Design-Technik, die gut in Kombination mit verschiedenen Methoden und Notationen arbeitet.

Frage:

• Welche Kriterien gibt es, mit denen ich potentielle Klassen identifizieren kann?
  1. Suche nach Nomen Phrasen
  2. Verfeinere die Liste von Kandidaten
     • physikalische Objekte
     • konzeptuelle Entitäten
     • Wähle ein Wort für ein Konzept
     • Vorsicht bei Adjektiven
     • Kategorien von Klassen
     • Interfaces zum System
     • Attributwerte
• Was sind Verantwortlichkeiten von Klassen und wie kann ich sie identifizieren? repräsentieren die öffentlichen Leistungen, die ein Objekt seinen Klienten anbietet
  Identifizieren:
  1. Studiere die Requirements-Spezifikationen:
  + Verben hervorheben und bestimmen, welche Verantwortlichkeiten diese repräsentieren
  + walk-through vom System machen
  2. Studiere die Kandidatenklassen:
  Klassennamen $\rightarrow$ Rollen $\rightarrow$ Verantwortlichkeiten

• Wie kann das Identifizieren von Verantwortlichkeiten beim Identifizieren von Klassen helfen?

• Was sind Kollaborationen und wie stehen sie in Beziehung zu Verantwortlichkeiten?
  sind Benutzeranfragen (client requests) an Dienste, die benötigt werden, um Verantwortlichkeiten zu erfüllen
  Kollaborationen können fehlenden Verantwortlichkeiten offenbaren
• Wie kann ich abstrakte Klassen identifizieren?
  1. Gruppiere verwandte Klassen mit gemeinsamen Attributen
  2. Führe abstrakte Oberklassen ein, die diese Gruppe repräsentieren
  3. Kategorien sind gute Kandidaten für abstrakte Klassen
• Welche Kriterien gibt es, um gute Klassenhierarchien zu entwerfen?
  1. Modelliere eine kind-of Hierarchie
  2. Schiebe gemeinsame Verantwortlichkeiten so hoch wie möglich
  3. Stelle sicher, dass abstrakte Klassen nicht von konkreten Klassen erben
  4. Eliminiere Klassen, die keine neue Funktionalität hinzufügen

• Wie kann das Refaktorisierenvon Verantwortlichkeiten Hierarchien verbessern?

• Leiten Sie aus einer Anforderungsbeschreibung Klassen, Verantwortlichkeiten und Kollaborationen ab

UML

Warum UML

• Reduziert Risiken durch das Dokumentieren von Annahmen
• Repräsentiert Industriestandard
• Ist hinreichend gut-definiert
• Ist offen

Frage

1. Was ist der Zweck von usecaseDiagrammen The purpose of a use-case diagram is to demonstrate the different ways that an user might interac with a system
2. Warum beschreiben Szenarien Objekte und nicht Klassen Ein Szenario beschreibt nur ein typisches Beispiel(Instanz) eines use cases. Object shows a snapshot the detailed
   state of a system at a point in time. So beschreibt Szenario Objekte aber nicht Klassen.
3. Wie können zeitliche Bedingungen in Szenarien beschrieben werden Sequenzdiagramm
4. Wie spezifiziert und interpretiert man Nachrichten-Labels in einem Szenario werden als horizontale(oder schräge) Pfeile vom Sender zum Empänger bezeichnet.
5. Wie benutzt man genestete Zustandsdiagramme, um Objektverhalten zu modellieren zeitliche Evolution eines Objekt von einer gegebenen Klasse im Abhängigkeit von Interaktion mit anderen Objekten innerhalb und außerhalb des Systems.
6. Was ist der Unterschied zwischen externen und internen Transitionen ? Externe: markieren Kreisbögen zwischen Zuständen
   Interne: sind Teil der ausgelösten Operation eines Zustandes

Design Patterns

Warum Design Patterns wichtig?

• Gemeisame Sprache für Entwickler
  • Verbessert Kommunikation
  • Missverständniss vorbeugen
• Lernen aus Erfahrung
  • ein guter Designer werden ist schwer
  • erprobte Lösungen für wiederkehrende Problem

Archtektur und Design

5 Kreterien：

• Modular Decomposability
• Modular Composability
• Modular understandability
• Modular Continuity
• Modular Protection

5 Regeln

• direct Mapping
• few interface
• small interface
• explicit interface
• information hidding

Frage

• Inwiefern wirkt sich die Architektur auf das Softwaresystem aus?
  Architektur beschreibt groben Aufbau eines Systems. Welche Komponente/Modul gibt es
  und wie interagieren sie.
• Wie kann die Auswahl einer geeigneten Architektur den Entwurf / Implementierung vereinfachen Client-Server Archtektur
• Was bedeutet Kopplung und Kohäsion auf Architekturebene
  Cohesion: ein Maß, wie gut Teiler einer Komponente zusammen gehören
  Coupling: ein Maß der Stärke der Verbindung zwischen Systemkomponenten
• Archtectural Style defines a vocabulary of compotents and contector types
  and a set of constraints on how they can be combined
• Für welche Szenarien sind MVC oder Pipes and Filters sinnvoll?
  • MVC: Nützlich, wenn es mehrere Wege gibt auf die Daten zuzugreifen
    Ermöglicht das Ändern der Daten unabhängig von deren Repräsentation
    Unterstützt unterschiedliche Präsentationen der gleichen Daten
  • Pipes and Filters: Anwendung kann in mehrere unabhängige Teile zerlegt werden
    Wenn viele Transformationen auf Daten nötig sind
    Wenn Flexibilität notwendig ist
• Was sind Limitierungen von monolithischen Systemen? Bei häufige Änderungen muss monolithisches System complete neu gebaut werden
• Was sollten Schichten nicht auf Elemente in Schichten darüber Zugriff haben?
  Schichten sind normalerweise beschränkt, so dass Elemente nur Andere Element in
  der gleichen Schicht oder Elemente von der Schicht darunter sehen können
• Wann macht der Einsatz von MicroServices Sinn und wann nicht?
  Ja: Häufige Änderungen ,Skalierbarkeit der Hardware, Modularität, Integration, Distributed development Nicht: nicht richtige Mindset der Entwickler, nicht klare Definition eines MicroServices ,Immer hoch kommunikation zwiesch Teams, comlexe Test und Deployment
• Welche Kriterien für den Einsatz bestimmter Architekturmuster gilt es zu beachten?
  • Welche Struktur des Softwaresystems?
    Komponenten-orientiert, monolithisch, Schichten, Pipes and Filters
  • Wie kommunizieren die Sub-Systeme? Ereignis-basiert, Publish-Subscribe , ansynchrone Nachrichten
  • Wie sind die Sub-Systeme verteilt? Client-Server, shared nothing, Peer2Peer, service-orientiert, Cloud

Implementierung

1. Nennen/Erklären Sie X Probleme variantenreicher Software. Skizzieren Sie mögliche Lösungen
2. Was sind querschneidende Belange? Was ist das Feature Traceability Problem?
   nicht alle Features in einem Programm können mittels Objekt(Klasse) modularisiert werden.
   Featurs sind semantisch zusammenhängende Einheiten
   Aber ihre Implementierung manchmal vertreut, vermischt, copiert im Code.
3. Erläutern Sie die Begriffe Scattering, Tangling, Tyrannei der dominanten Dekomposition
   • Scattering: Code, die zu einem Feature gehört, ist nicht modularisiert, sondern in gesamten Programm verteilt
   • Tangling: Code, die zu verschiedenen Features gehört, ist in einem Modul vermischt
   • Tyrannei: Problemstellung nur in einer Richtung modularisierbar. Entwicklern wählen eine Dekomposition aus,
     aber einige andere crosscut. Gleichzeitige Modularisierung entlang verschiednener Dimensionen nicht möglich.
4. Nennen/Erläutern Sie X Vorteile/Nachteile von Präprozessoren Vorteile:
   • in vielen Sprachen bereits enthalten
   • meist Programmer bereits erkennen
   • sehr einfache Programmierkonzept: markieren und entfernen
   • sehr flexible
     Nachteile:
   • unlesbarer Quelltext
   • Komplexität durch beliebige Schachtelung
   • Fehleanfähigkeit durch Komplexität und unkontrollen undisziplinierten Einsatz
   • Feature Code ist komplett verstreut(Feature-Traceability-Problem)
   • verhindert/erschwert Tool Support
5. Was ist das Feature Traceability Problem?
   Feature Code ist komplett verstreut(Feature-Traceability-Problem), ist es schwer, um Fehler von X Feature zu finden
6. Schreiben Sie einen einfachen Taschenrechner. Eingaben für den Taschenrechner werden als Kommandozeilenparameter übergeben. Als Basis-Feature soll die Addition implementiert sein. Implementieren Sie Subtraktion und Multiplikation als optionale Feature jeweils mit den folgenden Techniken: Parameter und Präprozessoren.

   class conf{
    public:
       static bool Sub;
       static bool Mul;
       conf(){
           Sub = false;
           Mul = false;
       }
       conf(bool a, bool b){
           if(a) Sub = true;
           if(b) Mul = true;
       }
   
   }
   

   class Expression_Evaluator{
       //code
       #ifdef SUB
       //code
       #else
       //code
       #ifdef Mul
       //code
       #endif
       //code
       #endif
       //code
    }
   

Clean Code

Frage

1. Was bedeutet clean code?
   Als sauber bezeichnen Softwaretechniker in erster Linien Quellcode, aber auch Dokumente, Konzepte, Regeln und Verfahren, die intuitiv zu verstehen ist.
2. Was heißt Refactoring, wozu ist es gut?
   Veränderung der Struktur von Quelltext, ohne die Funktion zu ändern
   Wozu:
   • Wartung von Quelltext
   • Verbesserung der Lesbarkeit von Quelltext
   • Code-Rettung

Testen

Frage

1. Warum brauchen wir Tests/Verifikation/Code Reviews?
   • sicherstellen, das Programm nicht abstürzt
   • regressiontest, keine neuen Fehler
   • sicherstellen, die Anforderung erfüllen
   • sicherstellen, keine Seiteneffekt
   • Fehler finden
2. Was kann man mit Tests nicht zeigen? Warum?
   show the absence of bugs
   presume guilty until proven otherwise
   Man muss annehmen, dass Programm fehlerhaft ist. Nicht, dann es korrekt ist.
3. Nennen/Erklären Sie die 4 vorgestellten Ebenen von Tests
4. Erklären Sie Black-Box/White-Box/Regressions/ Nightly/Daily-Builds
   • ein Methode, die die Funktionalitäten eines Programm(application) Ohne Hineinschauen deren Interne Struktur oder Leistung prüfen
   • test internal structure or works of an application, as opposed to its functionality
   • Nach jeder Änderungen werden alle Testfälle wieder ausführt. Sicherstelle, was vor der Änderung funktioniert hat, auch nach
     der Änderung weiterhin funktioniert
   • Release eines großen Projekts wird zu fest definiertem Zeitpunkt erstellt Zeitpunkt: wenn keine Änderung am Code zu erwarten ist