Software Engineering in der Praxis Praktische Übungen
|
|
|
- Alexandra Günther
- vor 8 Jahren
- Abrufe
Transkript
1 Software Engineering in der Praxis Praktische Übungen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 1 / 14
2 1 Inhalt 2 Überblick 3 Werkzeuge 4 Aufgaben Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 2 / 14
3 Objektorientierte Analyse Florin Pinte Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 3 / 14
4 Zweck der Objektorientierten Analyse Was soll das System leisten (nicht wie) Erkundung der Natur des gegebenen Problems Systemgrenzen, Außenschnittstellen identifizieren Hilfe bei der Zerlegung des Systems in Teile Abläufe, (grobe) Kontrollflüsse, Nebenläufigkeit Schaffung eines Ausgangspunktes für das Design Lernprozeß, kein Design! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 4 / 14
5 Zweck der Objektorientierten Analyse Was soll das System leisten (nicht wie) Erkundung der Natur des gegebenen Problems Systemgrenzen, Außenschnittstellen identifizieren Hilfe bei der Zerlegung des Systems in Teile Abläufe, (grobe) Kontrollflüsse, Nebenläufigkeit Schaffung eines Ausgangspunktes für das Design Lernprozeß, kein Design! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 4 / 14
6 Zweck der Objektorientierten Analyse Was soll das System leisten (nicht wie) Erkundung der Natur des gegebenen Problems Systemgrenzen, Außenschnittstellen identifizieren Hilfe bei der Zerlegung des Systems in Teile Abläufe, (grobe) Kontrollflüsse, Nebenläufigkeit Schaffung eines Ausgangspunktes für das Design Lernprozeß, kein Design! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 4 / 14
7 Zweck der Objektorientierten Analyse Was soll das System leisten (nicht wie) Erkundung der Natur des gegebenen Problems Systemgrenzen, Außenschnittstellen identifizieren Hilfe bei der Zerlegung des Systems in Teile Abläufe, (grobe) Kontrollflüsse, Nebenläufigkeit Schaffung eines Ausgangspunktes für das Design Lernprozeß, kein Design! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 4 / 14
8 Zweck der Objektorientierten Analyse Was soll das System leisten (nicht wie) Erkundung der Natur des gegebenen Problems Systemgrenzen, Außenschnittstellen identifizieren Hilfe bei der Zerlegung des Systems in Teile Abläufe, (grobe) Kontrollflüsse, Nebenläufigkeit Schaffung eines Ausgangspunktes für das Design Lernprozeß, kein Design! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 4 / 14
9 Zweck der Objektorientierten Analyse Was soll das System leisten (nicht wie) Erkundung der Natur des gegebenen Problems Systemgrenzen, Außenschnittstellen identifizieren Hilfe bei der Zerlegung des Systems in Teile Abläufe, (grobe) Kontrollflüsse, Nebenläufigkeit Schaffung eines Ausgangspunktes für das Design Lernprozeß, kein Design! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 4 / 14
10 Zweck der Objektorientierten Analyse Was soll das System leisten (nicht wie) Erkundung der Natur des gegebenen Problems Systemgrenzen, Außenschnittstellen identifizieren Hilfe bei der Zerlegung des Systems in Teile Abläufe, (grobe) Kontrollflüsse, Nebenläufigkeit Schaffung eines Ausgangspunktes für das Design Lernprozeß, kein Design! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 4 / 14
11 Use-Case Analyse UML Anwendungsfall-Diagramme Fokus auf das äußere funktionale Verhalten ( Feature ) Nutzer, Akteure Anwendungsfälle Systemgrenzen Beziehungen zwischen Akteuren und Anwendungsfällen Systematische Erhebung der Ereignisse, die die Systemgrenzen passieren Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 5 / 14
12 Use-Case Analyse UML Anwendungsfall-Diagramme Fokus auf das äußere funktionale Verhalten ( Feature ) Nutzer, Akteure Anwendungsfälle Systemgrenzen Beziehungen zwischen Akteuren und Anwendungsfällen Systematische Erhebung der Ereignisse, die die Systemgrenzen passieren Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 5 / 14
13 Use-Case Analyse UML Anwendungsfall-Diagramme Fokus auf das äußere funktionale Verhalten ( Feature ) Nutzer, Akteure Anwendungsfälle Systemgrenzen Beziehungen zwischen Akteuren und Anwendungsfällen Systematische Erhebung der Ereignisse, die die Systemgrenzen passieren Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 5 / 14
14 Use-Case Analyse UML Anwendungsfall-Diagramme Fokus auf das äußere funktionale Verhalten ( Feature ) Nutzer, Akteure Anwendungsfälle Systemgrenzen Beziehungen zwischen Akteuren und Anwendungsfällen Systematische Erhebung der Ereignisse, die die Systemgrenzen passieren Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 5 / 14
15 Use-Case Analyse UML Anwendungsfall-Diagramme Fokus auf das äußere funktionale Verhalten ( Feature ) Nutzer, Akteure Anwendungsfälle Systemgrenzen Beziehungen zwischen Akteuren und Anwendungsfällen Systematische Erhebung der Ereignisse, die die Systemgrenzen passieren Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 5 / 14
16 Use-Case Analyse UML Anwendungsfall-Diagramme Fokus auf das äußere funktionale Verhalten ( Feature ) Nutzer, Akteure Anwendungsfälle Systemgrenzen Beziehungen zwischen Akteuren und Anwendungsfällen Systematische Erhebung der Ereignisse, die die Systemgrenzen passieren Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 5 / 14
17 Use-Case Analyse UML Anwendungsfall-Diagramme Fokus auf das äußere funktionale Verhalten ( Feature ) Nutzer, Akteure Anwendungsfälle Systemgrenzen Beziehungen zwischen Akteuren und Anwendungsfällen Systematische Erhebung der Ereignisse, die die Systemgrenzen passieren Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 5 / 14
18 Beispiel
19 Analyse der automatischen Produktionszelle Use-Case Diagramme? Betrachte Nachbarsysteme als Nutzer Zeichne UseCase-Diagramme für die Systemteile... Oder wähle einen geeigneteren Diagrammtyp aus! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 7 / 14
20 Analyse der automatischen Produktionszelle Use-Case Diagramme? Betrachte Nachbarsysteme als Nutzer Zeichne UseCase-Diagramme für die Systemteile... Oder wähle einen geeigneteren Diagrammtyp aus! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 7 / 14
21 Analyse der automatischen Produktionszelle Use-Case Diagramme? Betrachte Nachbarsysteme als Nutzer Zeichne UseCase-Diagramme für die Systemteile... Oder wähle einen geeigneteren Diagrammtyp aus! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 7 / 14
22 Analyse der automatischen Produktionszelle Use-Case Diagramme? Betrachte Nachbarsysteme als Nutzer Zeichne UseCase-Diagramme für die Systemteile... Oder wähle einen geeigneteren Diagrammtyp aus! Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 7 / 14
23 Aktivitätsdiagramme Fokus auf Abläufe, die im System stattfinden Geschäftsprozesse, Systemprozesse, Methoden einer Klasse Eignet sich für Analyse und Design Aktivität := Menge potentieller Abläufe Kontrollelemente: Verzweigung, Vereinigung, Fork, Join Elemente: Aktionen, Kanten, Objektknoten, [Pin-Notation... ] Kontrolltoken, Datentoken uvm. Inspiriert von Petri-Netzen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 8 / 14
24 Aktivitätsdiagramme Fokus auf Abläufe, die im System stattfinden Geschäftsprozesse, Systemprozesse, Methoden einer Klasse Eignet sich für Analyse und Design Aktivität := Menge potentieller Abläufe Kontrollelemente: Verzweigung, Vereinigung, Fork, Join Elemente: Aktionen, Kanten, Objektknoten, [Pin-Notation... ] Kontrolltoken, Datentoken uvm. Inspiriert von Petri-Netzen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 8 / 14
25 Aktivitätsdiagramme Fokus auf Abläufe, die im System stattfinden Geschäftsprozesse, Systemprozesse, Methoden einer Klasse Eignet sich für Analyse und Design Aktivität := Menge potentieller Abläufe Kontrollelemente: Verzweigung, Vereinigung, Fork, Join Elemente: Aktionen, Kanten, Objektknoten, [Pin-Notation... ] Kontrolltoken, Datentoken uvm. Inspiriert von Petri-Netzen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 8 / 14
26 Aktivitätsdiagramme Fokus auf Abläufe, die im System stattfinden Geschäftsprozesse, Systemprozesse, Methoden einer Klasse Eignet sich für Analyse und Design Aktivität := Menge potentieller Abläufe Kontrollelemente: Verzweigung, Vereinigung, Fork, Join Elemente: Aktionen, Kanten, Objektknoten, [Pin-Notation... ] Kontrolltoken, Datentoken uvm. Inspiriert von Petri-Netzen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 8 / 14
27 Aktivitätsdiagramme Fokus auf Abläufe, die im System stattfinden Geschäftsprozesse, Systemprozesse, Methoden einer Klasse Eignet sich für Analyse und Design Aktivität := Menge potentieller Abläufe Kontrollelemente: Verzweigung, Vereinigung, Fork, Join Elemente: Aktionen, Kanten, Objektknoten, [Pin-Notation... ] Kontrolltoken, Datentoken uvm. Inspiriert von Petri-Netzen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 8 / 14
28 Aktivitätsdiagramme Fokus auf Abläufe, die im System stattfinden Geschäftsprozesse, Systemprozesse, Methoden einer Klasse Eignet sich für Analyse und Design Aktivität := Menge potentieller Abläufe Kontrollelemente: Verzweigung, Vereinigung, Fork, Join Elemente: Aktionen, Kanten, Objektknoten, [Pin-Notation... ] Kontrolltoken, Datentoken uvm. Inspiriert von Petri-Netzen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 8 / 14
29 Aktivitätsdiagramm: Kontrollfluß mit Swim-Lanes
30 Aktivitätsdiagramme Fokus auf Abläufe, die im System stattfinden Geschäftsprozesse, Systemprozesse, Methoden einer Klasse Eignet sich für Analyse und Design Aktivität := Menge potentieller Abläufe Kontrollelemente: Verzweigung, Vereinigung, Fork, Join Elemente: Aktionen, Kanten, Objektknoten, [Pin-Notation... ] Kontrolltoken, Datentoken uvm. Inspiriert von Petri-Netzen Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 10 / 14
31 UML-Zustandsautomaten Zustände: Name, Verhalten (3 ) Übergänge: Trigger [Guards] / Effect Entscheidungen Pseudozustände, Historien, Hierarchien, Regionen... Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 11 / 14
32 UML-Zustandsautomaten Zustände: Name, Verhalten (3 ) Übergänge: Trigger [Guards] / Effect Entscheidungen Pseudozustände, Historien, Hierarchien, Regionen... Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 11 / 14
33 UML-Zustandsautomaten Zustände: Name, Verhalten (3 ) Übergänge: Trigger [Guards] / Effect Entscheidungen Pseudozustände, Historien, Hierarchien, Regionen... Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 11 / 14
34 UML-Zustandsautomaten Zustände: Name, Verhalten (3 ) Übergänge: Trigger [Guards] / Effect Entscheidungen Pseudozustände, Historien, Hierarchien, Regionen... Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 11 / 14
35 Zustandsautomat Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 12 / 14
36 Werkzeuge (Auswahl) Topcased Fujaba StarUML Rational Software Architect Borland Together für Eclipse Magic Draw MID Innovator Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 13 / 14
37 Aufgaben Analyse der Domäne mit Hilfe verschiedener Diagrammtypen: Anwendungsfalldiagramm Aktivitätsdiagramm Zustandsdiagramm Pinte, Spisländer FAU Erlangen-Nürnberg Objektorientierte Analyse 14 / 14
Objektorientierte Analyse
Objektorientierte Analyse Software Engineering in der Praxis David Föhrweiser Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg Föhrweiser, Spisländer
Software 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
Software 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
Software 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
Objektorientiertes 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
Software Engineering in der Praxis
Inhalt Nachlese Aufgaben Literatur Software Engineering in der Praxis Praktische Übungen Inhalt Nachlese Aufgaben Literatur Marc Spisländer Dirk Wischermann Lehrstuhl für Software Engineering Friedrich-Alexander-Universität
Software Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Josef Adersberger Dirk Wischermann Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg 23. Oktober 2006 Inhalt Überblick
Requirements Engineering
Requirements Engineering Florin Pinte Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg Pinte, Spisländer FAU Erlangen-Nürnberg Requirements Engineering
Use Cases. Die Sicht des Nutzers. Fortgeschrittenenpraktikum SS 2004
Use Cases Die Sicht des Nutzers Fortgeschrittenenpraktikum SS 2004 Gunar Fiedler Lehrstuhl für Technologie der Informationssysteme Kontakt: fiedler@is.informatik.uni-kiel.de Use Cases 2 Was ist ein Use
BABOK Knowledge Area Requirements Analysis Modeling Techniques - Process Models - - State Diagrams - Holger Dexel, 26.02.2011
BABOK Knowledge Area Requirements Analysis Modeling Techniques - Process Models - - State Diagrams - Holger Dexel, 26.02.2011 This presentation is build upon material of the Business Analysis Body of Knowledge
Klausur Software Engineering für WI (EuI)
Autor: Prof. Dr. Bernhard Humm, FB Informatik, FH Darmstadt Datum: 14. Februar 2006 Klausur Software Engineering für WI (EuI) Ihr Name: Ihre Matrikelnummer Erreichte Punkte (von insgesamt 57 Punkten):
Insight 2011 Power Workshop kh Whiteboard Diagramm: Modellzusammenhänge visualisieren. Nürnberg, 29.11.2011
Insight 2011 Power Workshop kh Whiteboard Diagramm: Modellzusammenhänge visualisieren Nürnberg, 29.11.2011 Gliederung Whiteboard Diagramm: Modellzusammenhänge visualisieren Der Power Workshop im Überblick.
Geschä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
Studientag 1793 Software Engineering I. 6. Juli 2014
Studientag 1793 Software Engineering I 6. Juli 2014 In dieser Aufgabe soll ein Anwendungsfalldiagramm für die im Folgenden beschriebenen Abläufe bei dem Kauf einer Fahrkarte an einem Fahrkartenautomaten
Software-Engineering SS03. Zustandsautomat
Zustandsautomat Definition: Ein endlicher Automat oder Zustandsautomat besteht aus einer endlichen Zahl von internen Konfigurationen - Zustände genannt. Der Zustand eines Systems beinhaltet implizit die
Gliederung 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
Neue Funktionen in Innovator 11 R5
Neue Funktionen in Innovator 11 R5 Innovator for Enterprise Architects, Java Harvester und Prüfassistent 12.11.2013 Agenda 1 2 3 Einführung Was ist neu in Innovator 11 R5? Szenario Enterprise Architektur
Empirische Softwaretechnik Kosten und Nutzen von UML in der Wartung Dr. Victor Pankratius Andreas Höfer Wintersemester 2009/2010
Empirische Softwaretechnik Dr. Victor Pankratius Andreas Höfer Wintersemester 2009/2010 IPD Tichy, Fakultät für Informatik Pflichtlektüre hierzu: Dzidek, Arisholm, Briand, A Realistic Empirical Evaluation
Unified Modeling Language (UML)
Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine
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
Dreibeinige Stühle kippeln nicht Fachbereich und IT als gemeinsames Projekt-Team
Dreibeinige Stühle kippeln nicht Fachbereich und IT als gemeinsames Projekt-Team REConf 2014, Konferenztrack Sprache München, 11. März 2014 Dr. Jürgen Pitschke BCS Dr. Jürgen Pitschke www.enterprise-design.eu
Übungsaufgaben zum Software Engineering: Management
Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie
Fragenkatalog Geschäftsmodellierung Grundlagen
Fragenkatalog Geschäftsmodellierung Grundlagen 1. Erläutern Sie den Begriff der Geschäftsmodellierung - Erfassung und Spezifikation von Geschäftsprozessen für die Analyse und Gestaltung betrieblicher Systeme
4. Übung zu Software Engineering
4. Übung zu Software Engineering WS 2009/2010 Henning Heitkötter Klassendiagramm: Projektmanagement AUFGABE 10 1 OOA-Methode von Heide Balzert 1. Klassen finden 2. Assoziationen und Kompositionen finden
Motivation. Motivation
Vorlesung Modellierung nebenläufiger Systeme Sommersemester 2012 Universität Duisburg-Essen Was sind nebenläufige Systeme? Ganz allgemein: Systeme, bei denen mehrere Komponenten/Prozesse nebenläufig arbeiten
Grundlagen Software Engineering
Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der
Erfahrungsbericht: Einsatz objektorientierter Methoden in Flugkörper-Software
Erfahrungsbericht: Einsatz objektorientierter Methoden in Flugkörper-Software Michael Erskine LFK-Lenkflugkörpersysteme GmbH KOM-0253 Erwartungen OOA/OOD sind standardisierte Methoden UML eignet sich als
Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler
Übungen zur Vorlesung Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungsblatt 4 Lösungshilfe. Aufgabe 1. Zustandsdiagramm (8 Punkte) Geben Sie ein Zustandsdiagramm für
Requirements Engineering I
Norbert Seyff Requirements Engineering I UML Unified Modeling Language! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen
Inhalt Software-Metriken Software-Metriken mit Together FindBugs. Software-Metriken. Raimar Lill Matthias Meitner David Föhrweiser Marc Spisländer
Lill, Meitner, Föhrweiser, Spisländer FAU Erlangen-Nürnberg Software-Metriken 1 / 24 Software-Metriken Raimar Lill Matthias Meitner David Föhrweiser Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität
Objektorientierte Geschäftsprozessmodellierung mit der UML
Bernd bestereich Christian Weiss Claudia Schröder Tim Weilkiens Alexander Lenhard 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com
Software Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Adersberger, Spisländer FAU Erlangen-Nürnberg Software-Metriken 1 / 26 Software-Metriken Josef Adersberger Marc Spisländer Lehrstuhl für Software Engineering
Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin
Unsere Kunden erzählen keine Geschichten Ursula Meseberg microtool GmbH Berlin Unsere Kunden erzählen keine Geschichten Ein modellbasierter Prozess für die Anforderungsanalyse im Vorfeld agiler Produktentwicklung
Praktikum Software Engineering: Verfahren und Werkzeuge
Praktikum Software Engineering: Verfahren und Werkzeuge Lehrstuhl für Software Engineering (Informatik 11) Verfahren und Werkzeuge Seite 1 Software Engineering Absichten, Aufgaben Systemnutzung Anforderungsspezifikation
Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?
Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung
Trainings und Workshops
Titel: Soft Skills für (Designierte-) Führungskräfte I (Nr. 6001) Das Training ermöglicht jeden einzelnen Teilnehmer seinen eigenen Rollen zu identifizieren. Rollen, die er hatte, hat und haben möchte.
Petri-Netze / Eine Einführung (Teil 2)
Manuel Hertlein Seminar Systementwurf Lehrstuhl Theorie der Programmierung Wiederholung (1) Petri-Netz = bipartiter, gerichteter Graph Aufbau: Plätze (passive Komponenten) Transitionen (aktive Komponenten)
3.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
09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)
Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)
Vorlesung Programmieren
Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)
Use Cases. Use Cases
Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben
Software Engineering in der Praxis
Software Engineering in der Praxis Matthias Meitner Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg Meitner, Spisländer FAU Erlangen-Nürnberg Software
Softwaretechnologie - Wintersemester 2011/12 - Dr. Günter Kniesel
Übungen zur Vorlesung Softwaretechnologie - Wintersemester 2011/12 - Dr. Günter Kniesel Übungsblatt 4 - Lösungshilfe Aufgabe 1. Zustandsdiagramm (6 Punkte) Geben Sie ein Zustandsdiagramm für den Lebenszyklus
RUP Analyse und Design: Überblick
Inhaltsverzeichnis Übersicht [, 2, 8] 3. Vorgehensweise............................... 5 2 Planungsmethoden 37 2. Definitionsphase.............................. 6 3 Rational Unified Process [5, 6] und
Kommunikation. Sitzung 01 04./11. Dezember 2015
Kommunikation Sitzung 01 04./11. Dezember 2015 Unser Vorhaben Kommunikationsmodell Überblick über Netzwerk-Topologien Server-Client-Modell Internet Was ist Informatik eigentlich? Kunstwort aus Information
Requirements Engineering
Seite 1 Requirements Engineering Seite 2 Zielsetzung Systematischer Ansatz, Anforderungen zu Ermitteln Analysieren Organisieren Dokumentieren Mittel, um gemeinsame Basis zwischen Kunde und Entwickler zu
Prüfung Software Engineering I (IB)
Hochschule für angewandte Wissenschaften München Fakultät für Informatik und Mathematik Studiengruppe IB 3 A Wintersemester 2014/15 Prüfung Software Engineering I (IB) Datum : 21.01.2015, 14:30 Uhr Bearbeitungszeit
Musterfragen ALLGEMEINE Systemlehre
Musterfragen ALLGEMEINE Systemlehre (2.4.01) 1 Musterfragen ALLGEMEINE Systemlehre Die angeführten Fragen sind als Beispiele zu verstehen. Es gibt keine Garantie, daß diese und genau diese Fragen kommen.
Gemeinsamkeiten und Unterschiede bei der Anwendung für die Analyse von Geschäftsprozessen
Gemeinsamkeiten und Unterschiede bei der Anwendung für die Analyse von Geschäftsprozessen Gliederung Geschäftsprozess Einführung der Modellierungskonzepte PetriNetz und EPK Transformation von EPK in PN
Software 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
Landschaftsverband Rheinland Dezernat Schulen und Jugend. Risikomanagement
Risikomanagement Ein Projekt, durchgeführt von den Landesjugendämtern Rheinland und Westfalen- Lippe im Auftrag des Ministeriums für Generationen, Familie, Frauen und Integration NRW Projektanlass These:
Software Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Dirk Wischermann Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg 18. Dezember 2006 Inhalt Nachlese
Inhalt. Motivation Techniken des MDE. Fallbeispiele
ISE-Seminar 2012 Inhalt Motivation Techniken des MDE Computer Aided Software Engineering (CASE) Domain-Specific-Languages (DSL) Model Driven Architecture (MDA) Fallbeispiele Motivation Automatische Codegenerierung
4. AuD Tafelübung T-C3
4. AuD Tafelübung T-C3 Simon Ruderich 17. November 2010 Arrays Unregelmäßige Arrays i n t [ ] [ ] x = new i n t [ 3 ] [ 4 ] ; x [ 2 ] = new i n t [ 2 ] ; for ( i n t i = 0; i < x. l e n g t h ; i ++) {
Klausur Software-Engineering SS 2005 Iwanowski 23.08.2005
Klausur Software-Engineering SS 2005 Iwanowski 23.08.2005 Hinweise: Bearbeitungszeit: 90 Minuten Erlaubte Hilfsmittel: im Anhang, sonst keine Bitte notieren Sie Ihre Antworten ausschließlich auf dem Aufgabenblatt!
SEQUENZDIAGRAMM. Christoph Süsens
SEQUENZDIAGRAMM Christoph Süsens DEFINITION Das Sequenzdiagramm gibt Auskunft darüber: Welche Methoden für die Kommunikation zwischen ausgewählten Objekten zuständig sind. Wie der zeitliche Ablauf von
Evaluation of Database Design and Reverse Engineering Tools for a Large Software System
Evaluation of Database Design and Reverse Engineering Tools for a Large Software System Anne Thomas TU Dresden Dr. B. Demuth Pre Press GmbH (Dresden) T. Reuter Gliederung Einleitung Vorgehensweise Kontext
Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer
Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Vorausgesetzte Kenntnisse Allgemeine Kenntnisse aus dem Bereich der Softwareentwicklung - Programmierkenntnisse (Java, C) - Beherrschung der notwendigen
Liter pro Ew/Tag Jahr Anzahl Jahr Konstanz (im Internet unter: http://www.vmmarketing.de/) gab es in Deutschland im Jahr 2001 insgesamt 544.701 eingetragene Vereine. Bis zum
Rhapsody in J Modellierung von Echtzeitsystemen
Rhapsody in J Modellierung von Echtzeitsystemen Tobias Schumacher tobe@uni-paderborn.de Rhapsody in J - Modellierung von Echtzeitsystemen p.1/17 Anspruch des Tools Einsatzbereiche/Features Modellierung
Methodenbasiert in der Durchführung V-Modell XT-konform im Ergebnis
Methodenbasiert in der Durchführung V-Modell -konform im Ergebnis - 1 - So? oder gibt es einen anderen Weg? - 2 - Die Werkzeugfamilie Business professionelle Geschäftsprozessmodellierung mit UML Object
Bausteine eines Prozessmodells für Security-Engineering
Bausteine eines Prozessmodells für Security-Engineering Ruth Breu Universität Innsbruck M. Breu Mai-03/1 Motivation Entwicklung einer Methode zum systematischen Entwurf zugriffssicherer Systeme Integration
Lösungsvorschlag für Übungsblatt 6 Software Engineering 1 (WS 2012/13)
Prof. Ina Schaefer Institut für Softwaretechnik und Fahrzeuginformatik TU Braunschweig Lösungsvorschlag für Übungsblatt 6 Software Engineering 1 (WS 2012/13) Ausgabe: 12. Januar 2013 Abgabe: 25. Januar
Software-Engineering
FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 2: Grundbegriffe und Prinzipien FH Wedel Prof. Dr. Sebastian Iwanowski SWE2 Folie 2 Grundbegriffe
Kapitel 2: Der Software-Entwicklungsprozess
Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken
Produktmanager Gehaltsstudie 2013/2014 Auswertung der Befragung von über 500 Produktmanager in Deutschland
Produktmanager Gehaltsstudie 2013/2014 Auswertung der Befragung von über 500 Produktmanager in Deutschland Marketing Consult GmbH * Clemensstraße 30 * 80803 München * Telefon: +49 89 55297330 Telefax:
Die Integration von Requirements Management, Software Configuration Management und Change Management mit der MKS Integrity Suite 2006
Die Integration von Requirements Management, Software Configuration Management und Change Management mit der MKS Integrity Suite 2006 Oliver Böhm MKS GmbH Agenda Überblick Der Entwicklungsprozess: Requirements
Business Process Model and Notation
BPMN 2.0 Crashkurs Business Process Model and Notation entwickelt von der Object Management Group, einem Konsortium von vielen Firmen (u.a. HP, IBM, Microsoft, Oracle, SAP) >60 verschiedene Produkte implementieren
Software Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Pinte, Spisländer FAU Erlangen-Nürnberg Strukturelles Testen 1 / 11 Strukturelles Testen Florin Pinte Marc Spisländer Lehrstuhl für Software Engineering
2. Analyse und Design. 2.1. Prozessmodell Zielspurt
2. Analyse und Design 2.1. Prozessmodell Zielspurt Aktivität / Aufgabe Zielspurt Ereignis Gateway (Verzweigung) Kontrollfluss 2 Reflexion zum Arbeitsblatt Prozessmodellierung Business Process Modelling
Die MID ModellierungsMethodik M³ ein Baukasten für Produktlinien. Andreas Ditze, MDD & PL 2009, Leipzig, 23.03.2009
Die MID ModellierungsMethodik M³ ein Baukasten für Produktlinien Andreas Ditze, MDD & PL 2009, Leipzig, 23.03.2009 I N H A L T 1. Vorstellung 2. Was macht einen guten Baukasten aus? 3. Ziele der MID ModellierungsMethodik
Geschäftsprozesse modellieren mit Innovator Business
Geschäftsprozesse modellieren mit Innovator Business I N H A L T 1. Motivation und Begriffsklärung 2. Kurzeinführung in die Geschäftsprozessmodellierung 3. Anwendungsszenarien der GPM 2 Was Geschäftsprozessmodellierung
Testinstruktion BVB-09
Testinstruktion Bitte stellen Sie sich den Zeitpunkt direkt vor Beginn der Therapie vor. Überlegen Sie, was Sie zu diesem Zeitpunkt machten und wie Sie sich fühlten. Überblicken Sie bitte nunmehr immer
Übungen zur Softwaretechnik
Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se
EINFÜ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 ABLAUF Besprechung der Abgaben Petri-Netze BPMN Neue Übungsaufgaben
Software-Engineering
FH Wedel Prof. Dr. Sebastian Iwanowski SWE43 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 4: Systemanalyse Teil 3: Der Systemanalysestandard UML FH Wedel Prof. Dr. Sebastian Iwanowski
Geschäftsprozesse SOA-gerecht modellieren mit BPMN und UML. München, 28. Januar 2010
Geschäftsprozesse SOA-gerecht modellieren mit BPMN und UML München, 28. Januar 2010 INHALT Warum BPMN? Prozesse modellieren mit BPMN 2.0 Fachliche Services identifizieren BPMN-Prozesse mit UML ergänzen
Software Engineering:
Hochschule Darmstadt Fachbereich Informatik Software Engineering: Tipps zum Einsatz von Innovator auf einem privaten Rechner Software Engineering, Prof. Dr. R. Hahn, WS2011-12, h_da, Fachbereich Informatik
Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld. Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012
Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012 Agenda 1. Scope, Motivation und Begriffsklärung 2. Modellierung
Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert.
Usability Heuristiken Karima Tefifha Proseminar: "Software Engineering Kernkonzepte: Usability" 28.06.2012 Prof. Dr. Kurt Schneider Leibniz Universität Hannover Die ProSeminar-Ausarbeitung beschäftigt
Grundlagen der Softwaretechnik
Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:
TEIL I Strukturdiagramme 1 Einführung Klassendiagramm Objektdiagramm Kompositionsstrukturdiagramm...
Auf einen Blick TEIL I Strukturdiagramme 1 Einführung... 13 2 Klassendiagramm... 29 3 Objektdiagramm... 111 4 Kompositionsstrukturdiagramm... 125 5 Komponentendiagramm... 145 6 Verteilungsdiagramm... 161
Prüfung Software Engineering I (IB)
Hochschule für angewandte Wissenschaften München Fakultät für Informatik und Mathematik Studiengruppe IB 4 A Sommersemester 2015 Prüfung Software Engineering I (IB) Datum : 09.07.2015, 14:30 Uhr Bearbeitungszeit
(BABOK-v3-Technik 10.47)
(BABOK-v3-Technik 10.47) Allgemeines Use-Cases geben Antworten auf die Frage Was soll das geplante System leisten? Diese Frage sollte generell zu Beginn jeder Systementwicklung stehen. Use-Cases genauer
Vortrag von: Ilias Agorakis & Robert Roginer
MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile
Professionelle Seminare im Bereich MS-Office
Der Name BEREICH.VERSCHIEBEN() ist etwas unglücklich gewählt. Man kann mit der Funktion Bereiche zwar verschieben, man kann Bereiche aber auch verkleinern oder vergrößern. Besser wäre es, die Funktion
Requirements Engineering für IT Systeme
Requirements Engineering für IT Systeme Warum Systemanforderungen mit Unternehmenszielen anfangen Holger Dexel Webinar, 24.06.2013 Agenda Anforderungsdefinitionen Von der Herausforderung zur Lösung - ein
Objektorientierte Analyse
Objektorientierte Analyse OOA.4) Analysebeispiel EU-Rent Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik TU Dresden
Software Engineering in der Praxis
Software Engineering in der Praxis Praktische Übungen Inhalt Nachlese Überblick Aufgaben Lernziele bei der Objektorientierten Analyse Abgrenzung der Analyse zum Design als Lernprozeß UML Verhaltensdiagramme
UML 2.0 Das umfassende Handbuch
Christoph Kecher V.-M \MM UML 2.0 Das umfassende Handbuch Galileo Computing Inhalt Vorwort 11 1 Einführung 13 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3 Die Geschichte
Praktikum Software Engineering
Praktikum Software Engineering Verwendung von Enterprise Architect Pascal Weber, David Kulicke KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft
Modellierung von Echtzeitsystemen mit dem UML CASE Tool Telelogic Tau G2 Developer
Modellierung von Echtzeitsystemen mit dem UML CASE Tool Telelogic Tau G2 Developer Holger Sinnerbrink Einführung Firmenentwicklung Gründung von Telelogic 1983 als Forschungs- und Entwicklungsabteilung
Softwaretechnik. Fomuso Ekellem WS 2011/12
WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von
Lerninhalte und Kompetenzerwartungen in der Klasse 8 mit Bezug zum eingeführten Lehrwerk: Mathematik Neue Wege 8 (Schroedel-Verlag Bestell.-Nr.
Lerninhalte und Kompetenzerwartungen in der Klasse 8 mit Bezug zum eingeführten Lehrwerk: Mathematik Neue Wege 8 (Schroedel-Verlag Bestell.-Nr. 85478) Viele der im Kernlehrplan aufgeführten Kompetenzbereiche
Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003
Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen
Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur
Hochschule Darmstadt Fachbereich Informatik Softwaretechnik II 4.1 Darstellung der Architektur Darstellung der Architektur Was macht ein Architekt? Viele Pläne! Endkunde Elektro Bauarbeiter Sanitär Softwaretechnik
Unternehmensmodellierung
Josef L. Staud Unternehmensmodellierung Objektorientierte Theorie und Praxis mit UML 2.0 4ü Springer Inhaltsverzeichnis EINLEITUNG 1 1.1 Unternehmensmodellierung 1 1.2 Objektorientierung als solche 6 1.3
Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung
Modellierung verteilter Systeme Grundlagen der Programm und Systementwicklung Wintersemester 2009/10 Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. K. Spies, Dr. M. Spichkova, L. Heinemann, P.
Dokumentation für die Software-Wartung
7. Workshop Software-Reengineering Dokumentation für die Software-Wartung Stefan Opferkuch Universität Stuttgart Institut für Softwaretechnologie, Abteilung Software Engineering 4. Mai 2005 Übersicht Wie
Softwareanforderungsanalyse
Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen