eingebetteter Systeme

Transkript

1 im WiSe 2010/11 Entwicklung verteilter eingebetteter Systeme Prof. Dr. Joachim Fischer Dipl.-Inf. Ingmar Eveslage Dipl.-Inf. Frank Kühnlenz fischer eveslage 5.1

2 3. Grundlagen der Systemmodellierung 1. Systemsimulation was ist das? 2. Ein Blick zurück in die Anfänge 3. Modelle und Originale 4. Modellierungssprachen, Simulationsumgebungen g 5. Klassifikation dynamischer Systeme

3 Zustandsänderungen (Prinzip) Sei Z n-dimensionaler Zustandsvektor (Zustand z = Belegung von Z), der Zustandsgrößen eines (Teil-)Systems S zu diesem Zeitpunkt beschreibt der (neue) Zustand ergibt sich aus dem bisherigen (aktuellen) Zustand bei Berücksichtigung von Zuwachs und Reduktion (negativer Zuwachs) für die Zustandsgrößen im betrachteten Zeitraum des Zustandswechsels ausgehend von einem ausgezeichneten Anfangszustand z 0 Zeit t 0 t 1 t 2 t 3 z 0 z 1 z 2 z 3 Zustandsentwicklung in Abhängigkeit der Zeit S X Eingabe X Zuwachs im Zeitintervall (t k, t k+1 ] z 0 Z Änderung des Zustandsvektors Z im Zeitintervall [t k, t k+1 ] in Abhängigkeit von x(t k+1 ), z(t k ) g f f Zustandsübergangsfunktion, g - Ausgabefunktion Y Ausgabe Y äußere Reaktion des Systems auf die Eingabe im Zeitintervall (t k, t k+1 ] 5.3

4 Allgemeine (Teil-)Systemdefinition dient mehr der Klassifikation von Verhaltensmodellen X S Z f g Y S= (Z, z 0, X, Y, f, g, time) Z Menge der möglichen Zustände z 0 Z Anfangszustand X Menge der möglichen Eingaben Y Menge der möglichen Ausgaben time Zeitbasis als (T, <=, t 0 ) mit Menge möglicher Zeitpunkte T, einer Ordnungsrelation <= und einem minimalen Element t 0 f Z x X x T --> Z als Zustandsübergangsfunktion g Z x X x T --> Y als Ausgabefunktion 5.4

5 Arten von Zustandsänderungen zeitkontinuierliche Zustandsänderung stückweise stetige Funktionen zeitdiskrete Zustandsänderung Polygonzug Treppenfunktionen z (t)= f (z(t), x(t), t) mit z(t) () Z, x(t) X, t TT Differentialgleichungen t t z(t n+1 )= f (z(t n ), x(t n+1 ), t n+1 ) mit z(t n ) Z, x(t n+1 ) X, t n+1 T t numerische Lösungsverfahren Differenzengleichungen zelluläre Automaten Ereignissimulationen Prozesssimulation 5.5

6 Klassifizierung von Modellen und Simulationsverfahren Modell Simulator- Hardware Simulator- Software 5.6

7 Erdbebenfrühwarnsystem GFZ Potsdam HU Berlin Internet Ataköy Istanbul Kandilli Istanbul GIS reales bzw. gedachtes Phänomen Experiment- Management- System Sonderfall: Modell und Original- Teile liegen als Software vor Ausführungs- Modell im Speicher Simulator Ziel formales mathematisches Simulationsmodell informales /semiformales Systemmodell Zielcode: C++, OpenWRT, Boost Modell: SDL,UML,ASN.1 5.7

8 SOSEWIN Hardware, Software source - battery with solar cell - grid Ataköy It Istanbul bl Wrap-Board 32-bit Processor (AMD Geode) 233 MHz 128 MB RAM 1024 MB Flash 2 x 54 Mb/s Transceiver Linux OS (sensor drivers) Application Layer + Early Warning Service + Middleware Layer Communication Layer SOSEWIN Node... SOSEWIN Node 5.8

9 Traditional Software Development Informal Concepts, Ideas C++ Binary Application Layer Early Warning Service Sensor Data Retrieval Service Management Administration Services Middleware Layer Network Status Service Notification Service Software Deployment Service Time Synchronisation Service Monitoring Service Communication Layer Point-to-Point Communition Mulicast Communication External Communcation SOSEWIN Node SOSEWIN Node SOSEWIN Node SOSEWIN Node External Node test of a single node is not sufficient and of a complete system problematic 5.9

10 Our Model-Driven Approach unser nächstes Kapitel Informal Concepts, Ideas UML ASN.1 SDL Net topology, Simulation EarthquakeEventt C++ Binary* Simulation Lib C++ Binary Runtime Lib Application Layer Early Warning Service Sensor Data Retrieval Service Management Administration Services Middleware Layer Network Status Service Notification Service Software Deployment Service Time Synchronisation Service Monitoring Service Communication Layer Point-to-Point Communition Mulicast Communication External Communcation SOSEWIN Node SOSEWIN Node SOSEWIN Node SOSEWIN Node External Node simulation of a complete system simplifies testing 5.10

11 4. UML-Überblick 1. Historie von UML 2. Modellierungselemente von UML im Überblick 3. Diagrammarten 4. Diagrammrepräsentationen in UML 5. Struktur des UML-Standards

12 Die Vorläuferkonzepte von UML Formale Techniken OO- Konzepte, Modellierung Programm. Management Hoare CSP Hoare-logic Milner CCS Jones VDM Norwegian Computing Center SIMULA (Nygaard, Dahl) FORTRAN Algol C Pascal COBOL ER-model LOTOS (ISO) SDL-88 Microsoft Windows Xerox PARC SmallTalk (Kay) OOA(Yourdon) Apple MacIntosh Bell Labs C++ OODB SQL Corba Broy/Stølen Focus SDL-92 (ITU) SDL-2000 (ITU) ROOM MSC-92 (ITU) (Objectime) Objectory (Jacobsson) Booch OMT (Rumbaugh) UML 1.x (Rational/OMG) Sun JAVA ASM (Gurevich) MSC-2000 (ITU) UML 2.0 (OMG) EJB Web services 5.12

13 UML-Charakterisierung (Zusammenfassung) ist eine Notation/Sprache, keine Methode, Framework für UML-ähnliche Modellierungssprachen abstrahiert von architekturellen Vorgaben, Design- und Implementierungs-Styles, Technologien (Software, Hardware, Infrastrukturen,...), Entwicklungsprozessen standardisiert Begriffswelt (Modellierungskonzepte), Semantik (Bedeutung der Modellierungskonzepte), visuelle Darstellung (Notation der Modellierungskonzepte) führt Ideen verschiedener Techniken zusammen Booch, OMT, Jacobsson, ROOM, SDL, EDOC, MSC, Component Based Modeling,

14 Nutzen/Ziele des UML-Einsatzes Blueprint für die Softwareentwicklung hilft Nutzern, Entwicklern und Kunden bei der Kommunikation Anforderungen, Designvorgaben, Deployment-Constraints etc. mittels UML-Modellen festlegbar bietet Konzepte zur nachvollziehbaren Modellierung ( Tracebility ) vom initialen Geschäftsmodell bis zum einsetzbaren System zentrale Bibliothek für Wissen und Erfahrungen in Form von Modellen (Wiederverwendbarkeit) Verbesserung der Softwarequalität langfristige g Kostenreduzierung Flexibilität für schnelle technische und geschäftliche Änderungen aufgrund der Anwendbarkeit im gesamten Entwicklungsprozess große und komplexe Softwaresysteme erfordern sorgfältiges Design 5.14

15 Die UML Wenn die Sprache nicht stimmt, ist das was gesagt g wird, nicht das, was gemeint ist. (Konfuzius) UML = Unified Modeling Language ist zunächst Standardsprache (der OMG) zur Visualisierung, Spezifikation, Konstruktion und Dokumentation komplexer Softwaresysteme kombiniert Konzepte der Objektorientierten Modellierung Datenmodellierung (Entity-Relationship-Diagramme) Business-Modellierung (Work Flows) Komponentenmodellierung Verhaltensmodellierung (Erweiterte Zustandsautomaten)... UML-Modelle sind in erster Linie graphische Repräsentationen in Form von Diagrammen 5.15

16 4. UML-Überblick 1. Historie von UML 2. Modellierungselemente von UML im Überblick 3. Diagrammarten 4. Diagrammrepräsentationen in UML 5. Struktur des UML-Standards

17 UML-Modell Definition aus dem Standard A model captures a view of a physical system. It is an abstraction ti of the physical system, with a certain purpose. This purpose determines what is to be included in the model and what is irrelevant. Thus the model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the appropriate level of detail. Modelliere nicht so detailliert wie möglich, sondern so detailliert wie nötig! 5.17

18 UML-Grundkonzepte UML-Modellbausteine Dinge/Enititäten (im Sinne von Abstraktionen) Beziehungen zwischen den Entitäten Diagramme zur Anordnung von Entitäten Regeln zur Komposition der Modellbausteine (später) universelle Mechanismen, gültig für gesamte Sprache (später) 5.18

19 Vier Arten von Modellierungselementen/Entitäten nämlich zur Bildung von Strukturen Beschreibung von Verhalten Bildung von Gruppierungen von Entitäten Formulierung von Anmerkungen damit lassen sich UML-Modelle komplett beschreiben 5.19

20 1. Strukturelle Entitäten: Überblick Substantive ti in Modellen (formuliert in UML) bilden die Struktur tu eines es Modells (meist statisch, aber auch dynamisch) Zusammenfassung als Classifier Class Interface Association Signal Actor DataType Artifact Port UseCase Collaboration Activity Interaction State Machine Node Component z.t. mit weiteren Spezialisierungen dafür einige Beispiele (Syntax, Semantik) 5.20

21 Strukturelle Entitäten: Klasse, Interface Window orign size open() close() move() show() I_Window «interface» open() close() move() show() Klasse (Class) beschreibt Abstraktion einer Menge von Objekten mit gleichen Attributen, Operationen, Beziehungen, Semantik dargestellt als Rechteck mit Unterteilungen (Compartments) besitzt mindestens ein Interface Interface (Interface) beschreibt Sammlung von Operationen, die durch Dienste einer Klasse oder Komponente festgelegt sind beschreibt mit Signaturen potentielles äußeres Verhalten einer Klasse/Komponente komplett oder partiell keine Implementation!!! Bezug zur Klasse/Komponente muss explizit dargestellt werden I_Window Window Lolli-Pop-Notation I_Window User 5.21

22 Strukturelle Entitäten: Kollaboration, Anwendungsfall Verarbeitungskette..in Kombination mit Verhaltensbeschreibungen Kollaboration (Collaboration) beschreibt das Zusammenwirken von Objekten/Klassen in spezifischen Rollen als kooperatives Verhalten geht über Verhaltensdarstellung einer einzelnen Entität hinaus weist auch strukturelle Merkmale auf eine Entität kann an verschiedenen Kollaborationen teilhaben stellt eine Implementierung eines Verhaltensmusters dar Anwendungsfall..in Kombination mit Verhaltensbeschreibungen Anwendungsfall (Use Case) beschreibt sichtbare/messbare Handlungsfolgen ngsfolgen eines Systems für bestimmte externe Systemnutzer (Akteure) dient der strukturellen Beschreibung von Einsatzfällen/Anwendungen, die über Kollaborationen realisiert werden 5.22

23 Strukturelle Entitäten: aktive Klasse, Komponente, Artefakt, Knoten ~ ähnlich zum Konzept Klasse KeypadManager Aktive Klasse (active Class) beschreibt spezifische Klassen, deren Objekte selbst Auslöser von Aktionen sind Objekte können untereinander synchron oder asynchron Signale austauschen erlaubte Empfangssignale lassen sich spezifizieren geeignete Verhaltensbeschreibung: Zustandsautomat «signal» pushbutton() powerup() powerdown() provided AutoPilotControl Komponente (Component) modularer Teil eines Systems, dessen Implementierung AutoPilot sich hinter einer Menge von externen Interfaces verbirgt Systemkomponenten mit gleichen Interfaces sind GPS austauschbar (Problem besteht dennoch mit required Verhaltenskompatibilität!!!) Komponente ist die Zusammenfassung aller seiner beschreibenden und ausführbaren Artefakte 5.23

24 Strukturelle Entitäten: aktive Klasse, Komponente, Artefakt, Knoten ~ ähnlich zum Konzept Klasse Window.dll Artefakt (Artifact) physische Informationseinheit in Bit-Struktur: Modell, Quellcode, Script, ausführbarer Binärcode, Tabellen einer rel. Datenbank, Textdokument, , ) werden im Entwicklungsprozess angelegt oder aber zur Laufzeit des Systems erzeugt oder konsumiert Server Knoten (Node) physisches Element, das eine Rechnerressource darstellt (mit Prozessor, Speicher): dienen der Aufnahme und Ausführung von Komponenten 5.24

25 Klassenähnliche Entitäten Interface, aktive Klasse, Komponente, Artefakt, Knoten Rechteck mit charakteristischem Icon allgemeine Form der spezifischen Einschränkung einer UML-Entität: Stereotypet Grundsymbol:= Klasse (als Rechteck) Name der StereoType-Entität Name der klassenähnlichen Stereotype: «name» I_Window Manager EventHandler Code Station «interface» «active» «component» «artefact» «node» weitere Sterotype User «actor» Start «signal» Start «DataType» Prozess Thread weitere Gerät Anwendung Ausführungsumgebung Dokument Datei Bibliothek Seite Tabelle 5.25

26 2. Verhaltensorientierte Entitäten: Überblick Verben in Modellen (formuliert in UML), z.b. Member-Funktionen bestimmen das Verhalten eines Modells in Raum und Zeit Zusammenfassung als abstraktes Konzept Behaviour Opaque Behaviour Activity Interaction State Machine Hauptformen 5.26

27 Verhaltens-Entitäten: Interaktion, Zustandsautomat anzeigen anzeigen Interaktion (Interaction) beschreibt gerichtete Interaktion zwischen Objekten oder Rollen eines best. Kontextes zur Erbringung einer best. Funktionalität besteht aus Nachrichten, Aktionen und Konnektoren Pfeilart und Linienausführung i bewirken unterschiedliche h Semantiken x y alert error Zustandsautomat (State Machine, State-Chart) beschreibt Abfolge der Zustände, die ein Objekt oder eine Interaktion während seiner Existenz als Reaktion auf Ereignisse durchläuft, wobei Ereignisreaktion ebenfalls dargestellt wird gestatten die Beschreibung von Verhalten von Klassen oder Kollaborationen Zustandsautomaten bestehen aus weiteren Entitäten: Zustände (inkl. Start, Stop), Übergänge, Ereignisse 5.27

28 Verhaltens-Entität: Aktivität Aktivität (Activity) beschreibt gerichtete Abfolge von Schritten eines Verarbeitungsvorganges elementare Schritte einer Aktivität heißen Aktionen (Actions) Synchronisation bei der Interaktion liegt der Schwerpunkt auf einer Reihe von Objekten, die interagieren beim Zustandsautomaten beim Lebenslauf einer einzelnen Entität!!! bei der Interaktion liegt der Schwerpunkt bei den Übergängen von Schritt zu Schritt ohne zu beachten, welches Objekt den jeweiligen Schritt realisiert 5.28

29 3. Gruppierungs-Entitäten: Überblick Organisatorische Einheiten von UML-Modellen: Paket (Package), aber auch Paket-Variationen (Rahmenwerken, Modellen, Subsystemen, System) Aircrafts +Jet -TurboProps - Utilities Zusammenfassung von Struktur-, Verhaltens-, Anmerkungs- und anderen Gruppierungs-Entitäten ist möglich es gibt Regeln zur Abhängigkeit und zur Nutzung von Paketen Gruppierungs-Entitäten sind rein konzeptueller Natur existieren nicht zur Laufzeit 5.29

30 4. Anmerkungs-Entitäten: Überblick beschreibende Anteile eines UML-Modells Dies ist ein Kommentar { Dies ist eine Annotation } beliebiger Kommentar Informale oder formale Textbeschreibung von Modelleinschränkungen und zusätzen (Constraints) UML-Standard schließt OCL ein (Object Constraint Language) - können beliebigen Modellelementen zugeordnet werden -Achtung: Anmerkungen werden von Tools auch über einblendbare Textboxen realisiert 5.30

31 Zwischen-Fazit 1 Konfuzius: Wenn die Sprache nicht stimmt, ist das was gesagt wird, nicht das, was gemeint ist. 2 UML-Modellbausteine Modellbausteine (als Übersicht) Dinge/Enititäten (im Sinne von Abstraktionen) Beziehungen zwischen den Entitäten Diagramme zur Anordnung von Entitäten a b {or } Bildung von Strukturen Beschreibung von Verhalten Bildung von Gruppierungen von Entitäten Formulierung von Anmerkungen/ Einschränkungen 3 Dualität: Stereotype-Modellelemente Icons Code «artefact» Code 5.31

32 4. UML-Überblick 1. Historie von UML 2. Modellierungselemente von UML im Überblick 3. Repräsentation von UML 4. Diagrammarten 5. Diagrammrepräsentationen in UML 6. Struktur des UML-Standards 7. Beispiel: Klassendiagramm

33 Fünf Arten von Beziehungen in UML Abhängigkeit (Dependency) weitere Spezialfälle Assoziation (Association) weitere Spezialfälle Generalisierung (Generalisation) Realisierung (Realisation) repräsentieren die grundlegenden Beziehungsbausteine weitere Spezialfälle von Assoziationen und Abhängigkeiten Erweiterung (Extension) wird für den Profilmechanismus benötigt 5.33

34 Spezialfälle der Assoziation Aggregation: strukturelle Beziehung zwischen einem Ganzen und seinen Teilen Aggregation (Aggregation) keine Beziehung zwischen der Lebensdauer von Teil und Ganzem besitzt Richtung Teil-Entität kann gleichzeitig oder nacheinander Teil verschiedener Ganzer-Entitäten sein Assoziation mit Raute als Zusatz stärkste Beziehung= Komposition (Composition) besteht über die Lebensdauer (Teil und Ganzes haben i.d.r. gleiche Lebensdauer) besitzt Richtung Teil-Entität kann nur Teil von einem Ganzen sein Unterscheidung bei der Behandlung von statisch existenten und dynamisch erzeugten Teilen 5.34

35 Beziehungen: Generalisierung, Realisierung Generalisierung (Generalisation) Strukturelle Beziehung zwischen Classifier-Entitäten, für diese sind Spezialisierung bzw. Generalisierung erlaubt (z.b. Klasse, Signal, Zustandsautomat, ) die spezialisierte Entität übernimmt Struktur und Verhalten der generalisierenden Entität Generalisierung Richtung zum generalisierenden Classifier Realisierung (Realisation) Semantische Beziehung zwischen Classifier-Entitäten, Realisierung Richtung zur realisierenden Entität 5.35

36 Realisierung als spezielle semantische Abhängigkeit Beispiel von Realisierung und Abhängigkeit (Alternative zur Lolli-Pop-Notation) UML1.4 «use» X Objekte irgendeiner Klasse X benutzen Funktionalität, die über das Interface If zur Verfügung gestellt wird «use» X «Interface» If «Interface» If «realize» A Klasse A realisiert Interface If A dennoch breites Spektrum von Abhängigkeitsvariationen in UML

37 Typ Variation Schlüsselwort /Symbol Abstraktion (abstraction) Ableitung (derivation) «derive» Festlegung (manifestation) Verfeinerung (refinement) Trace-Abhängigkeit «manifest» «refine» «trace» Bindung (binding) - «bind» (parameter list, ) Deployment (depolyment) - «deploy» oder explizite Verschachtelung UseCase-Include - «include» UseCase-Erweiterung - «extend» (extension pont list, ) Paketimport privat (private) «access» öffentlich (public) «import» Paketverschmelzung - «merge» Erlaubnis (permission) - «permit» Informationsfluss - «flow» Ersetzung (substitution) - «substitute» Benutzung (usage) Benutzung (allgemein) «use» Ruf (call) Erzeugung (creation) Instanziierung Verantwortung (responsibility) Senden (send) «call» «create» «instantiate» «responsibility» «send» 5.37

38 4. UML-Überblick 1. Historie von UML 2. Modellierungselemente von UML im Überblick 3. Repräsentation von UML-Modellelementen 4. Diagrammarten 5. Diagrammrepräsentationen in UML 6. Struktur des UML-Standards 7. Beispiel: Klassendiagramm

39 Repräsentation von UML-Elementen erfolgt mittels grafischer Symbole (z.b. Rechteck für eine Klasse) aber ohne fest genormte Darstellung, sie müssen lediglich den Regeln des UML-Metamodells Metamodells (abstrakte Grammatik) folgen alternative Repräsentationen zur graphischen Notation: XML-konforme Strukturen Codedateien abstrakter Syntaxbaum des UML-Metamodells 5.39

40 Illustration: UML-Modell- Repräsentation werkzeugabhängiger Speicher abstrakte Syntax graphische Notation :Class name ="Person" operation :Operation name = "sprechen" Repository attribute :Property name = "name" Textformat Person name sprechen() gewisse Freiheiten in der Darstellung XML Metadata Interchange (XMI) <UML:Class name="person" > <feature xmi:type= "UML-Attribute" name= "name" visibility= "private"/> <feature xmi:type= "UML-Operation" name= "sprechen" visibility= "public"/> <UML:Class> Person { private: name public: sprechen() } 5.40

41 Wo stehen wir? UML-Modellbausteine Dinge/Enititäten (im Sinne von Abstraktionen) Beziehungen zwischen den Entitäten Diagramme zur Anordnung von Entitäten 5.41

42 2. UML-Überblick 1. Historie von UML 2. Modellierungselemente von UML im Überblick 3. UML-Diagrammarten 4. Diagrammrepräsentationen in UML 5. Struktur des UML-Standards 6. Beispiel: UML-Klassendiagramm

43 Diagrammsprachen der UML 2.0 Diagramme Strukturdiagramme Klassendiagramm Paketdiagramm Objektdiagramm Diagramm:= graph. Darstellung von verbundenen Entitäten (meist als Graph) Verhaltensdiagramme Nutzfalldiagramm (Use-Case) Aktivitätsdiagramm Zustandsdiagramm Interaktionsdiagramme Sequenzdiagramm Ziel: Modellensemble eines Systems aus verschiedenen Blickwinkeln in separaten Diagrammen typisch: mehrfacher Bezug auf bestimmte Modellentitäten 5.43

44 Diagrammarten zur Anordnung von Entitäten: Struktur und Verhalten 5.44

46 Diagramm, Diagrammtyp bestimmte Modellelemente können geeignet in Kombination angewendet werden (andere schließen sich aus) Elemente vordefinierter Diagrammtypen: Klassendiagramm: Klassen, Attribute, Operationen, Assoziationen Zustandsdiagramm: Zustände, Transitionen, Ereignisse aber: es nicht exakt festgelegt, welche Elemente zulässig sind Definition nutzereigener Diagrammtypen ist möglich Anwendungen: i. allg. mehrere Diagramme eines Diagrammtyps 5.46

47 Auslagerung von Diagrammteilen sd a x y x y ref a Auslagerung und mögliche Mehrfacheinbindung von Rahmen 5.47

48 Auslagerung von Diagrammteilen (2) pkg P A P C B Paketinhalt: Klassendiagramm Referenzsymbol definierendes Diagramm Deklaration/ Referenz eines Modellelementes Definition eines Modellelementes 5.48

49 Sichten ein und dasselbe Modellelement kann unterschiedlich detailliert für unterschiedliche Sichten dargestellt werden KlasseA op1() Sicht der Analysephase Repository KlasseA KlasseA +attr1 : int= y -attr2 : String [0..*] +op1 : int -op2 (v: KlasseC) Sicht der Codegenerierung Klasse A ist in einem Namensraum nur einmal im Repository definiert 5.49

50 Systemarchitekturmodell eines Systems unter Verwendung von UML Systemaufbau Konfigurationsverwaltung Entwurfssicht Implementationssicht Klassen-, Objektdiagramme Anwendungsfalldiagramme Aktivitäts-, Sequenz-, Kooperations-, Zustandsdiagramme Nutzersicht Komponentendiagramme Verteilungs-/ Konfigurations- i diagramme Leistung Skalierbarkeit Durchsatz Verhaltenssicht Umgebungssicht Systemtopologie Verteilung Auslieferung Installation 5.50

51 Austausch von Diagrammen schreiben Repository Modellierungstool B API uraltes Problem der Informatik: Dokumentenaustausch lesen Versionsmanagement Modellierungstool A XMI stored UMLmodels Modell von UML 1.0 trotz XMI-Standard nicht erreicht (obwohl nur Austausch semantischer Infos) Ursache: mehrere Standards: UML, MOF, XMI (Versionskonflikte) nicht behobene Fehler im Standard unpräzise Spezifikation UML 2.0 fordert sogar Diagramm-Austausch (XMI-Datei mit Teilbäumen von Layout-Repräsentationen) 5.51

53 Struktur des Standards grundlegende g Sprachkonstrukte in abstrakter Syntax (Klasse, Assoziation, ) Modellierungskonzepte Sprachdefinitions -konzepte Transformations- konzepte Infrastr ructure SuperstructureLibrary Superstructure MOF OCL XMI Classes Composite Structures Common Behaviours State Components Activities Interactions UseCases Machines Deployments Actions 5.53

54 Die UML-Spracharchitektur Infrastructure- Klasse M3 «instanceof» Class «instanceof» «instanceof» «instanceof» Meta- Meta- modell Urmodell (MOF) M3- Klassen M2 Attribute «instanceof» Class «instanceof» type Operation «instanceof» InstanceSpecification «instanceof» UML- Metamodell M2- Klassen M1 Modell Bordkarte +flugnummer:string «snapshot» b: Bordkarte +flugnummer= LH801 M1- Klassen +gültig():boolean «instanceof» «instanceof» M0 System (in C++) VMT- Bordkarte Fkt-Eintrittspunkt Fkt.Code b flugnummer [Adr] Zeiger LH801 M0- Klassen 5.54

55 UML-Modifikationen (Aufbau eigener Sprachen) im Prinzip kann unter Verwendung von UML ein eigenes Metamodell (für eine DSL) aufgebaut werden Wege, UML zu erweitern a) direkte Erweiterung des UML-Metamodells: Einführung weiterer Metaklassen, die von UML-Metaklassen erben b) Profil-Mechanismus Achtung: beide Ansätze erlauben es aber nicht, Teile der UML auszublenden das komplette UML-Metamodell M steht im Hintergrund, das nur mit OCL in der Instanziierung eingeschränkt werden kann 5.55

56 Direkte Erweiterung des UML-Metamodells Resultat: ein erweitertes Metamodell eine erweiterte UML-Sprache im UML -Modell lässt sich nun MyMetaClass benutzen UML::Class If «instanceof» MOF::Classifier If generalisize MyMetaClass «instanceof» «instanceof» A «MyMetaClass» Beispiel «Interface» Beispiel Achtung: Ansatz funktioniert für jede MOF-basierte Sprache (z.b. UML, aber ohne Tool-Unterstützung (komplett neue Sprache!!!) 5.56

57 Profile und Stereotype Definition einer Stereotype als Extension (nur für UML erlaubt) im Kontext eines Profils «metaclass» UML::Class «stereotype» CM::NewConcept transactional: boolean «CM::NewConcept» ProfilName::Beispiel {transactional= true} Einschränkung in der Erweiterung: Reduktion auf Attribute (Tagged Values) Vorteil: Kann Erweiterung mit UML-Tool vornehmen und über spezielle Pakete benutzen Problem: spezielle Symbole 5.57

59 partner 1..* 1..* ProgrammPartner kundenanzahl: Integer {ordered} BonusProgramm aufnehmen(k: Kunde) 1..* ServiceStufe aktuellergrad 0..* 0..* programm Mitgliedschaft 0..1 BonusKonto karte 0..* Kunde name: String titel: String geburtstag: Datum geschlecht: Geschlecht alter(): Integer besitzer 0..* karten KundenKarte punkte:integer gültig: Boolean name: String angebot gültigab: Datum 0..* plus(i:integer) minus(i:integer) gültigbis: Datum Service 0..* * istleer(): Boolean farbe: enum {silber, gold} bedingung: Boolean verfügbar druckname: String pluspunkte: Integer transaktionen 0..* karte minuspunkte: Integer beschreibung: String Transaktion punkte: Integer 0..* datum: Datum 0..* transaktionen transaktionen programm(): Datum BonusProrgramm now programm(): liegtvor(d: Datum):Boolean BonusProrgramm liegtnach(d: Datum):Boolean Minus Plus =(d: Datum): Boolean 5.59

60 partner 1..* 1..* ProgrammPartner kundenanzahl: Integer angebot 0..* Service {ordered} bedingung: Boolean pluspunkte: Integer minuspunkte: Integer beschreibung: String BonusProgramm aufnehmen(k: Kunde) 1..* ServiceStufe name: String * 0..* verfügbar Kunde::alter(): Integer post: result>= 18 transaktionen context KundenKarte inv: gültigab.liegtvor(gültigbis) Minus 0..* aktuellergrad 0..* programm Mitgliedschaft 0..1 BonusKonto punkte:integer plus(i:integer) minus(i:integer) istleer(): Boolean transaktionen 0..* punkte: Integer 0..* datum: Datum Transaktion Datum karte 0..* 0..* programm(): transaktionen liegtvor(d: Datum):Boolean BonusProrgramm liegtnach(d: Datum):Boolean =(d: Datum): Boolean Kunde name: String titel: String geburtstag: Datum geschlecht: Geschlecht alter(): Integer besitzer 0..* karten KundenKarte gültig: Boolean gültigab: Datum gültigbis: Datum farbe: enum {silber, gold} druckname: String karte Invariante für Attribut 5.60

61 partner 1..* 1..* ProgrammPartner kundenanzahl: Integer {ordered} BonusProgramm aufnehmen(k: Kunde) 1..* ServiceStufe aktuellergrad 0..* 0..* programm Mitgliedschaft 0..1 BonusKonto karte 0..* Kunde name: String titel: String geburtstag: Datum geschlecht: Geschlecht alter(): Integer besitzer 0..* karten KundenKarte punkte:integer gültig: Boolean name: String angebot gültigab: Datum 0..* plus(i:integer) minus(i:integer) gültigbis: Datum Service 0..* * istleer(): Boolean farbe: enum {silber, gold} bedingung: Boolean verfügbar druckname: String pluspunkte: Integer transaktionen 0..* karte minuspunkte: Integer beschreibung: String Transaktion punkte: Integer 0..* datum: Datum 0..* context Mitgliedschaft inv: karte.besitzer transaktionen = kunde transaktionen programm(): Datum Invariante für Assoziationsklasse BonusProrgramm now programm(): context Kundenkarte liegtvor(d: Datum):Boolean BonusProrgramm inv: liegtnach(d: Datum):Boolean druckname = besitzer.titel.concat Minus titel (besitzer.name) Plus =(d: Datum): Boolean 5.61

62 partner 1..* 1..* BonusProgramm aufnehmen(k: Kunde) context ProgrammPartner Bonusprogramm inv: servicestufe->first().name= silber kundenanzahl: Integer {ordered} 1..* ServiceStufe aktuellergrad 0..* 0..* programm Mitgliedschaft 0..1 BonusKonto karte 0..* Kunde name: String titel: String geburtstag: Datum geschlecht: Geschlecht alter(): Integer besitzer 0..* karten KundenKarte punkte:integer gültig: Boolean name: String angebot gültigab: Datum 0..* plus(i:integer) minus(i:integer) gültigbis: Datum Service 0..* * istleer(): Boolean farbe: enum {silber, gold} bedingung: Boolean verfügbar druckname: String pluspunkte: Integer transaktionen 0..* karte minuspunkte: Integer beschreibung: String Transaktion punkte: Integer 0..* datum: Datum 0..* transaktionen transaktionen programm(): context Datum BonusProgramm inv: BonusProrgramm now servicestufe->size() = 2 programm(): liegtvor(d: Datum):Boolean Anzahl verschiedener Service-Grade wird BonusProrgramm liegtnach(d: auf Datum):Boolean 2 begrenzt Minus Plus =(d: Datum): Boolean geordnete Menge, von der die Kardinalität bestimmt wird 5.62