UML ist scheisse!



  • FireFlow schrieb:

    DSD-Steve schrieb:

    Was ist UML? 😕

    Die besseren Fragen wären:
    Was ist Google?
    Was ist Wikipedia?
    Warum schält Mama meinen Surfblocker für externe Seiten nicht frei?

    Gruß

    Warum sind das bessere Fragen?



  • DSD-Steve schrieb:

    Warum sind das bessere Fragen?

    Weil du damit mal lernen könntest 99% deiner Fragen selbst zu beantworten.



  • FireFlow schrieb:

    DSD-Steve schrieb:

    Warum sind das bessere Fragen?

    Weil du damit mal lernen könntest 99% deiner Fragen selbst zu beantworten.

    Wieso?



  • FireFlow schrieb:

    DSD-Steve schrieb:

    Warum sind das bessere Fragen?

    Weil du damit mal lernen könntest 99% deiner Fragen selbst zu beantworten.

    Was für Fragen?



  • DSD-Steve schrieb:

    FireFlow schrieb:

    DSD-Steve schrieb:

    Warum sind das bessere Fragen?

    Weil du damit mal lernen könntest 99% deiner Fragen selbst zu beantworten.

    Was für Fragen?

    z.B. die hier:
    http://www.c-plusplus.net/forum/viewtopic-var-t-is-129170.html



  • ich hoffe wirklich für dsd-steve, dass er nur vortäuscht saublöd zu sein. allerdings macht er das erschreckend gut



  • fa45t45454 schrieb:

    ich hoffe wirklich für dsd-steve, dass er nur vortäuscht saublöd zu sein. allerdings macht er das erschreckend gut

    Find ich nicht. Das ist so offensichtlich vorgetäuscht, dass es schon wieder blöde ist. Also hast du quasi doch recht. Obwohl....



  • Proggger schrieb:

    meine meinung...

    👍



  • Was bedeutet nun UML?



  • DSD-Steve schrieb:

    Was bedeutet nun UML?

    http://en.wikipedia.org/wiki/Unified_Modeling_Language 😃



  • Gregor@Home schrieb:

    DSD-Steve schrieb:

    Was bedeutet nun UML?

    http://en.wikipedia.org/wiki/Unified_Modeling_Language 😃

    Es funzt bei ir nur die .de Version von Wikipedia.de 😞
    Kannste mal Inhalt hier reinposten?



  • DSD-Steve schrieb:

    Gregor@Home schrieb:

    DSD-Steve schrieb:

    Was bedeutet nun UML?

    http://en.wikipedia.org/wiki/Unified_Modeling_Language 😃

    Es funzt bei ir nur die .de Version von Wikipedia.de 😞
    Kannste mal Inhalt hier reinposten?

    ok

    Unified Modeling Language
    From Wikipedia, the free encyclopedia.

    The Unified Modeling Language (UML) is a non-proprietary, object modeling and specification language used in software engineering. UML includes a standardized graphical notation that may be used to create an abstract model of a system: the UML model.

    While UML was designed to specify, visualize, construct, and document software-intensive systems, UML is not restricted to modeling software. UML has its strengths at higher, more architectural levels and has been used for modeling hardware (engineering systems) and is commonly used for business process modeling, systems engineering modeling, and representing organizational structure.

    Contents [hide]
    1 History
    2 Methods
    3 Modeling
    4 Diagrams
    5 Concepts
    6 Criticism
    7 Extensions
    8 See also
    9 References
    10 External links

    [edit]

    History

    When Rational Software Corporation hired James Rumbaugh from General Electric in 1994 they became the source of the two most popular object-oriented modeling approaches of the day: Rumbaugh's OMT (which was better in analysis) and Grady Booch's Booch method (which was better in design). Together Grady and Jim attempted to reconcile their two approaches and started work on a Unified Method.

    In June 1995 the Object Management Group (OMG) put out a call for a common modeling approach to reconcile the greater than 50 named approaches in the market. This effort was pushed significantly by Ivar Jacobson of Objectory and Richard Soley of OMG.

    In 1995, Rational acquired Objectory and with it got the help of Ivar Jacobson, the developer of the OOSE method. Together, Rumbaugh, Booch, and Jacobson, often called the three amigos, redirected their efforts from developing a unified method to developing a unified notation to answer the call from OMG.

    With this leadership of three leading OO methodologists in Rational, a team of experts representing many companies were represented to submit their Unified Modeling Language (UML) proposal to OMG. The team, called the UML Partners, included Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments, and Unisys. In the complex technical/political negotiations that characterize OMG standard development, the several competitor proposals were either dropped or merged with the UML proposal, adding IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies, and Softeam to the UML Partners. By the fall of 1997, after much public review and comment, the UML standard, (by now called UML 1.1) was approved by OMG.

    As a notation, the influence of the OMT style is most apparent (e.g., in boxes for classes and objects). Though the Booch cloud notation was dropped, the Booch capability to specify lower-level design detail was embraced. The concept and notation of use cases (from Objectory) was integrated into the notation. Concepts from many other software-development methods (e.g., Class-Relation (circa 1994 from the French company Softeam), CRC Cards (circa 1989 from Kent Beck and Ward Cunningham), and OORam) were subsumed under the idea of supporting all these methods with a single modeling language. UML is useful in a variety of engineering problems, from single process, single user applications to concurrent, distributed systems, making UML rich but large.

    UML has since been revised and grown, with several releases (the major being UML 1.3 and 1.5), fixing some dead ends and adding new notational capabilities. Many industry firms have now contributed to the standard. The current standard is UML 2.0., a major rewrite. The latest UML version prior to 2.0 was 1.5; this 1.5 version will continue to be the official current version until all four components of UML 2 are completed and ratified.

    The first part of UML 2.0, the Superstructure which describes the new diagrams and modeling elements available, was adopted by the OMG in October 2004. Other parts of UML 2, notably the infrastructure, the object constraint language (OCL) and the diagram interchange were yet to be completed and ratified as of November 2005.

    The final UML 2.0 specification has been declared available and has been added to OMG's formal specification library. The other parts of the UML specification, the UML 2.0 infrastructure, the UML 2.0 Diagram Interchange, and UML 2.0 OCL specifications have been adopted but are not yet considered available.

    As change is inevitable, a UML 2.1 revision is underway.

    Most of the commercially successful modeling tools now support most of UML 2.0, leaving only the rarely used features left to implement. Of course, it will take some time for the tools that are in the hands of the developers to reach this level of compliance.
    [edit]

    Methods

    UML is not a method by itself, however it was designed to be compatible with the leading object-oriented software development methods of its time (e.g., OMT, Booch, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notation (e.g., OMT) and new methods have been created based on UML. Most known is Rational Unified Process (RUP) created by the Rational Software Corporation. There are many other UML-based methods like Abstraction Method, Dynamic Systems Development Method, and others, designed to provide more specific solutions, or achieve different objectives.
    [edit]

    Modeling

    It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The model also contains a "semantic backplane" — textual documentation such as written use cases that drive the model elements and diagrams.

    There are three prominent parts of a system's model:

    Functional Model
    Showcases the functionality of the system from the user's Point of View.
    Includes Use Case Diagrams.

    Object Model
    Showcases the structure and substructure of the system using objects, attributes, operations, and associations.
    Includes Class Diagrams.

    Dynamic Model
    Showcases the internal behavior of the system.
    Includes Sequence Diagrams, Activity Diagrams and State Machine Diagrams.

    Models can be exchanged among UML tools by using the XML-based XMI format.
    [edit]

    Diagrams

    Hierarchy of UML 2.0 Diagrams, shown as a class diagram

    In UML 2.0 there are 13 types of diagrams. To understand them, it is sometimes useful to categorize them hierarchically, as shown in the hierarchy chart on the right.

    Structure Diagrams emphasize what things must be in the system being modeled:
    Class diagram
    Component diagram
    Object diagram
    Composite structure diagram
    Deployment diagram
    Package diagram

    Behavior Diagrams emphasize what must happen in the system being modeled:
    Activity diagram
    Use Case diagram
    State Machine diagram

    Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:
    Sequence diagram
    Collaboration (UML 1.x)/Communication diagram (UML 2.0)
    Interaction overview diagram (UML 2.0)
    Timing diagram (UML 2.0)

    The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.

    UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams. This flexibility has been partially restricted in UML 2.0.

    Diagrams can be exchanged among UML tools by using the Diagram Interchange (DI, XMI[DI]) standard.

    In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is always allowed in a UML diagram.
    [edit]

    Concepts

    UML uses the following concepts:

    For Structure
    Actor, Attribute, Class, Component, Interface, Object, Package.

    For Behavior
    Activity, Event, Message, Method, Operation, State, Use Case.

    For Relationships
    Aggregation, Association, Composition, Depends, Generalization (or Inheritance).

    Other Concepts
    Stereotype. It qualifies the symbol it is attached to.
    Multiplicity notation which corresponds to Database modeling cardinality, e.g., 1, 0..1, 1..*
    Role
    [edit]

    Criticism

    Although UML is a widely recognized and used standard, it is criticized for imprecise semantics leading to subjective interpretation and difficulties in the formal test phases of development. In one remedy to this form of misinterpretation, authors provide some form of explanation of their models in the form of narration or copious diagram notes.

    Another problem is that UML doesn't apply well to distributed systems. In such systems, factors such as serialization, message passing and persistence are of great importance. UML lacks the ability to specify such things. For example, it is not possible to specify using UML that an object "lives" in a server process and that it is shared among various instances of a running process. The constraints of distributed system development are not an inherent part of UML, much as the plot of a great novel is not part of the rules of grammar.

    UML is often considered to be too bloated, too fine-grained in many aspects. Details best captured in source code may be difficult to capture using UML notation, the problem is that people try to do so. The 80-20 rule can be safely applied to UML: a small part of UML is adequate for most of the modeling needs, while many aspects of UML cater to some specialized or esoteric usages. However, the scope of a technique such as model-driven architecture requires an expressive, general notation such as UML 2.0.

    A third problem leading to criticism and dissatisfaction is the large-scale adoption of UML by people without the required skills, often when management forces UML upon them. An ACM article, Self-diagnosis and early treatment are crucial in the fight against UML Fever is an amusing but all-too-true account of this and related issues.

    Another perspective holds that it is a working system that is important, not beautiful models. As Jack Reeves succinctly put it, "The code is the design." [1][2] Pursuing this notion leads to the need for better ways of writing software; UML has value in approaches that compile the models to generate source or executable code.
    [edit]

    Extensions

    When it is necessary to introduce new notations or terminologies, UML provides user-defined extensions through the use of stereotypes, tagged values and constraints. Currently there are two extensions defined, namely Business and Objectory Process extensions.

    Magnus Penker and Hans-Erik Eriksson (2000) describe Business Extensions in Business Modeling with UML.

    Ovidiu S. Noran at the Griffith University compares UML and IDEF in "Business Modelling: UML vs. IDEF". [3]

    Peter Coad et al. (1999) have also suggested a small set of UML colors .
    [edit]

    See also
    UML tool
    List of UML tools
    Object Constraint Language (OCL)
    Domain-specific modelling
    UML colors
    [edit]

    References
    Chonoles, Michael Jesse, James A. Schardt (2003). UML 2 for Dummies, Wiley Publishing. ISBN 0-7645-2614-6.
    Coad, Peter, Eric Lefebvre; Jeff De Luca (1999). Java Modeling In Color With UML: Enterprise Components and Process, Prentice Hall. ISBN 0-130-11510-X.
    Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed., Addison-Wesley. ISBN 0321193687.
    Martin, Robert Cecil (2003). UML for Java Programmers, Prentice Hall. ISBN 0-13-142848-9.
    Penker, Magnus, Hans-Erik Eriksson (2000). Business Modeling with UML, John Wiley & Sons. ISBN 0-471-29551-5.
    Ovidiu S. Noran. Business Modelling: UML vs. IDEF. (PDF) URL accessed on 2005-11-04.
    Tom Gooch. History of UML. URL accessed on 2005-11-08.
    [edit]

    External links
    UML Resource Page of the Object Management Group – contains among other information the UML specification
    UML Certification Exam
    UML Forum A virtual community and knowledge portal for modelers interested in UML and its applications.
    UML Certification Resource Center
    Practical UML™: A Hands-On Introduction for Developers – a quick introduction to the UML (by Randy Miller)
    UML Reference Card
    Article Database modeling in UML from Methods & Tools
    Article Death by UML Fever on the occasional misuse of UML, from ACM Queue
    Article "Open source UML editors lag proprietary leader" by Irfan Habib
    Article "UML 3.0 and the Future of Modeling" by Cris Kobryn
    Article A practical series of Analysis Patterns Role problems are very frequent, and there exists at least half-a-dozen ways to solve them. By Francis Mosse

    This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.

    Categories: FOLDOC sourced articles | Unified Modeling Language
    ArticleDiscussionEdit this pageHistory

    🕶 :p



  • Jetzt unterstütz die Pappnase doch nicht auch noch mit seinem Getrolle. Ist ignorieren eigentlich so schwer?



  • Die Unified Modeling Language (UML) ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die Modellierung von Software und anderen Systemen. Im Sinne einer Sprache definiert die UML dabei Bezeichner für die meisten Begriffe, die für die Modellierung wichtig sind, und legt mögliche Beziehungen zwischen diesen Begriffen fest. Die UML definiert weiter grafische Notationen für diese Begriffe und für Modelle von statischen Strukturen und von dynamischen Abläufen, die man mit diesen Begriffen formulieren kann.

    Die UML ist heute eine der dominierenden Sprachen für die Modellierung von Softwaresystemen. Die meisten Leute kommen zum ersten Mal mit der UML in Kontakt, wenn sie in der einen oder anderen Rolle an einem Softwareprojekt beteiligt sind. Der erste Kontakt besteht häufig darin, dass gewisse Diagramme der UML zu erstellen, zu verstehen oder zu beurteilen sind:

    * Projektauftraggeber und Fachvertreter prüfen und bestätigen zum Beispiel Anforderungen an ein System, die Wirtschaftsanalytiker in Anwendungsfalldiagrammen der UML festgehalten haben.
    * Softwarentwickler realisieren Arbeitsabläufe, die Wirtschaftsanalytiker in Zusammenarbeit mit Fachvertretern in Aktivitätsdiagramm beschrieben haben.
    * Systemingenieure installieren und betreiben Softwaresysteme basierend auf einem Installationsplan, der als Verteilungsdiagramm vorliegt.

    Die graphische Notation ist jedoch nur ein Aspekt, der durch die UML geregelt wird. Die UML legt in erster Linie fest, mit welchen Begriffen und welchen Beziehungen zwischen diesen Begriffen sogenannte Modelle spezifiziert werden - Diagramme der UML zeigen nur eine graphische Sicht auf Ausschnitte eines Modells. Die UML hält auch fest, in welchem Format Modelle und Diagramme zwischen Werkzeugen ausgetauscht werden können.
    Inhaltsverzeichnis
    [Verbergen]

    * 1 Entstehungsgeschichte
    o 1.1 Von den Anfängen zur Unified Modeling Language 1.x
    o 1.2 Entstehungsgeschichte der Unified Modeling Language 2.0
    * 2 Strukturierung
    o 2.1 Teilspezifikationen
    o 2.2 Metamodellierung
    o 2.3 Spracheinheiten
    o 2.4 Einteilung der Spracheinheiten in Schichten
    * 3 Spracheinheiten
    o 3.1 Spracheinheit Aktionen
    o 3.2 Spracheinheit Aktivitäten
    o 3.3 Spracheinheit Allgemeines Verhalten
    o 3.4 Spracheinheit Anwendungsfälle
    o 3.5 Spracheinheit Informationsflüsse
    o 3.6 Spracheinheit Interaktionen
    o 3.7 Spracheinheit Klassen
    o 3.8 Spracheinheit Komponenten
    o 3.9 Spracheinheit Kompositionsstrukturen
    o 3.10 Spracheinheit Modelle
    o 3.11 Spracheinheit Profile
    o 3.12 Spracheinheit Schablonen
    o 3.13 Spracheinheit Verteilungen
    o 3.14 Spracheinheit Zustandsautomaten
    * 4 Darstellung in Diagrammen
    o 4.1 Erstellen von Diagrammen
    * 5 Austausch von Modellen und Diagrammen
    * 6 Literatur
    * 7 Weblinks
    o 7.1 Spezifikationen zur UML2
    o 7.2 Weitere
    * 8 Siehe auch

    [Bearbeiten]

    Entstehungsgeschichte

    Die erste Version der UML entstand in den 90er-Jahren des 20. Jahrhunderts als Reaktion auf zahlreiche Vorschläge für Modellierungssprachen und -methoden, die die zu dieser Zeit aufkommende objekt-orientierte Softwareentwicklung unterstützen sollten. Eine erste Folge von Sprachversionen, auch bekannt unter dem Namen UML 1.x, wurde 2005 durch eine grundlegend überarbeitete Version, oft als UML2 bezeichnet, abgelöst.
    [Bearbeiten]

    Von den Anfängen zur Unified Modeling Language 1.x
    Historie der objektorientierten Methoden und Notationen
    vergrößern
    Historie der objektorientierten Methoden und Notationen

    Die Väter der UML, insbesondere Grady Booch, Ivar Jacobson und James Rumbaugh, auch "die drei Amigos" genannt, waren in den 90er-Jahren des 20. Jahrhunderts bekannte Propagandisten der objekt-orientierten Programmierung, die alle bereits ihre mehr oder weniger ähnlichen eigenen Modellierungssprachen entwickelt hatten. Als sie zusammen beim Unternehmen Rational Software beschäftigt waren, entstand der Ansatz, die verschiedenen Notationssysteme strukturiert zusammenzuführen.

    Als Resultat dieser Bemühungen entstand die UML. Die Standardisierung, Pflege und und Weiterentwicklung der Sprache wurde an die Object Management Group (OMG) übergeben, die die Sprache am 19. November 1997 als Standard akzeptiert hat.

    [Bearbeiten]

    Entstehungsgeschichte der Unified Modeling Language 2.0

    Im August 1999 stieß die Object Management Group (OMG) die Entwicklung der UML2 an, indem sie einen entsprechenden Request for Information (RFI) publizierte.

    Ein Jahr später, im September 2000, bat die OMG ihre Mitglieder und weitere interessierte Kreise um Vorschläge für die UML2. Gemäß der neu für die UML2 definierten Architektur hat die OMG drei Requests For Proposals (RFP) publiziert, einen UML 2.0 Infrastructure RFP, einen UML 2.0 Superstructure RFP und einen UML 2.0 OCL RFP. Wer Vorschläge einreichen wollte, hatte dazu ungefähr ein weiteres Jahr Zeit.

    In einer ersten Runde haben verschiedene Gruppen und Einzelpersonen Entwürfe eingereicht, darunter Gruppen mit den Namen 3C, U2 und U2P. Mitte 2002 lagen von diesen Konsortien mehrmals überarbeitete und konsolidierte Antworten auf einzelne Request for proposals vor. Erst im Oktober 2002 konnten dann am Treffen der zuständigen Arbeitsgruppe in Helsinki alle Vorschläge für die UML 2.0 Infrastructure und die UML 2.0 Superstructure präsentiert werden. Einen Termin für eine weitere überarbeitete Version der Vorschläge legte die Arbeitsgruppe auf Anfang Januar 2003 fest. Die Hauptschwierigkeit bestand nun darin, die unterschiedlichen Entwürfe zu einer Spezifikation zu verschmelzen. Einerseits wurde zum Teil Kritik laut, dass sich die unterschiedlichen Philosophien in den eingereichten Vorschlägen nur schwerlich würden bereinigen lassen, andererseits reichte im Januar 2003 ein neues Konsortium unter dem Namen 4M einen Vorschlag (UML4MDA) ein, der die Differenzen zwischen den bisherigen Spezifikationen zu überbrücken versuchte.

    Im März 2003 empfahl die zuständige Arbeitsgruppe die Vorschläge des Konsortiums U2 für die UML 2.0 Infrastructure und für die UML 2.0 OCL zur Freigabe, im Mai dann auch die UML 2.0 Superstructure des gleichen Konsortiums, so dass ab Juni 2003 drei Finalization Task Forces der OMG die Arbeit aufnehmen konnten, um die Teilspezifikationen abzuschließen. Die Task Forces konnten ihre Arbeit jedoch nicht wie geplant bis im April 2004 abschließend und gründeten deshalb gleich anschließend eine zweite Finalization Task Force, die die verbleibenden Probleme bis im September 2004 lösen sollte.

    Im September 2004 konnten schließlich alle Finalization Task Forces ihre Arbeit beenden. Für die UML 2.0 OCL und die UML 2.0 Infrastructure lagen damit endgültig abgenommene Dokumente (Final Adopted Specification) vor. Nur bei der UML 2.0 Superstructure schien sich dieser letzte Schritt noch etwas zu verzögern: im März 2005 bot der OMG-Webauftritt weiterhin nur ein temporäres Dokument mit der informellen Bezeichnung UML 2.0 Superstructure FTF convenience document zum Herunterladen an.

    Anfang 2005 war deshalb noch unklar, ob nun die UML2 als Ganzes oder nur Teile davon freigegeben waren.
    [Bearbeiten]

    Strukturierung

    Der Umfang der UML ist während der Entwicklung von der UML 1.0 bis zur UML2 laufend gewachsen. Die aktuelle Version UML2 ist insbesondere weitaus umfangreicher als die Vorgängerversionen UML 1.x. Sowohl für die Entwicklung der UML2 als auch für die Vermittlung, die Anwendung und nicht zuletzt für die Lesbarkeit der UML2-Spezifikation ist eine Strukturierung der Spezifikation sehr wichtig. Was deshalb in den ersten Versionen der UML in einem Dokument spezifiziert werden konnte, musste für die UML2 in Teilspezifikationen aufgeteilt werden. In den folgenden Abschnitten wird der Aufbau der UML2 beschrieben.
    [Bearbeiten]

    Teilspezifikationen

    Die UML2 ist in drei Teilspezifikationen aufgeteilt. Die UML 2.0 Infrastructure Specification legt das Fundament für die UML2, indem sie die am häufigsten verwendeten Elemente der UML2 und die Modellelemente beschreibt, die die restlichen Modellelemente spezialisieren. In diesem Dokument werden Konzepte wie die Klasse, die Assoziation oder die Multiplizität eines Attributs spezifiziert. Die UML 2.0 Superstructure Specification baut auf dem Fundament der UML 2.0 Infrastructure Specification auf und definiert die Modellelemente der UML2, die sich für bestimmte Einsatzzwecke eignen. Typische Konzepte, die in diesem Dokument spezifiziert werden, sind der Anwendungsfall, die Aktivität oder der Zustandsautomat. Schließlich spezifiziert das Dokument mit dem Titel UML 2.0 Object Constraint Language die Object Constraint Language 2.0 (OCL2).

    Ein weiterer, vierter Teil beschäftigt sich nicht mit dem semantischen Modell der UML sondern spezifiziert das Layout der Diagramme. Dieses Dokument trägt den Titel UML 2.0 Diagram Interchange und ist eine Neuerung in der UML 2.0: die UML 1.x kannte kein standardisiertes Format, mit dem das Layout von Diagrammen zwischen unterschiedlichen Werkzeugen ausgetauscht werden konnte. Die semantischen Information in einem UML-Modell konnte ein Werkzeug auch bisher an ein anderes Werkzeug übergeben, das Aussehen der Diagramme, das heißt die Positionen und Größe einzelner Diagrammelemente, ging dabei aber verloren. Diagram Interchange (DI) soll dieses Manko beseitigen.
    [Bearbeiten]

    Metamodellierung

    Benutzer können mit Hilfe der UML2 Modelle beschreiben. Die Elemente, aus denen die UML2 besteht und die Beziehungen, die zwischen diesen Elementen bestehen dürfen, bilden ihrerseits wieder ein Modell, das sogenannte Metamodell der UML2. Die UML2 ist also mit einem Ansatz definiert, den man als Metamodellierung bezeichnet. Das Metamodell der UML2 ist mit einer weiteren Modellierungssprache definiert, der sogenannten Meta-Object Facility (MOF), die parallel zu UML ebenfalls in eine Version 2.0 weiterentwickelt wurde.
    Hierarchie der Metamodellierung
    vergrößern
    Hierarchie der Metamodellierung

    Wie die UML 1.x ist also auch die UML2 auf der dritten von vier Metamodellierungsebenen eingeordnet.

    Auf der obersten, als M3 bezeichneten Ebene befindet sich das Meta-Metamodell der MOF 2.0. Auf der dritten, als M2 bezeichneten Ebene befindet sich das Metamodell der UML2. Auf der zweiten, als M1 bezeichneten Ebene befinden sich die Modelle, die Benutzer basierend auf der UML2 erstellen. Auf der untersten, als M0 bezeichneten Ebene, befinden sich die Objekte aus der Realität, die modelliert werden.

    Zur UML 1.x besteht jedoch ein wesentlicher Unterschied: die auf diesen vier Ebenen verwendeten Modellierungssprachen, besonders die Sprachen auf den Ebenen M2 und M3 teilen sich die gemeinsame Spracheinheit der Infrastrukturbibliothek (InfrastructureLibrary). Sie wird in der UML 2.0 Infrastructure definiert und bildet einen Kern der wesentlichen Modellierungselemente, der sowohl in der UML 2.0 Infrastructure, als auch in der UML 2.0 Superstructure und in der MOF 2.0 eingesetzt wird.
    [Bearbeiten]

    Spracheinheiten

    Die UML 2.0 Superstructure ist auf einer ersten Ebene modular in Spracheinheiten (language units) aufgebaut. Eine Spracheinheit umfasst eine Menge von eng zusammenhängenden Modellierungselementen, mit denen ein Benutzer einen ausgewählten Aspekt eines Systems mit einem bestimmten Formalismus modellieren kann. Die Spracheinheit Aktivitäten (Activities) umfasst zum Beispiel Elemente für die Modellierung eines Systemverhaltens, das sich am besten mit dem Formalismus von Daten- und Kontrollflüssen darstellen lässt.
    [Bearbeiten]

    Einteilung der Spracheinheiten in Schichten

    Auf einer dritten Stufe sind die meisten Spracheinheiten in mehrere Schichten gegliedert. Die unterste Schicht umfasst jeweils die einfachsten und am häufigsten verwendeten Modellierungselemente, während höhere Schichten zunehmend komplexere Modellierungselemente einführen. Die Spracheinheit Aktivitäten umfasst beispielsweise FundamentalActivities als unterste Schicht und darauf aufbauend die Schicht BasicActivities. FundamentalActivities definiert zunächst nur, dass Aktivitäten strukturell aus hierarchisch geschachtelten Gruppen von Aktionen bestehen. BasicActivities erweitert dieses Gerüst um Kanten und weitere Hilfsknoten zu einem Graphen, den man in der UML2 dann visuell als Aktivitätsdiagramme darstellt.
    [Bearbeiten]

    Spracheinheiten
    [Bearbeiten]

    Spracheinheit Aktionen
    Beispiel der graphischen Notation für eine Aktion mit zwei Eingabe- und einem Ausgabepin
    vergrößern
    Beispiel der graphischen Notation für eine Aktion mit zwei Eingabe- und einem Ausgabepin

    Die Spracheinheit Aktionen umfasst die Definition der Aktionen in UML2. Aktionen sind die elementaren Bausteine für die Modellierung eines Verhaltens. Sie können Eingabewerte über sogenannte Eingabepins entgegennehmen bzw. Ausgabewerte an sogenannten Ausgabepins produzieren.

    Die UML2 definiert in dieser Spracheinheit mehrere Gruppen von grundlegenden Aktionen. Vier davon sind hier erklärt.

    Zu den Aufruf-Aktionen gehört die Aktion zum Aufrufen einer Operation auf einer Klasse (CallOperationAction), die Aktion zum Aufrufen des Verhaltens einer Klasse (CallBehaviorAction) und die Aktionen zum Senden eines Signals (SendSignalAction und BroadcastSignalAction) sowie die Aktion zum Senden eines Objekts (SendObjectAction).

    Zu den Aktionen für die Manipulation von Objekten gehören Aktionen zum Erstellen und Zerstören eines Objekts (CreateObjectAction bzw. DestroyObjectAction) und zum Testen der Identität eines Objekts (TestIdentityAction).

    Ein Satz von Aktionen ist vordefiniert für die Manipulation von Strukturmerkmalen. Dazu gehört eine Aktion zum Lesen eines Strukturmerkmals (ReadStructuralFeatureAction), zum Löschen der Inhalte eines Strukturmerkmals (ClearStructuralFeatureAction) und zum Manipulieren dessen Inhalten(AddStructuralFeatureValueAction und RemoveStructuralFeatureValueAction).

    Zu den Aktionen für die Manipulation von Objektbeziehungen gehört eine Aktion für das Anlegen und das Löschen einer Objektbeziehung (CreateLinkAction bzw. DestroyLinkAction) sowie eine Aktion, mit der alle Objektbeziehungen zu einer bestimmten Assoziation gelöscht werden (ClearAssociationAction).
    [Bearbeiten]

    Spracheinheit Aktivitäten
    Spaghetti-Kochen modelliert als Aktivität
    vergrößern
    Spaghetti-Kochen modelliert als Aktivität

    Die Aktivität ist das zentrale Element, das in der Spracheinheit Aktivitäten definiert ist. Sie ist gleichzeitig eine der wesentlichen Neuerungen der UML2 gegenüber der UML 1.4. Eine Aktivität ist ein Modell für ein Verhalten, das als Menge von elementaren Aktionen beschrieben ist, zwischen denen Kontroll- und Datenflüsse existieren.

    Aktivitäten haben die Struktur eines Graphen. Knoten stellen Aktionen sowie Punkte, an denen die Flüsse zwischen den Aktionen kontrolliert werden, dar; Kanten stehen für Objekt- und Kontrollflüsse. Die Aufgabe des Sprachpakets Aktivitäten ist es nun, alle Typen von Knoten und Kanten zu definieren, die für die Modellierung von Aktivitäten benötigt werden.

    Knoten werden insbesondere in Objekt- und Kontrollknoten unterschieden, Kanten analog dazu in Objekt- und Kontrollflüsse.

    Komplexere Aktivitäten können verschachtelt und mit Kontrollstrukturen modularisiert werden.

    Graphisch werden Aktivitäten in Aktivitätsdiagrammen modelliert.
    [Bearbeiten]

    Spracheinheit Allgemeines Verhalten

    Die Spracheinheit Allgemeines Verhalten umfasst die allgemeinen Modellelemente für die Spezifikation des Verhaltens eines mit der UML2 modellierten Systems. Hier sind die Modellelemente zusammengefasst, die für die Spezifikation von Aktivitäten, Interaktionen oder Zustandsautomaten benötigt werden.

    Die Spracheinheit definiert die Gemeinsamkeiten jeder Verhaltensbeschreibung und dass eine aktive Klasse ein eigenes Verhalten haben kann. Verhalten in einem System, das mit der UML2 modelliert ist, startet immer aufgrund von diskreten Ereignissen. Dieses Sprachpaket definiert, welche Arten von Ereignissen die UML2 unterstützt.

    Die Behandlung der Zeit wird ebenfalls weitgehend in diesem Sprachpaket geregelt. Es definiert Metaklassen für die Beobachtung der Zeit (TimeObservationAction), für die Notation von Zeitausdrücken (TimeExpression), für die Definition von Zeitintervallen (TimeInterval) sowie für das Konzept einer zeitlichen Dauer (Duration).
    [Bearbeiten]

    Spracheinheit Anwendungsfälle
    Beispiel für die graphische Darstellung zweier Anwendungsfälle und zweier Akteure
    vergrößern
    Beispiel für die graphische Darstellung zweier Anwendungsfälle und zweier Akteure

    Die Spracheinheit Anwendungsfälle stellt Elemente für die Modellierung von Anforderungen an ein System zur Verfügung. Das wichtigste Element ist der Anwendungsfall. Anwendungsfälle halten fest, was ein System tun soll. Das zweite wichtige Element ist der Akteur. Akteure spezifizieren, wer (im Sinne einer Person) oder was (im Sinne eines anderen Systems) etwas mit dem System tun soll.

    Graphisch werden Anwendungsfälle in Anwendungsfalldiagrammen dargestellt.
    [Bearbeiten]

    Spracheinheit Informationsflüsse
    Beispiel eines Strukturdiagramms mit zwei Informationsflüssen
    vergrößern
    Beispiel eines Strukturdiagramms mit zwei Informationsflüssen

    Techniken, die die UML2 für die Spezifikation des Verhaltens eines Systems anbietet, liegen präzise semantische Modelle zugrunde. Dies gilt insbesondere für Verhaltensbeschreibungen mit Hilfe von Interaktionen oder Aktivitäten, die zudem darauf ausgerichtet sind, das Verhalten eines Systems sehr feingranular zu spezifizieren. Soll das Modell eines Systems nur einige grundlegenden Informationsflüsse im System aufzeigen, eignen sich diese Techniken deshalb nur bedingt.

    Die Spracheinheit Informationsflüsse, die in der UML2 neu eingeführt wurde, stellt Modellelemente zur Verfügung, um diese Situation zu verbessern. Sie bietet die Modellelemente Informationseinheit und Informationsfluss an, mit denen ein Modellierer Informationsflüsse in einem System auf hoher Abstraktionsstufe festhalten kann.

    Informationsflüsse können dabei eine Vielzahl von anderen Modellelementen der UML2 verbinden, insbesondere Klassen, Anwendungsfälle, Ausprägungsspezifikationen, Akteure, Schnittstellen, Ports und noch einige mehr.

    Die UML2 gibt keinen Diagrammtyp für Informationsflüsse vor. Die graphische Notation für Informationsflüsse und Informationseinheiten kann in allen Strukturdiagrammen vorkommen.
    [Bearbeiten]

    Spracheinheit Interaktionen
    Beispiel für die Spezifikation einer Interaktion mit Hilfe eines Sequenzdiagramm
    vergrößern
    Beispiel für die Spezifikation einer Interaktion mit Hilfe eines Sequenzdiagramm

    Das Verhalten eines modellierten Systems kann in der UML2 auf unterschiedliche Art und Weise spezifiziert werden. Eine davon ist die Modellierung von Interaktionen. Eine Interaktion ist die Spezifikation eines Verhaltens, das am besten über den Austausch von Meldungen zwischen eigenständigen Objekten beschrieben wird. Die Spracheinheit stellt dafür die geeigneten Modellelemente zur Verfügung.

    Wer Interaktionen modelliert, geht davon aus, dass das modellierte System aus einem Netzwerk von Objekten besteht, die untereinander Meldungen austauschen. Schickt ein Objekt einem anderen Objekt eine Meldung, kann man zwei Ereignisauftritte identifizieren: erstens das Auftreten eines Meldungsereignis, wenn die Meldung vom ersten Objekt abgeschickt wird sowie zweitens eines Meldungsereignis, wenn die Meldung beim zweiten Objekt ankommt. Weitere Ereignisse treten auf, wenn eine Aktion oder ein anderes Verhalten im Kontext eines Objekts beginnt oder endet. Eine Spur (trace) bezeichnet eine Folge von solchen Ereignissen. Interaktionen spezifizieren nun ein Verhalten als zwei Mengen von Spuren, einer Menge gültiger und einer Menge ungültiger Spuren.

    Damit ist präziser gesagt, was wir meinen, wenn wir von Interaktionen sprechen: die Bedeutung (Semantik) einer Interaktion ist durch Mengen von Spuren gegeben. Modelliert werden Interaktionen jedoch als Mengen von Lebenslinien, auf denen Aktionen und andere Verhalten ablaufen und zwischen denen Nachrichten ausgetauscht werden.

    Interaktionen modelliert man graphisch in Kommunikationsdiagrammen, in Sequenzdiagrammen oder in Zeitverlaufsdiagrammen.
    [Bearbeiten]

    Spracheinheit Klassen
    Beispiel für ein Klassendiagramm, das Elemente aus der Spracheinheit Klassen verwendet
    vergrößern
    Beispiel für ein Klassendiagramm, das Elemente aus der Spracheinheit Klassen verwendet

    Die Spracheinheit Klassen umfasst den eigentlichen Kern der Modellierungssprache. Sie definiert insbesondere, was man in der UML2 unter einer Klasse versteht und welche Beziehungen zwischen Klassen möglich sind. In dieser Spracheinheit sind grundlegende Prinzipien der UML2 definiert. Die Metaklasse Element ist das Wurzelelement für alle anderen Modellelemente. Jedes Element kann andere Elemente besitzen, auch beliebig viele Kommentare, die wiederum andere Elemente kommentieren können. Zwischen Elementen können Beziehungen definiert werden. Elemente können benannt sein und gehören in diesem Fall zu einem Namensraum. Weiter können gewisse Elemente einen Typ haben. Sie werden dann als typisierte Elemente bezeichnet. Einem Element kann eine Multiplizität mit einer unteren und einer oberen Schranke zugeordnet sein.

    Diese Spracheinheit enthält vier Unterpakete. Das Unterpaket Kernel umfasst zentrale Modellierungselemente, die aus der UML 2.0 Infrastructure wiederverwendet werden. Dazu gehören die Klasse, die Ausprägungsspezifikation, der Namensraum, das Paket, das Attribut, die Assoziation, die Abhängigkeitsbeziehung, der Paketimport, die Paketverschmelzung und die Generalisierung. Das zweite Unterpaket, AssociationClasses, umfasst die Definition von Assoziationsklassen. Interfaces, das dritte Unterpaket, stellt die Definition von Schnittstellen bereit. Schliesslich deklariert das Unterpaket PowerTypes Modellelemente für die sogenannten PowerTypes.

    Elemente aus dieser Spracheinheit werden meistens in Klassendiagrammen, Objektdiagrammen und Paketdiagrammen dargestellt.
    [Bearbeiten]

    Spracheinheit Komponenten
    Beispiel einer Komponente mit drei angebotenen und einer benötigten Schnittstelle, sowie zwei Ports
    vergrößern
    Beispiel einer Komponente mit drei angebotenen und einer benötigten Schnittstelle, sowie zwei Ports

    Komponenten sind modulare Teile eines Systems, die so strukturiert sind, dass sie in ihrer Umgebung durch eine andere, äquivalente Komponente ersetzt werden könnten. In der Softwareentwicklung verwendet man insbesondere das Konzept der Softwarekomponente, um ein Softwaresystem in modulare Teile zu gliedern. Die Spracheinheit Komponenten der UML2 stellt Konstrukte zur Verfügung, um Systeme, die aus Komponenten aufgebaut sind, zu modellieren.

    Das wichtigste Element ist die Komponente, die eine innere Struktur gegen aussen abgrenzt. Die Spezifikation einer Komponente deklariert vor allem den von aussen sichtbaren Rand und definiert damit eine Black Box-Sicht auf die Komponente. Sichtbar sind eine Menge von angebotenen und erforderlichen Schnittstellen sowie allenfalls eine Menge von Ports.

    Die Spracheinheit umfasst ferner den Delegations- und den Kompositionskonnektor. Der Delegationskonnektor verbindet Ports auf der Hülle einer Komponente mit Elementen im Innern der Komponente. Der Kompositionskonnektor verbindet angebotene Schnittstellen einer Komponente mit benötigten Schnittstellen einer anderen Komponente.

    Die Elemente dieser Spracheinheit werden meistens in Komponentendiagrammen, zum Teil aber auch in Klassendiagrammen oder Verteilungsdiagrammen dargestellt.
    [Bearbeiten]

    Spracheinheit Kompositionsstrukturen
    Beispiel eines Kompositionsstrukturdiagramm, das Elemente aus der Spracheinheit Kompositionsstrukturen graphisch darstellt
    vergrößern
    Beispiel eines Kompositionsstrukturdiagramm, das Elemente aus der Spracheinheit Kompositionsstrukturen graphisch darstellt

    Die Spracheinheit Kompositionsstrukturen bereichert die UML2 um einen neuen Ansatz für die Modellierung der inneren Struktur eines zusammengesetzten Ganzen. Das „Ganze“ wird dabei als gekapselter Classifier modelliert, für die „Teile“ stellt diese Spracheinheit die Parts zur Verfügung. Untereinander können Parts durch Konnektoren verbunden sein. Der gekapselte Classifier steht also für ein System mit klarer Abgrenzung von Innen und Aussen, dessen innere Struktur mit Hilfe von Parts und Konnektoren spezifiziert ist. Damit die Grenze zwischen Innen und Aussen zumindest teilweise durchlässig ist, kann der gekapselte Classifier auf der Hülle über eine Menge von Ein- und Ausgangspunkten, so genannten Ports, verfügen.

    Elemente aus dieser Spracheinheit werden meistens in Kompositionsstrukturdiagrammen dargestellt.
    [Bearbeiten]

    Spracheinheit Modelle

    Die Spracheinheit Modelle umfasst nur ein Modellelement: das Modell.
    [Bearbeiten]

    Spracheinheit Profile
    Beispiel für die Definition und die Anwendung eines vereinfachten Profils für die Organisationsmodellierung
    vergrößern
    Beispiel für die Definition und die Anwendung eines vereinfachten Profils für die Organisationsmodellierung

    Die UML2 stellt mit der Spracheinheit Profile einen leichtgewichtigen Erweiterungsmechanismus zur Verfügung, mit dem sie spezifischen Einsatzgebieten angepasst werden kann. Der Mechanismus wird als leichtgewichtig bezeichnet, weil er das Metamodell der UML2 unverändert lässt, oft ein entscheidendender Vorteil, denn auf dem Markt erhältliche Werkzeuge für die Erstellung und Pflege von UML2-Modellen können oft nur mit Modellen basierend auf dem standardisierten UML2-Metamodell umgehen.

    Die UML2 umfasst in ihren Spracheinheiten verschiedene Möglichkeiten für die Modellierung der Struktur und des Verhaltens eines Systems, muss dabei aber auf einer generischen Ebene bleiben. Sie verwendet zum Beispiel die generischen Begriffe Aktivität oder Artefakt und kennt den spezifischen Begriff Geschäftsprozess aus der Geschäftsmodellierung oder Enterprise Java Beans der Java-Plattform nicht. Falls diese Begriffe in der Modellierung benötigt werden, müssen sie über den Erweiterungsmechanismus der Profile zur UML2 hinzugefügt werden. Auch spezielle Notationen, zum Beispiel eine realistischere Zeichnung anstelle des Strichmännchens, das einen Akteur darstellt, können der UML2 mit Hilfe der Profile hinzugefügt werden. Weiter können Profile Lücken in der Definition der Semantik der UML2 schliessen, die dort absichtlich für spezifische Einsatzgebiete offen gelassen wurden (engl. semantic variation points). Schliesslich können Profile Einschränkungen definieren, um die Art und Weise zu beschränken, wie ein Element aus der UML2 verwendet wird.

    Mit Hilfe des Erweiterungsmechanismus der Profile kann das Metamodell der UML2 jedoch nicht beliebig angepasst werden. So können zum Beispiel keine Elemente aus dem Metamodell der UML2 entfernt, keine Einschränkungen aufgehoben und keine echten neuen Metaklassen, sondern nur Erweiterungen (Stereotypen) von bestehenden Metaklassen, deklariert werden.

    Die Spracheinheit definiert zunächst das Konzept eines Profils. Ein Profil ist eine Sammlung von Stereotypen, und definiert die eigentliche Erweiterung. Ein Profil ist ein Paket und wird auf andere Pakete angewendet, womit die Erweiterung, die das Profil definiert, für das entsprechende Paket gilt.

    Die UML2 kennt keinen speziellen Diagrammtyp für Profile. Die graphischen Notationen für Elemente aus dieser Spracheinheit kommen sowohl in Paketdiagrammen als auch in Klassendiagrammen vor.
    [Bearbeiten]

    Spracheinheit Schablonen
    [Bearbeiten]

    Spracheinheit Verteilungen
    Beispiel eines Verteilungsdiagramms mit einem Knoten und zwei Artefakten
    vergrößern
    Beispiel eines Verteilungsdiagramms mit einem Knoten und zwei Artefakten

    Die Spracheinheit Verteilungen (engl. Deployments) ist auf ein sehr spezifisches Einsatzgebiet ausgerichtet, nämlich auf die Verteilung von lauffähiger Software in einem Netzwerk. Die UML2 bezeichnet eine so installierbare Einheit als Artefakt und geht davon aus, dass diese auf Knoten installiert werden. Knoten können entweder Geräte oder Ausführungsumgebungen sein. Eine Verteilungsbeziehung, das heisst eine spezielle Abhängigkeitsbeziehung, modelliert, dass ein Artefakt auf einem Knoten installiert wird.

    Elemente aus dieser Spracheinheit werden normalerweise in Verteilungsdiagrammen dargestellt.
    [Bearbeiten]

    Spracheinheit Zustandsautomaten

    [Bearbeiten]

    Darstellung in Diagrammen

    Die UML2 kennt sechs Strukturdiagramme: das Klassendiagramm, das Kompositionsstrukturdiagramm (auch: Montagediagramm), das Komponentendiagramm, das Verteilungsdiagramm, das Objektdiagramm und das Paketdiagramm. Dazu kommen sieben Verhaltensdiagramme: das Aktivitätsdiagramm, das Sequenzdiagramm, das Kommunikationsdiagramm, das Interaktionsübersichtsdiagramm, das Zeitverlaufsdiagramm, das Anwendungsfalldiagramm (auch: Nutzfalldiagramm) und das Zustandsdiagramm.

    Die Grenzen zwischen den dreizehn Diagrammtypen verläuft weniger scharf, als diese Klassifizierung vermuten lässt. Die UML2 verbietet nicht, dass ein Diagramm graphische Elemente enthalten darf, die eigentlich zu unterschiedlichen Diagrammtypen gehören. Es ist sogar denkbar, dass Elemente aus einem Strukturdiagramm und aus einem Verhaltensdiagramm auf dem gleichen Diagramm dargestellt werden, wenn damit eine besonders treffende Aussage zu einem Modell erreicht wird.

    Die UML2 geht aber in anderer Hinsicht weit formaler mit Diagramme um als die UML 1.4. Neu definiert die UML2 unter dem Namen UML 2.0 Diagram Interchange ein Austauschformat für Diagramme, so dass unterschiedliche Werkzeuge, mit denen Modelle basierend auf der UML2 erstellt werden, die Diagramme austauschen und wiederverwenden können. In der UML 1.x war das nur für die Repository-Modelle hinter den Diagrammen möglich, aber nicht für die eigentlichen Diagramme.
    [Bearbeiten]

    Erstellen von Diagrammen

    Diagramme der UML2 können auf verschiedene Arten erstellt werden. Wenn die Notation der UML2 als gemeinsame Sprache eingesetzt wird, um in einem Analyseteam Entwürfe von Analysemodellen an der Weisswandtafel (Whiteboard) festzuhalten, reichen Stifte und Papier als Werkzeug. Häufig werden Diagramme der UML2 jedoch mit Hilfe von speziellen Programmen erstellt, die man in zwei Klassen einteilen kann. Die erste Gruppe von Programmen helfen beim Zeichnen von Diagramme der UML2, ohne dass sie die Modellelemente, welche den graphischen Elementen auf den Diagrammen entsprechen, in einem Repository ablegen. Zu dieser Gruppe gehören alle Programme zum Erstellen von Zeichungen, zum Beispiel Visio als kommerzielles bzw. Dia als gemeinfreies Werkzeug. Die zweite Gruppe besteht aus Programmen, die die Erstellung von Modellen und das Zeichnen von Diagrammen der UML2 unterstützen, zum Beispiel Rational Software Architect als kommerzielles bzw. ArgoUML als gemeinfreies Werkzeug. Mitte 2005 gab es jedoch noch kein verfügbares Werkzeug in der zweiten Gruppe, das alle dreizehn Diagrammarten aus der UML2 vollumfänglich unterstützt hat.
    [Bearbeiten]

    Austausch von Modellen und Diagrammen

    Damit Modelle von einem Werkzeug ans andere übergeben werden können, definiert die Object Management Group ein standardisiertes Austauschformat, das auch für UML-Modell eingesetzt wird. Das Format basiert auf der Auszeichnungssprache XML und heisst XML Metadata Interchange (XMI).

    Für die UML-Versionen 1.x sah das Format keine Möglichkeit vor, Diagramme in einem standardisierten Format auszutauschen, was von vielen Anwendern der UML als wesentliche Lücke wahrgenommen wurde. Parallel zur Entwicklung der UML2 hat die OMG deshalb auch das standardisierte Austauschformat XMI überarbeitet. Unter anderem wurde die beschriebene Lücke geschlossen, indem die Spezifikation unter dem Namen UML 2.0 Diagram Interchange um ein Format für den Austausch von Diagrammen erweitert wurde.
    [Bearbeiten]

    Literatur

    * Heide Balzert, Lehrbuch der Objektmodellierung, Spektrum Akademischer Verlag, 1999, ISBN 3-8274-0285-9
    * Heide Balzert: UML 2 in 5 Tagen, W3L, 2005, ISBN 3937137610
    * G.Booch, J.Rumbaugh, I.Jacobson: Das
    * M. Born, E. Holz, O. Kath: Softwareentwicklung mit UML 2, Addison-Wesley, 2004, ISBN 3-8273-2086-0
    * B. Brügge, A. H. Dutoit: Objekt-orientierte Softwaretechnik mit UML, Entwurfsmustern und Java, Pearson Studium, 2004, ISBN 3827370825
    * M. Fowler; Kendall, Scott: UML konzentriert, Addison-Wesley Verlag, 2000, ISBN 3-8273-1617-0
    * M. Fowler: UML Distilled, 3. Auflage, Addison-Wesley, 2003, ISBN 0-321-19368-7
    * M. Hitz, G. Kappel, E. Kapsammer, W. Retschitzegger: UML@Work, Dpunkt Verlag, 2005, ISBN 3898642615
    * M. Jeckle, C. Rupp, J. Hahn, B. Zengler, S. Queins: UML 2 glasklar, Hanser-Verlag, 2003, ISBN 3-446-22575-7
    * B. Kahlbrandt: Software Engineering mit der Unified Modeling Language, Springer, 2001, ISBN 3540416005
    * Christoph Kecher: "UML 2.0 - Das umfassende Handbuch" Galileo Computing, 2005, ISBN 3-89842-573-8
    * B. Oestereich: Objektorientierte Softwareentwicklung mit der UML 2.0, Oldenbourg Verlag, 2004, ISBN 3486272667
    * Dan Pilone: UML – kurz & gut, O'Reilly, ISBN 3-89721-263-3
    * B. Rumpe, Modellierung mit UML, Springer Verlag, 2004, ISBN 3540209042
    * Sinan Si Alhir: Learning UML, O'Reilly, ISBN 0-596-00344-7
    * H. Störrle: UML 2 für Studenten, Pearson Studium Deutschland, 2005, ISBN 3827371430
    * H. Störrle: UML 2 erfolgreich einsetzen, Addison-Wesley, 2005, ISBN 3827322685
    * T. Weilkiens, B. Oestereich: UML2 Zertifizierung, Dpunkt Verlag, 2004, ISBN 3898642941
    * W. Zuser, T. Grechenig, M. Köhle: Software Engineering mit UML und dem Unified Process, Pearson Studium, 2004, ISBN 3827370906



  • Danke Danke Danke

    tut mir echt leid aber ich bin halt nunmal zu blöd zu googlen oder mal bei Wikipedia "UML" einzugeben und meine Mama hat mir die .com seiten gesperrt 😞


Anmelden zum Antworten