The Unified Modeling Language™ (UML®) is a standard visual modeling language intended to be used for
modeling business and similar processes,
analysis, design, and implementation of software-based systems.
UML is a common language used by various parties involved in the software engineering lifecycle: business analysts, software architects, developers, testers and system administrators. It is used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems.
UML can be applied to various application domains (e.g., banking, selling and buying product via internet, healthcare, finance, etc.) and it can be used together with all major object and component software development methods and for diverse implementation platforms (e.g., Java EE, .NET).
It is important to emphasize that UML is “only” a standard modeling language, not a software development process. A software development process is expected to
provide guidance to the order of the activities performed by a group of people (the development team),
specify what artifacts should be developed,
control the tasks performed by both individual developers and the team as a whole, and
offer criteria in order to monitor and measure the produced artifacts and the performed activities within a project.
UML is not about providing these pieces of information. It is not prescriptive but descriptive: as a modeling language, it does not prescribe any activities and does not require to produce any artifacts; however, it can be used to describe the artifacts that an applied software development process requires.
Therefore, UML is intended to be process independent and it can be applied in the context of different processes. However, it is most suitable for use case-driven, iterative and incremental development processes. An example of such process is Rational Unified Process (RUP).
Important
Our case study does not depend on the application of a given software process model. However, the presentation of the steps will resemble the reader similar to those of plan-driven approaches. The reason for that is very trivial: plan-driven approaches are more documentation-oriented than agile methods (which are much more code-oriented) and therefore, in our opinion, it is easier to describe (and understand) a system in a plan-driven way for learning purposes, especially because we focus on the analysis and design instead of actual programming.
UML is not completely visual which means that given some UML diagram, the described part or behavior of the system might not be understood from the diagram alone. Some pieces of information could be intentionally omitted from the diagram, some information represented on the diagram could have different interpretations, and some concepts of UML have no graphical notation at all, so there is no way to depict those on diagrams.
For example, semantics of multiplicity of actors and multiplicity of use cases on use case diagrams is not defined precisely in the UML specification and could mean either concurrent or successive usage of use cases.
Name of an abstract classifier is shown in italics while final classifier has no specific graphical notation, so there is no way to determine whether classifier is final or not from the diagram.
This, on one hand, provides a great flexibility when having a more or less informal system description intended to be read by human beings (some people involved in the process). On the other hand, the lack of proper semantics (that can lead to ambigous interpretations) or missing notations are problematic when applying a model-driven style of development that would require precise statements about each models so that a model tarnsformation or code generation migh take place.
A UML diagram is a partial graphical representation (view) of a model of a system under design, implementation, or already in existence. UML diagrams contain graphical elements (symbols)—UML nodes connected with edges (also known as paths or flows)—that represent elements in the UML model of the designed system. Since it is uncommon to describe a system by using UML models only, system description might also contain other documentation such as use cases written as templated texts.
The UML offers a set of diagram types to capture the different aspect of software systems. The diagram type is defined by the primary graphical symbols shown on the diagram. For example, a diagram where the primary symbols are classes is a class diagram. A diagram showing actors and use cases is called a use case diagram. A sequence diagram shows sequence of message exchanges between lifelines.UML specification also allows to create a mixture of different kinds of diagrams, e.g. to combine structural and behavioral elements to show a state machine nested inside a use case. Consequently, the boundaries between the various kinds of diagrams are not strictly enforced. At the same time, some UML tools do restrict set of available graphical elements which could be used when working on specific type of diagram.
Object Management Group (OMG) is the name of the organization responsible for developing and maintaining the UML standard. UML version 2.4.1 consists of two separate documents, namely, the UML Infrastructure ([UML2.4.1INFRA]) and the UML Superstructure ([UML2.4.1SUPER]).
Note
This will be changed from the 2.5 version of the UML since these documents will be merged together.
UML Infrastructure defines a core metamodel that is used to define the full MetaObject Facility (MOF), UML and Profiles. The key concept to understand is that in UML, reuse is the pervasive design consideration. The core of the UML Infrastructure is defined on an abstract level, and is extended by using object-oriented principles to define the UML Superstructure. Superstructure complements Infrastructure by defining user level constructs required for UML 2.4.1 (e.g., various digram types).
Note
The MetaObject Facility (MOF) Specification is the foundation of OMG's industry-standard environment where models can be exported from one application, imported into another, transported across a network, stored in a repository and then retrieved, rendered into different formats (including XMI, OMG's XML-based standard format for model transmission and storage), transformed, and used to generate application code.
MOF is designed as a four-layered architecture (see Figure 1.6, “Layered architecture of MOF .”). It provides a meta-meta model at the top layer, called the M3 layer. This M3-model is the language used by MOF to build metamodels, called M2-models. The most prominent example of a Layer 2 MOF 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 real-world objects.
Beyond the M3-model, MOF describes the means to create and manipulate models and metamodels by defining CORBA interfaces that describe those operations. Because of the similarities between the MOF M3-model and UML structure models, MOF metamodels are usually modeled as UML class diagrams. A supporting standard of MOF is the XML Metadata Interchange (XMI), which provides an exchange format based on XML for models of the various layers.
MOF is a closed metamodeling architecture; it defines an M3-model, which conforms to itself. MOF allows a strict meta-modeling architecture; every model element on each layer is strictly in correspondence with a model element of the layer above. MOF only provides a means to define the structure, or abstract syntax of a language or of data. For defining metamodels, MOF plays exactly the role that EBNF plays for defining programming language grammars. MOF is a Domain Specific Language (DSL) used to define metamodels, just as EBNF is a DSL for defining grammars. Similarly to EBNF, MOF could be defined in MOF. This is referred to as metacircular description.
UML specification defines two major kinds of UML diagrams: structural diagrams and behavioral diagrams.
Structural diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts.
Behavioral diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time.
UML 2.4 diagrams could be categorized hierarchically as shown below:
Structural diagrams are not utilizing time related concepts, do not show the details of dynamic behavior. However, they may show relationships to the behaviors of the classifiers exhibited in the structure diagrams.
Class diagram is a static structure diagram which describes structure of a system at the level of classifiers (classes, interfaces, etc.). It shows some classifiers of the system, subsystem or component, different relationships between classifiers, their attributes and operations, constraints.
Object diagram can be defined as "a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a particular snapshot of the detailed state of a system at a point in time." It also stated that object diagram is "a class diagram with objects and no classes."
Package diagram shows packages and relationships between the packages. A package is a namespace that is used to group together elements that are semantically related and might change together. It is a general purpose mechanism to organize elements into groups to provide better structure for system model.
Composite Structure Diagram could be used to show the internal structure of a classifier, classifier interactions with the environment through ports, a behavior of a collaboration. The term "structure" for this type of diagrams is defined in UML as a composition of interconnected elements, representing run-time instances collaborating over communications links to achieve some common objectives.
Component diagram shows components and their dependencies. This diagrams type plays an important role in modeling systems that are used for Component-Based Development (CBD), to describe systems with Service-Oriented Architecture (SOA).
Deployment diagram shows architecture of the system as deployment (distribution) of software artifacts to deployment targets. In UML 2.x, artifacts are deployed to nodes, and artifacts could manifest (implement) components so components are deployed to nodes indirectly through artifacts. Deployment diagrams could be used to show logical or physical network architecture of the system.
Profile diagram is an auxiliary UML diagram which allows defining custom stereotypes, tagged values, and constraints. The Profile mechanism has been defined in UML for providing a lightweight extension mechanism to the UML standard. Profiles allow to adapt the UML metamodel for different platforms (such as Java EE or .NET), or domains (such as real-time or business process modeling). Even though the concept of profiles are older, Profile diagrams were first introduced in UML 2.0.
Behavioral diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time.
Use case diagrams are behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors) to provide some observable and valuable results to the actors or other stakeholders of the system(s). Note, that UML 2.4 specification also defines use case diagrams as specialization of class diagrams (which are structure diagrams). Use case diagrams could be considered as a special case of class diagrams where classifiers are restricted to be either actors or use cases and the most used relationship is association.
Activity diagram shows sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors. These are commonly called control flow and object flow models.
State machine diagram is used for modeling discrete behavior through finite state transitions. In addition to expressing the behavior of a part of the system, state machines can also be used to express the usage protocol of part of a system. These two kinds of state machines are referred to as behavioral state machines and protocol state machines.
Interaction diagrams include few different types of diagrams:
Sequence diagram is the most common kind of interaction diagrams, which focuses on the message interchange between lifelines (objects).
Communication diagram (previously known as Collaboration Diagram) is a kind of interaction diagram, which focuses on the interaction between lifelines where the architecture of the internal structure and how this corresponds with the message passing is central. The sequencing of messages is given through a sequence numbering scheme.
Interaction overview diagram defines interactions through a variant of activity diagrams in a way that promotes overview of the control flow. Interaction overview diagrams focus on the overview of the flow of control where the nodes are interactions or interaction uses. The lifelines and the messages do not appear at this overview level. Timing diagrams are used to show interactions when a primary purpose of the diagram is to reason about time.
Timing diagrams are used to show interactions when a primary purpose of the diagram is to reason about time. They focus on conditions changing within and among lifelines along a linear time axis.
Each UML diagram has a contents area. As an option, some diagrams may also have a frame (shown as rectangle) with frame heading. The frame could be used in the cases when the diagrammed element has some owned elements that are attached to the border, like ports for classes and components, and entry/exit points on state machines.
The heading of a frame represents the kind, name, and parameters of the element owning or namespace enclosing the elements represented in the contents area.
frame-heading ::= [ element-kind ] element-name [ parameters ] element-kind ::= short-element-kind | long-element-kind
The following UML elements and namespaces could have frames:
Table 1.1. UML elements that can have frames
| Short kind | Long kind - owning element or enclosing namespace |
|---|---|
| act | activity |
| class | class |
| cmp | component |
| dep | deployment |
| sd | interaction |
| pkg | package |
| stm | state machine |
| uc | use case |
Note
It is a common mistake to assume that frame kind specifies type of the depicted UML diagram. In fact, type of the diagram is defined by the primary graphical elements shown in the contents area of the diagram. Frame kind is kind of the UML element owning or namespace enclosing the elements shown in the frame contents area. For instance, an activity, sequence or state machine diagram belonging to a use case (i.e., providing more details on it) can still be of a use case type.
UML diagrams are mostly useful if they express something in a higher level of abstraction than the code. Writing UML just for the sake of writing UML becomes unneeded bureaucracy and makes the project and the code less adaptable to changes with no benefit whatsoever. For example, a UML class diagram showing all the classes on a package, with all their attributes and methods—something that can be easily auto-generated—provides no value at all: it is at the same level of abstraction than the code. Plus, the code will most surely be a better source for that information because it will always be up to date, and it will probably be documented and organized in a way that is easier to know which methods/attributes/things are more important. On the other hand, if you have concepts of a higher level of abstraction than what can be expressed on the code, documenting those on a diagram is a good idea. For example, a diagram showing the higher level abstract modules on a complex system, with their dependencies and maybe a little description of their responsibilities and what package/namespace they map to in the source code can be a really useful for a new team member that needs to be introduced to the project, or can also be used to figure out where a new class/functionality should be thrown. Another example of a useful diagram could be a sequence diagram showing the high-level steps to be taken in a communication protocol. Maybe each step of those have it's little quirks and complexities, but it is probably enough to describe them in the code itself. The higher level diagram can help a programmer to understand the "big picture" of things easily without needing to worry about the complexities of each interaction. Anyway, those are just some examples; there are lots of cases where a simple diagram can be of a lot of help. Just remember that you should be doing them only when you cannot express something in the code itself. If you find yourself using UML diagrams to explain the source code itself, make the source code more self-documenting instead. Finally, some of the general rules that apply to code can also apply to diagrams: avoid repeating yourself, keep it simple, don't fear of changing things (just because something is documented on a UML diagram does not mean it cannot be changed) and always think of who will be reading/maintaining those diagrams in the future (probably your future-self) when writing them.
Important
It is not our goal to introduce the details of all diagram types of UML 2.x to the reader. It is the case study which drives which UML diagram types will be used: those that are needed to model our sample application. However, we will deal with the majority of diagram types (at a different level of detail), even if it is important to underline that not all diagram types are equally important. We use some of them much more frequently than others, that is the reason why particular importance will be given to Use case diagrams, Class diagrams and Sequence diagrams. Different application types might require the use of different diagram types.