Unified Modeling Language (UML)

  • 6 August 2015
  • admin
Unified Modeling Language (UML) combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies.[2]
The Unified Modeling Language (UML) offers a standard way to visualize a system's architectural blueprints, including elements such as:
activities
actors
business processes
database schemas
(logical) components
programming language statements
reusable software components.[3]
 
UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language.[4] UML aims to be a standard modeling language which can model concurrent and distributed systems.
UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages. UML is extensible, with two mechanisms for customization: profiles and stereotypes.
 
Software development methods
UML is not a development method by itself;[13] however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch method, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notations (for example OMT), and new methods have been created based on UML, such as IBM Rational Unified Process (RUP). Others include Abstraction Method and Dynamic Systems Development Method.
 
Modeling
 
It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphic representation of a system's model. The model also contains documentation that drives the model elements and diagrams (such as written use cases).
UML diagrams represent two different views of a system model:[14]
Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams.
Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.
UML models can be exchanged among UML tools by using the XMI interchange format.
 
Diagrams overview
UML diagrams
Structural UML diagrams
Class diagram
Component diagram
Composite structure diagram
Deployment diagram
Object diagram
Package diagram
Profile diagram
Behavioral UML diagrams
Activity diagram
Communication diagram
Interaction overview diagram
Sequence diagram
State diagram
Timing diagram
Use case diagram
v t e
UML 2.2 has 14 types of diagrams divided into two categories.[15] Seven diagram types represent structural information, and the other seven represent general types of behavior, including four that represent different aspects of interactions. These diagrams can be categorized hierarchically as shown in the following class diagram:
Hierarchy of UML 2.2 Diagrams, shown as a class diagram.
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. UML profiles may define additional diagram types or extend existing diagrams with additional notations.
In keeping with the tradition of engineering drawings,[citation needed] a comment or note explaining usage, constraint, or intent is allowed in a UML diagram.
Structure diagrams[edit source | editbeta]
Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems.
Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.
Component diagram: describes how a software system is split up into components and shows the dependencies among these components.
Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible.
Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware.
Object diagram: shows a complete or partial view of the structure of an example modeled system at a specific time.
Package diagram: describes how a system is split up into logical groupings by showing the dependencies among these groupings.
Profile diagram: operates at the metamodel level to show stereotypes as classes with the <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype. The extension relation (solid line with closed, filled arrowhead) indicates what metamodel element a given stereotype is extending.
 
  • Class diagram
  • Component diagram
  • Composite structure diagram
  • Deployment diagram
  • Object diagram
  • Package diagram
 
Behavior diagrams
Behavior diagrams emphasize what must happen in the system being modeled. Since behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems.
Activity diagram: describes the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
UML state machine diagram: describes the states and state transitions of the system.
Use Case Diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.
 
  • UML Activity Diagram
  • State Machine diagram
  • Use Case Diagram
 
Interaction diagrams
Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:
Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
Interaction overview diagram: provides an overview in which the nodes represent communication diagrams.
Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.
Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints.
 
Communication diagram
Interaction overview diagram
Sequence diagram
 
The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.
 
Meta modeling
The Object Management Group (OMG) has developed a metamodeling architecture to define the Unified Modeling Language (UML), called the Meta-Object Facility (MOF).[16] The Meta-Object Facility is designed as a four-layered architecture, as shown in the image at right. It provides a meta-meta model at the top layer, called the M3 layer. This M3-model is the language used by Meta-Object Facility to build metamodels, called M2-models.
The most prominent example of a Layer 2 Meta-Object Facility model is the UML metamodel, the model that describes the UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe runtime instance of the system.
Beyond the M3-model, the Meta-Object Facility describes the means to create and manipulate models and metamodels by defining Common Object Request Broker Architecture (CORBA) interfaces that describe those operations. Because of the similarities between the Meta-Object Facility M0-model and UML structure models, Meta-Object Facility metamodels are usually modeled as UML class diagrams. A supporting standard of the Meta-Object Facility is XMI, which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer.