Software Engineering 1

Jetzt loslegen. Gratis!
oder registrieren mit Ihrer E-Mail-Adresse
Software Engineering 1 von Mind Map: Software Engineering 1

1. Domain Modelierung

1.1. Finden von Konzepten

1.1.1. Strategie 1: Von existierenden Modellen ausgehen

1.1.2. Strategie 2: Checkliste mit Kategorien

1.1.3. Strategie 3: Substantive suchen

1.2. Multiplizitäten

1.2.1. * -> zero or more; "many"

1.2.2. 1 .. * -> one or more

1.2.3. 1 .. 40 -> one to 40

1.2.4. 5 -> exactly 5

1.2.5. 3,5,8 -> exactly 3, 5, or 8

1.3. Refining the Domain Model

1.3.1. Aggregation

1.3.1.1. Spezielle Assoziation zur Modellierung von Ganzes-Teile-Beziehungen, aus „Has-a“-Beziehung

1.3.1.2. ganzes <>-- teil

1.3.2. Composition

1.3.2.1. Composite Aggregation oder Composition: Aggregation, bei welcher, die Teile ausschliesslich dem Ganzen gehören

1.3.2.2. ganzes <0>-- teil

1.3.2.3. Multiplizität ist beim Ganzen genau 1!

2. GRASP

2.1. General Responsibility Assignment Patterns

2.1.1. Pattern

2.1.1.1. Information Expert

2.1.1.1.1. geringe Kopplung (low coupling) und hohe Kohäsion (high cohesion)

2.1.1.2. Creator

2.1.1.2.1. lose Kopplung (low coupling)

2.1.1.3. High Cohesion

2.1.1.3.1. Mass für den inneren Zusammenhalt von Klassen

2.1.1.4. Low Coupling

2.1.1.4.1. Mass für die Abhängigkeit eines Elementes (z.B. einer Klasse) von Umgebung (z.B. von anderen Klassen)

2.1.1.4.2. Teile Responsibilities so zu, dass eine lose Kopplung resultiert

2.1.1.5. Controller

2.1.1.5.1. Objekt verantwortlich, Systemereignisse zu verarbeiten, gehört nicht zum Userinterface

2.1.1.6. Polymorphism

2.1.1.6.1. GoF-Pattern

2.1.1.7. Pure Fabrication

2.1.1.7.1. Technologie-Know-How gehört nicht in Domainklasse

2.1.1.8. Indirection

2.1.1.8.1. Objekt einführen, das zwischen Objekten vermittelt

2.1.1.8.2. GoF-Pattern

2.1.1.9. Protected Variations

2.1.1.9.1. 1. Bereiche identifizieren, die Änderungen unterworfen sind

2.1.1.9.2. 2. Variation Points von Umgebung abschotten (d.h. stabile „Interfaces“)

2.1.1.9.3. Nutzen

2.1.1.9.4. alternative Namen

3. Visibility

3.1. Attribute Visibility

3.1.1. a besitzt als Attribut Referenz auf b (Aggregation oder Assoziation)

3.1.2. existiert über längeren Zeitraum

3.2. Parameter Visibility

3.2.1. b ist ein Parameter einer Methode von a

3.2.2. Temporäre Form der Sichtbarkeit

3.3. Local Visibility

3.3.1. b ist lokales Objekt in Methode von a

3.3.2. Temoräre Form der Sichtbarkeit, wenn

3.3.2.1. 1. Lokale Instanz erzeugt u. lokaler Variablen zugewiesen

3.3.2.2. 2. Rückgabwert ist Objekt, das lokaler Instanz zugewiesen

3.4. Global Visibility

3.4.1. b ist global sichtbar

3.4.2. Permanente Form der Sichtbarkeit

3.4.3. Sollte eigentlich nie verwendet werden (hohe Kopplung!)

4. Architektur

4.1. Views

4.1.1. Logical View

4.1.1.1. Gliederung in Packages und Klassen

4.1.1.2. statisch

4.1.1.3. dynamisch

4.1.1.4. Layer

4.1.2. Process View

4.1.2.1. Nebenläufigkeit

4.1.3. Deployement View

4.1.3.1. Zuordnung auf Hardware-Elemente

4.1.3.2. Tier

4.1.4. Implementation View

4.1.4.1. Quellcode, ausführbare Programme

4.1.5. Use Case View

4.1.5.1. Realisierung Architektur- relevanter Use Cases

4.1.6. Data View

4.1.6.1. Persistente Datenspeicherung

4.2. Definition Software Architektur

4.2.1. signifikante Entscheidungen zur Organisation eines SW-Systems

4.2.2. Struktur

4.2.2.1. Anordnung der Strukturelemente - statisch

4.2.2.2. Interfaces zwischen Strukturelementen

4.2.2.3. Zusammenspiel zwischen Strukturelementen - dynamisch

4.3. Ausgangslage für Architekturen

4.3.1. Funktionale Anforderungen

4.3.2. Nichtfunktionale Anforderungen

4.3.3. Randbedingungen (constraints)

5. Objektorientierte Analyse

5.1. klassisch

5.1.1. Domainmodell mit Operationen

5.1.2. Interaktionsdiagramm zwischen Objekten

5.1.3. "white box" Analyse

5.2. Larman

5.2.1. Domainmodell ohne Operationen

5.2.2. Systemsequenzdiagramm SSD

5.2.3. System als "black box"

5.2.4. Contracts und Systemoperationen

5.3. Activity-Diagramm

5.3.1. Basiselemente

5.3.1.1. Start & End

5.3.1.1.1. An initial or start node is depicted by a large black spot, as shown below.

5.3.1.1.2. There are two types of final node: activity and flow final nodes. The activity final node is depicted as a circle with a dot inside.

5.3.1.2. Activity

5.3.1.2.1. An activity is the specification of a parameterized sequence of behaviour. An activity is shown as a round-cornered rectangle enclosing all the actions, control flows and other elements that make up the activity.

5.3.1.3. Action

5.3.1.3.1. An action represents a single step within an activity. Actions are denoted by round-cornered rectangles.

5.3.1.4. Control Flow

5.3.1.4.1. A control flow shows the flow of control from one action to the next. Its notation is a line with an arrowhead.

5.3.1.5. Fork & Join

5.3.1.5.1. Forks and joins have the same notation: either a horizontal or vertical bar (the orientation is dependent on whether the control flow is running left to right or top to bottom). They indicate the start and end of concurrent threads of control. The following diagram shows an example of their use

5.3.1.6. Branch mit Kondition & Merge

5.3.1.6.1. Decision nodes and merge nodes have the same notation: a diamond shape. They can both be named. The control flows coming away from a decision node will have guard conditions which will allow control to flow if the guard condition is met. The following diagram shows use of a decision node and a merge node.

5.3.2. Weitere Elemente

5.3.2.1. Swimlanes

5.3.2.2. Objectflow

5.3.2.3. Partition

5.3.2.3.1. An activity partition is shown as either a horizontal or vertical swimlane. In the following diagram, the partitions are used to separate actions within an activity into those performed by the accounting department and those performed by the customer.

6. Testen

6.1. Spezifikationsorientiertes Testen

6.1.1. Basis Use Cases

6.1.1.1. "tut's das, was der Kunde spezifiziert hat?"

6.1.2. Ein Szenario pro (Sub-) Use Case erstellen

6.1.3. Gut durch Kunden ausführbar

6.1.4. Black-box Test

6.2. Definition Testen

6.2.1. Ausführung von Software mit dem Ziel

6.2.1.1. Fehler zu finden

6.2.1.2. Sicherstellen, dass Vorgaben erfüllt

6.3. Anforderungen an Software Test

6.3.1. Geplant -> Testplanung

6.3.2. Systematisch spezifiziert -> Testspezifikation

6.3.3. Resultate festgehalten -> Testprotokoll

6.3.4. reproduzierbar

6.3.5. automatisiert

6.4. Test kategorisieren

6.4.1. link auf funktionale / nf Anforderungen!!!

6.5. Software-Prüfung

6.5.1. Dynamische Prüfung: Code ausführen

6.5.1.1. Testen

6.5.1.2. Dynamische Analyse

6.5.2. Statische Prüfung

6.5.2.1. Metrikanalyse

6.5.2.2. Ohne Rechner: Review

6.6. Begriffe: Verifikation und Validierung

6.6.1. Verifikation (verification)

6.6.1.1. „Are we building the product right?“

6.6.2. Validierung (validation)

6.6.2.1. „Are we building the right product?“

6.7. Testmethoden

6.7.1. Black-Box Tests

6.7.1.1. Äquivalenzklassen

6.7.1.1.1. Wertebereich einer Eingabegrösse, für welche der Prüfling voraussichtlich das gleiche Verhalten zeigt

6.7.1.1.2. einTestfallpro Äquivalenzklasse

6.7.1.2. Grenzwertanalyse

6.7.1.2.1. Fehler sehr oft an Grenzen zulässiger Eingabewertebereiche

6.7.1.2.2. wählt Testfälle an den Grenzen

6.7.1.2.3. Erweiterung der Äquivalenzklassenmethode

6.7.1.3. Zustandbasiertes Testen

6.7.2. White-Box-Tests

6.7.2.1. Kontrollfluss-orientiertes Testen

6.7.2.1.1. Anweisungsüberdeckung

6.7.2.1.2. Zweigüberdeckung

6.7.2.1.3. Pfadüberdeckung

6.7.2.2. Datenfluss-orientiertes Testen

6.8. Testüberdeckung (test coverage)

6.8.1. Anweisungsüberdeckung (statement coverage)

6.8.1.1. Prozentualer Anteil der Anweisungen, die in Test ausgeführt werden

6.8.1.2. 100% Anweisungsüberdeckung ist Minimum

6.8.2. Zweigüberdeckung

6.8.2.1. Prozentualer Anteil der Kanten (Zweige), die in Test durchlaufen werden

6.8.2.2. Eine 100% Zweigüberdeckung enthält auch eine 100% Anweisungsüberdeckung

6.8.2.3. Zusätzlich werden auch alle „leeren Zweige“ durchlaufen

6.8.3. Pfadüberdeckung

6.8.3.1. Prozentualer Anteil der Pfade, die in Test durchlaufen werden

6.8.3.2. Ein Pfad ist ein möglicher Weg durch den Kontrollgraph

6.8.3.2.1. kleine Programme mit Schleifen -> riesige Anzahl Pfade

6.8.3.2.2. 100% Pfadüberdeckung nicht zu erreichen

6.8.4. Bedingungsüberdeckung

6.8.4.1. Zusammengesetzte Bedingungen - > verschiedene Kombinationen testen

6.8.4.2. Einfache Bedingungsüberdeckung

6.8.4.2.1. alle atomaren Bedingungen mind. einmal true und einmal false

6.8.4.2.2. garantiert keine 100%ige Anweisungsüberdeckung

6.9. Automatisierte Tests

6.9.1. Vorteile

6.9.1.1. Wiederholbarkeit -> Regressionstests

6.9.1.1.1. Absicherung bei Änderung, Portierung, Erweiterung

6.9.1.1.2. geringe/keine Kosten bei Wiederholung

6.9.1.2. Eindeutige Spezifikation

6.9.1.2.1. Testcode ist Programmcode und damit eindeutig

6.9.2. Nachteile

6.9.2.1. Mehr Code zu schreiben und zu pflegen

6.9.2.2. Testcode ist Programmcode

6.9.2.2.1. Werden wirklich die richtigen Anforderungen getestet?

6.9.2.2.2. Was muss überhaupt getestet werden?

6.10. Right-BICEP

6.10.1. Are the results right?

6.10.2. Are all boundary conditions CORRECT?

6.10.2.1. Conformance

6.10.2.2. Ordering

6.10.2.3. Range

6.10.2.4. Reference

6.10.2.5. Existence

6.10.2.6. Cardinality

6.10.2.7. Time

6.10.3. Can you check inverse relationships?

6.10.4. Can you cross-check results using other means?

6.10.5. Can you force error conditions to happen?

6.10.6. Are performance characteristics within bounds?

6.11. A TRIP

6.11.1. Automatic

6.11.2. Thorough

6.11.2.1. sorgfältig

6.11.3. Repeatable

6.11.4. Independent

6.11.4.1. keine Abhängigkeit zwischen Tests

6.11.5. Professional

7. Einführung

7.1. Software Engineering Definition

7.1.1. Software engineering is the application

7.1.1.1. of a systematic, disciplined, quantifiable approach

7.1.1.2. to the development, operation, and maintenance of software,

7.1.1.3. that is, the application of engineering to software.

7.1.2. Elemente Software-Engineering

7.1.2.1. Prozesse

7.1.2.1.1. beschreibt, wer was wann und wie tut

7.1.2.2. Prinzipien

7.1.2.3. Modelle

7.1.2.4. Notationen

7.1.2.5. Werkzeuge

7.2. RUP

7.2.1. Inception

7.2.2. Elaboration

7.2.3. Construction

7.2.4. Transition

7.2.5. Disciplines

7.2.5.1. Eine Displin (discipline) ist eine Menge zusammengehöriger Aktivitäten (activities) eines bestimmten Schwerpunktes der Softwareentwicklung

7.2.6. Modelle

7.2.6.1. Domain-Modell

7.2.6.1.1. abstrahiert den Problembereich

7.2.6.1.2. Zerlegt Problem in verständliche Teile -> Konzeptionelle Klassen, Konzepte (domain objects)

7.2.6.1.3. Kommunikation zwischen verschiedenen Rollen in Entwicklung

7.2.6.2. Design-Modell

7.2.6.2.1. abstrakte Darstellung der Lösung

7.3. Syntax vs. Semantik

7.3.1. Syntax

7.3.1.1. bezeichnet die (formal) definierte äussere Form einer Notation

7.3.2. Semantik

7.3.2.1. ist die Bedeutung einer Notation

8. Softwareanforderungen

8.1. Klassifikation

8.1.1. Software Anforderungen

8.1.1.1. Funktionale Was?

8.1.1.2. Nichtfunktionale Wie gut?

8.1.1.2.1. Leistung

8.1.1.2.2. Mengen

8.1.1.2.3. Qualitätsmerkmale

8.1.1.2.4. Randbedingungen

8.1.1.2.5. Schnittstellenanforderungen

8.2. Use Cases

8.2.1. Begriffe

8.2.2. Formate

8.2.2.1. Brief

8.2.2.2. Casual

8.2.2.3. Fully Dressed

8.2.3. Teile eines Uses Cases

8.2.3.1. Primary Actor

8.2.3.1.1. Supporting Actors

8.2.3.1.2. Offstage Actors

8.2.3.2. Stakeholders and Interests

8.2.3.3. Preconditions

8.2.3.4. Post Conditions / Success Guarantees

8.2.3.5. Main Success Scenario

8.2.3.6. Extensions

8.2.3.7. Special Requirements

8.2.3.8. Technology and Data Variation Lists

8.2.4. Vorgehen Use Cases

8.2.4.1. 1. Systemgrenzen festlegen

8.2.4.1.1. Software, HW/SW-System, Organisation

8.2.4.2. 2. Primäre Aktoren identifizieren

8.2.4.2.1. Ihre Ziele als Systembenutzer werden durch System erfüllt

8.2.4.3. 3. Ziele jedes Aktoren identifizieren

8.2.4.3.1. So abstrakt wie möglich auf Ebene EBP

8.2.4.4. 4. Use Cases schreiben

8.2.5. Details Use Case Diagramme

8.2.5.1. «include»

8.2.5.1.1. Teil von Use Case in separaten Subfunction Use Case ausgelagert

8.2.5.2. «extend»

8.2.5.2.1. Erweitert Basis Use Case

8.3. Anforderungsspezifikation

8.3.1. Korrektheit

8.3.2. Eindeutigkeit

8.3.3. Vollständigkeit

8.3.4. Konsistenz

8.3.5. Mit Gewichtung versehen bezüglich Wichtigkeit / Priorität / Stabilität

8.3.6. Überprüfbarkeit

8.3.7. Änderbarkeit

8.3.8. Verfolgbarkeit

9. Systemsequenzdiagramme

9.1. Aktoren, System als Blackbox

9.2. SSD beschreibt Use Case Szenario

10. Konfigurationsmanagement

10.1. Locking Verfahren

10.1.1. pessimistic Locking (default bei rcs)

10.1.2. optimistic Locking (default bei cvs/svn)

10.2. CVS Commands

10.2.1. Directory erzeugen

10.2.1.1. mkdir ~/foobar

10.2.2. CVS init

10.2.2.1. cvs -d ~/foobar init

10.2.3. neues Modul

10.2.3.1. mkdir sesame

10.2.3.2. cd sesame

10.2.3.3. files erzeugen...

10.2.3.4. cvs -d ~/foobar import -m"" sesame sesame initial

10.2.3.5. im importierten Directory (sesame) NICHT weiterarbeiten.

10.2.4. Arbeitsbereich anlegen

10.2.4.1. mkdir ~/work

10.2.4.2. cd ~/work

10.2.4.3. Modul auschecken:

10.2.4.3.1. cvs -d ~/foobar co sesame

10.2.5. Sonstige

10.2.5.1. Status einer Datei

10.2.5.1.1. cvs status Color.txt

10.2.5.2. Unterschiede?

10.2.5.2.1. cvs diff Color.txt

10.2.5.3. Commit Changes

10.2.5.3.1. cvs commit

10.2.5.4. Arbeitsbereich aktuell?

10.2.5.4.1. cvs -nq update

10.2.5.5. Status neuer Datei

10.2.5.5.1. cvs status Color.txt

10.2.5.6. Historie

10.2.5.6.1. cvs log Color.txt

10.2.5.7. Datei hinzufügen

10.2.5.7.1. cvs add Color.txt

11. Entwurf

11.1. logische Architektur

11.1.1. Klassendiagramm

11.1.1.1. Packages

11.1.1.2. Dependencies

11.2. physische Architektur

11.2.1. Tiers

11.2.2. UML Deployment Diagramm

11.3. Auswahl von Packages

11.3.1. Kohäsion (cohesion)

11.3.1.1. Mass für Zusammenhalt innerhalb (z.B. Packages)

11.3.1.2. In Package gruppieren, was zusammen eine gemeinsame Funktion erfüllt

11.3.2. Kopplung (coupling)

11.3.2.1. Mass für Abhängigkeit zwischen (z.B. Packages)

11.3.2.2. Schnittstellen möglichst schmal und einfach zwischen Packages

11.4. Interaktionsdiagrammen

11.4.1. Interaktionsdiagramme zeigen dazu das dynamisches Verhalten des Systems

11.4.2. Participants

11.4.2.1. unnamed instance

11.4.2.1.1. : Sale

11.4.2.2. named instance

11.4.2.2.1. s1 : sale

11.4.2.3. class based on another class

11.4.2.3.1. <<metaclass>> iClass

11.4.2.4. instance of ArrayList, parameterized to hold Sales

11.4.2.4.1. sales : ArrayList<Sale>

11.4.2.5. instance of Sale, from an ArrayList<Sale>

11.4.2.5.1. sales[i] : Sale

11.4.2.6. Singletons top right corner a 1

11.4.3. Instanz löschen

11.4.3.1. «destroy»

11.5. Notationselemente für Design-Klassendiagramme

11.5.1. Klassen, abstrakte Klassen, Vererbung, Interfaces

11.5.2. Assoziationen, Kompositionen, Aggregationen

11.5.3. Navigationspfade

11.5.3.1. Semantische Zusammenhänge

11.5.3.2. Nur dort, wo Links zwischen Objekten bestehen müssen (Sichtbarkeit nötig)

11.5.4. Abhängigkeiten (Dependencies)

11.5.4.1. Modelliert allgemein Abhängigkeiten zwischen Elementen

11.5.4.2. Wenn Assoziation, Vererbung braucht keine Dependency eingezeichnet werden

11.5.5. Attribute mit Typinformation und Sichtbarkeit

11.5.6. Methoden ev. mit Parameter und Rückgabewerten

12. GoF Pattern

12.1. Creational

12.1.1. Abstract Factory

12.1.1.1. Dann macht es Sinn, die Factories zusammenzufassen und eine gemeinsame abstrakte Klasse für diese Factory- Eigenschaften zu definieren.

12.1.1.1.1. oft bei umgebungsabhängigen Klassenhierarchien

12.1.1.1.2. mehrere Factory Methods zusammengefasst

12.1.2. Prototype

12.1.3. Singleton

12.1.3.1. Definiere eine statische Methode in der Singleton- Klasse. Diese Methode gibt das Singleton zurück

12.1.3.1.1. Achtung: Singletons sind globale Objekte ( -> hohe Kopplung! )

12.1.4. Factory Method

12.1.4.1. Unterklassen können das Verhalten ändern, durch Überschreiben der Factory Method

12.1.5. Builder

12.2. Structural

12.2.1. Adapter

12.2.1.1. Konvertiere inkompatible Schnittstelle über Adapterklasse, die das gewünschte Interface implementiert.

12.2.2. Bridge

12.2.3. Composite

12.2.3.1. Implementiere Klassen für einzelne (atomare) Objekte und zusammengesetzte Objekte mit einer gemeinsamen Schnittstelle.

12.2.4. Decorator

12.2.4.1. Umgib das ursprüngliche Objekt mit einem Decorator, welcher das gleiche Interface implementiert, wie das Originalobjekt. Der Decorator implementiert die zusätzliche Funktionalität und delegiert für die Kernfunktionalität an das Originalobjekt

12.2.5. Flyweight

12.2.6. Facade

12.2.6.1. Definiere einen einzigen Einstiegspunkt zum Subsystem für Nutzer. Ein Façade-Objekt das das Subsystem "einwickelt" (wrapped). Alle Interaktion mit dem Subsystem läuft über dieses Façade-Objekt. Der innere Aufbau des Subsystems bleibt verborgen.

12.2.7. Proxy

12.3. Behavioral

12.3.1. Chain of Responsibility

12.3.2. Command

12.3.2.1. Kapsle die Aktion als Command Objekt. Gib allen Command Objekten eine gemeinsamen Schnittstelle, welche die notwendigen Anforderungen widerspiegelt. Statt eine Aktionsmethode direkt aufzurufen, erzeuge das entsprechende Command Objekt, auf dem dann die Aktion ausgeführt wird.

12.3.3. Iterator

12.3.3.1. Der Container stellt einen Iterator zur Verfügung, welcher Element um Element aus dem Container liefert

12.3.4. Mediator

12.3.5. Memento

12.3.6. Observer

12.3.7. State

12.3.7.1. Implementiere für jeden Zustand eine eigene Klasse. Alle Zustandsklassen haben eine gemeinsame Schnittstelle. Die Ausgangsklasse delegiert die zustandsabhängigen Methoden an diese Schnittstelle. Jeder Zustandswechsel tauscht das aktuelle Zustandsobjekt aus.

12.3.8. Strategy

12.3.8.1. Definiere eine gemeinsame Schnittstelle für die Algorithmen, implementiere das Objekt gegen diese Schnittstelle und lasse die einzelnen Algorithmen diese Schnittstelle implementieren

12.3.9. Visitor

12.3.10. Template Method

12.3.10.1. Definiere die Struktur des Algorithmus (Skelett) in der Basisklasse. Diese Template Methode ruft andere Methoden für die variierenden Details auf. Diese anderen Methoden (Hook methods) werden in den Unterklassen entsprechend überschrieben.

12.4. Null Object

12.4.1. Eine Klasse implementieren, welche das erforderliche Interface implementiert, deren Methoden aber nichts tun oder den geforderten Defaultwert liefern.

13. Projektmanagement

13.1. 4 Planungsfaktoren

13.1.1. Funktionalität (Scope)

13.1.2. Qualität

13.1.3. Zeit

13.1.4. Kosten