1|Page

The Unified Modeling Language (UML) is a consolidation of the practices that have been
established over the years in the use of modeling languages. UML enables us to present the
widely varying aspects of a software system (e.g., requirements, data structures, data flows, and
information flows) within a single framework using object-oriented concepts. Before we venture
too deeply into UML, however, we will first explain why modeling is an indispensable part of
software development.

UML can be used consistently across the entire software development process. At all stages of
development, the same language concepts can be used in the same notation. Thus, a model can
be refined in stages. There is no need for a model to be translated into another modeling
language. This enables an iterative and incremental software development process. UML is well-
suited for various application areas with different requirements regarding complexity, data
volume, real time, etc.

Imagine that you want to develop a software system that a customer has ordered from you. One
of the first challenges you are confronted with is clarifying what the customer actually wants and
whether you have understood the customer’s exact requirements for the prospective system. This
first step is already critical for the success or failure of your project. The question is, how do you
communicate with your customer? Natural language is not necessarily a good choice as it is
imprecise and ambiguous. Misunderstandings can easily arise and there is a very great risk that
people with different backgrounds (e.g., a computer scientist and a business manager) will talk at
cross-purposes, which can have serious consequences. What you need is to be able to create a
model for your software. This model highlights the important aspects of the software in a clear
form

CLASS: In many object-oriented approaches, it is possible to define classes that describe the
attributes and the behavior of a set of objects (the instances of a class) abstractly and thus group
common features of objects. For example, people have a name, an address, and a social security
number. In a nutshell, a class it is a template for creating objects as well as representing objects
initial state ( attributes), behaviors (or methods).

Courses have a unique identifier, a title, and a description. Lecture halls have a name as well as a
location, etc. A class also defines a set of permitted operations that can be applied to the
instances of the class. For example, you can reserve a lecture hall for a certain date, a student
can register for an exam, etc. In this way, classes describe the behavior of objects.

OBJECT: The instances of a class are referred to as its objects. For example, lh1, the Lecture
Hall 1 of the Department of Computer Science, FCAH&PT, is a concrete instance of the class
LectureHall. In particular, an object is distinguished by the fact that it has its own identity, that
is, different instances of a class can be uniquely identified.

DIAGRAMS
2|Page

A model is represented graphically in the form of diagrams. A Diagram diagram provides a view
of that part of reality described by the model. There are diagrams that express which users use
which functionality and diagrams that show the structure of the system but without specifying
a concrete implementation. However, UML offers 14 diagrams that describe either the structure
or the behavior of a system.

STRUCTURE DIAGRAMS
UML offers seven types of diagrams for modeling the structure of a system from different
perspectives.
CLASS DIAGRAM: Central modeling technique use all object- oriented methods to represent
objects. describe the different types of objects in a system and the different kinds of static
relationships among them. It illustrates the structure of the system by describing classes,
attributes, methods and relationships between them.

OBJECT DIAGRAM: Based on the definitions of the related class diagram, an object shows a
concrete snapshot of the system state at a specific execution time. For example, an object
diagram could show that a professor Henry Foster (henryFoster) teaches the courses Object-
Oriented Modeling (oom) and Object-Oriented Programming (oop).

THE PACKAGE DIAGRAM: groups diagrams or model elements according to common

properties, such as functional cohesion. For example, in a university administration system, you
could introduce packages that contain information about the teaching, the research, and the
administrative aspects. Packages are often integrated in other diagrams rather than being
shown in separate diagrams.
3|Page

THE COMPONENT DIAGRAM: UML pays homage to component-oriented software

development by offering component diagrams. A component is an independent, executable unit
that provides other components with services or uses the services of other components. UML
does not prescribe any strict separation between object-oriented and component-oriented
concepts. Indeed, these concepts may be combined in any way required. When specifying a
component, you can model two views explicitly: the external view (black box view), which
represents the specification of the component, and the internal view (white box view), which
defines the implementation of the component.

THE COMPOSITION STRUCTURE DIAGRAM: allows a hierarchical decomposition of the

parts of the system. You can therefore use a composition structure diagram to describe the
internal structure of classes or components in detail. This enables you to achieve a higher level of
detail than, for example, in a class diagram because the modeling is context-specific. You can
specify details of the internal structure that are valid precisely for the context under
consideration.

DEPLOYMENT DIAGRAM.: The hardware topology used and the runtime system assigned
can be represented by the deployment diagram. The hardware encompasses processing units in
the form of nodes as well as communication relationships between the nodes. A runtime system
contains artifacts that are deployed to the nodes.

THE PROFILE DIAGRAM: Using profiles, you can extend UML to introduce domain-
specific concepts. The actual core of the language definition of UML, the metamodel, remains
unchanged. You can thus reuse modeling tools without having to make adjustments. For
example, you can use profiles to introduce the concept of Java Enterprise Beans.

BEHAVIOR DIAGRAMS

With the behavior diagrams, UML offers the infrastructure that enables you to define behavior
in detail. Behavior refers to the direct consequences of an action of at least one object. It affects
how the states of objects change over time. Behavior can either be specified through the actions
of a single object or result from interactions between multiple objects.

THE USE CASE DIAGRAM

UML offers the use case diagram to enable you to define the requirements that a system must
fulfill. This diagram describes which users use which functionalities of the system but does not
address specific details of the implementation. The units of functionality that the system provides
for its users are called use cases. In a FCAH&PT administration system, for example, the
functionality Registration would be a use case used by students.

THE STATE MACHINE DIAGRAM

Within their life cycle, objects go through different states. For example, State machine diagram
a person is in the state logged out when first visiting a website. The state changes to logged in
after the person successfully entered username and password (event login). As soon as the person
logs out (event logout), the person returns to the state logged out. This behavior can be
represented in UML using the state machine diagram. This diagram describes the permissible
4|Page

behavior of an object in the form of possible states and state transitions triggered by various
events.

THE ACTIVITY DIAGRAM

Activity diagram You can model processes of any kind using activity diagrams: both business
processes and software processes. For example, an activity diagram can show which actions are
necessary for a student to participate in a lecture and an assignment. Activity diagrams offer
control flow mechanisms as well as data flow mechanisms that coordinate the actions that make
up an activity, that is, a process.

THE SEQUENCE DIAGRAM

Sequence diagram The sequence diagram describes the interactions between objects to fulfill a
specific task, for example, registration for an exam in a university administration system. The
focus is on the chronological order of the messages exchanged between the interaction partners.
Various constructs for controlling the chronological order of the messages as well as concepts for
modularization allow you to model complex interactions.

THE COMMUNICATION DIAGRAM

Communication diagram Similarly to the sequence diagram, the communication diagram

describes the communication between different objects. Here, the focus is on the communication
relationships between the interaction partners rather than on the chronological order of the
Message exchange. Complex control structures are not available. This diagram clearly shows
who interacts with whom.

THE TIMING DIAGRAM

Timing diagram The timing diagram explicitly shows the state changes of the interaction
partners that can occur due to time events or as a result of the exchange of messages. For
example, a person is in the state logged in as soon as the message is received from the university
administration system that the password sent is valid.

THE INTERACTION OVERVIEW DIAGRAM

The interaction overview diagram models the connection between different interaction processes
by setting individual interaction diagrams (i.e., sequence diagram, communication diagram,
timing diagram, and other interaction overview diagrams) in a time-based and causal sequence.
It also specifies conditions under which interaction processes are permitted to take place. To
model the control flow, concepts from the activity diagram are used. For example, a user of the
university administration system must first log in (which already represents a separate interaction
with the system) before being allowed to use further functionalities.