OOSE nach Jacobson Sebastian Pohl/ST7 Betreuer: Prof. Dr. Kahlbrandt.

Slides:



Advertisements
Ähnliche Präsentationen
Vorgehensmodell - Wasserfallmodell
Advertisements

Objektorientierung Auffassung der Software als eine Sammlung
Universität Dortmund, Lehrstuhl Informatik 1 EINI II Einführung in die Informatik für Naturwissenschaftler und Ingenieure.
Das „Vorgehensmodell“
UML-Basics: Einführung in Objekt-Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler.
IT-Projektmanagement
Projektplanung für Softwareprojekte
Objektorientierter Entwurf
WS 04/05 wiss. Übung: Systemanalyse und Softwaredesign
Manfred Thaller, Universität zu Köln Köln 28. Januar 2008
Manfred Thaller, Universität zu Köln Köln 7. Januar 2010
Konzeption und Implementation visueller Editoren zur Bearbeitung von SPS-Schrittketten mit dem Editorgeneratorsystem DEViL Dennis Klassen Höxterstraße.
Anwendungsfalldiagramm
Anwendungsfalldiagramm
Anwendungsfalldiagramm
Systemanalyse In der Systemanalyse wird aus den fachspezifischen Anforderungen das Systemmodell erstellt; im Systemmodell ist spezifiziert, was das System.
DHBW Stuttgart, Informationstechnik, SW-Engineering, Bedienung des Innovators Sep 2012 / rie Seite 1 Innovator 11 (lokales Repository auf H:\..) INNOVATOR.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme I nstitut für K ernenergetik und E nergiesysteme Rational Unified Process (RUP) - Definitionen.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Was ist Refactoring? Bevor man die Integration angeht, mag es angebracht sein, den.
es gibt (fast) nichts, was nicht anders gemacht werden könnte
1 Vorlesung Informatik 2 Algorithmen und Datenstrukturen (02 – Funktionenklassen) Prof. Dr. Th. Ottmann.
Rational Unified Process (RUP) - Definitionen
1 Analyse von Software-statisch- Darmstadt,den Presentation: Sebastian Schikowski Steve Kenfack.
Explizite und editierbare Metainformationen für Software Muster.
Programmiermethodik SS2007 © 2007 Albert Zündorf, University of Kassel 1 6. Story Driven Modeling Gliederung: 1. Einführung 2. Objektdiagramme zur Analyse.
Projektplan: Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University.
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Test Summary: m ein Fehler pro Tag m Test First m Funktionstests.
Objektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl
Erweiterung von Eclipse als Entwicklungs-Plattform aus Sicht des Eclipse-Boardmitgliedes TogetherSoft Together auf Basis von Eclipse.
UML Begleitdokumentation des Projekts
Vorlesung Gestaltung von soziotechnischen Informationssystemen - RequirementsEngineering und Contextual Design- Thomas Herrmann, Lehrstuhl Informations-
Tino Reindanz - FSU Jena Seminar Aktive Datenbanken – SS 2007 Folie 1 Seminar Aktive Datenbanken Rule Development Rule Development for Active Database.
Spatial Decision Support Systems (SDSS)
Anpassung des RUP an ein konkretes Projekt - 1
Vorgehensmodelle: Schwergewichtige Modelle
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Objektmodellierung Objekte und Klassen Ein Objekt ist ein Exemplar.
Spezifikation von Anforderungen
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM.
12. Vorlesung: Aktivitätsdiagramme
Unified Modeling Language Repetition / Einführung zu UML
UML WS 09/10: Datenbanken vs MarkUp Dozent: Prof. Dr. Manfred Thaller
Objektorientierte Analyse
Vorgehensweise bei der Software-Entwicklung des Publication Managers
NDK Enterprise Technologien Informationen Infrastruktur und Fallstudie Daniel Nydegger Studienleiter Enterprise System Entwicklung.
UML-Kurzüberblick Peter Brusten.
UML Modellierung des Verhaltens von Klassen und Objekten
PRO:CONTROL Ziel des Moduls Arbeitspakete
Projektmanagement Ziel und Umfang eines Softwareprojektes definieren
Fachkonzepte in der UML
Daten- und Ablaufmodellierung
Fingerübungen zu OOT Erstellen Sie, ausgehend vom nachfolgenden Beschrieb ein Use-Case Diagramm: Tanken an einer Tanksäule Der Kunde fährt mit seinem Wagen.
Objektorientierung.
Rational Unified Process
Software Engineering Grundlagen
Der Design-Flow eines ASIC
Software Engineering Strukturierter Entwurf
WebComposition & WCML Ein Vortrag von Michael Capper & Lars Völker.
Kurze Rekapitulation aus der Einführungsvorlesung Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 20. Oktober 2011.
MDA – Model Driven Architecture
Zitat-management-System Meilenstein 1
Objektorientierte (OO) Programmierung
…Be readY.
© Till Hänisch, 2002 BA Heidenheim Objekte und UML "You can model 80 percent of most problems by using about 20 percent of the UML." -- Grady Booch But.
Technische Universität München, Informatik XI Angewandte Informatik / Kooperative Systeme Verteilte Anwendungen: Entwurf Dr. Wolfgang Wörndl
Systems Requirements & Achitectur ENG 2 & ENG 3 Training Kunde,
Webservices SOAP und REST Nicole Fronhofs 1. Betreuer: Prof. Dr. Volker Sander 2. Betreuer: B. Sc. Sebastian Olscher.
Systemanalyse BA Heidenheim 2002.
 Präsentation transkript:

OOSE nach Jacobson Sebastian Pohl/ST7 Betreuer: Prof. Dr. Kahlbrandt

(C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering Gliederung Warum eine SE-Methode? OOSE: Methode Beispiel Zusammenfassung (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

(C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering Warum eine SE-Methode? erstellen von korrekter und sicherer Software Software muß wartbar und erweiterbar sein Methode muß einfach zu verstehen sein schnelle Entwicklung muß möglich sein (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

OOSE: von den Kundenanforderungen zur Anwendung System Analyse Konstruktion Tests Kunde hat Anforderung Entwickler bildet diese Anforderung in Objekte ab (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

(C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering Analyse was soll das System leisten? bilden einer stabilen, robusten, wartbaren, erweiterbaren systemunabhängigen Struktur wir verstehen den Problemraum besser Methode um mit User zu diskutieren Analyse ist Grundlage des gesamten Projekts (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

(C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering Requirements Modell Erkennen der Funktionalität 3 Werkzeuge: Use Case Model: beschreiben der Funktionalität Interface-Objects: beschreiben der Interfaces Problem-Domain-Objects: Objekte, die ein reales Gegenüber besitzen (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

(C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering Use Case Modell Grafische Form: Use Case Actors Connection Text Form: zu jedem Use Case wird die genaue Folge der Interaktionen zwischen Actor und System beschrieben Name Name (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

Recycling-Machine: Use Cases Dosen Flaschen Tagesreport Kisten Güter eintauschen Kunde Güter ändern Operator (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

(C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering Analyse Modell Strukturierung des Systems es werden Information, Präsentation und Verhalten modelliert Entity-Object Interface-Object Control-Object Connection Komplexität minimieren durch Bildung von Subsystemen (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

Recycling-Machine: Analyse Modell Alarmgeber Alarmdevice extends Drucker Kunden- panel Güter- empfänger Güter Report- generator Operator- panel Quittungs- basis erbt Dose Kiste Flasche (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

(C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering Konstruktion Basis bilden das Requirements und Analyse Modell warum nicht gleich von der Analyse-Phase zum Source-Code? Spezifizierung der Objekte Berücksichtigen der Implementationsumgebung Validierung der Analyse-Phase Konstruktion = Design + Implementation (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

Design Modell: Blöcke/IA-Diagramm Block: Objekte werden als Blöcke dargestellt einführen von Blöcken aus Klassenbibliotheken einführen neuer Blöcke (z.B. DBMS-Kapselung) Interaction-Diagramm: pro Use Case ein IA-Diagramm es wird beschrieben, wie Objekte kommunizieren Operationen (Methode) der Objekte (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

Recycling-Machine: Blöcke 1 Alarmgeber Alarmdevice Drucker Kunden- panel Güter- empfänger Güter Report- generator Operator- panel Quittungs- basis erbt Dose Kiste Flasche (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

Recycling-Machine: Blöcke 2 e[0...M] C C GüterListe[1] LinkedList Link erbt Quittungs- basis Tauschgut[1] Tauschgut Güter (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

Recycling-Machine: Interaction-Diagramm System grenze Kunden panel Güter empfänger Quittungs basis Güter Startknopf Sensoren aktiv DO neues Gut messen und check wenn neues Gut neues anlegen G.Anzahl = G.Anzahl + 1 Gesamt = Gesamt + 1 WHILE neue Güter start create activate item() neues Gut exists() neuGut(Gut) incr (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

Design Modell: Block-Design State-Transition-Diagramm: für jeden Block (Objekt) ein STD Verhalten der verschiedenen Objekte wird beschrieben Start-Symbol State Send message Receive message Return from message Decision abstrakte Ebene über der Programmiersprache (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

Recycling-Machine: STD (Güterempfänger) Init G. = Güter QB. = Quittungsbasis D. = Drucker Create erwarte erstes Gut item (l,h,w) druckeQuittung G.exist (l,h,w) D.print (Date) yes existed? Quittungsbasis exist? QB.printOn (str) no no D.print(str) yes QB.create QB.received (Gut) QB.delete return (fail) return (OK) -- (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

(C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering Test Modell Unit testing Integration testing System testing Tests müssen geplant werden: Analyse failure Plan testing Specify tests fail Identify tests Perform tests Finish test OK (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering

(C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering Zusammenfassung gutes Herausarbeiten der Objekte einfaches Modell viele Schritte nötig lokale Änderungen wartbar erweiterbar paralleles Arbeiten Tracebility (C) '95 Sebastian Pohl OOSE: Object Oriented Software Engineering