Vorlesung Softwaretechnik - Systemanalyse und -modellierung PDF

Vorlesung Softwaretechnik 4. Systemanalyse und -modellierung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Farbe! Warum, was, wie und wozu? Systemanalyse und -modellierung Warum? W...

Vorlesung Softwaretechnik 4. Systemanalyse und -modellierung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Farbe! Warum, was, wie und wozu? Systemanalyse und -modellierung Warum? Was? Wie? Wozu? Klassendiagramme Verstehen des Modellierungssprachen Aufgabengebiets häufig in der Industrie angewandt Wie man ein System mit Objektorientierte Analyse Strukturierung der Hilfe einer Reihe von Lösung Modellen zur Beschreibung von Objektdiagramme Struktur und Verhalten Schaffung einheitlicher entwickeln kann Sequenzdiagramme Terminologie Basiswissen für andere Vorlesungen Auffinden von Statecharts Grundkonzepten 2 Software Engineering | RWTH Aachen Systemmodellierung Analyse Anforderungs- (system analysis) spezifikation (Pflichtenheft, Anforderungs- requirements Ermittlung specification) "Lastenheft" (requirements Produktdefinition elicitation) (Funktionale Spezifikation, system specification) System- modellierung (system modelling) - Präzise Beschreibung der Systemfunktionen Entwurf - „Was“ ist zu realisieren, ohne das „Wie“ vorherzubestimmen 3 Software Engineering | RWTH Aachen Systemmodellierung Abstrakte Modellierung der zu lösenden fachlichen Aufgabe (fachliches Modell, domain model) Kleines Team Aufgabe: - Strukturierung des Aufgabengebiets - Schaffung einheitlicher Terminologie - Auffinden von Grundkonzepten Grundregeln: - Zusammenhang mit Anforderungsspezifikation sichern - Implementierungsaspekte ausklammern § Annahme perfekter Technologie - Funktionale Essenz des Systems § Datenhaltung, Benutzungsoberfläche im allgemeinen zurückstellen 4 Software Engineering | RWTH Aachen Objektorientierte Analyse (OOA) Grundidee: Modellierung der fachlichen Aufgabe durch kooperierende Objekte. Statisches Modell Dynamisches Modell Klassen: Nachweis der Eigenschaften und Bewältigung typischer Aufgaben von Objekten Anwendungsfälle OOA- Beziehungen Modell Zustände und zwischen Klassen Verhalten von Objekten (bzw. Objekten) beschreibt "Gesellschaft" kooperierender Objekte 5 Software Engineering | RWTH Aachen Modellierung mit UML: Strukturen Klassendiagramm - Statische Struktur - Typen, Vererbung - Innerer Aufbau von Klassen - mögliche Beziehungen zwischen ihren Objekten Objektdiagramm - Snapshot einer möglichen Situation - Exemplarisch: konkrete Objekte, konkrete Werte Später noch (für die Architektur): - Composition Structure Diagramm, Deployment Diagramm, … 6 Software Engineering | RWTH Aachen Modellierung mit UML: Verhalten Sequenzdiagramm - Interaktion zwischen Objekten - Exemplarische Abläufe, Methodenaufrufe Statechart - Zustandsautomat + Hierarchie + … - Beschreibt mögliche Abläufe und ihre Verbindung mit dem Zustandsraum eines Objekts Wir kennen schon: - Aktivitätsdiagramm - Use case 7 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 4. Systemanalyse und -modellierung Analyse Entwurf tierung Integration Wartung 4.1. UML Klassendiagramme Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Literatur: Software Engineering B. Rumpe: Modellierung mit UML, 2011 RWTH Aachen Vertiefung: Vorlesung Modellbasierte Softwareentwicklung http://www.se-rwth.de/ Software Language Engineering Warum, was, wie und wozu? Klassendiagramme Warum? Was? Wie? Wozu? Betrachtung der Modellierungssprache & Gemeinsames Verständnis Beispiel für Terminologie Intensiv in der Praxis Lesen / Verstehen von verwendet Klassendiagrammen Klasse mit Attributen und Methoden Strukturierung des Aufgabengebiets Vererbung, Schnittstellen, In der Analyse wichtig um Enumerations Konzepte und Erstellung von hochwertigen Verbindungen zwischen Umbau und/oder Konzepten zu verstehen Klassendiagrammen Assoziation, Komposition, Verfeinerung im Design Qualifizierte Assoziation 9 Software Engineering | RWTH Aachen  Grundlagen Grundkonzepte der Objektorientierung Ein System besteht aus variabel vielen Objekten. Die Anzahl und Struktur ändert sich dynamisch. Ein Objekt hat ein definiertes Verhalten. - Menge genau definierter Operationen - Operation wird beim Empfang einer Nachricht ausgeführt. Ein Objekt hat einen inneren Zustand. - Zustand des Objekts ist Privatsache (Kapselungsprinzip). - Resultat einer Operation hängt vom aktuellen Zustand ab. Ein Objekt hat eine eindeutige Identität. - Identität ist fest und unabhängig von anderen Eigenschaften. - Es können mehrere verschiedene Objekte mit identischem Verhalten und identischem inneren Zustand im gleichen System existieren. 10 Software Engineering | RWTH Aachen  Grundlagen Konzepte der Objektorientierung Ein Objekt gehört zu einer Klasse. - Die Klasse schreibt das Verhaltensschema und die innere Klasse Struktur ihrer Objekte vor. Klassen besitzen einen ‘Stammbaum’, in der Verhaltensschema und innere Struktur durch A Vererbung weitergegeben werden. - Vererbung bedeutet Generalisierung einer Klasse zu einer Oberklasse. Polymorphie: Eine Nachricht kann verschiedene B G Reaktionen auslösen, je nachdem zu welcher Unterklasse einer Oberklasse das empfangende Objekt gehört. - Polymorphe Methode: ist in verschiedenen Klassen unterschiedlich implementiert C D 11 Software Engineering | RWTH Aachen Klasse mit Attributen und Methoden Feld für den Klassennamen Dies ist ein Klassendiagramm CD „class diagram“ (CD) Sichtbarkeitsangaben: Attributliste: Auction Typen können public +long auctionIdent weggelassen werden #String title protected -Money bestBid private int numberOfBids Methodenliste: keine Signatur einer Methode kann +int getNumberOfBids() unvollständig sein Aussage #incNumberOfBids() +bid(Person, Time, Money) +getAuctionType() -setAuctionIdent(Long) Kommentar Prüft Korrektheit und erhöht die Anzahl der Gebote 12 Software Engineering | RWTH Aachen  Vererbung, Schnittstellen-Implementierung «interface» Serializable CD analyze +void serialize(Buffer) «abstract» Message #Time time … +Time getMessageTime() +deliverMessage(Auction) BidMessage ExtensionMessage StatusMessage #Person bidder #Auction auction #Auction auction #Auction auction #Time newClosing #int newStatus #Money bidValue #String reason #Time biddingTime 13 Software Engineering | RWTH Aachen Vererbung, Schnittstellen-Implementierung Interface durch «interface» Stereotyp markiert Serializable CD und mit kursivem Namen dargestellt +void serialize(Buffer) Interface- abstrakte Klasse Implementierung «abstract» mit abstrakter Methode Message (Manchmal auch nur #Time time kursiv dargestellt) Oberklasse … +Time getMessageTime() +deliverMessage(Auction) Vererbung mehrere Unterklassen BidMessage ExtensionMessage StatusMessage #Person bidder #Auction auction #Auction auction #Auction auction #Time newClosing #int newStatus #Money bidValue #String reason #Time biddingTime 14 Software Engineering | RWTH Aachen Abstrakte Klassen Klasse kann nicht instanziiert werden primär in Generalisierungshierarchien sinnvoll Dient zum "Herausheben" gemeinsamer Merkmale der Unterklassen Notation: - Schlüsselwort «abstract» oder Klassenname in kursiver Schrift Konto «abstract» oder Projekt Projekt Erweitertes Konto Haushaltskonto Industrie Sonstiges 15 Software Engineering | RWTH Aachen Vererbung (Generalisierung/Spezialisierung) Beziehung zwischen einer spezialisierten Klasse und einer allgemeineren Klasse - Die spezialisierte Klasse erbt die Eigenschaften der allgemeineren Klasse - Kann weitere Eigenschaften (in Form von Attributen und Methoden) hinzufügen - Eine Instanz der Unterklasse kann überall dort verwendet werden, wo eine Instanz der Oberklasse erlaubt ist (zumindest laut Signatur) Hierarchie von „ist-ein“ Beziehungen Mehrfachvererbung Generalisierung im Prinzip möglich «abstract» Person Projekt Spezialisierung Studierender Mitarbeiter Drittmittelprojekt Lehre InternesProjekt HiWi EU DFG 16 Software Engineering | RWTH Aachen Interface Implementierung Ein Interface kann viele andere Interfaces erweitern Eine Klasse kann viele Interfaces implementieren UML: Eine Klasse kann von vielen Klassen erben - Java: von nur einer Klasse erben (extends); C++: Mehrfachvererbung möglich CD «interface» «interface» «interface» Serializable BeanContextChild Collection Interface-Erweiterung Interface- «interface» Implementierung BeanContext BeanContextSupport 17 Software Engineering | RWTH Aachen Enumeration-Klasse CD Klasse, die eine Aufzählung definiert «enum» TrafficLightColor RED Drei Enum-Werte (Konstanten) YELLOW GREEN + TrafficLightColor switch() Funktionen auf den + boolean canIWalk() Konstanten 18 Software Engineering | RWTH Aachen  Assoziationen CD analyze auctions bidder Auction participants Person * * 1 1 * * «interface» «interface» Message BiddingPolicy TimingPolicy 19 Software Engineering | RWTH Aachen Assoziationen CD Assoziationsname Assoziationsrolle auctions bidder Auction participants Person * * Komposition Kardinalität 1 1 * * «interface» «interface» Message BiddingPolicy TimingPolicy Navigationsrichtung Navigation in beide Richtungen (hier nur in eine Richtung) 20 Software Engineering | RWTH Aachen Assoziationen Assoziationsname Assoziationsrolle CD auctions bidder Auction participants Person 0..99 * Kardinalität Assoziation als binäre Beziehung zwischen Kardinalitäten: Klassen - genau-eines: 1 - „Person participates in Auction“ - optional: 0..1 - Aus Sicht der Person: Navigation zu den Auktionen, - beliebig: * deshalb - nicht-null: 1..* (oder +) § Assoziationsrolle „auctions“ links - feste Intervalle: 3..9, 41 § Eine Person kann an bis zu 99 Auktionen (aber nur selten teilnehmen (0..99) verwendet) 21 Software Engineering | RWTH Aachen Assoziationen und Links CD auctions bidder Auction participants Person 0..99 * Ausprägung einer Assoziation durch Links zur Laufzeit: OD Strom:Auction Müller:Person Objekte Objektdiagramm Karton:Auction Huber:Person Auto:Auction Kohl:Person Links Schmidt:Person 22 Software Engineering | RWTH Aachen Aggregation Aggregation = spezielle Form der Assoziation Bedeutung Aggregation Beispiel - Schwache Zusammengehörigkeit, CD - Lesbar als „A hat ein B“ A Auto - Jedes der Teile hat einen eigenen Lebenszyklus 1 - Die Teile sind austauschbar 3…4 Probleme B Reifen - Schwer unterscheidbar von „normaler“ Assoziation A „hat“ B - In Programmcode gleich umgesetzt wie Assoziation Auto „hat“ 3 bis 4 Reifen - Eher selten verwendet - Daher: in Vorlesung nicht weiter behandelt 23 Software Engineering | RWTH Aachen Komposition Komposition = spezielle Form der Assoziation Kardinalität bei Raute ist CD Auction 1 (default) oder 0..1 Komposition durch Assoziation 1 1 Kardinalität «interface» «interface» BiddingPolicy TimingPolicy Bedeutung: - Kompositum aus Teilen zusammengesetzt - Objekte bilden eine zusammengehörende Einheit - Teile vom Kompositum abhängig § Lebenszyklus kombiniert § Austauschbarkeit nicht gegeben - Allerdings: Interpretationsunterschiede bei Werkzeugen § Daher: Projektspezifisch ggf. präzisieren! 24 Software Engineering | RWTH Aachen  Qualifizierte Assoziation CD analyze AllData auctionIdent String 1 1 Auction Person {ordered} {ordered} * * Message 25 Software Engineering | RWTH Aachen Qualifizierte Assoziation CD AllData Qualifikator mit auctionIdent String Qualifikator mit Typangabe Attribut der Zielklasse 1 Qualifizierte 1 Anzahl der Objekte, Auction Assoziation Person die bei qualifiziertem Zugriff erreicht werden {ordered} {ordered} geordnete, und damit durch * * natürliche Zahlen qualifizierte Message Assoziation Anzahl der verlinkbaren Objekte (gesamt) 26 Software Engineering | RWTH Aachen Qualifizierte Assoziation und Links auctions bidder Person CD Auction String participants * 0..1 String login Qualifikator “String“ erlaubt einzelne Objekte zu selektieren Dasselbe Objekt kann in unterschiedlichen Auktionen unterschiedlich qualifiziert sein. OD "Kohl" Theo Kohl Strom:Auction "Huber" Dirk Huber "Hans" Hans Kohl Auto:Auction "Kohl" 27 Software Engineering | RWTH Aachen Qualifizierte Assoziation Qualifizierte Assoziationen erlauben Selektion einzelner Objekte aus einer Menge mit Qualifikator Qualifikatoren können sein: - Zahlen-Intervall (0-..), das Reihenfolge anzeigt ({ordered}) - Expliziter Identifikator (Attribut) des Zielobjekts (auctionIdent) - Frei wählbarer Wert eines vorgebenen Typs Auch Komposition kann qualifiziert sein Qualifikation an beiden Enden möglich (aber selten) Qualifizierte Assoziation benötigt erweiterte Mechanismen zur Bearbeitung - Selektiver Zugriff, selektive Änderung 28 Software Engineering | RWTH Aachen Beispiel: Qualifizierte Assoziation und Links mit Attribut als Qualifier Person CD anrufer kontakt +String name Telefonbuch telnr nameZurNummer * 1 +String telnr OD 0241 1111111 Melanie Mayr Gelbe Seiten: 0241 3333333 Telefonbuch 0241 5555555 Maximilian Berger 0241 5555555 Gerd Müller OnlineTel: Telefonbuch 0241 3333333 29 Software Engineering | RWTH Aachen Beispiel: Qualifizierte Assoziation und Links mit Typ als Qualifier Person CD anrufer kontakt +String name Telefonbuch String hatKontakt * 1 +String telnr OD "Melli" Melanie Mayr Anna:Telefonbuch "Maxi" "Darling" Maximilian Berger "Zahnarzt Dr. Müller" Hans:Telefonbuch Gerd Müller "Maximilian Berger" Jutta:Telefonbuch "Darling" 30 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 4. Systemanalyse und -modellierung Analyse Entwurf tierung Integration Wartung 4.2. UMLP-Klassendiagramme zur Codegenerierung Anforderungs- UML System- Code- ermittlung modellierung generierung Prof. Bernhard Rumpe Literatur: Software Engineering B. Rumpe: Modellierung mit UML, 2011 RWTH Aachen Vertiefung: Vorlesung Modellbasierte Softwareentwicklung http://www.se-rwth.de/ Software Language Engineering Code aus einer Klasse synthetisieren? Auction CD +long auctionIdent #String title Vorschlag? -Money bestBid int numberOfBids #incNumberOfBids() 32 Software Engineering | RWTH Aachen Code aus einer Klasse synthetisieren? Auction CD +long auctionIdent #String title -Money bestBid int numberOfBids #incNumberOfBids() 11 class Auction { C++ 12 public: 13 long auctionIdent; 1 class Auction { Java 14 int numberOfBids; 2 public long auctionIdent; 15 protected: 3 protected String title; 16 std::string title; 4 private Money bestBid; 17 private: 5 public int numberOfBids; 18 Money bestBid; 6 19 protected: 7 protected void incNumberOfBids() {... } 20 void incNumberOfBids() {... } 8} 21 }; 33 Software Engineering | RWTH Aachen Alternative Code-Synthesen? Mögliche zusätzliche Anforderungen: - get/set-Methoden für Attribute - Serialisierbarkeit des Objekts - Speichern von Objekten in einer Datenbank-Tabelle § evtl. sogar die Erzeugung der Tabelle als SQL-Statement - Attributzugriff wird durch Security-Manager gesichert - Plattformabhängigkeit des Codes Unterschiedliche Anforderungen führen zu unterschiedlichen Realisierungen: - Das Modell als abstrakte (!) und kompakte Darstellung - Technologieunabhängig! 34 Software Engineering | RWTH Aachen Beispiel: Code-Generierung mit get/set-Methoden JAVA Auction CD Generator +long auctionIdent 1 class Auction { 2 private long _auctionIdent; #String title 3 private String _title; -Money bestBid 4 private Money _bestBid; int numberOfBids 5 private int _numberOfBids; 6 7 synchronized public long getAuctionIdent() { return _auctionIdent; } 8 synchronized protected String getTitle() { return _title; } 9 synchronized private Money getBestBid() { return _bestBid; } 10 synchronized public int getNumberOfBids() { return _numberOfBids; } 11 12 synchronized public void setAuctionIdent(long x) { _auctionIdent=x;} 13 synchronized protected void setTitle(String x) { _title =x; } 14 synchronized private void setBestBid(Money x) { _bestBid =x; } 15 synchronized public void setNumberOfBids(int x) { _numberOfBids =x; 16 } 17 } 35 Software Engineering | RWTH Aachen Beispiel: Code-Generierung mit get/set-Methoden 1 class Auction { C++ Auction CD 2 private: 3 long _auctionIdent; +long auctionIdent 4 std::string _title; Generator #String title 5 Money _bestBid; -Money bestBid 6 int _numberOfBids; int numberOfBids 7 8 public: 9 long getAuctionIdent() const { return _auctionIdent; } 10 void setAuctionIdent(long x) { _auctionIdent=x;} 11 int getNumberOfBids() const { return _numberOfBids; } 12 void setNumberOfBids(int x) { _numberOfBids =x;} 13 protected: 14 std::string getTitle() const { return _title; } 15 void setTitle(std::string x) { _title =x; } 16 private: 17 Money getBestBid() const { return _bestBid; } 18 void setBestBid(Money x) { _bestBid =x; } 19 }; 36 Software Engineering | RWTH Aachen Code für Qualifizierte Assoziation und Links Person CD anrufer kontakt +String name Telefonbuch String hatKontakt * 1 +String tel Auszug CD Telefonbuch … - Mapkontakt +Collection getKontakt() z.B. HashMap +putKontakt(String n, Person p) und einige der möglichen Zugriffsfunktionen 37 Software Engineering | RWTH Aachen Generative Software Engineering Einsatzgebiete: Generative Software Engineering (GSE) ist eine - Codegenerierung Methode der effizienten Generierung von (Teilen von) Software durch Generatoren - Generierung von Testfällen (z.B. auch JUnit-Testfälle) auf Grundlage von Modellen - Prototyping wie z.B. der UML oder einer DSL (domain-specific language) - Simulation mit dem Ziel, die Qualität zu erhöhen und Weitere Gründe: - Vermeidung lästiger Programmieraufgaben die Entwicklungszeit zu senken. - Technik-unabhängiger - Softwarestack-unabhängiger - Varianten darstellbar 38 Software Engineering | RWTH Aachen Code Synthese von kompletten, lauffähigen Informationssystemen? Informationssysteme (IS) sind formale, soziotechnische, organisatorische Systeme, die der Erfassung, Verarbeitung, Speicherung und Verteilung von Informationen dienen. Aus soziotechnischer Sicht setzen sich Informationssysteme aus vier Komponenten zusammen: Aufgaben, Menschen, Strukturen (oder Rollen) und Technologien. Hauptziel Information System ▪▪▪ Admin Information bereitstellen, genauer: ▪▪▪ ▪▪▪ - create, read, update, delete (CRUD) von Daten, GUI GUI Models Generator Models - Suche, Authentifikation, Visualisierung,... System ▪▪▪ Manager ▪▪▪ ▪▪▪ Core GSE Lösung Data Model Verwendung eines Generator Frameworks, wie z.B. Reader MontiGem, um ein System zu generieren Developer {…} Templates Data Storage 39 Software Engineering | RWTH Aachen Modellgetriebenes Software Engineering von Informationssystemen ▪▪▪ ▪▪▪ ▪▪▪ GENERATOR Framework Data Model ▪▪▪ ▪▪▪ ▪▪▪ ▪▪▪ ▪▪▪ ▪▪▪ View Developer Models INFORMATION SYSTEM ▪▪▪ ▪▪▪ Admin ▪▪▪ ▪▪▪ ▪▪▪ GUI ▪▪▪ System Core Models Manager Reader Data Storage 1 Modelle definieren 2 Generieren 3 Handgeschriebene Erweiterungen Required: Klassendiagramme (Datenstruktur), Datenbank … durch hookpoints hinzufügen GUI Modelle (Views) Kommunikationsinfrastruktur Ermöglicht die Neugenerierung zwischen Frontend und Backend Definition der Geschäftslogik Optional: OCL (Validierung von Eingabedaten), Grafische Nutzer Interfaces (GUI) Anpassungen der Oberfläche BPMN (Workflows) Im Code sind hookpoints vorgesehen Optimierung des generierten Codes 40 Software Engineering | RWTH Aachen Beispiel “Social Network” 1 1 CD SocNet Relationship * invited «abstract» sent * Profile {ordered} «interface» boolean isPending Date requested * initiated 1 * received * Post String profileName Date accepted /int numOfPosts {ordered} /int friends 1 * «enum» InstantMessage RelationType 0..1 Person * * Group replyTo Date timestamp FRIEND member String content FAMILY Date lastVisit boolean isOpen FOLLOWER String firstName Date created COLLEAGUE String secondName String purpose OTHER Date dateOfBirth /int members PhotoMessage int zip profileName String city String country organizer * organized picture 1.. * tagged 1 1 Photo * Tag * 1 double height boolean confirmed double width 41 Software Engineering | RWTH Aachen We Use a Textual Notation for CDs A class diagram thus becomes a text-file of this form and is stored in SocNet.cd 1 classdiagram SocNet { CD 2 3 class {...} 4 5 class {...} 6 7 enum {...} 8 9 association... ; 10 11 composition... ; 12 } 42 Software Engineering | RWTH Aachen Classes and Interfaces CD SocNet Classes and interfaces look similar to Java code «interface» Post but neither contain methods nor visibilities. 1 classdiagram SocNet { InstantMessage 2 Date timestamp 3 interface Post; String content 4 5 class InstantMessage implements Post { 6 Date timestamp; 7 String content; 8 } 9 } 43 Software Engineering | RWTH Aachen Associations (I) * * CD SocNet An association in the CD: Person member Group association member [*] Person Group [*]; navigation direction, assoc. name class name multiplicity, can be [*], , [0..1], [1..*] Navigation directions: ->, B; composition c2 A B [*]; composition c3 A [[theQualfier]] -- B ; composition c4 A -- B [*] ; composition c5 A -> B [1..*]; 46 Software Engineering | RWTH Aachen Enumerations Relationship CD SocNet An enumeration (enum) can be used as type: boolean isPending Date requested class Relationship { Date accepted boolean pending; Date requested; 1 Date accepted; «enum» } RelationType FRIEND FAMILY FOLLOWER enum RelationType { COLLEAGUE FRIEND, FAMILY, FOLLOWER, COLLEAGUE, OTHER; OTHER } association Relationship -> RelationType ; 47 Software Engineering | RWTH Aachen Importing Types and Classes An import statement, similar to Java is available 1 package dex; 2 import java.util.Date; Import foreign types, e.g. defined as Java classes, 3 import com.acronio.accounting.*; like Date or Account 4 Imported types are used as class types in the CD 5 classdiagram MyBankApp { 6 Note: A library with these types must be known by 7 class MyAccount extends Account { CD4Analysis tool (e.g. for CoCo check) 8 Date opening; 9 String name; Note: if imported class is used as supertype, some 10 } API functions must be provided 11 12 association transfers Note: import from other models (e.g. other class 13 MyAccount -> MoneyTransfer ; diagrams) is also possible (but not explained here, 14 see --path) 15 } 48 Software Engineering | RWTH Aachen Generic Types and Classes CD4Analysis does not allow to introduce generic 1 package dex; types 2 import java.util.Date; 3 import com.acronio.accounting.*; It only provides these generic type constructors: 4 5 classdiagram MyBankApp { - Optional<. > 6 - Set<. > 7 class MyAccount { - List<. > 8 Optional someDate; - Map<. ,. > 9 List numbers; 10 Set owners; with one, respectively two type parameters. Map phoneBook; 11 12 } Note: Use of generics with classes is normally not recommended, as associations do have the very(!) 13 14 } same effect. E.g. do not use Set, but association... -> Person [*]. 15 49 Software Engineering | RWTH Aachen  Appendix The full CD SocNet in textual form (I) package dex; import java.util.Date; CD SocNet classdiagram SocNet { abstract class Profile { String profileName; /int numOfPosts; /int friends; } class Person extends Profile { Date lastVisit; String firstName; String secondName; Date dateOfBirth; int zip; String city; String country; } class Group extends Profile { boolean isOpen; Date created; String purpose; /int members; } association member [*] Person Group [*]; association Person (organizer) (organized) [[profileName]] Group [*]; 50 Software Engineering | RWTH Aachen  Appendix The full CD SocNet in textual form (II) class Relationship { boolean isPending; Date requested; CD SocNet Date accepted; } association invited [*] Relationship Profile ; association initiated [*] Relationship Profile ; enum RelationType { FRIEND, FAMILY, FOLLOWER, COLLEAGUE, OTHER; } association Relationship -> RelationType ; interface Post; association received [*] Profile Post [*] ; association sent Profile Post [*] ; class InstantMessage implements Post { Date timestamp; String content; } association [*] InstantMessage (replyTo) InstantMessage [0..1]; class PhotoMessage extends InstantMessage; association [1..*] Photo (picture) PhotoMessage; class Photo { double height; double width; } class Tag { boolean confirmed; } association Person (tagged) Tag [*]; association [*] Tag Photo ; } 51 Software Engineering | RWTH Aachen CD4A Context Conditions - 1 Diagram Name Extends / Implements - Must match file name - No inheritance cycles - First character upper-case - Classes may only extend classes, interfaces only interfaces Keywords - Only interfaces may be implemented - May not be used for types, e.g., “class”, “implements” Attributes Classes, Interfaces, Enumerations - Start in lower-case and must be unique - Must be unique - Type must be resolvable and (optional) initialization must - First character upper-case be type compatible - Enum constants must be unique within an enum - Overriding attribute in sub class must be of same type as the attribute in super class 52 Software Engineering | RWTH Aachen CD4A Context Conditions - 2 Associations Types - Source may not be an enumeration or external type - Generics may not be nested - Ordered associations must have a cardinality - Usage of generics must be parameterized with the correct greater than 1 number of type-parameters (e.g., invalid: Optional, - Qualified Optional, Optional, valid: Optional) § Attribute of attribute-qualifier must exist in referenced - Derived attributes may not be initialized class § Type of type-qualifier must be resolvable - Names: § Association names and role names must start in lower- case § Association names, role names and implicit role names (lower-case name of target type) must not conflict with each other or attributes in the source class - Composition § Cardinality on side of the composite is (default) or [0..1]. 53 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 4. Systemanalyse und -modellierung Analyse Entwurf tierung Integration Wartung 4.3. Modellqualität: UML Klassendiagramme Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Literatur: Software Engineering B. Rumpe: Modellierung mit UML, 2011 RWTH Aachen Vertiefung: Vorlesung Modellbasierte Softwareentwicklung http://www.se-rwth.de/ Software Language Engineering  Beispiel-Klassendiagramm aus der Seminarverwaltung CD Person analyze name adresse telefon Kunde SeminarArt Dozent umsatz name stundensatz Buchungswunsch kundennummer veranstCode Buchung Veranstaltung datum status datum prüfen() stornieren() absagen() 55 Software Engineering | RWTH Aachen Kritik zum Klassendiagramm aus der Seminarverwaltung CD Annahme: entstanden in einer frühen Phase der Analyse * Assoziationen ohne weitere Informationen * Attribute ohne Datentyp: kann ok sein * Methoden selektiv genannt * Etwas komisches Layout * Buchung vs. Buchungswunsch?? Doppelt * Buchung ist nicht mit Veranstaltung verbunden (auch Buchungswunsch nicht) * Preise für Teilnahme? * Ort, etc.? 56 Software Engineering | RWTH Aachen  Beispiel: Campus-Management analyze CD Studiengang 0..1 koordiniert «abstract» name: String Person * name: String email: String * * verantwortlich Modul name: String 1 credits: Int 1 * Note * 1 * Akademiker Student titel: String 1 matrNr: Int * notenwert: Int * Lehrveranstaltung credits: Int 57 Software Engineering | RWTH Aachen Kritik zum Klassendiagramm Campus-Management CD Annahme: mittlere Phase der Analyse (nur die Essenz gezeigt) Qualität gut: Assoziationen präzisiert Attribute mit Datentyp „Koordinator“ Groß & kein Verb Assocs ohne Namen: kann ok sein, da eindeutig Probleme: - Studierende können unterschiedliche Credits für dieselbe Veranstaltung bekommen - Selbe Veranstaltung mehrfach benotbar … - Dozent benotet einfach fremde Module 58 Software Engineering | RWTH Aachen  Beispiel: Kalender Besprechungsraum raumNr CD analyze kapazität reservieren() Termin freigeben() Team 0..1 Ort name * 1 0..1 Privattermin Teambesprechung beschreibung titel beginn beginn 1..* 1 Leiter dauer dauer * leitet Teammitglied ort 1 name wegzeit raumFestlegen() einladen() abteilung verschieben() Teilnahme absagen() terminBestätigen() * 2..* genehmigen() * verschieben() für 1 59 Software Engineering | RWTH Aachen Kritik zum Klassendiagramm Kalender Annahme: frühe Phase der Analyse (nur die Essenz gezeigt) Qualität mittel: Assoziationen präzisiert Attribute ohne Datentyp Manche Methoden Layout komisch Termin nicht eingebunden, Vererbung? Unklar, ob Leiter auch in Team-Assoc enthalten 60 Software Engineering | RWTH Aachen Eigeninitiative: Klassendiagramm für... Auktion bei Ebay Autoverleih E-Scooter Verleih discuss 61 Software Engineering | RWTH Aachen Was haben wir gelernt? Klassen- diagramme in Gute Modelle der Analyse Klassen Assoziationen erstellen …sind notwendig …haben Attribute … haben Namen, …benötigt viel um die wichtigsten und Methoden Rollen, Übung und Können Begriffe und Kardinalitäten, Zusammenhänge zu Navigations- verstehen … können Abstrakte richtungen Klassen, Interfaces, Enumerations sein … werden im …gibt es in weiteren Verlauf unterschiedlichen (Entwurf) ev. … können von Varianten: umgebaut bzw. anderen Klassen Assoziation, verfeinert erben Komposition, Qualifizierte Assoziation …können Interfaces implementieren 62 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 4. Systemanalyse und -modellierung Analyse Entwurf tierung Integration Wartung 4.4. Methodik der Objektorientierten Analyse Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Methodik der Objektorientierten Analyse Klassen finden animated Ziel: Iteration Assoziationen und Von den Aggregationen finden Anforderungen zu einem Modell Attribute finden der fachlichen Aufgabe Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Diese Zustandsdiagramme erstellen Variante ist Operationen spezifizieren datenorientiert Strukturen überprüfen Subsysteme finden 64 Software Engineering | RWTH Aachen Klassen in der Analyse Konzentration auf relevante Klassen: - Das sind meist Datenklassen - Oft nicht: § Technische Klassen (GUI, DB, etc.) § Eher keine Manager-/ Verwalterklassen Ggf. eigene Klassendiagramme für - reines Datenmodell - Datenmodell + Manager - … + technische Klassen Oft ist ein Umbau der (Analyse-)Datenklassen bei der Architekturdefinition sinnvoll! Viele kleine Methodiken lösen Detailprobleme … 65 Software Engineering | RWTH Aachen Pakete: Beispiel Personal- und Seminar- CD Kundenverwaltung verwaltung Person Seminartyp Mitarbeiter Dozent Veranstaltung Kunde Buchung Optimierbar? 66 Software Engineering | RWTH Aachen Pakete finden Ein Paket ist eine Gruppe von Klassen - UML: "Subsystem" als spezielles Paket (Architektureinheit) Ein Paket: - ist für sich allein verständlich - hat eine wohldefinierte Schnittstelle zur Umgebung - ermöglicht Betrachtung des Systems aus einer abstrakteren Sicht Ziel: Starke Bindung innerhalb des Pakets - Einheitlicher Themenbereich - Aggregation und Vererbung soweit wie möglich nur innerhalb des Pakets Ziel: Schwache Kopplung zwischen Paketen UML: - Möglichst wenig Assoziationen über Paketgrenzen hinweg Faustregeln für ein sinnvolles Paket: - 10-15 Klassen - 1 DIN A4 Seite für ein Diagramm 67 Software Engineering | RWTH Aachen Methode: Entkopplung von Paketen Personal- und Seminar- CD Kundenverwaltung verwaltung Dozent Seminartyp Veranstaltung Starke Kopplung Wichtigste Möglichkeit zur Entkopplung: Fachliche Zusammengehörigkeit sicherstellen Weitere Möglichkeiten zur Entkopplung (schon entwurfsnah): - Dozentenklasse zerlegen in Personal- und seminarbezogene Information - "Stellvertreter"-Klassen einführen (siehe auch Entwurfsmuster Proxy, Half-Object-plus-Protocol) - Schnittstellen-Objekte einführen (z.B. Personalverwaltungs-API) (Entwurfsmuster Facade) 68 Software Engineering | RWTH Aachen Methode: Zuordnung von Operationen Prinzipien: - Möglichst intensive Ausnutzung der Datenzuordnung: § da zuordnen, wo am besten von lokaler Information Gebrauch gemacht werden kann - Notwendigkeit zur Objektinteraktion möglichst minimieren - Möglichst Gebrauch von vorhandenen Operationen machen bzw. Operationen in verschiedenen Kontexten wiederverwenden. Es gibt auch Zweifelsfälle - Insbesondere ist Nutzungsverhalten oft schwer abschätzbar 69 Software Engineering | RWTH Aachen Zusammenfassung | Objektorientierte Analyse … also nicht übertreiben! 70 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 4. Systemanalyse und -modellierung Analyse Entwurf tierung Integration Wartung 4.5. Objektdiagramme Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Warum, was, wie und wozu? Objektdiagramme Warum? Was? Wie? Wozu? Modellierung spezieller Exemplarische Objekte mit Attributen, Situationen bzw. Modellierung von Typen und Werte Randfälle Beschreibung konkreter Situationen Objekten Kommunikation mit den Links der Assoziationen Kunden Details hilfreich z.B. beim Lesen von Testen Objektdiagrammen Komplexere Objektstrukturen Verwendung in Tests 72 Software Engineering | RWTH Aachen  Grundlagen Objektdiagramme Exemplarische Modellierung von Strukturen, z.B. - statisch unveränderliche Strukturen in eigentlich dynamischen objektorientierten Systemen - spezielle Situationen, die z.B. als Vor- oder Nachbedingung bei Tests verwendet werden Sammlung von Objekten und deren Beziehungen zu einem Zeitpunkt im Leben eines Systems - Instanzen - Exemplarisch - Mehrere Objektdiagramme können unterschiedliche Situationen zu verschiedenen Zeitpunkten innerhalb desselben Systemteils beschreiben 73 Software Engineering | RWTH Aachen Beispiel: Einzelnes Objekt OD discuss … strom:Auction +long auctionIdent = 783 #String title = “Strom, 7GW“ -Money bestBid int numberOfBids = 112 Anzahl der gültigen Gebote wird aus Message -Liste berechnet 74 Software Engineering | RWTH Aachen Beispiel: Einzelnes Objekt dies ist ein Objektdiagramm (OD) Objektname: Typ OD Sichtbarkeitsangaben und Attributliste: … Typ, Attributname und Wert. andere Merkmale können strom:Auction Typen und Werte können angegeben werden +long auctionIdent = 783 ausgelassen werden #String title = “Strom, 7GW“ -Money bestBid int numberOfBids = 112 Anzahl der gültigen Gebote wird aus Message eine Methodenliste -Liste berechnet wird nicht angegeben! Kommentar 75 Software Engineering | RWTH Aachen Beispiel: Linkstruktur … OD … participants theo:Person kupfer912:Auction participants personIdent = 1783 long auctionIdent = 912 participants name = “Theobald Schmidt“ String title = “420t Kupfer“ isActive = false discuss int numberOfBids = 0 observers otto:Person … personIdent = 20544 name = “Ottokar Huber“ … … isActive = true «interface» «interface» :BiddingPolicy :TimingPolicy lisa:Person … personIdent = 45392 name = “Elisabeth Müller“ isActive = true 76 Software Engineering | RWTH Aachen Beispiel: Linkstruktur Links der „participants“-Assoziation bidirektionale Navigation … OD … participants theo:Person kupfer912:Auction participants personIdent = 1783 long auctionIdent = 912 participants name = “Theobald Schmidt“ String title = “420t Kupfer“ isActive = false discuss int numberOfBids = 0 observers otto:Person … Link vom Kompositum zu seiner Komponente personIdent = 20544 name = “Ottokar Huber“ … … isActive = true «interface» «interface» :BiddingPolicy :TimingPolicy lisa:Person … Stereotyp illustriert, personIdent = 45392 dass hier Interfaces name = “Elisabeth Müller“ angegeben sind mehrere Objekte isActive = true derselben Klasse 77 Software Engineering | RWTH Aachen  Objektstruktur mit Einbettung, um Komposition zwischen Objekten darzustellen kupfer912:Auction … OD long auctionIdent = 912 animated String title = “420t Kupfer“ int numberOfBids = 0 … … bidpol:DownwardBiddingPolicy timePol:ConstantTimingPolicy int kind = BiddingPolicy.DOWNWARD int status = TimingPolicy.RUNNING int bidCountMax = BiddingPolicy.UNLIMITED boolean isInExtension = false int extensionTimeSecs = 180 min:Money … start:Time … long amount = 52290000 Int decimalplaces = 2 long timeSc = 953640000 String currency = "$US" /String time = "13:00:00" /String full = "522.900,00 $US“ /String date = „21.Februar 2001“ finish:Time … max:Money … long timeSc = 953647200 /String full = "720.000,00 $US" /String time = "15:00:00" /String date = "21.Februar 2001" Siehe: http://mbse.se-rwth.de/book1/index.php?c=chapter4-1#x1-9100412 78 Software Engineering | RWTH Aachen Was haben wir gelernt? OO-Analyse Methode Objektdiagramme Objekte Ziel: Von den Modellierung von … haben Attribute mit Anforderungen zu einem Strukturen auf konkreten Werten aber Modell der fachlichen exemplarischer Basis beschreiben KEINE Aufgabe eigenen Methoden, … können für Tests Datenorientiert (vs. verwendet werden z.B. … können Links zu Verhaltensorientiert) Randfälle und Spezialfälle anderen Objekten haben und Identifikation von Klassen, Assoziationen, Attribute, … können komponiert Operationen, Szenarien, sein Vererbungsstrukturen,… 79 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 4. Systemanalyse und -modellierung Analyse Entwurf tierung Integration Wartung 4.6. Modellierung von Szenarien: Sequenzdiagramme Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Warum, was, wie und wozu? Sequenzdiagramme Warum? Was? Wie? Wozu? Modellierung von Benötigen Verständnis Verhaltenssequenzen, Erstellung von Besseres Verständnis zu Interaktionen der d.h. beispielhafte Sequenzdiagrammen von Szenarien und Systemkomponenten Folgen von für einzelne Szenarien Fehlerfällen Interaktionen Normalfälle Szenarien für beschreiben und Kommunikation Modellierung von Fehlerfälle Normalfälle, Ausnahmefälle, Tests zwischen Objekten Testszenarien untersuchen 81 Software Engineering | RWTH Aachen  Wiederholung Methodik der Objektorientierten Analyse Klassen finden Ziel: Iteration Assoziationen und Von den Aggregationen finden Anforderungen zu einem Modell Attribute finden der fachlichen Aufgabe Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Diese Zustandsdiagramme erstellen Variante ist Operationen spezifizieren datenorientiert Strukturen überprüfen Subsysteme finden 82 Software Engineering | RWTH Aachen Szenarien Definition: Ein Szenario ist eine Beschreibung einer beispielhaften Folge von Interaktionen von Akteuren mit dem System zur Beschreibung eines Anwendungsfalls. Es gibt Szenarien für Normalfälle ('gut-Fälle') und Ausnahmefälle. Anwendungsgebiete: - Normalfall-Szenarien zur Diskussion mit Anwendern - Ausnahmefall-Szenarien zur Erkennung abzufangender Fehlerquellen - Testszenarien um festzulegen, welche Tests auszuprobieren sind - In Abläufen erzeugte Szenarien, um Debugging durchzuführen 83 Software Engineering | RWTH Aachen Einfaches Sequenzdiagramm Objekte werden oben angeordnet Die Zeitlinie schreitet für alle Objekte gleich voran Ein Sequenzdiagramm zeigt den Nachrichten- bzw. Ereignisfluss zwischen Objekten - z.B. Versenden von Nachrichten, Datenaustausch, Methodenaufruf SD c:Customer b:ATM dies ist ein Sequenzdiagramm (SD) Objekt InsertCard Nachricht getPin return(nr) Zeitlinie (nach unten) 84 Software Engineering | RWTH Aachen Grundlegende SD Elemente Objektidentifikator Klassenname Objektsymbol: c:Customer ohne Aktivierung Aktivierungsbalken Zeitlinie: Parameter: optional angeben Pfeile: Kommunikationsform transfer(amount, receiver) nicht festgelegt Nachrichtenname synchrone Kommunikation asynchrone Kommunikation 85 Software Engineering | RWTH Aachen Pfeilarten Neutrale Pfeile: - legen den Kommunikationsmechanismus nicht fest - erlauben diese Entscheidung später zu treffen Synchrone Pfeile: - Interaktion ist ein gemeinsames Ereignis zwischen Sender und Empfänger - keine Verzögerung, z.B. wie ein Telefongespräch - Beispiele: Methodenaufruf Asynchrone Pfeile: - Senden und Empfang einer Nachricht sind unterschiedliche Ereignisse - Normalerweise ist Verzögerung im Spiel, wie bei SMS-Senden - Empfänger muss nicht sofort bereit sein, die Nachricht zu empfangen 86 Software Engineering | RWTH Aachen Aktivierungsbalken (Aktivierung) Aktivierungsbalken - erlauben anzuzeigen, wenn ein Objekt aktiv ist - können den Kontrollfluss im System darstellen - können verschachtelt werden (Objektrekursion) SD c:Customer b:Bank transfer(receiver,amount) acknowledged logTransfer(amount) 87 Software Engineering | RWTH Aachen Returns Return zeigt an, - wenn der Kontrollfluss zum Aufrufer zurück geht - welches Ergebnis dabei übertragen wird Spezielle Pfeile zeigen Returns an (diese sind optional) Asynchrone Nachrichten haben natürlich keine Returns SD b1:Bank b2:Bank transfer(amount) true Expliziter Return 88 Software Engineering | RWTH Aachen Objekterzeugung und -löschung Objekte die erzeugt werden, werden an der Erzeugungsstelle dargestellt Eine create-Nachricht zeigt direkt auf das Objekt Objektlöschung wird durch ein Kreuz am Ende der Zeitlinie angezeigt - (Java kennt keine übrigens explizite Objektlöschung) SD c:Customer b1:Bank Erzeugung b2:Bank transfer(rb, ra, a) Transaction(ra, a) t:Transaction BTransfer(t) act(t) delete Löschung 89 Software Engineering | RWTH Aachen Beispiel: Autovermietung k:Kunde m:Mitarbeiter visa:Kreditfirma f:Fahrzeug SD buche(k, f, dauer) getKreditkarte() kk istGueltig(kk) true istVerfuegbar(dauer) true new(k, f, kk, dauer) v:Vertrag v v 90 Software Engineering | RWTH Aachen Beispiel: Autovermietung k:Kunde m:Mitarbeiter visa:Kreditfirma f:Fahrzeug SD buche(this, f, dauer) getKreditkarte() kk istGueltig(kk) false Ablehnung 91 Software Engineering | RWTH Aachen Beispiel: Auktionssystem SD kupfer912: bidPol: timePol: Auction BiddingPolicy TimingPolicy placeBid(bid) validateBid(bid) Analyse return BiddingPolicy.OK newCurrentClosingTime(kupfer912, bid) return t 92 Software Engineering | RWTH Aachen Eigeninitiative: Sequenzdiagramm für … Telefonanruf über Vermittlung oder: Auktionsverlauf bei Ebay, oder... discuss 93 Software Engineering | RWTH Aachen Was haben wir gelernt? Sequenz- Beschrieben Szenarien diagramme werden kann… … beschreiben eine …sind exemplarische Systeminterne exemplarische Folge von Verhaltens- Kommunikation Interaktionen von beschreibungen Akteuren mit dem Kommunikation System bestehen aus… zwischen System und Anwender …werden durch … einer horizontal Kommunikation Sequenzdiagramme angeordneten Menge zwischen dargestellt von Objekten Anwendern/Menschen Normalfälle ('gut-Fälle'), … nach unten Ausnahmefälle, voranschreitenden Testfälle Zeitlinien und … synchronen oder asynchronen Interaktionen zwischen den Objekten 94 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 4. Systemanalyse und -modellierung Analyse Entwurf tierung Integration Wartung 4.7. Dynamik Modellierung mit Statecharts Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Warum, was, wie und wozu? Statecharts Warum? Was? Wie? Wozu? Verhalten ist die Beschreibung des Essenz von Software Objektverhaltens Definition zulässiger Erstellung von zustandsabhängiger Ereignisfolgen, Statechart Modellen Protokolle, Verhalten abhängig Modellierung von Steuerungen von internen Objektzuständen und Zuständen Zustandsübergängen 96 Software Engineering | RWTH Aachen  Wiederholung Methodik der Objektorientierten Analyse Klassen finden Ziel: Iteration Assoziationen und Von den Aggregationen finden Anforderungen zu einem Modell Attribute finden der fachlichen Aufgabe Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Diese Zustandsdiagramme erstellen Variante ist Operationen spezifizieren datenorientiert Strukturen überprüfen Subsysteme finden 97 Software Engineering | RWTH Aachen Beispiel: Zustandsmodell einer Tür Automat