Conceptual Model of the UML

To understand the UML, we need to form a conceptual model of the language, and this requires learning three major elements: 1) UML's basic building blocks, 2) The rules that tell us how these building blocks may be put together and 3) Some common mechanisms that apply throughout the UML.

Building Blocks of UML

The vocabulary of the UML consists of three kinds of building blocks:

1. Things
2. Relationships
3. Diagrams

Things are the abstractions that are first-class citizens in a model; relationships tie these things together and diagrams group interesting collections of things.

Things in UML

There are four kinds of things in UML:

1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things

These things are the basic object-oriented building blocks of the UML. We use them to write well-formed models.

Structural Things

Structural things are the nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. In all, there are seven kinds of structural things:

First, a class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically a class is rendered as a rectangle, usually including its name, attributes and operations as shown below:

Second, an interface is a collection of operations that specify a service of a class or component. An interface therefore describes the externally visible behavior of that element. Graphically, an interface is rendered as a circle together with its name. An interface is typically attached to the class or component that realizes that interface.

Third, a collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements. Therefore, collaborations have structural as well as behavioral dimensions. Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name as shown below:

Fourth, a use case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor. A use case is used to structure the behavioral things in a model. A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name as shown below:

Fifth, an active class is a class whose object own one or more processes or threads and therefore can initiate control activity. An active class is just like a class except its objects represent elements whose behavior is concurrent with other elements. Graphically, an active class is rendered just like a class, but with thick lines, usually including its name, attributes and operations as shown below:

Sixth,a component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Generally, a component is rendered as a rectangle with tabs, usually including its name as shown below:

Seventh, a node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. Graphically, a node is rendered as a cube, usually including only its name as shown below:

Behavioral Things

Behavioral things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. In all, there are two primary kinds of behavioral things.

First, an interaction is a behavior contains a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. An interaction involves messages, action sequences and links. Graphically, a message is rendered as a directed line, almost always including the name of its operation as shown below:

Second, a state machine is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events. A state machine involves other elements like states, transitions, events and activities. Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates as shown below:

Grouping Things

Grouping things are the organized parts of UML models. These are the boxes into which a model can be decomposed. In all, there is one primary kind of grouping thing, namely, packages.

A package is general purpose mechanism for organizing elements into groups. Structural things, behavioral things and even other things may be placed in a package. Graphically, a package is rendered as a tabbed folder, usually including only its name and sometimes, its contents as shown below:

Annotational Things

Annotational things are the explanatory parts of UML models. These are the comments we may apply to describe, illuminate and remark about any element in a model. There is one primary kind of annotational thing, called a note. Graphically a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment as shown below:

Relationships in UML

There are four kinds of relationships in UML:

1.       Dependency

2.       Association

3.       Generalization

4.       Realization

These relationships are the basic relational building blocks of the UML. We use them to write well-formed models.

First, a dependency is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing. Graphically, a dependency is rendered as a dashed line, possibly directed and occasionally including a label as shown below:

Second, an association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts. Graphically, an association is rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments such as multiplicity and role names as shown below:

Third, a generalization is a specialization/generalization relationship in which objects of the specialized element (child) are substitutable for objects of the generalized element (parent). Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent as shown below:

Fourth, a realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship as shown below:

Diagrams in UML

A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of things and relationships. We draw diagrams to visualize a system from different perspectives. So, a diagram is a projection into a system. In theory, a diagram may contain any combination of things and relationships. In practice, however a small number of common combinations arise, which are consistent with the five most useful views that make up the architecture of a software-intensive system. For this reason, UML includes nine such diagrams:

1.       Class diagram

2.       Object diagram

3.       Use case diagram

4.       Sequence diagram

5.       Collaboration diagram

6.       Statechart diagram

7.       Activity diagram

8.       Component diagram

9.       Deployment diagram

A class diagram shows a set of classes, interfaces, collaborations and their relationships. These diagrams are the most common diagrams found in modeling the object-oriented systems. Class diagrams address the static design view of a system. Class diagrams that include active classes address the static process view of a system.

An object diagram shows a set of objects and their relationships. Object diagrams represent static snapshots of instances of the things found in class diagrams. These diagrams address the static design view or static process view of a system as do class diagrams.

A use case diagram shows a set of use cases and actors and their relationships. Use case diagrams address the static use case view of a system. Theses diagrams are especially important in organizing and modeling the behaviors of a system.

Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams. Interaction diagrams address the dynamic view of a system. A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages. A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages.

A statechart diagram shows a state machine, consisting of states, transitions, events and activities. Statechart diagrams address the dynamic view of a system.

An activity diagram is a special kind of statechart diagram that shows the flow from activity to activity within a system. Activity diagrams address the dynamic view of a system. They are especially important in modeling the function of a system and emphasize the flow of control among objects.

A component diagram shows the organizations and dependencies among a set of components. Component diagrams address the static implementation view of a system.

A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of architecture. They are related to component diagrams in that a node typically encloses one or more components.

Rules of UML

The UML’s building blocks can’t simply be thrown together in a random fashion. Like any other language, UML has a number of rules that specify what a well-formed model should look like. A well-formed model is one that is semantically self-consistent and in harmony with all its related models.

The UML has semantic rules for:

 

Models built during the development of a software-intensive system tend to evolve and may be viewed by many stakeholders in different ways and at different times. For this reason, it is common for the development team to not only build models that are well-formed, but also to build models that are:

 

These less-than-well-formed models are unavoidable as the details of a system unfold during the software development life cycle.

Common Mechanisms in UML

UML is made simpler by the presence of four common mechanisms that apply consistently throughout the language:

1.       Specifications

2.       Adornments

3.       Common divisions

4.       Extensibility mechanisms

Specifications

The UML is more than just a graphical language. Rather, behind every part of its graphical notation there is a specification that provides a textual statement of syntax and semantics of that building block. For example, behind a class icon is a specification that provides the full set of attributes, operations and behaviors that the class embodies. We use the UML’s graphical notation to visualize the system. We use UML’s specification to state the system’s details.

Adornments

Most elements in the UML have a unique and direct graphical notation that provides a visual representation of the most important aspects of the element. For example, the notation for a class is intentionally designed to be easy to draw, because classes are the most common element found in modeling object-oriented systems.

A class’s specification may include other details, such as whether it is abstract or the visibility of its attributes and operations. Many of these details can be rendered as graphical or textual adornments to the class’s basic rectangular notation. The below figure shows a class, adorned to indicate that it is an abstract class with two public, one protected and one private operation:

Common Divisions

In modeling object-oriented systems, the world often gets divided in at least a couple of ways. First, there is division of class and object. A class is an abstraction and an object is one concrete manifestation of that abstraction. In UML, we can model classes as well as objects, as shown below:

 

In the above figure, there is one class, named customer, together with three objects: Jan, :Customer and Elyse.

Second, there is separation of interface and implementation. An interface declares a contract, and an implementation represents one concrete realization of that contract. In UML, you can model both interfaces and their implementations as shown below:

In the above figure, there is one component named spellingwizard.dll that implements two interfaces, IUnknown and ISpelling.

Extensibility Mechanisms

The UML provides a standard language for writing software blueprints, but it is not possible for one closed language to ever be enough to express all possible nuances of all models across all domains across all time. For this reason, UML is opened-ended, making it possible for us to extend the language in controlled ways. UML’s extensibility mechanisms include:

·         Stereotypes

·         Tagged values

·         Constraints

A stereotype extends the vocabulary of the UML, allowing us to create new kinds of building blocks that are derived from existing ones but that are specific to our problem. For example, if we are working in a programming language, such as Java or C++, we will often want to model exceptions. In these languages, exceptions are just classes, although they are treated in very special ways.

A tagged value extends the properties of a UML building block, allowing us to create new information in that element’s specification. For example, if we are working on a shrink-wrapped product that undergoes many releases over time, we often want to track the version and author of certain critical abstractions. Version and author are not primitive concepts in UML. They can be added to any building block, such as a class, by introducing new tagged values to that building block as shown in the figure below:

A constraint extends the semantics of a UML building block, allowing you to add new rules or modify existing ones. For example, you might want to constrain the EventQueue class so that all additions are done in order. Below figure shows that you can add a constraint that explicitly marks these for the operation add.

Collectively, these three extensibility mechanisms allow you to shape and grow UML to our project’s needs.

More Resources:
http://www.cs.uah.edu/~rcoleman/Common/SoftwareEng/UML.html