Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Software Engineering 1 by Mind Map: Software Engineering 1
0.0 stars - reviews range from 0 to 5

Software Engineering 1

Testen

Spezifikationsorientiertes Testen

Basis Use Cases, "tut's das, was der Kunde spezifiziert hat?"

Ein Szenario pro (Sub-) Use Case erstellen

Gut durch Kunden ausführbar

Black-box Test

Definition Testen

Ausführung von Software mit dem Ziel, Fehler zu finden, Sicherstellen, dass Vorgaben erfüllt

Anforderungen an Software Test

Geplant -> Testplanung

Systematisch spezifiziert -> Testspezifikation

Resultate festgehalten -> Testprotokoll

reproduzierbar

automatisiert

Test kategorisieren

link auf funktionale / nf Anforderungen!!!

Software-Prüfung

Dynamische Prüfung: Code ausführen, Testen, Dynamische Analyse

Statische Prüfung, Metrikanalyse, Ohne Rechner: Review

Begriffe: Verifikation und Validierung

Verifikation (verification), „Are we building the product right?“

Validierung (validation), „Are we building the right product?“

Testmethoden

Black-Box Tests, Äquivalenzklassen, Wertebereich einer Eingabegrösse, für welche der Prüfling voraussichtlich das gleiche Verhalten zeigt, einTestfallpro Äquivalenzklasse, Grenzwertanalyse, Fehler sehr oft an Grenzen zulässiger Eingabewertebereiche, wählt Testfälle an den Grenzen, Erweiterung der Äquivalenzklassenmethode, Zustandbasiertes Testen

White-Box-Tests, Kontrollfluss-orientiertes Testen, Anweisungsüberdeckung, Zweigüberdeckung, Pfadüberdeckung, Datenfluss-orientiertes Testen

Testüberdeckung (test coverage)

Anweisungsüberdeckung (statement coverage), Prozentualer Anteil der Anweisungen, die in Test ausgeführt werden, 100% Anweisungsüberdeckung ist Minimum

Zweigüberdeckung, Prozentualer Anteil der Kanten (Zweige), die in Test durchlaufen werden, Eine 100% Zweigüberdeckung enthält auch eine 100% Anweisungsüberdeckung, Zusätzlich werden auch alle „leeren Zweige“ durchlaufen

Pfadüberdeckung, Prozentualer Anteil der Pfade, die in Test durchlaufen werden, Ein Pfad ist ein möglicher Weg durch den Kontrollgraph, kleine Programme mit Schleifen -> riesige Anzahl Pfade, 100% Pfadüberdeckung nicht zu erreichen

Bedingungsüberdeckung, Zusammengesetzte Bedingungen - > verschiedene Kombinationen testen, Einfache Bedingungsüberdeckung, alle atomaren Bedingungen mind. einmal true und einmal false, garantiert keine 100%ige Anweisungsüberdeckung

Automatisierte Tests

Vorteile, Wiederholbarkeit -> Regressionstests, Absicherung bei Änderung, Portierung, Erweiterung, geringe/keine Kosten bei Wiederholung, Eindeutige Spezifikation, Testcode ist Programmcode und damit eindeutig

Nachteile, Mehr Code zu schreiben und zu pflegen, Testcode ist Programmcode, Werden wirklich die richtigen Anforderungen getestet?, Was muss überhaupt getestet werden?

Right-BICEP

Are the results right?

Are all boundary conditions CORRECT?, Conformance, Ordering, Range, Reference, Existence, Cardinality, Time

Can you check inverse relationships?

Can you cross-check results using other means?

Can you force error conditions to happen?

Are performance characteristics within bounds?

A TRIP

Automatic

Thorough, sorgfältig

Repeatable

Independent, keine Abhängigkeit zwischen Tests

Professional

Einführung

Software Engineering Definition

Software engineering is the application, of a systematic, disciplined, quantifiable approach, to the development, operation, and maintenance of software,, that is, the application of engineering to software.

Elemente Software-Engineering, Prozesse, beschreibt, wer was wann und wie tut, Prinzipien, Modelle, Notationen, Werkzeuge

RUP

Inception

Elaboration

Construction

Transition

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

Modelle, Domain-Modell, abstrahiert den Problembereich, Zerlegt Problem in verständliche Teile -> Konzeptionelle Klassen, Konzepte (domain objects), Kommunikation zwischen verschiedenen Rollen in Entwicklung, Design-Modell, abstrakte Darstellung der Lösung

Syntax vs. Semantik

Syntax, bezeichnet die (formal) definierte äussere Form einer Notation

Semantik, ist die Bedeutung einer Notation

Domain Modelierung

Finden von Konzepten

Strategie 1: Von existierenden Modellen ausgehen

Strategie 2: Checkliste mit Kategorien

Strategie 3: Substantive suchen

Multiplizitäten

* -> zero or more; "many"

1 .. * -> one or more

1 .. 40 -> one to 40

5 -> exactly 5

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

Refining the Domain Model

Aggregation, Spezielle Assoziation zur Modellierung von Ganzes-Teile-Beziehungen, aus „Has-a“-Beziehung, ganzes <>-- teil

Composition, Composite Aggregation oder Composition: Aggregation, bei welcher, die Teile ausschliesslich dem Ganzen gehören, ganzes <0>-- teil, Multiplizität ist beim Ganzen genau 1!

Softwareanforderungen

Klassifikation

Software Anforderungen, Funktionale Was?, Nichtfunktionale Wie gut?, Leistung, Mengen, Qualitätsmerkmale, Benutzbarkeit, Wartbarkeit, Zuverlässigkeit, Randbedingungen, Schnittstellenanforderungen

Use Cases

Begriffe

Formate, Brief, Casual, Fully Dressed

Teile eines Uses Cases, Primary Actor, Supporting Actors, Offstage Actors, Stakeholders and Interests, Preconditions, Post Conditions / Success Guarantees, Main Success Scenario, Extensions, Special Requirements, Technology and Data Variation Lists

Vorgehen Use Cases, 1. Systemgrenzen festlegen, Software, HW/SW-System, Organisation, 2. Primäre Aktoren identifizieren, Ihre Ziele als Systembenutzer werden durch System erfüllt, 3. Ziele jedes Aktoren identifizieren, So abstrakt wie möglich auf Ebene EBP, 4. Use Cases schreiben

Details Use Case Diagramme, «include», Teil von Use Case in separaten Subfunction Use Case ausgelagert, «extend», Erweitert Basis Use Case, Regel: Zurückhaltend verwenden

Anforderungsspezifikation

Korrektheit

Eindeutigkeit

Vollständigkeit

Konsistenz

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

Überprüfbarkeit

Änderbarkeit

Verfolgbarkeit

Systemsequenzdiagramme

Aktoren, System als Blackbox

SSD beschreibt Use Case Szenario

Konfigurationsmanagement

Locking Verfahren

pessimistic Locking (default bei rcs)

optimistic Locking (default bei cvs/svn)

CVS Commands

Directory erzeugen, mkdir ~/foobar

CVS init, cvs -d ~/foobar init

neues Modul, mkdir sesame, cd sesame, files erzeugen..., cvs -d ~/foobar import -m"" sesame sesame initial, im importierten Directory (sesame) NICHT weiterarbeiten.

Arbeitsbereich anlegen, mkdir ~/work, cd ~/work, Modul auschecken:, cvs -d ~/foobar co sesame

Sonstige, Status einer Datei, cvs status Color.txt, Unterschiede?, cvs diff Color.txt, Commit Changes, cvs commit, Arbeitsbereich aktuell?, cvs -nq update, Status neuer Datei, cvs status Color.txt, Historie, cvs log Color.txt, Datei hinzufügen, cvs add Color.txt

Entwurf

logische Architektur

Klassendiagramm, Packages, Dependencies

physische Architektur

Tiers

UML Deployment Diagramm

Auswahl von Packages

Kohäsion (cohesion), Mass für Zusammenhalt innerhalb (z.B. Packages), In Package gruppieren, was zusammen eine gemeinsame Funktion erfüllt

Kopplung (coupling), Mass für Abhängigkeit zwischen (z.B. Packages), Schnittstellen möglichst schmal und einfach zwischen Packages

Interaktionsdiagrammen

Interaktionsdiagramme zeigen dazu das dynamisches Verhalten des Systems

Participants, unnamed instance, : Sale, named instance, s1 : sale, class based on another class, <<metaclass>> iClass, instance of ArrayList, parameterized to hold Sales, sales : ArrayList<Sale>, instance of Sale, from an ArrayList<Sale>, sales[i] : Sale, Singletons top right corner a 1

Instanz löschen, «destroy»

Notationselemente für Design-Klassendiagramme

Klassen, abstrakte Klassen, Vererbung, Interfaces

Assoziationen, Kompositionen, Aggregationen

Navigationspfade, Semantische Zusammenhänge, Nur dort, wo Links zwischen Objekten bestehen müssen (Sichtbarkeit nötig)

Abhängigkeiten (Dependencies), Modelliert allgemein Abhängigkeiten zwischen Elementen, Wenn Assoziation, Vererbung braucht keine Dependency eingezeichnet werden

Attribute mit Typinformation und Sichtbarkeit

Methoden ev. mit Parameter und Rückgabewerten

GRASP

General Responsibility Assignment Patterns

Pattern, Information Expert, geringe Kopplung (low coupling) und hohe Kohäsion (high cohesion), Creator, lose Kopplung (low coupling), Creator muss Objekt sowieso kennen, d.h. Kopplung wird nicht erhöht, wenn er Objekt erzeugt, High Cohesion, Mass für den inneren Zusammenhalt von Klassen, Low Coupling, Mass für die Abhängigkeit eines Elementes (z.B. einer Klasse) von Umgebung (z.B. von anderen Klassen), Teile Responsibilities so zu, dass eine lose Kopplung resultiert, Controller, Objekt verantwortlich, Systemereignisse zu verarbeiten, gehört nicht zum Userinterface, Wieso ist die Anwendung dieses Patterns insbesondere in Systemen wichtig, die ein ausgeprägt zustandsabhängiges Verhalten besitzen?, Bei stark zustandsabhängigem Verhalten ist dieser Koordinationbedarf sehr ausgeprägt, also braucht es den Controller um dringender., Polymorphism, GoF-Pattern, Adapter, Command, Composite, Proxy, State, Strategy, Pure Fabrication, Technologie-Know-How gehört nicht in Domainklasse, Indirection, Objekt einführen, das zwischen Objekten vermittelt, GoF-Pattern, Proxy, Adapter, Bridge, Facade, Observer, Mediator, Protected Variations, 1. Bereiche identifizieren, die Änderungen unterworfen sind, 2. Variation Points von Umgebung abschotten (d.h. stabile „Interfaces“), Nutzen, Neue Implementationen ohne Änderungen in Client, Code ist leichter änderbar, erweiterbar, alternative Namen, Information Hiding, Open-Closed Principle

Visibility

Attribute Visibility

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

existiert über längeren Zeitraum

Parameter Visibility

b ist ein Parameter einer Methode von a

Temporäre Form der Sichtbarkeit

Local Visibility

b ist lokales Objekt in Methode von a

Temoräre Form der Sichtbarkeit, wenn, 1. Lokale Instanz erzeugt u. lokaler Variablen zugewiesen, 2. Rückgabwert ist Objekt, das lokaler Instanz zugewiesen

Global Visibility

b ist global sichtbar

Permanente Form der Sichtbarkeit

Sollte eigentlich nie verwendet werden (hohe Kopplung!)

GoF Pattern

Creational

Abstract Factory, Dann macht es Sinn, die Factories zusammenzufassen und eine gemeinsame abstrakte Klasse für diese Factory- Eigenschaften zu definieren., oft bei umgebungsabhängigen Klassenhierarchien, mehrere Factory Methods zusammengefasst

Prototype

Singleton, Definiere eine statische Methode in der Singleton- Klasse. Diese Methode gibt das Singleton zurück, Achtung: Singletons sind globale Objekte ( -> hohe Kopplung! )

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

Builder

Structural

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

Bridge

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

Decorator, 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

Flyweight

Facade, 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.

Proxy

Behavioral

Chain of Responsibility

Command, 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.

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

Mediator

Memento

Observer

State, 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.

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

Visitor

Template Method, 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.

Null Object

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

Architektur

Views

Logical View, Gliederung in Packages und Klassen, statisch, dynamisch, Layer

Process View, Nebenläufigkeit

Deployement View, Zuordnung auf Hardware-Elemente, Tier

Implementation View, Quellcode, ausführbare Programme

Use Case View, Realisierung Architektur- relevanter Use Cases

Data View, Persistente Datenspeicherung

Definition Software Architektur

signifikante Entscheidungen zur Organisation eines SW-Systems

Struktur, Anordnung der Strukturelemente - statisch, Interfaces zwischen Strukturelementen, Zusammenspiel zwischen Strukturelementen - dynamisch

Ausgangslage für Architekturen

Funktionale Anforderungen

Nichtfunktionale Anforderungen

Randbedingungen (constraints)

Projektmanagement

4 Planungsfaktoren

Funktionalität (Scope)

Qualität

Zeit

Kosten

Objektorientierte Analyse

klassisch

Domainmodell mit Operationen

Interaktionsdiagramm zwischen Objekten

"white box" Analyse

Larman

Domainmodell ohne Operationen

Systemsequenzdiagramm SSD

System als "black box"

Contracts und Systemoperationen

Activity-Diagramm

Basiselemente, Start & End, An initial or start node is depicted by a large black spot, as shown below., 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., Activity, 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., Action, An action represents a single step within an activity. Actions are denoted by round-cornered rectangles., Control Flow, A control flow shows the flow of control from one action to the next. Its notation is a line with an arrowhead., Fork & Join, 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, Branch mit Kondition & Merge, 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.

Weitere Elemente, Swimlanes, Objectflow, Partition, 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.