UML: Difference between revisions
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
The purpose of the UML is the visualization, specification, construction and documentation of object-oriented systems. Specification means precise, unambiguitous and complete. The UML is process independent, although optimally it should be used in a process that is use case driven, architecture-centric, iterative and incremental. | |||
===History=== | |||
[[File:OO-historie-2.svg.png|UML History]] | |||
==Rational Unified Process== | ==Rational Unified Process== | ||
| Line 51: | Line 52: | ||
===Sequence Diagrams=== | ===Sequence Diagrams=== | ||
The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. | The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. | ||
====Kritik==== | |||
Eine Codegenerierung ist schwer vorstellbar, die Syntax ist sehr beschränkt. Es gibt Ansätze Schleifen und Bedingungen grafisch darzustellen, dann wird das Diagramm sehr komplex. Auch Übergabeparameter von Methoden, insbesondere aber Returnwerte lassen sich schwer darstellen. Ein weiteres Problem ist die Granularität, diese ist in einer Programmiersprache wie Java sehr viel höher, vor allem bezogen auf die Anzahl Anweisungen und auf das, was innerhalb einer Klasse nach einem Methodenaufruf passiert. Außerdem werden die Diagramme sehr breit. Der Sinn des Aktivitätsbalken ist auch nicht ganz klar. | |||
====Specific Elements==== | ====Specific Elements==== | ||
| Line 65: | Line 68: | ||
=====Return Message===== | =====Return Message===== | ||
[[Image:UMLReturnMessage.jpg]] | [[Image:UMLReturnMessage.jpg]] | ||
===Deployment Diagram=== | |||
[[File:Deployment.jpg]] | |||
==Sources== | ==Sources== | ||
* file://C:\Uwes\Documents\Software_Development\Modeling\UML\Uml.vsd | |||
* file://C:\Uwes\Documents\Software_Development\Modeling\UML\uml-2-Notationsuebersicht-oose.de.pdf | |||
Latest revision as of 11:42, 8 January 2013
Introduction[edit]
The purpose of the UML is the visualization, specification, construction and documentation of object-oriented systems. Specification means precise, unambiguitous and complete. The UML is process independent, although optimally it should be used in a process that is use case driven, architecture-centric, iterative and incremental.
History[edit]
Rational Unified Process[edit]
Zu Beginn war der Entwicklungsprozess aus der UML ausgeklammert. Der 'Rational Unified Process' (RUP) soll diese Lücke schliessen. Der Rational Unified Process kombiniert Werkzeuge mit der passenden Methodik für eine erfolgreiche Softwareentwicklung. Dazu wurden bewährte Praktiken aus mehreren Bereichen der Softwareentwicklung vereint. Dazu zählen:
- Geschäftsprozessmodellierung
- Anforderungsmanagment
- komponentenbasierte Entwicklung
- Daten-Engineering
- Konfigurations- und Änderungsmanagment
- Test und Qualitätssicherung
RUP soll den vorher bekannten Rational Objectory Process ablösen.
Modelling elements[edit]
Class[edit]
Die Modelelemente interface, datatype, signal, component, node, use case and subsystem werden in der UML mit dem Begriff classifiers zusammengefasst.
The <classname> can be a simple name or a path name which is the simple name prefixed by the package seperated by a dot in which the class lives. <Responsibilities> are just free text. The <stereotype> is explained in chapter 3.6. The icon can replace the whole rectangle. If the value of the <multiplicity> specifier is 1 than the class is called a singleton. The attributes and operation compartments can be suppressed. Drawing an empty compartment states that there are no entries in this compartment. Usually the <classname> is in bold letters but this has no semantically meaning. The tagged value (property list) is explained in chapter 3.7 and contains properties specific to the language, to the generated code or to the documentation. The order of the attributes is meaningful. Visibility should be used very late because different programming languages implement different visibility properties:
- + public
- - private
- # protected
- ~ package
A tagged value for an attribute might be {changeable}, {addOnly} and {frozen}. frozen means const, changeable is so to say normal and addOnly is for attributes with a multiplicity greater than one. A tagged value for an operation might be {leaf} which signals that this operation may not be overriden by a child. Others are {isQuery}, {sequential}, {guarded} and {concurrent}. The UML distinguishes between operation and method. An operation specifies a service that can be requested from any object of the class; a method is an implementation of an operation. The direction for an operation parameter might be in, out and inout.
An active class is a class whose instances are active objects.
An interface is a collection of operations that are used to specify a service of a class or component . An interface can also be rendered as a stereotyped class.
A type is a stereotype of a class used to specify a domain of objects, together with the operations applicable to the object .
Parameterized Classes are drawn as follows:
Diagrams[edit]
Sequence Diagrams[edit]
The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur.
Kritik[edit]
Eine Codegenerierung ist schwer vorstellbar, die Syntax ist sehr beschränkt. Es gibt Ansätze Schleifen und Bedingungen grafisch darzustellen, dann wird das Diagramm sehr komplex. Auch Übergabeparameter von Methoden, insbesondere aber Returnwerte lassen sich schwer darstellen. Ein weiteres Problem ist die Granularität, diese ist in einer Programmiersprache wie Java sehr viel höher, vor allem bezogen auf die Anzahl Anweisungen und auf das, was innerhalb einer Klasse nach einem Methodenaufruf passiert. Außerdem werden die Diagramme sehr breit. Der Sinn des Aktivitätsbalken ist auch nicht ganz klar.
Specific Elements[edit]
Die Darstellung der unterschiedlichen Elemente ist offensichtlich nicht fest definiert, daher findet man häufig unterschiedliche Notationen z.B. für synchrone oder asynchrone Messages.
Lifeline[edit]
Synchronous Message[edit]
Asynchronous Message[edit]
Return Message[edit]
Deployment Diagram[edit]
Sources[edit]
- file://C:\Uwes\Documents\Software_Development\Modeling\UML\Uml.vsd
- file://C:\Uwes\Documents\Software_Development\Modeling\UML\uml-2-Notationsuebersicht-oose.de.pdf