4. Requirements analysieren. und modellieren
|
|
- Volker Goldschmidt
- vor 7 Jahren
- Abrufe
Transkript
1 4. Requirements analysieren und modellieren
2 2
3 Ziel der Analyse Klares Verständnis von Wert, Nutzen und Aufwand der Anforderungen Bewertung von Einflüssen, Abhängigkeiten und Unsicherheiten Detektiv-Arbeit Problem Anforderungen beschreiben Anforderungsmodell Lösungsweg beschreiben Entwurfs- (Lösungs-)Modell Aufgaben des Systems verstehen Priorisierte Anforderungen Nach der Befragung aller Stakeholder und der Dokumentation der Antworten geht es im nächsten Schritt darum, die Anforderungen sauber zu modellieren und (erst) dann mögliche Lösungen (Lösungswege) zu beschreiben, vergleichen, Die Modellierung der Anforderungen (und Lösungen) führt uns aber oft nicht nur zu neuen Fragen, sondern auch zu weiteren Anforderungen. 3
4 Die drei Perspektiven auf das System Struktur Daten mit Attributen Anforderungen Funktion Funktionalität, Daten-Verarbeitung Verhalten Zustände, Reaktion auf Ereignisse Die verschiedenen Sichten auf das System helfen bei der Aufteilung/Gliederung der Anforderungen. Ein Problem hat immer verschiedene Aspekte und muss darum von allen Seiten begutachtet werden. Nur durch das Betrachten des Problems aus verschiedenen Blickwinkeln können wir alle Aspekte erkennen und beschreiben/modellieren. 3. Requirements spezifizieren 4
5 Verschiedene Aspekte/Sichten Funktionsperspektive Funktionalität aus Sicht des Benutzers Use Cases (+Beschreibungen) und Aktivitätsdiagramme Strukturperspektive Struktur des Systems und Kommunikation zwischen verschiedenen (Teil)-Systemen Komponentendiagramm, Klassendiagramm, ER-Diagramm, Verhaltensperspektive Reaktionen auf Ereignisse, Zustandswechsel Zustandsdiagramm, Entscheidungsbäume, Und/Oder-Bäume, Für die verschiedenen Sichten werden je die passenden UML-Diagramme verwendet. 5
6 Analyse Modellierung 1. Mind Map/Kontextdiagramm -> Problem-Raum 2. Glossar (Geschäfts-Wörter/Bereiche) 3. Use Cases / Szenarien a) Zustandsanalyse Initialisierung, Stand-by, Fehlerfall, Störung, Notbetrieb, Backup, b) Aktivitäten-Diagramm c) Entscheidungsbaum 4. Qualitätsanforderungen und Randbedingungen a) Ergonomie, Sicherheit, Performance, 5. Detaillierte Modelle Fachklassen-, Objekt-, verfeinerte Aktivitäten-, Zustands-, Kommunikations- oder Sequenzdiagramme Der gesamte Ablauf des Requirements Engineering beginnt mit den Befragungen beim Kunden, wo die Geschäftsprozesse (Business Use Cases) erfasst, erste Mind Maps oder Use Cases erstellt sowie der Problem-Kontext (das System-Umfeld) grob erörtert wird. Schon sehr früh müssen die Fachbegriffe geklärt werden, was zum Erstellen eines Glossars führt. Im Schritt 3 werden je nach Projekt die verschiedenen System-Zustände (und deren Übergänge, Events), die Arbeits-Abläufe (Aktivitäten) oder die möglichen Prozesse beschrieben. Weiter müssen auch die Fehlerfälle erfasst (und mit Hilfe von Test-Szenarien abgesichert) werden. Schritt 4 enthält möglicherweise einen Prototyp für das User Interface. 6
7 Definition Ein Modell ist ein abstraktes Abbild einer existierenden oder noch zu schaffenden Realität. Ein Modell dient als Abbild der Realität (was ist vorhanden, was soll «erschaffen» werden) zur Verkürzung/Vereinfachung der Realität (nur die Aspekte welche für diesen Sachverhalt relevant sind) in einem spezifischen Verwendungszweck (Einschränken auf ein spezifisches Problem/Sachverhalt) Ein Anforderungsmodell ist ein konzeptuelles Modell, welches die Anforderungen eines Systems dokumentiert. Ein Entwurfsmodell ist ein konzeptuelles Modell, welches die Aspekte einer Lösung eines Problems dokumentiert. Anforderungs- und Entwurfs-Modelle werden heute üblicherweise mit UML konstruiert. 7
8 Schwierigkeit Während den Anforderungen darf die Lösung beim RE nicht bereits (im Kopf) vorhanden sein. Der RE muss sich zwingen, Problembasiert und nicht Lösungsorientiert zu arbeiten. Diese Trennung fällt typischerweise nicht leicht, insbesondere bei erfahrenen RE, die schon viele Lösungen entwickelt haben. Auch für erfahrenen Requirements Engineering Spezialisten ist es oft schwierig, während der Anforderungsanalyse nicht bereits eine Lösung anzusteuern (dies würde zu einer unerwünschten Einschränkung der möglichen Lösungen führen). Besonders wenn der Problemkreis gut bekannt ist, besteht die Gefahr, sich nicht von «alten» bereits durchgeführten Projekten (und deren gewählten Lösungen) beeinflussen zu lassen. 8
9 Zielmodelle Intentionen der Stakeholder in Form von Zielen Gewünschte Eigenschaften des zu entwickelnden Systems Visionen als Grobziel Verfeinerung der Ziele in Ziel-Dekompositionen (welche Nebenziele sind für das Erreichen des zentralen Ziel nötig) Oft dokumentiert durch Und-Oder Bäume 9
10 Und/Oder Baum ODER - Baum Ziel UND - Baum Ziel Teilziel1 Teilziel2 Teilziel3 Teilziel1 Teilziel2 Teilziel3 Beispiel-Baum Reise buchen Eingeben des Reisewunschs Auswählen einer Reise nach Datum nach Zielort Und/Oder gehören nicht zur UML Sprache, weshalb sie nicht standardisiert sind. Es ist daher wichtig, diese Symbole möglichst einfach (und immer gleich) zu wählen. 10
11 Modellieren von Abläufen Komplexe Abläufe lassen sich oft nicht einfach durch natürliche Sprache erklären. Beim Beschreiben durch natürliche Sprache besteht die Gefahr, dass Äste oder Bedingungen vergessen gehen. Besser für die Beschreibung von Abläufen sind darum Entscheidungsbäume oder Aktivitätsdiagramme (vgl. OOAD). Aktivitätsdiagramme (Flowcharts oder Activity-Diagramms) werden im OOAD Kurs behandelt. 11
12 Entscheidungsbäume (einfache Abläufe) Da sie nicht standardisiert sind gibt es verschiedene Arten von Entscheidungsbäumen. 12
13 Was Wann Womit - Weniger geeignet 0 Neutral + Gut geeignet ++ Seht gut geeignet Akz ept anz bei m Kun den Nota tions - Kenn tniss e Spezi fikati ons- Level Kom plexe Syste me Kon siste nz- Sich erru ng Natürliche Sprache /- Use-Case Use-Case Beschreibung Szenario (User Story) Aktivitätsdiagramm (Ablauf) Klassendiagramm (ERM, Domain Model) Komponentendiagramm Zustandsdiagramm (Ereignisse) Sequenzdiagramm (Kommunikation) Und/Oder- oder Entscheidungsbaum Ein de uti gke it Diese Matrix kann helfen die Frage zu beantworten: Welche Teile des Systems sollen womit dokumentiert werden. Nicht alle Dokumentationsarten sind für alle Situationen gleich geeignet. Komplexe Systeme erfordern eventuell ein Dazulernen beim Kunden. Gewisse Diagramme werden erst für den Lieferanten/Auftragnehmer wirklich relevant. 13
14 Einsatz von Diagrammen Versteht der Kunde die Notation? Lohnt sich der Aufwand für das Zeichnen (und ev. Erlernen) des Diagramm-Typs Bringt die neue Technik genügend Qualitätsgewinn? Wird jede Anforderung an genau einer Stelle dokumentiert (Redundanz-Freiheit) Sind die Diagramme so einfach wie möglich gehalten Anzahl Notations-Elemente (beim Kunden) beschränken Anforderungen werden zuerst grob und je später desto exakter spezifiziert. Daher kann es gut sein, dass in den Kapiteln 1 und 2 die gleiche Anforderung bereits erwähnt wurde. Erst in Kapitel 3 wird sie dann exakt spezifiziert. Dort sollte sie aber nur an einer Stelle dokumentiert werden. 14
15 Umgang mit Komplexität Natürliche Sprache für sehr einfache oder sehr abstrakte / sehr detaillierte Ebene Gruppieren/Aufteilen/Sortieren der Anforderungen (nach Rolle, Subsystem, Geschäftsprozess, ) Komplexe Abläufe, Situationen durch Diagramme modellieren Diagramme wo nötig durch natürliche Sprache ergänzen. Einfache Anforderungen werden am besten durch natürliche Sprache spezifiziert. Dafür lohnt sich der Aufwand ein Diagramm zu zeichnen normalerweise nicht. Komplexe Abläufe oder Situationen werden dann durch Diagramme erklärt, da die natürliche Sprache hier klar an Grenzen stösst (nicht mehr verstanden wird). Diagramme müssen, wo nötig und nicht selbsterklärend, durch natürliche Sprache ergänzt werden. 15
16 Nicht-funktionale Anforderungen Qualitätsanforderungen (Performance, Erweiterbarkeit, Ergonomie, ) Technologische Anforderungen (Datenbank-System, Programmier-Umgebung/Sprache, Betriebssystem, ) Durchzuführende Tätigkeiten wie Wartung, Support, Schulung, Rechtliche Anforderungen wie Lizenzbestimmungen oder Kosten Einzuhaltende Standards und Normen. Nicht-funktionale Anforderungen werden (fast) immer in natürlicher Sprache spezifiziert. Hier ist eine klare, messbare, testbare und unmissverständliche Formulierung extrem wichtig (siehe Kapitel 3. Requirements spezifizieren). 16
17 Struktur-Brüche Übergänge sind unvermeidlich Anforderungen Anforderungsmodell Anforderungsmodell Entwurfsmodell Entwurfsmodell Systemstruktur Systemstruktur Software und Hardwarekomponenten Klare Dokumentation/Unterscheidung zwischen Anforderung und Lösungsentwurf Klare, konsistente, für alle verständliche Modellierung Objektorientierte Analysetechnik Struktur-Brüche sind zwischen den verschiedenen Phasen unvermeidlich. Wichtig ist es, trotzdem klar zwischen Anforderung und Lösungsmodell zu unterscheiden. Dies geschieht durch eine klare Dokumentation (wer ist verantwortlich für oder Autor von welche(n) Bilder(n), Texte(n), Diagramme(n), ). Nur so kann klar getrennt werden zwischen Lösung und Problem (bzw. Anforderung). Ein sauberes objektorientiertes Vorgehen kann Brüche mildern, indem schon zu Beginn die richtigen Namen für Objekte, Methoden, Interfaces, benutzt werden. 17
Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.
Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf 2 Nach derbefragung aller Stakeholder und der Dokumentation
MehrVgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl,
Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl, Chris Rupp Nachdem die Projekt-Vision und die Stakeholder
MehrGrundlagen, Einführung, Begriffe
Grundlagen, Einführung, Begriffe SysML Was ist ein System? Aufgaben des Systems Engineering Modellierung eines Systems Was ist SysML Astah SysML Tool Dr. Beatrice Amrhein Was ist ein System? 2 System EinSystem
MehrRequirements Engineering
Klaus Pohl Chris Rupp Basiswissen Requirements Engineering Aus- und Weiterbildung zum»certified Professional for Requirements Engineering«Foundation Level nach IREB-Standard 4., überarbeitete Auflage dpunkt.vertag
MehrVgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.
Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,
MehrDGQ Regionalkreis Hamburg Anforderungsmanagement ins SW-Projekten. 08. Juni 2011
DGQ Regionalkreis Hamburg Anforderungsmanagement ins SW-Projekten 08. Juni 2011 1 Heinrich Dreier hd@3er-consult.de +49 (0)176 62635052 DGQ- Mitglied Q-Manager Navigationsentwicklung freiberuflicher technischer
MehrInhaltsverzeichnis. Vorwort Kapitel 1 Einleitung Reisebeschreibung Zielpublikum Fallbeispiel...
Vorwort..................................................... 13 Kapitel 1 Einleitung......................................... 15 1.1 Reisebeschreibung............................ 18 1.2 Zielpublikum.................................
MehrNotationen zur Prozessmodellierung
Notationen zur Prozessmodellierung August 2014 Inhalt (erweiterte) ereignisgesteuerte Prozesskette (eepk) 3 Wertschöpfungskettendiagramm (WKD) 5 Business Process Model and Notation (BPMN) 7 Unified Modeling
MehrObjektorientiertes Design
Objektorientiertes Design Yi Zhao Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg Zhao, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1
MehrUML (Unified Modelling Language) von Christian Bartl
UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...
MehrVgl. Oestereich Kap 2.4 Seiten
Vgl. Oestereich Kap 2.4 Seiten 99-110 1 Vgl. Oestereich Kap 2.41 Seiten 99ff 2 Wie das Klassendiagramm ist auch das Objektdiagramm ebenfalls ein Strukturdiagramm. Da die Anzahl der Attribute sehr groß
MehrJason T. Roff UML. IT Tutorial. Übersetzung aus dem Amerikanischen von Reinhard Engel
Jason T. Roff UML IT Tutorial Übersetzung aus dem Amerikanischen von Reinhard Engel Inhaltsverzeichnis Inhaltsverzeichnis Einführung 11 Grundlagen der UML 15 Warum wir Software modellieren 16 Analyse,
MehrEinführung in die objektorientierte Programmierung
Einführung in die objektorientierte Programmierung Seminarunterlage Version: 4.04 Copyright Version 4.04 vom 17. Juni 2016 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten.
MehrTesten mit Use Cases. Chris Rupp Dr. Stefan Queins
Testen mit Use Cases Chris Rupp Dr. Stefan Queins Das Problem Requirements- Engineering Was kann passieren? Was ist das gewünschte Verhalten? Was soll ich testen? Welche Eingaben benötigt mein Testpfad?
MehrRequirements Engineering I
Martin Glinz Requirements Engineering I Kapitel 9 UML Unified Modeling Language Universität Zürich Institut für Informatik 2006, 2008 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind
Mehr3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.
1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes
MehrRealtime Studio Professional. ARTiSAN. Eine Visuelle Softwareentwicklungsumgebung zur Erstellung von Echtzeitanwendungen
ARTiSAN Eine Visuelle Softwareentwicklungsumgebung zur Erstellung von Echtzeitanwendungen Gliederung 1. Einleitung 2. RealTime Modeler Verwendete Entwicklungsmodelle Umsetzung und Anwendung der Konzepte
MehrLastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006)
Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006) Alles, was in dieser Schriftart gesetzt ist, dient nur zur Erläuterung und sollte im fertigen Lastenheft nicht mehr auftauchen! Der Umfang
MehrRückblick: Entity-Relationship-Modell
Rückblick: Entity-Relationship-Modell Entity-Relationship-Modell für konzeptuellen Entwurf Entitytypen (entity types) (z.b. Studenten) Beziehungstypen (relationships) (z.b. hören) Attribute beschreiben
MehrVorlesung Programmieren
Vorlesung Programmieren Unified Modeling Language (UML) Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/pfisterer Unified Modeling Language (UML)
MehrObjektorientierte Softwareentwicklung
Objektorientierte Softwareentwicklung Analyse- und Designmethoden Analyse- & Designmethoden Strukturierte, traditionelle Methoden Objektorientierte Methoden Funktionsorientierte Methoden Datenorientierte
MehrSoftware Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 17 Objektorientiertes Design Florin Pinte Marc Spisländer Lehrstuhl für Software
MehrDr. Beatrice Amrhein. April 16
Dr. Beatrice Amrhein April 16 2 Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André-Claude Godet, welches er mir freundlicherweise als Ausgangspunkt für dieses Skript zur Verfügung gestellt
MehrKapitel 2 - Die Definitionsphase
Kapitel 2 - Die Definitionsphase SWT I Sommersemester 2010 Walter F. Tichy, Andreas Höfer, Korbinian Molitorisz IPD Tichy, Fakultät für Informatik KIT die Kooperation von Forschungszentrum Karlsruhe GmbH
MehrOO - Analyse mario world wars
OO - Analyse mario world wars Projekt: mario world wars Voraussetzung: Pflichtenheft Autoren: Thomas Vogel, Michael Palmer, Florian Oeser Kontakt: mario@link2wall.de Letzte Änderung: 14.10.08 Seite 1 von
MehrMedia Engineering. Objektorientierte Modellierung. Verhaltensmodellierung. R. Weller University of Bremen, Germany cgvr.cs.uni-bremen.
Media Engineering Objektorientierte Modellierung Verhaltensmodellierung R. Weller University of Bremen, Germany cgvr.cs.uni-bremen.de Objektorientierte Analyse und Design im Detail Identifiziere Akteure
MehrSoftware-Engineering
FH Wedel Prof. Dr. Sebastian Iwanowski SWE44 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 4: Systemanalyse Teil 4: ARIS FH Wedel Prof. Dr. Sebastian Iwanowski SWE44 Folie 2 CASE-Tools
MehrObjektorientierte Systementwicklung
Karl-Heinz Rau Objektorientierte Systementwicklung Vom Geschäftsprozess zum Java-Programm Mit 162 Abbildungen vieweg Überblick und Vorbemerkungen 1 1 Objektorientierte Software-Entwicklung 5 1.1 Überblick
Mehr22. Januar Gruppe 2: TOPCASED
22. Januar 2008 Aufgabenstellung Modellgetriebene Softwareentwicklung auf Basis von am Beispiel eines Seminarverwaltungssystems Ziel Entwicklungsprozess Anforderungen & Codegenerierung Modellierung & Templates
MehrINSPIRE - Modellierung
INSPIRE - Modellierung Inhalt Motivation Modellierung UML Diagramme INSPIRE-Schulung LKROS 2 Motivation Was ist ein Modell, und warum wollen wir modellieren? Warum brauchen wir eine Modellierungssprache
MehrLehrstuhl für Datenverarbeitung. Technische Universität München. Grundkurs C++ Objektmodellierung. Grundkurs C++
Grundkurs C++ Objektmodellierung Grundkurs C++ Objektmodellierung welche Objekte bzw. Klassen werden benötigt? welche Information wird benötigt, um ein Objekt zu beschreiben? welche Beziehungen bestehen
MehrEinführung in die Modellierung
Informatik II: Modellierung Prof. Dr. Martin Glinz Kapitel 1 Einführung in die Modellierung Universität Zürich Institut für Informatik Inhalt 1.1 Der Modellbegriff 1.2 Wozu Modelle? 1.3 Modellbildung 1.4
MehrAnalyse und Design mituml2
Analyse und Design mituml2 Objektorientierte Softwareentwicklung von Bernd Oestereich 7, aktualisierte Auflage Oldenbourg Verlag München Wien Ш1!Н1Н1КД nhjektorientierte Softwareentwicklung - Analyse und
MehrNACHRICHTENTECHNISCHER SYSTEME
Einführung UML COMPUTERSIMULATION NACHRICHTENTECHNISCHER SYSTEME 11. Unified Modeling Language UML 220 Standardsprache d zur Visualisierung, i Spezifikation, Konstruktion und Dokumentation komplexer (Software-)
Mehrsystems landscape engineering - übung -
systems landscape engineering - übung - Wintersemester 2010 /2011 Arbeitsgruppe Wirtschaftsinformatik - Managementinformationssysteme - Dipl. Wirt.-Inform. Sven Gerber Arbeitsgruppe Wirtschaftsinformatik
MehrLehrplan: Business Analyse/ Requirements Engineering (BA- RE)
Lehrplan: Business Analyse/ Requirements Engineering (BA- RE) Gliederung 1 Grundlagen der industriellen So@ware Entwicklung 2 Unternehmens- und Geschä@sprozessmodellierung 3 Grundlagen und Begriffe des
Mehr3. Requirements spezifizieren. Templates, Kapitel-Raster Mind Maps
3. Requirements spezifizieren Templates, Kapitel-Raster Mind Maps Ablauf des Requirements Engineering Nachdem die Projekt-Vision und die Stakeholder bekannt sind, können die Geschäfts-Prozesse und die
MehrTamagotchi-Spezifikation in UML
Tamagotchi-Spezifikation in UML Christian Becker Steffen Glomb Michael Graf Gliederung Grundlagen Notation Werkzeug Modellierung Details der Spezifikation Erfahrungen Beurteilung von Notation und Werkzeug
MehrUniversität Karlsruhe (TH)
Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Kapitel 2 Die Definitionsphase Prof. Walter F. Tichy Wo sind wir gerade? Planung Lastenheft (funktionales Modell) Definition (Analyse) Pflichtenheft
MehrAnforderungen. Was ist eine Anforderung? Formulierungsschablonen Das Anforderungsdiagramm Glossar. Dr. Beatrice Amrhein
Anforderungen Was ist eine Anforderung? Formulierungsschablonen Das Anforderungsdiagramm Glossar Dr. Beatrice Amrhein Was ist eine Anforderung? 2 Anforderungen an ein System Funktionale Anforderungen o
Mehr7. Konkretisierungen im Feindesign. 7.1 Zustandsdiagramme 7.2 Object Constraint Language
7. Konkretisierungen im Feindesign 7.1 Zustandsdiagramme 7.2 Object Constraint Language 173 Verfeinerte Modellierung Durch die verschiedenen Sichten der Systemarchitektur wird der Weg vom Anforderungsmodell
MehrVgl. Oestereich Kap 2.1 Seiten
Vgl. Oestereich Kap 2.1 Seiten 21-49. 1 Ein Use Case ist eine zeitlich ununterbrochene Interaktion (ein Arbeitsschritt). Use Case Namen bestehen aus einem Subjekt und einem Verb wie zum Beispiel Daten
MehrSoftware Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 17 Objektorientiertes Design Florin Pinte Marc Spisländer Lehrstuhl für Software
MehrSoftware Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Meitner, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 16 Objektorientiertes Design Matthias Meitner Marc Spisländer Lehrstuhl für
MehrSystematisches Requirements Engineering und Management
Christof Ebert Systematisches Requirements Engineering und Management Anforderungen ermitteln, spezifizieren, analysieren und verwalten 2., aktualisierte und erweiterte Auflage ^1 dpunkt.verlag Inhalt
MehrWirtschaftsinformatik 6a: Modellierung. Hochschule für Wirtschaft und Recht SS 16 Dozent: R. Witte
Wirtschaftsinformatik 6a: Modellierung Hochschule für Wirtschaft und Recht SS 16 Dozent: R. Witte Computertechnik Man kann Software auf 2 Arten herstellen: Entweder macht man sie so klar und einfach,
MehrMit den 5 Prinzipien der Lebendigkeit für Anforderungen komplexe Systeme meistern. Dr.-Ing. Thaddäus Dorsch, HOOD GmbH,
Mit den 5 Prinzipien der Lebendigkeit für Anforderungen komplexe Systeme meistern Dr.-Ing. Thaddäus Dorsch, HOOD GmbH, 29.03.2017, REConf2017 2 KLASSISCHES REQUIREMENTS ENGINEERING Kundenanforderungen
Mehr7 Gewinnung von Anforderungen. 7.1 Voraussetzungen. Beteiligte kennen
7 Gewinnung von Anforderungen 7.1 Voraussetzungen Beteiligte kennen Beteiligtenanalyse (stakeholder analysis): Wer hat in welcher Rolle hat mit dem zu erstellenden System zu tun? Wer kann/soll/darf/muss
MehrSommersemester Analyse II: Verhalten (Zustandsautomaten)
Sommersemester 23 Analyse II: Verhalten (Zustandsautomaten) 8 Aufgabe 2 Analyse II: Verhalten (Zustandsautomaten) Umfang: 2 Wochen Punkte: P. Nachdem in der ersten Aufgabe die Systemstruktur mit Hilfe
MehrDatenbanken. Teil 2: Informationen. Kapitel 7: Objektorientierte Sicht. UML-Diagramme. Vorstellung der unterschiedlichen UML-Diagramme
Datenbanken objektorientierte Sicht Seite 1 von 76 Datenbanken Teil 2: Informationen Kapitel 7: Objektorientierte Sicht UML-Diagramme Vorstellung der unterschiedlichen UML-Diagramme 1. Diagrammtypen 2.
MehrBasiswissen Requirements Engineering
Klaus Pohl Chris Rupp Basiswissen Requirements Engineering Aus- und Weiterbildung zum»certified Professional for Requirements Engineering«Foundation Level nach IREB-Standard Г5 I dpunkt.verlag Inhalt Die
MehrObjektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl
Objektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl 26.07.21 Themenübersicht Objektorientierte Software-Entwicklung Objektorientierte Analyse und Design OOA OOD Objektorientierte
MehrSoftware- und Systementwicklung
Software- und Systementwicklung Seminar: Designing for Privacy 11.11.2009 Moritz Vossenberg Inhalt Vorgehensmodelle Wasserfallmodell V-Modell Phasen (Pflichtenheft) UML Klassendiagramm Sequenzdiagramm
MehrObjektorientierte Analyse & Design
Objektorientierte Analyse & Design Analyse-Phase Teil 1 Einordnung im SW-Lebenszyklus Software- Entwicklung Einsatz Wartung Problemdefinition Spezifikation Implementation Auslieferung Analyse Entwurf Erprobung
MehrKlausur. Softwareentwurf. 14. Februar 2011 Bearbeitungszeit: 120 Minuten
Klausur Softwareentwurf 14. Februar 2011 Bearbeitungszeit: 120 Minuten FG Datenbank- und Informationssysteme Prof. Dr. Gregor Engels unbedingt vollständig und lesbar ausfüllen! Vorname: Matrikelnummer:
MehrInhalt. 1 Einführung 17. Strukturdiagramme. 2 Klassendiagramm 37
Vorwort... 13 1 Einführung 17 1.1 Weshalb muss Software modelliert werden?... 17 1.2 Die Phasen bei der Softwareentwicklung... 18 1.2.1 Analyse... 18 1.2.2 Entwurf... 19 1.2.3 Implementierung und Dokumentation...
MehrDas UML Benutzerhandbuch
Grady Booch James Rumbaugh Ivar Jacobson Das UML Benutzerhandbuch Aktuell zur Version 2.0 Inhalt Vorwort 15 Ziele 15 Publikum 16 Wie Sie dieses Buch verwenden sollten 16 Aufbau und besondere Merkmale 17
Mehr[Hier klicken und Text eingeben] [Hier klicken und Text eingeben] Auftragsnummer: [Hier klicken und Text eingeben] Auftragnehmer:
Pflichtenheft Auftraggeber: Auftragsnummer: Auftragnehmer: Bearbeiter: Berlin, den (microtool GmbH, Berlin) Pflichtenheft Inhalt 1 Einleitung (Introduction) 3 1.1 Zielsetzung (Purpose) 3 1.2 Scope (Scope)
MehrSoftware Engineering Projekt. Pflichtenheft
Software Engineering Projekt Pflichtenheft Ziele eines Pflichtenheftes Eine Festsetzung der Leistung und des Umfangs der Software Anforderungen Zugesicherter Funktionsumfang Zugesicherter Produktumgebung
MehrInhaltsverzeichnis. Business Analysis und Requirements Engineering
sverzeichnis zu Business Analysis und Requirements Engineering von Peter Hruschka ISBN (Buch): 978-3-446-43807-1 ISBN (E-Book): 978-3-446-43862-0 Weitere Informationen und Bestellungen unter http://www.hanser-fachbuch.de/978-3-446-43807-1
MehrUnified Modeling Language (UML )
Unified Modeling Language (UML ) Seminar: Programmiersprachenkonzepte Inhalt Einleitung UML 2.0 Diagrammtypen 2 Einleitung Objektorientierte Modellierungssprache Definiert vollständige Semantik Dient der
MehrAnalyse und Modellierung von Informationssystemen
Analyse und Modellierung von Informationssystemen Dr. Klaus Höppner Hochschule Darmstadt Sommersemester 2013 1 / 18 UML Einführung Klassendiagramme in der UML Relationen zwischen Klassen 2 / 18 UML: Grundsätzliches
MehrObjektorientierte Modellierung (1)
Objektorientierte Modellierung (1) Die objektorientierte Modellierung verwendet: Klassen und deren Objekte Beziehungen zwischen Objekten bzw. Klassen Klassen und Objekte Definition Klasse Eine Klasse ist
MehrSoftwareanforderungsanalyse
Softwareanforderungsanalyse Vorgehen, Modellstruktur und Spezifikationsdokument - Ein Fazit Burkhardt Renz THM, Fachbereich MNI Wintersemester 208/9 Übersicht Vorgehen Struktur des Modells Metamodell Generierung
MehrSoftwaretechnologie für Fortgeschrittene Wohce 4 Modellierung UML
Softwaretechnologie für Fortgeschrittene Wohce 4 Modellierung UML The role of UML Theoretical model model for comparison calibration verification Empirical model model of deduction induction Generating
MehrCARL HANSER VERLAG. Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins. UML 2 glasklar
CARL HANSER VERLAG Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins UML 2 glasklar 3-446-22575-7 www.hanser.de Einleitung... 1 Liebe Leserin, lieber Leser... 1 Ihre Meinung ist uns
MehrSemantisches Geschäftsprozessmanagement Übung 1
Matthias Dräger 0.05.20 Markus Bischoff Semantisches Geschäftsprozessmanagement Übung Aufgabe : ) Vorteile von BPM und Modellierung - Modellierung zum besseren Verständnis eines Systems / eines Geschäftsprozesses
MehrDokumente eines IT-Projektes:
Dokumente eines IT-Projektes: - Pflichtenheft & Co - jheger@upb.de Fachbereich Informatik Paderborn, 04.06.2003 Überlappendes Phasenschema Dokumente der einzelnen Phasen 2 1.1 Überlappendes Phasenschema
MehrDr. Beatrice Amrhein. April 13
Dr. Beatrice Amrhein April 13 Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André- Claude Godet, welches er mir freundlicherweise als Ausgangspunkt für dieses Skript zur Verfügung gestellt
MehrMario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins. UML2 glasklar. UNIFIED MODELING LANGUAGE l HANSER
Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins UML2 glasklar UNIFIED MODELING LANGUAGE l V HANSER Inhalt Vorwort 1 Einleitung 2 Liebe Leserin, lieber Leser 2 Ihre Meinung ist uns
MehrSoftwaretechnik 2015/2016
Softwaretechnik 2015/2016 PST Lehrstuhl Prof. Dr. Matthias Hölzl HAUPT-/ BACHELOR- SEMINAR ADAPTIVE SYSTEME PST Joschka PROF. DR. Rinke WIRSING 14. JUNI 2009 VORNAME NAME AGENDA Übung 11: 14.01.2016 Schon
MehrSystemmodelle. Grundlagen des Software Engineerings
Systemmodelle Grundlagen des Software Engineerings Lernziele } Verstehen, warum es wichtig ist, die Grenzen eines Systems festzusetzen und seinen Kontext zu modellieren } Die Konzepte der Verhaltens-,
MehrChristoph Kecher, Alexander Salvanos UML 2.5. Das umfassende Handbuch. Rheinwerk. Computing
Christoph Kecher, Alexander Salvanos UML 2.5 Das umfassende Handbuch Rheinwerk Computing Inhalt Vorwort 13 1 Einführung 17 1.1 Weshalb muss Software modelliert werden? 17 1.2 Die Phasen bei der Softwareentwicklung
MehrFormale Modellierung Vorlesung vom : Beyond JML
Rev. 1702 1 [12] Formale Modellierung Vorlesung vom 07.05.12: Beyond JML Till Mossakowski & Christoph Lüth Universität Bremen Sommersemester 2012 2 [12] Heute im Programm Grenzen der JML Nach JML: UML
MehrEINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.
EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG
MehrDie Foundation-Phase Kombination von RE-Techniken zum Projektstart. Martin Kleckers, Agile Coach Berlin, 26. SEPTEMBER 2018
Die Foundation-Phase Kombination von RE-Techniken zum Projektstart Martin Kleckers, Agile Coach Berlin, 26. SEPTEMBER 2018 440 m Umsatz in 2017 + 2.500 Glückliche Kunden 1992 Gegründetes Familienunternehmen
Mehr<thema> Projektdokumentation zum Softwareentwicklungsprojekt. 25. April 2012. Entwickler: <autor1>, <autor2>, <autor3> Auftraggeber: <auftraggeber>
Projektdokumentation zum Softwareentwicklungsprojekt Lehrveranstaltung Software Engineering I und II 25. April 2012 Entwickler: , , Auftraggeber: Bachelorstudiengang
MehrObjektdiagramm Komponentendiagramm Paketdiagramm. 6. Weitere Strukturdiagramme
6. Weitere Strukturdiagramme Objektdiagramm Komponentendiagramm Paketdiagramm 1 6.1 Objekte Ausprägungsspezifikation von Klassen und Assoziationen 2 Definition Das Objektdiagramm zeigt eine bestimmte Sicht
MehrDas UML Benutzerhandbuch
Grady Booch James Rumbaugh Ivar Jacobson Das UML Benutzerhandbuch Aktuell zur Version 2.0 ADDISON-WESLEY An imprint of Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario
MehrSoftware-Engineering
SWE2 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 2: Grundbegriffe und Prinzipien SWE2 Slide 2 Grundbegriffe der Software-Entwicklung: Systeme System Ausschnitt aus der realen oder
Mehr4. Übung zu Software Engineering
4. Übung zu Software Engineering WS 2007/2008 Aufgabe 8 Erstellen Sie für den aus Aufgabe 1 bekannten Function-Point-Kalkulator ein Pflichtenheft. Bitte begrenzen Sie dessen Umfang auf maximal 2 DIN A4
MehrWeb Engineering-Seminar Methoden zur Web Modellierung: Object-oriented Hypermedia Method (OO-H)
Web Engineering-Seminar Methoden zur Web Modellierung: Object-oriented Hypermedia Method (OO-H) Dominik Kirsten Daniel Schäferbarthold Trier, 21.01.2008 1 Gliederung 1. Einführung 1.1 Anforderungen an
MehrSchrittweise vorgestellt
3 MBSE Lehrstuhl für Raumfahrttechnik Schrittweise vorgestellt Was erwartet mich in diesem Kapitel? Erläuterung der MBSE-Methodologie anhand der durchgängigen Beispielmission MOVE Modellierung von Anwendungsfällen
MehrHarald Störrle UML 2 für Studenten
Harald Störrle UML 2 für Studenten ein Imprint von Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario Sydney Mexico City Madrid Amsterdam Inhaltsverzeichnis Vorwort 11 Teil
MehrGliederung des Vortrages
Gliederung des Vortrages Unified Modeling Language Rational Rose Sergej Schwenk Oktober 1999 0. Einführung 1. Historie 2. Der Entwicklungsprozeß 3. UML 3.1 Anwendungsfalldiagramme 3.2 Klassendiagramme
MehrObjektorientierte Analyse (OOA) Inhaltsübersicht
Inhaltsübersicht Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1 Einführung In der
MehrAbhängigkeiten und Assoziationen
Abhängigkeiten und Assoziationen Arbeitsmaterial www.informatikzentrale.de Abhängigkeiten und Assoziationen Wirtschaftsinformatik Klasse 13, September 2018 Auf manche Übungen folgen Lösungsvorschläge deshalb
MehrInhaltsverzeichnis. Teil I Einführung 13. Teil II Struktur 41. Vorwort 11
UML 2 für Studenten Inhaltsverzeichnis Vorwort 11 Teil I Einführung 13 Kapitel 1 UML (nicht nur) für Studenten 15 1.1 Zielgruppen 16 1.2 Konventionen 17 1.3 Abgrenzung 18 1.4 Aufbau dieses Buches 18 Kapitel
MehrGeschäftsabläufe und Beziehungen zwischen. (Mitarbeitende / Geschäftsobjekte)
BusinessModel Geschäftsabläufe und Beziehungen zwischen Mitarbeitenden und Geschäftsobjekten: Arbeitsabläufe, Mitarbeitende, Hilfsmittel und Organisationsstruktur. Was läuft manuell, was IT-gestützt, wer
MehrUnified Modeling Language 2
Unified Modeling Language 2 Marvin Frommhold 17.11.2008 Gliederung Einleitung Geschichte Strukturierung der Spezifikation Diagrammtypen Strukturdiagramme Verhaltensdiagramme CASE-Werkzeuge Quellen Was
MehrAufgabe S1: Einmal quer durch s Skript
Aufgabe S1: Einmal quer durch s Skript / 10 Punkten Entscheiden Sie, ob die folgenden Aussagen zutreffen oder nicht. Machen Sie in der entsprechenden Spalte ein Kreuz. Für jede richtige Antwort erhalten
MehrSoftware Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, WS 2006/07
Software Engineering 3. Anforderungsanalyse Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering: 3. Anforderungsanalyse 2 Definitionen Anforderungen (Requirements): Beschreibung aller
MehrSoftware Engineering
Software Engineering Besprechung zur Uebung 2 (Anforderungsspezifikation) Reinhard Stoiber HS 07 Allgemeines Gruppen 3er Gruppen: 12 2er Gruppen: 0 1er Gruppen: 5 Weitere 3er Gruppen könnten noch geformt
MehrSWE6 Slide 1. Software-Engineering. Vorlesung 6 vom Sebastian Iwanowski FH Wedel
SWE6 Slide 1 Software-Engineering Vorlesung 6 vom 22.11.2004 Sebastian Iwanowski FH Wedel SWE6 Slide 2 Software-Engineering Vorlesungsthemen: 1. Überblick über das Thema und die Vorlesung 2. Grundlegende
MehrVisual Studio 2010 Jetzt auch für Architekten
TeamConf 2010 Visual Studio 2010 Jetzt auch für Architekten 06. Mai 2010 München Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de Daniel Meixner Consultant daniel.meixner@conplement.de
MehrDas diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen
Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 16OH21005 gefördert. Die Verantwortung für den Inhalt dieser
Mehr