UML is a standardized graphical display format for the visualization, specification, design and documentation of (software) systems. It offers a set of standardized diagram types with which complex data, processes and systems can easily be arranged in a clear, intuitive manner.

UML is neither a procedure nor a process; rather, it provides a "dictionary" of symbols - each of which has a specific meaning. It offers diagram types for object-oriented analysis, design and programming, thereby ensuring a seamless transition from requirements placed on a system to final implementation. Structure and system behavior are likewise shown, thereby offering clear reference points for solution optimization.

One major aspect of UML is the ability to use diagrams as a part of project documentation. These can be utilised in various ways in the most diverse kinds of documents; for example, Use Case Diagrams used in describing functional requirements can be specified in the requirements definition. Classes or component diagrams can be used as software architecture in a design document. As a matter of principle, UML diagrams can be used in practically any technical documentation (e.g. test plans) while also serving as part of the user handbook.

Despite the fact that the idea of object orientation is more than 30 years old, and the development of object-oriented programming languages spans almost the same length of time, the first books on object-oriented analysis and design methods didn't appear until the early 1990's. The godfathers of this idea were Grady Booch, Ivar Jacobson and James Rumbaugh. Each of these three "veterans" had developed his own method, each one specialized in and limited to its own area of application.

In 1995 Booch and Rumbaugh began to merge their methods into a common Unified Method (UM) notation. The Unified Method was soon renamed as Unified Modeling Language (UML), a more adequate term since it is mostly concerned with the unification of the graphical presentation and semantics of modeling elements, and does not describe an actual method. Indeed, "modeling language" is basically just another term for notation.

Short time later Ivar Jacobson joined in the foray and his Use Cases were soon integrated. From that point on, these three pioneers called themselves the "Amigos".

Although the methods of Booch, Rumbaugh and Jacobson were already very popular and held a large market share, the Unified Modeling Language (UML) became a quasi-standard. Finally, in 1997, UML Version 1.1 was submitted to the Object Management Group (OMG) for standardization, and accepted. The versions 1.2 to 1.5 both contain several important corrections. In 2004, Version 2.0 was approved with many key modifications and extensions as the new standard. UML 2.3 has become standard in 2010. (Source: OOSE)

The use of UML as a "common language" leads to an improvement in cooperation between technical and non-technical competencies like project leaders, business analysts, software/hardware architects, designers and developers. It helps in the better understanding of systems, in revealing simplification and/or recoverability options, and in the easier recognition of possible risks. Through early detection of errors in the analysis and design phase of a project, costs can be reduced during the implementation phase. The advantages associated with Round-Trip Engineering offer developers the ability to save a great deal of time.

Although UML was initially developed for the modeling of software systems, it can also be implemented for any hardware or organizational project. By allowing processes to be visualized, they can subsequently be analysed and improved. Developers of embedded systems or real-time systems may use non-object-oriented programming languages - applying UML makes sense in this case also!

The official specification for UML 2.1 is a complex work of over one thousand pages (http://uml.org), arranged into the following sub-components:

  • Infrastructure (Architectural Core, Profiles, Stereotypen),
  • Superstructure (Static and Dynamic Modeling Elements),
  • OCL (Object Constraint Language) and
  • Diagram Interchange (UML Exchange Format)

The present book covers only the most important UML core elements and in no way constitutes a complete and comprehensive source of reference. For additional and more specific details on UML, more advanced literature is referred to (see attachment).

Enterprise Architect uses the extension mechanism (Profile) designated in UML to provide new elements - such as an element for Requirement - as well as additional diagram types. Likewise, extended properties - such as test windows, job orders, risks, etc. - can also be prepared. Thereby, a UML-based tool emerges which, together with a likewise integratable development platform, enables comprehensive project work including requirements management, operational documentation and more.

Officially, in UML there is no diagram overview or categorization. Although UML models and the Repository behind the diagrams are defined in UML, diagrams - or special Repository views - can be relatively freely specified.

In UML, a diagram is actually more of a collection of notation elements. It is in this way, for example, that the package diagram describes the package symbol, the Merge relationship, etc. A Class diagram describes classes, associations, etc. Naturally, however, classes and packages may still be displayed together in one diagram.

A diagram is composed of a diagram space enclosed by a rectangle with a diagram header in the upper left corner. This diagram header shows the diagram type (optional), diagram name (obligatory) and parameter (optional).

The diagram type is, for example, sd for Sequence Diagram, or cd for Class Diagram. The Parameter field is important for customizable models.

UML Version 2.3 contains 13 diagram types which can be divided into roughly two groups. The group structure diagrams represent the static aspects of a system, while the group of behavioral diagrams represent dynamic components.

To many who are new to UML, the question soon arises as to how these diagrams are actually associated with one another. This is a very legitimate question; however, UML itself does not give us a clear answer. It is primarily the software development methodology, or rather the background processes thereof, which can best answer this question. One possible approach concerning the order, or phases of a project, in which the diagrams can be implemented can be shown as follows:

Use Case Diagram

Analysis Phase

  • which use cases are included in the application to be generated
    • which actors are released by this use case
    • what use case dependencies are interconnected, e.g.

o whether one use case is contained within another

o whether one use case represents a specialization of another

o whether one existing use case is extended by a second

Activity Diagram

Analysis & Design Phase

  • which steps will be taken within a use case
    • what state transition the involved objects experience when handling changes from one activity to another

Package Diagram

Analysis & Design Phase

  • into which packages the application can be subdivided
    • which packages allow further subdivision
    • what levels of communication must be realized between packages

Class Diagram

Analysis & Design Phase

  • which relations have to be obtained within a project definition (domain model)
    • which classes, components and packages are involved
    • via what type of communication cooperation is to take place
    • which methods and properties do the classes require
    • what are the minimum and maximum numbers of objects to be linked
    • which classes are responsible for multiple objects as a container

Sequence Diagram

Design Phase

  • which methods are responsible for communication between selected objects
    • how the chronological cycle of method calls between selected objects is to occur
    • which objects in a sequence are to be newly created or destroyed

Communication Diagram

Design Phase

  • how selected objects communicate with one another
    • in which order the method calls are carried out
    • which alternative method calls exist should they be required

State Diagram

Design Phase

  • what state transitions are released by which method call
    • which condition will be assumed following object creation
    • which methods destroy the object

Component Diagram

Design Phase

  • how are soft and/or hardware parts capsuled with defined function and defined interfaces
    • which components have interfaces to one another
    • what software parts create functionality in components

Deployment Diagram

Design Phase

  • which PCs in the application work together
    • what application module will be run on which PC
    • on which communication options should cooperation be based

 

If necessary, the order of diagram use may deviate from that shown in the table because, for example, the division of the work of multiple programmers cannot be managed. In such case, the package diagram can first be created with the class diagram. This order serves to show only one possibility of how you can realise a model of your application, and how the phase transitions can be formulated.

The area of application will also have an effect; the resulting diagram order of implemented diagrams for a business automation job will differ considerably from that of an embedded task job.

Modeling of Behaviors concerns the description of processes, chronological dependencies, state changes, the treatment of events, and the like. UML is object-oriented, therefore behavior is nothing which exists independently, but rather always affects certain objects. When examined in detail, the execution of a Behavior can always be traced to an object.

Every behavior results from actions of at least one object, and leads to changes in the states of the involved objects.

In UML, behavior is principally event-oriented. The execution of behaviors is always triggered by an event. Two special events always occur: the Start event and the End event.

Behavior can be started either directly (i.e. CallBehaviorEvent) or indirectly via a Trigger (TriggerEvent), such as when a point in time is reached (TimeEvent), when a message is received (ReceivingEvent), or when a particular value is reached or changed (ChangeEvent).

In UML, four different specifications are provided for behaviour descriptions:

  • State diagrams (state machines)
    • Activities and actions (activities)
    • Interactions (interaction)
    • Use cases (use cases)

A use case diagram is actually a structure diagram, since the use case diagram itself doesn't describe processes and behavioral patterns, but rather only the structure (relationships) of use cases and actors. Nevertheless, the use case diagram is categorized as a behavioral diagram in many UML publications. The content of this diagram type is showing the desired functionality, the desired outcome - is the argument.