Lesson No.

1
Unitied
Modeling
Language

Contents

1. The software development challenge. . . . . . . . . . . . . . . . . . 3

2. A brief history of OOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. A review of existing methodologies. . . . . . . . . . . . . . . . . . . 7
4.1. The methodology of procedure-oriented programming. . . . . 7
4.2. The methodology of object-oriented programming. . . . . . . . 12
4.3. The methodology of object-oriented analysis and design. . . 15
4.4. The methodology of system analysis and system modeling. .19
5. Classes and objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. A diagram excursus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1. Entity-Relationship Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Structured Analysis and Design Technique Diagrams. . . . . . 34
6.3. Data Flow Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7. History of the UML language. . . . . . . . . . . . . . . . . . . . . . . 45
 Lesson 1

1. The software
development challenge
Today, the complexity of developing systems has considerably
increased.
The demonstration of such complexity is not only displayed
in upsizing and functionality growth. User needs and extension
of the requirements for system quality cause not less problems,
if not more of them.
Traditional ways of resolution of the complexity problem
such as extension of development teams, specialization, and
work distribution lead to even more difficulties with reconciling
the results and ready systems integration.
A major step towards victory over the complexity was
the appearance of object-oriented programing (OOP). But
it was only a step. The appearance of OOP did not resolve
the problem of insufficient mutual understanding between
developers and users, ineffective development management
in terms of changing requirements, uncontrollability of the
changes in the course of work, subjectivity in the assessment
of the quality of the developing products, etc.

3
STEP Computer Academy

2. A brief history of OOP

First, computer codes and then assembly language were
used to create software on the first computers. However, this
language does not meet today’s standards. With the increasing
complexity of software, it has turned out that developers are
not able to remember all the information required to debug
and enhance their programs. What values are stored in the
register? Is there a variable with the same name? What variables
must be initialized before passing control to the next code?
These problems have been partly solved by means of the
first high-level languages: Fortran, Cobol, and Algol. However,
the software complexity of programs kept growing, and there
were projects where no one of developers could keep all details
in mind. Programmers teamed up to work on such projects.
Significant interrelation of the software parts prevents from
creating software by kind of the design of material objects. For
example, building, car and electrical appliances are usually
assembled from ready-made components, which do not require
development from scratch. Software reuse is the goal, which
is constantly strived to but is rarely achieved. It is difficult to
extract independent fragments from a software system. OOP
has been designed to make this task easy.

4
 Lesson 1

3. Basic concepts
In itself the use of object-oriented language does not force
programmer to write object-oriented programs, though it
simplifies their development. To take the advantage of OOP,
problems must be solved in a different way than it is common
in traditional programming.
The next statement applied to natural languages is well-
known: the language that expresses the idea directs thinking.
As well as for the computer languages, it is valid for natural
languages: the language directs the thoughts, but does not
prescribe them.
In much the same way, an object-oriented engineering does
not supply programmer with a new computing power that
would allow to solve the problems beyond the reach of other
means. The object-oriented approach simplifies the task and
reorganizes it into a more natural form. This allows experts
to handle the problem in a way that fosters the management
of large software systems.
OOP is often called a new programming paradigm.
Programming paradigm is a way of conceptualizing, which
defines how to carry out calculations and how the work done
by the computer should be structured and organized.
The process of dividing tasks into separate, structurally
related, parts is called decomposition. Algorithms and data
structures processed by them are allocated for the problem
in the procedural decomposition; the rules, which connect
certain concepts, are allocated in the logic decomposition.

5
STEP Computer Academy

In the object-oriented decomposition, classes and methods

of interaction of the objects of these classes with each another
are allocated in the problem.
The main way to deal with the complexity of software is
abstraction, i.e. the ability to separate logical sense of a software
fragment from the problem of its implementation.
Abstraction is an allocating of such essential object attributes
that distinguish the object from all other kinds of objects; thus,
features of this certain object are clearly defined in terms of
its further consideration. Abstraction allows to separate the
most significant features of the behavior from the inessential
features. Abstraction determines the essential characteristics
of an object that distinguish it from all other kinds of objects
and clearly outlines the conceptual boundaries of the object
from the observer’s point of view.
Modularity is an enhanced method for creating and managing
collections of names and associated values. The gist of the
module lies in breaking the name space into two parts: an open
(public) part is accessible from the outside; a closed (private)
part is available only within the module.
Hierarchy is a ranked (ordered) system of abstractions.

6
 Lesson 1

4. A review of existing
methodologies
4.1. The methodology
of procedure-oriented programming
The appearance of the first electronic computers marked a new
stage in the development of computing technology. It seemed
enough to develop a sequence of elementary operations, each
of which would be converted into instructions understandable
to computer, and any computational problem could be solved.
The idea proved to be so viable that dominated the whole
process of software development for a long time. Special
programming languages that allowed to transform individual
computing operations into the appropriate code were created.
These languages include Assembler, C, Pascal, and others.
The basis of this methodology of software design is a
procedural or algorithmic organization of the code structure.
It seemed so reasonable for solving computational problems
that no one doubted the expedience of such approach.
The initial concept of this methodology is the concept of
the algorithm, which, in general, means a requirement to
perform a specified sequence of actions aimed at achieving a
certain goal or solution of the given problem.
It is commonly thought that the term «algorithm» was
named after the medieval mathematician Al-Khwarizmi, who
described the rules of performing arithmetic operations in the
decimal system in 825

7
STEP Computer Academy

The whole history of mathematics is closely related to the

development of various algorithms for solving urgent problems
of the corresponding era. Moreover, the very notion of algorithm
has become the subject of an appropriate theory — the theory of
algorithms, which studies the general properties of algorithms.
With time, the content of this theory became so abstract that
only specialists could understand the corresponding results.
Therefore, all programming languages were called algorithmic for
a while, and the first graphical tool for documenting programs
was called algorithm flowchart.
Practical requirements did not always require identification
of the computability of specific functions or decidability of
certain tasks. A new concept of the procedure originated
and consolidated in the programming languages. The notion
specified the general concept of the algorithm applied to the
problem solving on computers. As well as the algorithm, the
procedure is a complete sequence of actions or operations
aimed at solving certain tasks. A special phrase, which was
called a procedure, appeared in the programming languages.
With time, the large software development has become a
serious problem and required partition. Procedural decomposition
is a basis for the partition; in so doing, separate parts of the
program or modules present a set of procedures for the solving
of a certain set of tasks. The main feature of the procedural
programming is that the program always has a time start, or
initial procedure and end. The entire program can be visually
represented as a directed sequence of graphics primitives or
blocks.

8
 Lesson 1

Start

Data input

Data handling

Calculation

Function call

End

A graphical representation of the program in sequential procedures

9
STEP Computer Academy

An important characteristic of these programs is the necessity

to complete all actions of the preceding procedure for the start
of the actions of the subsequent procedure. Changing the order
of execution of these actions even within a single procedure
required inclusion of special conditional statements if-else and
goto in the programming languages .It was done to implement
branch resolution of the computational process, depending on
the intermediate results of the problem solving.
The appearance and intensive use of the conditional statements
and imperative go-to statement was the subject of raucous
debate among programmers. The point is that the uncontrolled
use of the imperative go-to statement in the program could
seriously complicate the understanding of the code. The relevant
programs were compared with spaghetti, referring to numerous
transitions from one program segment to another or — that
is even worse — the return from the terminal statements of
the program to its initial statements. The situation seemed so
dramatic that it was even suggested to exclude the statement goto
from the programming languages. Since that time, programming
without using goto has been considered a good style.
The above-mentioned ideas have contributed the formation
of a certain frame of reference in the field of programming and
writing software code, which has been called the structured
programming methodology.
The basis of this methodology is a procedural decomposition
of software system and organization of individual modules as a
set of the performed procedures. Under this methodology, the
top-down design has been developed. The period of the greatest
popularity of the ideas of the structured programming was in
the end of 1970s — beginning of 1980s.
10
 Lesson 1

As an auxiliary means of the code structuring, it was

recommended to use indentation in the beginning of each line,
which should allocate nested loops and conditional statements.
It is intended to promote understanding and readability of the
program.
Here is an example of the program in C, illustrating this
feature in writing programs:

#include <iostream>
#include <stdlib.h>
#include <time.h>
using namespace std;
void main()
{
const int n=20;
int Mas[n];
srand(time(0));
for(int i=0;i<n;i++)
{
Mas[i] = rand()%100;
cout<<Mas[i]<<" ";
}
for(int i=0;i<n;i++)
{
bool sort = true;
for(int k=0;k<n-1;k++)
{
if(Mas[k]>Mas[k+1])
{
int n = Mas[k];
Mas[k] = Mas[k+1];
Mas[k+1]=n;
sort=false;
}
}
if(sort==true) break;
}
cout<<endl<<endl;
for(int i=0;i<n;i++)
{
cout<<Mas[i]<<" ";
}
}

11
STEP Computer Academy

During this period, program size was considered the main

indicator of the complexity of programming. The number of
lines in the code was suggested to be an assessment of the
program complexity in a quite serious way. True, there were
some assumptions regarding the syntax of the lines, which
were to meet certain rules. Total laboriousness of the software
development was assessed by means of a special unit — «man-
month» or «man-year». The professionalism of programmer
was directly connected to the number of lines in the code that
he could write and debug, say, for a month.

4.2. The methodology of object-oriented

programming
With time, the things changed greatly. It turned out that
programming labor at early stages was estimated significantly
lower than efforts expended, which caused additional costs and
deadlines of program releasing. In the process of applications
development, users could change their function objectives, which
caused further postponement of the release date. Increasing
the size of the software led to the need to hire more developers,
which, in its turn, required additional resources to organize
their coordinated work.
Quality changes associated with the change of emphasize in
computer use were not less important. Large-scale enterprises,
companies and offices were the main consumers in the era
of «big machines» but then personal computers appeared
to become a universal attribute of small and medium-sized
business.

12
 Lesson 1

Computational and calculated — algorithmic problems

traditionally occupied minor place, while processing and data
handling problems were placed in the forefront.
It became apparent that traditional methods of procedural
programming were able to cope neither with the growing
complexity of programs and their development, nor with
the need to improve their reliability. In the second half of
the 1980s, there was an urgent need for a new programming
methodology, which would be able to solve the whole set of
problems. The object-oriented programming (OOP) has become
this methodology.
The fundamental notions of OOP are the concepts of class
and object. Some abstraction of a set of objects that share a
common set of properties and display the same behavior is
understood under the class. Each object is considered as an
instance of the corresponding class. Objects that do not possess
completely identical properties or the same behavior, cannot
be attributed to the same class by definition.
The basic principles of OOP are inheritance, encapsulation
and polymorphism.
Inheritance is a principle, according to which the knowledge
of the more general category is permitted to apply for a narrow
category.
Encapsulation is a hiding of the individual details of the
internal organization of classes from the objects or users
which are considered external towards it. Encapsulation is
derived from dividing the module into two parts or sections,
the interface and implementation, in some programming
languages. The interface contains all information necessary to
interact with other objects. Implementation hides or disguises
13
STEP Computer Academy

all details that are irrelevant to the process of interaction of

objects from other objects.
Polymorphism is the ability of some objects to take different
external forms, depending on the circumstances. With reference
to the OOP, polymorphism means that actions performed
by methods of the same name can be different depending
on the classes, to which one or another method is applied.
Polymorphism of the object-oriented languages is associated
with function overloading but is not identical to it. It is important
to have in mind that the names of methods and properties
are closely related to the classes, in which they are described.
It provides a certain reliability of the program because it
eliminates random use of a method, which is not intended
to solve extrinsic problems.
The emergence of the object-oriented programming languages
was due to the need to implement the concept of classes and
objects at the syntax level. Inclusion of classes in the well-known
programming languages C and Pascal led to the emergence of
C++ and Object Pascal respectively.
Widespread occurrence of the OOP methodology has
had an impact on the process of software development. In
particular, the procedure-oriented decomposition of software
gave way to the object-oriented decomposition, where classes
and objects with the corresponding properties and methods
became individual structural units instead of procedures and
functions. As a consequence, the program was no longer a
sequence of the actions predefined at the coding stage, and
became an event-driven program. The latter circumstance
has become dominant in the development of a wide range of
advanced applications. In this case, each program is an infinite
14
 Lesson 1

waiting loop for some predefined events. The initiators of the

events may be other programs or users.
The most important circumstance in the development of
the OOP methodology was a realization of the fact that the
process of code writing could be separated from the process
of the program structure designing. Indeed, before developer
starts programming classes, their properties and methods,
he needs to determine what these classes are. Moreover, it is
necessary to establish the interrelation between the classes
as well as to answer the following questions: how many and
what classes need to be determined for the task solving, what
properties and methods are needed to give the desired behavior
to the classes.
This set of problems is not so only associated with the code
writing but with a general analysis of the requirements for
the future program, as well as with the analysis of a specific
domain, for which the program is developed. All these factors
have led to a special methodology of object-oriented analysis
and design (OOAD).

4.3. The methodology of object-oriented

analysis and design
The need for the analysis of the domain before writing the
program was recognized in the time of development of large-
scale projects a long time ago.
Allocation of initial or base components of the domain
required for the solution of different problems is a non-trivial
issue. The complexity of the issue manifests itself in the informal
nature of the procedures or rules that may be used for this
purpose. Moreover, such work must be carried out together

15
STEP Computer Academy

with the specialists or experts who are familiarly acquainted

with the domain.
Several methods and rules were proposed for extraction or
identification of the components of the domain. This process
itself was called conceptualization of the domain. Thus, some
abstract unit that possesses functionality, i.e. can perform
certain actions associated with the given problems, is called
a component.
On the one hand, the appearance of the methodology OOAD
required the development of various means of the domain
conceptualization; on the other hand, it required the professionals
who mastered this methodology. At that point, a relatively
new type of specialist called the analyst or architect appeared.
Along with the experts in the domain, analyst is involved in the
construction of the conceptual schema of the future program,
which is further encoded by programmers. The individual
components are chosen in such a way so to be represented
as classes and objects in the subsequent development. In this
case, the language, which represents the information about the
conceptual schema of the domain, is of no small importance.
The division of the process of the development of complex
software applications into separate phases contributed to the
formation of the concept of the software life cycle.
The software life cycle (LC) is understood as a set of interrelated
and time-related stages, starting from developing requirements
to the software and ending with a disposal to use it.

16
 Lesson 1

According to the accepted views, software life cycle consists

of the following phases:
■■ analysis of the domain and formulation of the software
requirements
■■ program design
■■ software code implementation
■■ software implementation
■■ software maintenance
■■ disposal
At the phase of the domain analysis of the formulation of
requirements, a determination of functions to be performed by
the developing software is realized, as well as the conceptualization
of the domain. This work is done by the analysts in collaboration
with the experts in the domain. Some conceptual diagram
containing the description of the main components and the
functions they are to perform must be presented as a result.
Program design phase lies in the development of a detailed
scheme of the future software, which specifies the classes, their
properties and methods, as well as various relations between them.
As a rule, analysts, architects and individual skilled programmers
participate in the process at this stage. The result of this phase
presupposes a detailed software diagram of the program, which
lists all the classes and the relations between them in the operation
of the software. According to the methodology OOAD, this
scheme should serve as a source of information for the code.
The result of the programming phase is a software application,
which obtains the required functionality and is able to solve the
required tasks in a particular domain.

17
STEP Computer Academy

Phases of implementation and maintenance of the software are

associated with the need to set up and configure the programming
environment, as well as with the rectification of the errors
occurred in the course of its use. Sometimes program testing is
meant a separate phase, which refers to software sanity check for
a certain set of input data or some special modes of operation.
The result of these phases is increasing software reliability, which
excludes critical situations or damaging the company, which
uses the application.
The methodology OOAD is closely connected to the concept
of automated software engineering (Computer Aided Software
Engineering, CASE). The appearance of early CASE tools was
met with certain alertness. Eventually, both rave reviews and
critical appraisal of their capabilities emerged. There were a few
reasons for such conflicting views. The first reason was that early
CASE tools were simple an add-in for a database management
system. Although the visualization of the process of development
of a database conceptual schema is of great importance, it does
not solve problems related to the development of applications
of other types.
The second reason is more complex as it is connected with
graphic notation, implemented in a particular CASE tool. While
programming languages had a narrow syntax, the attempts
to offer the appropriate syntax for the visual presentation of
the conceptual DB schemes were taken quite ambiguously.
Against this background, the emergence of the Unified Modeling
Language (UML) focused on the tasks of the first two phases of
the software life cycle was taken with great optimism.

18
 Lesson 1

4.4. The methodology of system analysis and

system modeling
System analysis as a scientific discipline has a longer history
than OOP and OOAD, as well as its own domain. The main
concept of the system analysis is the concept of the system,
which is understood as a collection of objects, components
or elements of any kind, which form certain integrity. The
defining pre-requisite for selection of a certain set as a system
is the emergence of its new properties, which its constituent
elements do not obtain. There can be a lot of examples of
different systems: personal computer, car, man, biosphere,
software, etc.
The most important characteristics of any system are its
structure and the process of functioning. The structure of a
system is a time-steady set of relations between its elements or
components. The system links together all elements and prevents
the system from collapsing into individual components. The
system structure may reflect a variety of relations, including
nested elements of one system in another system. In this case,
a small or embedded system is known as a subsystem, while
the larger one is called a metasystem.
The process of the system functioning is closely connected to
the change of its properties or temporal behavior. This important
feature of the system is its condition, which is defined as a set
of properties or attributes that represent the most significant
features of the system behavior at any given time.

19
STEP Computer Academy

The process of the system functioning reflects the temporal

behavior of the system and can be presented as a consistent
change of its conditions. If the system changes its condition
to another one, it is said that the system moves from one
condition to another. The set of characteristics or system
modifier conditions is called transition.
The methodology of system analysis is the conceptual basis
of the system-oriented decomposition of the domain. In this
case, the initial components of the conceptualization are
systems and the relations between them. The concept of the
system is more general than the concept of classes and objects
in OOAD. The result of the system analysis is a construction
of a model of the system or domain.
The importance of the construction of those models lies in
the ability to use them in order to obtain information about
the properties or the behavior of the original system. The
process of construction and subsequent use of the models in
order to obtain information about the original system is called
modeling. The most common model of the system is a so-called
model «black box». In this case, the system is represented in
the form of a rectangle, which internal structure is hidden
from the analyst or unknown. However, the system is not
completely isolated from the environment, since the latter has
some informational or material impact on the system. Such
effects are called input actions. In its turn, the system also has
certain informational or material impact on the environment
or other systems, which is called an output action. Graphically,
this model can be depicted as follows:

20
 Lesson 1

e
input actions n
t
SYSTEM e output actions
r x
a i
n t
c
e

The value of the models, similar to the model «black box», is

very relative. However, the general model of the system contains
some important information about functional characteristics
of the system, which give a notion of its behavior. Indeed, we
cannot obtain any other information except for the common
information about what effects the system reacts to and how
this reaction is shown as regards to the surrounding objects
and systems.
The process of the development of appropriate models and
their subsequent constructive use requires not only knowledge
of the methodology of system analysis but the availability of
corresponding graphic means or languages to fix the results
of modeling and document them. It is obviously that natural
language does not fit well for this purpose because it is ambiguous
and vague. Rather serious theoretical methods based on the
development of mathematical and logical modeling tools
have been developed for the construction of the models, as
well as various problem-specific formal and graphic notations
offered. It is important to understand that unification of any
modeling language is closely related to the methodology of
system modeling.

21
STEP Computer Academy

The complexity of the system and its model accordingly

can be viewed from different perspectives. First, one can
highlight the complexity of the structure of the system, which
is characterized by a number of system elements and different
types of interrelations between these elements. The second
aspect of the complexity is a complexity of the process of system
functioning. It may be due to the unpredictable behavior of
the system or with the inability of the formal representation
of the rules on conversion of input actions into output actions.

22
 Lesson 1

5. Classes and objects

«Object is a specific identifiable item, component or entity
(real or abstract), possessing an important functionality in a
given domain» (Smith, Tockey).
By definition, we call object a concept, abstraction, or any
item with clearly defined boundaries, which makes sense in
the context of the applied problem. Introduction of objects
pursues two aims:
■■ understanding the applied problem;
■■ introduction of a framework for implementation on the
computer.
An object obtains condition, behavior and identity. Objects
exist in time; they can change and have their own internal
condition. Objects are transient and can be created, destroyed
and divided.
The structure and behavior of similar objects determine a
class, which is general for them.
The condition of the object is characterized by a list of all
possible (usually static) properties of the given object and the
current values (usually dynamic) of each of these properties.
The behavior is determined by the sequence of actions
performed with the object.
Action of the object or is imposed by other objects in terms
of changing their condition and sending messages characterizes
behavior.
Combining objects in classes allows to enter an abstraction
in the task and to consider it in more general formulation.
The class has a name that applies to all objects of that class.
23
STEP Computer Academy

Additionally, attribute names are entered in the class, and

the attributes are defined for objects. In this regard, the class
definition is similar to the description of the type of the structure
(record); and each object has the same meaning as the instance
of the structure (variable or constant of the appropriate type).
Attribute is a value representing an object in its class. Examples
of attributes.
Among the attributes, there are permanent attributes
(constants) and variable attributes. Permanent attributes
characterize the object in its class (for example, account number,
category, person’s name, etc.). The current value of the variable
attributes characterizes the current state of the object (for
example, account balance, age of the person, etc.); changing
the values of these attributes, we change the condition of the
object.

Object Operations
Operation is a function (or conversion), which can be
applied to the objects of a given class.
All objects in this class use the same instance of each operation
(i.e., increasing the number of objects of a certain class does
not increase the number of the loaded software code). The
object, from which the operation is called, is transmitted to
it as its implicit argument (parameter this).

24
 Lesson 1

In general, the same operation can be applied to objects of

different classes; such operation is called polymorphous because
it can have different shapes for different classes. For example,
objects of classes vector and complex number can be defined
for the operation+; such operation will be polymorphous as
the addition of vectors and addition of complex numbers are
different operations, generally speaking.
Each operation corresponds to a method — the implementation
of this operation for the objects of a given class. Thus, the
operation is a specification of the method, while method is
the implementation of the operation.
Operation (and its implementing methods) is defined by its
signature, which includes types (classes) of all its arguments
and the type (class) of the result (return value), in addition to
the name of the operation. All of the methods that implement
the operation must have the same signature as the operation
implemented.
In the system simulation, it is useful to distinguish the
operations with side effects (these effects are expressed in the
change of object attributes, i.e. its condition changing) and
the operations, which give the desired value without changing
the condition of the object. These latter operations are called
queries.
The values of some attributes of the object can only be
accessed by the operations of this object.
Queries with no arguments (except for implicit argument, i.e.
the object, to which the operation is applied) can be considered
as derived attributes.

25
STEP Computer Academy

Types of the most common operations:

1. Modifier (alters the condition of the object by recording
or access).
2. Selector (gives access to determine the condition of the
object without changing it (read operation).
3. Iterator (accessing to parts of the object in a certain
sequence).
4. Constructor (creation of the object or its initialization).
5. Destructor (destruction of the object or release of the
memory occupied by it).

Object relationships
Data dependency can be set between the objects. These
dependencies express connection or relationships between
the classes of these objects. Relationships between any two
objects are based on their mutual knowledge: what operations
can be performed and what behavior is to expect.
Types of relationships between objects.
1. Communication.
2. Aggregation
With respect to communication objects can perform different
roles:
Actor or active object: the object can influence but is never
imposed (the active object).
Server or performer: is the subject to management by other
objects but is never active.
Agent or broker: performs a role both of actor and server,
it is usually created in the active object’s interests.

26
 Lesson 1

Relationship of the aggregation type is a type of the relation

part-whole (A part-of). It allows to start with a whole (aggregate)
to come to its parts (attributes). Implicitly, aggregation may mean
physical occurrence of one object into another (composition or
structure of the object), but there may be different semantics
as well, such as membership of one object to another.

CLASS
Class is a set of objects related to the generality of structure
and behavior.
As a rule, interface (appearance visible to all and a set of methods
supported) and the implementation of the class (secure interior
device) are distinguished.
To set a class, one must specify the name of the class and then
list its attributes and operations (or methods).
Each object has an associated data structure, which fields are
attributes of the object and function designators (code fragments)
that implement the operations of the object (note that function
designators are usually replaced by references to those functions
as a result of the code optimization). Thus, the object is some data
structure, the type of which corresponds to the class of this object.
Sometimes it is necessary to redefine an operation specified
in one of its superclasses. To do this, the operation, which can be
obtained from the superclass as a result of inheritance, is defined
in the subclass as well; its re-determination «hides» its definition in
the superclass that not inherited but redefined operation is used in
the subclass. Let us recall that each operation is determined by its
signature; hence, the signature of the redefining of the operation
must match the signature of the operation of the superclass, which
is redefined by this operation.
27
STEP Computer Academy

Redefining may pursue one of the following purposes:

■■ expansion: new operation extends the inherited
operation, taking into account the impact of the
subclass attributes;
■■ constraint: the new operation is limited to the
implementation of only a part of actions of the
inherited operation using specifics of the subclass
objects;
■■ optimization: use specifics of the subclass objects allows
to simplify and speed up the corresponding method;
■■ convenience.
The relationship between the classes implemented in the
programming languages:
■■ Association is a notional or semantic relationship
between classes. The relationship is one-to-one, one-to-
many, many-to-many.
■■ Generalization and inheritance reveal the analogy
between different classes of objects and define multi-
level classification of objects. Thus, in the graphic
systems classes that define the delineation of various
geometric figures, such as points, lines (straight lines,
arcs of circles and curves defined by splines), polygons,
circles, etc., can exist.

28
 Lesson 1

Method of implementation is a delegation when the objects

are considered as prototypes (samples), which delegate their
behavior to other objects, limiting the need for new classes. It
implements the ratio of commonality and associativity. There
are simple and multiple inheritances. Abstract classes (do not
obtain implementation of the objects). The most common
class is the base class.
■■ Aggregation is the relationship between the class
of compound objects and classes that represent the
components of these objects (the ratio «whole/ part»).
■■ The ratio of the variety or ratio of the commonality
(classification)
■■ Polymorphism (assignment to several types).
■■ Use. In the implementation of the class, another class
may be used. Example: The line — the point.
■■ Filling. Extra class. Homogeneous classes consist of
objects of the same class and heterogeneous classes
presuppose different objects.
The class, which instances consist of sets of other classes.
Parameterized classes.
Metaclasses (class of classes) treats class as an object.
Relationships between classes and objects.
Classification is the means of regulating of knowledge.
Methods of classification.
The classical categorization. Objects with given property
are of the same class.
The conceptual association. Initially, a conceptual description
is formed, and then categorization (latent symptoms) is done.
The theory of prototypes. The similarity with the prototype
class.
29
STEP Computer Academy

6. A diagram excursus
Under the structural system analysis, the method of study
of the system that begins with the general description followed
by the details of the individual aspects of its behavior and
functioning is commonly used. The general system model is
constructed in the form of a hierarchical structure that reflects
the various levels of abstraction with a limited number of
components at each of the levels. One of the main principles of
the structural system analysis is to identify the most essential
components or elements of the system at each level of abstraction.
In the context of the software engineering, three diagrammatic
notations called diagrams are considered: Entity-Relationship
Diagrams, (ERD), Structured Analysis and Design Technique
(SADT, functional simulation), and Data Flow Diagrams, DFD.

6.1. Entity-Relationship Diagrams

Entity-Relationship diagrams are designed for graphical
representation of data models of the developed software system
and offer a set of standard notations to define the data and the
relationships between them. With this type of diagram, the
individual components of the conceptual data model and a
set of relationships between them, which are essential for the
system being developed, can be described.
The basic concepts of the notation are the concepts of entity
and relationships. Thus, under the entity, an arbitrary set of
real or abstract objects, each of which has the same properties
and characteristics, is understood. In this case, each object
can be considered an instance of one and only one entity; it

30
 Lesson 1

must have a unique name or identifier, and be different from

other instances of a given entity.
Examples of entities can be as follows: bank, bank customer,
customer’s account, airport, passenger, flight, computer, terminal,
car driver. Each of the entities may be treated with varying
degrees of detailing and at different levels of abstraction, which
is determined by the particular approach of the problem. For
a graphical representation of the entity, a special notation is
used:

Independent entity Dependent Аssociated

entity entity

Relationship is defined as the ratio or some association

between individual entities.
Family relationship «father-son» or production relations
«employer — employee» are the examples of relationships.
Another type of relationships is defined by the relations
«to possess» or «to possess a property». Different types of
relationships are shown graphically in the form of a rhombus
with the corresponding name of the relationship

31
STEP Computer Academy

limited relationship unlimited

relationship

Pictorial data model is designed so that the relationship

between the individual entities reflect not only the nature of
the semantic nature of the corresponding relationship but also
additional aspects of the obligation of the relationships, as well
as the ratio of instances of entities involved in the relationships.
Let us consider a simple example of a situation that is
described by two entities: «Employee» and «Company». It
is natural to use employees’ membership in the company
as relationship. We should take into account considerations
that several employees may work in the company, and these
employees cannot be employees of other companies.
This information can be represented graphically in the
following diagram «entity-relationship»:

N 1
employee works in company

In the figure, the letter «N» near the relationships means

that the company can operate more than one employee, while
the value of N is not fixed in advance.

32
 Lesson 1

The number «1» at the other end of the relationship means

that employee can work in only one particular company, i.e.
employees from other companies or organizations are not
allowed to combine jobs.
A slightly different situation is composed if we consider
the entities «employee» and «project», and the relationships
« work on» (meaning the project).

N M
employee works on project

One employee can participate in the development of

several projects, and several employees can participate in
the development of a single project. Thus, this relationship is
multi-valued. This fact is expressly reflected in the diagram
by indicating the letter «N» and «M» near the relevant entities,
where the selection of specific characters is not essential.
The above two diagrams can be combined into one, which
will provide information about all employees involved in the
development of projects in the given company. Additional
relationship, which characterizes the projects of the company,
can be introduced.

33
STEP Computer Academy

N 1
Employee Works in Company

N 1

Works on Develops

M M
Project

The limitation of the diagrams «entity-relationship» is

shown in the specialization of a conceptual model into a more
detailed view of the simulated software system, which must
contain information about the behavior and functioning of its
individual components in addition to the static relationships.
For this purpose, a different type of diagrams called data flow
diagrams is used.

6.2. Structured Analysis and

Design Technique Diagrams
First, the development of structured analysis and design
technique began in the 1960s when Douglass T. Ross introduced
a special modeling technique called SADT (Structured Analysis
& Design Technique). US Air Force used the methodology
SADT as a part of the Integrated Computer Aided Manufacturing,
ICAM and called it IDEF0 (Icam DEFinition). The aim of the
program ICAM was to increase the effectiveness of the computer
technology in the design of new weapons and means of warfare.
The researches resulted in the conclusion that the descriptive
languages were not effective for documentation and modeling

34
 Lesson 1

of the process of the functioning of complex systems. In natural

language, such descriptions do not provide the required level
of consistency and completeness, which have a dominant role
in solving problems of modeling.
Within the ICAM framework, several graphical modeling
languages have been developed:
■■ notation IDEF0 — to document the processes of
production and display the information about the use
of resources at every stage of system design.
■■ notation IDEF1 — to document information on the
production environment of the systems.
■■ notation IDEF2 — to document the temporal behavior
of the system.
■■ notation IDEF3 — especially for business process
modeling.
The notation IDEF2 has never been fully implemented. In
1985, the notation IDEF1 was expanded and renamed IDEFIX.
The methodology IDEF-SADT was applied in government and
commercial organizations because it completely satisfied various
requirements for the modeling of a wide class of systems in
that period of time.
In early 1990, a specially created group of users IDEF (IDEF
User Group), in collaboration with the National Institutes
for Standards and Technology, NIST, attempted to create a
standard for IDEF0 and IDEFIX. This attempt was successful
and resulted in the adoption of the US government standard
known as FIPS for those two technologies IDEF0 and IDEFIX
in 1993. In subsequent years, the standard continued to develop
rapidly and formed the basis for the implementation in some
early CASE tools.
35
STEP Computer Academy

The methodology IDEF-SADT is a set of methods, rules and

procedures intended for the construction of a system functional
model of a certain domain. The functional model SADT shows the
structure of the system operation and its individual subsystems,
i.e., performed actions and relationships between these actions.
For this purpose, special models that allow to visualize the
sequence of specific actions are designed. The initial building
blocks of any model of IDEF0 are an activity and arrows.
Let us consider the basic concepts of the methodology IDEF-
SADT, which are used in the construction of functional modeling
diagrams. The activity is an action or set of actions that have
a concrete purpose and lead to some final result. Sometimes
activity is called a process. The models IDEF0 track the various
activities of the system, their description and the interaction
with other processes. In the diagrams, activity or process are
represented by a rectangle called a block. The arrow is used
to refer to a drive or impact that provides transfer of data or
objects from one activity to another. The arrows are also required
to describe what the activity produces and what resources it
consumes. This so-called role of the arrow — ICOM — is the
abbreviation of the first letters from the names of corresponding
arrows IDEF0.
При этом различают стрелки четырех видов:
■■ I (Input) — input, i.e. everything that enters the process
or is consumed by the process.
■■ C (Control) — control or limitation on the operation of
the process.
■■ O (Output) — output or result of the process.
■■ M (Mechanism) — a mechanism that is used to perform
the process.
36
 Lesson 1

The methodology IDEF0 is uniquely specifies how each type

ICOM of the arrows is depicted on the diagram. The arrow Input
comes out of the left side of the frame of the working field and
enters the left side of the rectangle of the process. The arrow
Control comes in and out from the top. The arrow Output
emerges from the right side of the process and enters the right
side of the frame. The arrow Mechanism enters the bottom of
the rectangle. Thus, a basic understanding of the process in the
diagrams IDEF0 is as follows:

Control

input The process output

(activity)

Mechanism

One of the most important features of the methodology IDEF-

SADT is the gradual introduction of more detailed representations
of the system model as the individual diagrams are being developed.
The model IDEF-SADT construction begins with the presentation of
the entire system as a simple diagram, consisting of a process block
and arrows ICOM, which displays the main types of interaction
with the objects outside the system. Since the initial process
represents the entire system as a whole, this view is the most
common and is subject to further decomposition.

37
STEP Computer Academy

To illustrate the basic ideas of the methodology IDEFSADT,

let us consider the following simple example. We represent
the activities on registration of a bank credit as a process. The
input to this process is the client’s application for a credit, and
the output is the corresponding result, i.e., the credit. Control
factors are the regulations of credit preparation, which regulate
the conditions for obtaining corresponding funds on credit.
The mechanism of this process is an employee of the bank,
which is authorized to perform all operations on preparation
of the credit.

38
 Lesson 1

Credit regulations

Credit Credit
Preparation of credit
application
from client

Bank officer

In the final analysis, the model IDEF-SADT is a series

of hierarchically interrelated diagrams with supporting
documentation that breaks the initial representation of a
complex system into separate parts. The details of each of the
main processes are represented as more detailed processes in
other diagrams. In this case, each diagram of the lower level is a
decomposition of a process from a general diagram. Therefore,
a general diagram is specified for a number of more detailed
diagrams at each step of decomposition.
Currently, the diagrams of the structural system analysis
IDEF-SADT continue to be used for modeling and detailed
analysis of the functional model of existing business processes
on premises by a number of organizations, as well as to develop
new business processes. The main drawback of this methodology
relates to the lack of explicit funds for the object-oriented
representation of complex systems models. Although some
analysts have pointed out the importance of the knowledge and
application of the notation IDEF-SADT, the limited capacity
39
STEP Computer Academy

of the methodology applied to the implementation of the

relevant graphic models in the object-oriented programming
code significantly narrows the range of the problems solved
by means of the notation.

6.3. Data Flow Diagrams

The basis of this methodology of graphic modeling of
information systems is a special technology data flow diagrams
(DFD) plotting.
System model in the context of DFD is represented as some
information model, main components of which are various
data flows that carry information from one subsystem to
another. Each of the subsystems performs certain conversion
of the input data flow, and transmits the results of processing
information in the form of data flows for other subsystems.
The main components of the data flow diagrams are as
follows:
■■ External entities
■■ Processes
■■ Systems / subsystems
■■ Data storage or repository
■■ Data Flows
External entity is a material object or natural person that
may act as a source or data receiver. The definition of an object
or system as an external entity is not strictly fixed. Although
external entity is located outside the boundaries of the given
system, some external entities can be transferred into the
system model diagram in the process of further analysis. On
the other hand, some processes can be placed outside the
diagram and represented as external entities. Examples of
40
 Lesson 1

external entities are the next: clients of organization, customers,

staff and suppliers.
External entity is designated as a rectangle with a shadow,
within which its name is indicated. It is recommended to use
a noun in the nominative case to name it. Sometimes external
entity is also called the terminator.

AAname
nameofofthe
theexternal
externalentity
entity

The process is a set of operations to transform input data

flows into output data flows in accordance with a particular
algorithm or regulation. Although the process can be physically
implemented in various ways, software process implementation
is referred to most often. In the data flow diagram, the process
is depicted as a rectangle with rounded vertexes divided into
three sections or fields by horizontal lines.

a process number field

a process name field

a physical realization process name field

41
STEP Computer Academy

A process number field is used to identify the latter. In

the middle field, the name of the process is indicated. It is
recommended to use a verb in the infinitive form with the
necessary amendments to name the process. The lower field
contains the reference to the method of the physical realization
of the process.
The information model of the system is constructed as
some hierarchical scheme in the form of so-called context
diagram, in which the original model is represented as a series
of subsystems of relevant data conversion processes. In the
context diagram DFD, the subsystem or system is depicted in
the same way as the process: a rectangle with rounded vertexes.

a process number field

a process name field

a name field

Data storage or repository is an abstract device or a method

of storing information that moves between the processes. It is
assumed that data can be placed into the storage at any time and
removed after some time, and the physical methods of placing and
extraction of the data may be arbitrary. The data storage can be
physically implemented in various ways but its implementation is
mostly assumed in electronic form (a drive) on magnetic media.
42
 Lesson 1

In the data flow diagram, the data storage is depicted a as rectangle

with two fields. The first field is used to specify the number or
identifier of the drive that starts with the letter «D». The second
field is used to specify the name. Thus, it is recommended to use a
noun that describes a method of storing the relevant information
as the name for the drive.

A number field A drive name field

Finally, the data flow determines the qualitative character

of the information transmitted through a connection from the
source to the receiver. The actual flow of data can be transmitted
between two computers over the network, or in any other
manner that allows to extract data and then restore them in
the required format. In the diagram DFD, the data flow is
represented by a line with an arrow at one of its ends; the arrow
indicates the direction of data flow. Each data flow has its own
name, reflecting its content. Thus, the system information model
in the notation DFD is constructed in the form of data flow
diagrams that are graphically represented using corresponding
notations. As an example, let us consider a simplified model of
getting a certain amount of cash by bank customer on his credit
card. External entities of the example are client of the bank
and, possibly, a bank employee, who controls the process of
customer servicing. Data storage can be a database of accounts
of individual customers of the bank. Separate data flows reflect
the nature of the transmitted information, necessary for the
customer service. The corresponding model for this example
can be represented as follows:
43
STEP Computer Academy

Data on the Notification on

customer’s credit 1.1 giving the amount
card in cash

Bank Bank
Give the customer the
customer employee
amount of cash

Bank terminal
Amount in cash Service protocol

An inquiry about Data on the

the state of the customer’s current
customer’s current account
account

D1 Account database

Today, data flow diagrams are used in some CASE tools for
building information models of data processing systems. The
main disadvantage of this methodology is also associated with
the lack of explicit funds for the object-oriented representation of
the models of complex systems, as well as for the representation
of complex data processing algorithms.
As in the diagrams DFD, runtime characteristics of individual
processes and data transfer between processes are not indicated,
the model systems implementing synchronous processing of
the data cannot be adequately represented in the notation DFD.
All these features of the methodology of structural analysis
of the system have limited the ability of its wide use and
provided the basis for the inclusion of appropriate resources
in the Unified Modeling Language.

44
 Lesson 1

7. History of the UML language

Some languages of the object-oriented modeling appeared
between the mid-1970s and the end of the 1980s when various
researchers and programmers offered their approaches to OOAD
(the methodology of object-oriented analysis and design). In
the period of 1989-1994, the total number of the best-known
modeling languages increased from 10 to more than 50. Many
users experienced serious difficulties in the choice of the OOAD
language because none of them met all the requirements for the
construction of complex systems models. The adoption of specific
techniques and graphic notations as standards (IDEF0, IDEFIX)
could not change the situation of irreconcilable competition
between them in the early 90s.
By the mid-1990s, some of the methods were significantly
improved; they gained independent importance in solving various
OOAD-related problems. At that time the best known methods
were:
■■ Method introduced by Grady Booch, has received the code
name The Booch method.
■■ Method designed by James Rumbaugh, called Object
Modeling Technique — OMT.
■■ method created by Ivar Jacobson, called Object-Oriented
Software Engineering — OOSE.
Each of these methods focused on the support of individual
stages of OOAD. For example, the method OOSE contained use
case facilities, which were essential at the stage of analysis of the
requirements in the design of business applications. The method
OMT was most suitable for the analysis of data processing in the
45
STEP Computer Academy

information systems. The Booch method was mostly applied

during the design and development of various software systems.
The history of UML development dates back to October 1994,
when Grady Booch and James Rumbaugh from the Rational
Software Corporation started their work on the unification of the
methods Booch and OMT. Although those methods were quite
popular, the collaboration was aimed at the study of all known
object-oriented methods to combine their advantages. G. Booch
and J. Rumbaugh concentrated their efforts on the full unification
of the results of their work. The project of the so-called Unified
Method was prepared and published in October 1995. In the
autumn of the same year, A. Jacobson, chief technology officer
of the company Objectory AB (Sweden), joined them in order
to integrate his method OOSE with the previous two methods.
First, the authors of the methods Booch, OMT and OOSE
intended to develop a unified modeling language only for those
techniques. On the one hand, each of these methods was tested
in practice and showed its constructiveness in solving individual
problems of OOAD. It provided a basis for further modifications
by eliminating inconsistencies of certain concepts and notations.
On the other hand, the unification of the semantics and notation
should have provide some stability in the market of the object-
oriented CASE tools, which was necessary for the successful
promotion of appropriate software tools. Finally, the collaboration
gave hope for a significant improvement of all three methods.

46
 Lesson 1

Starting work on the unification of their methods, G.

Booch, J. Rumbaugh and A. Jacobson formulated the following
requirements for the language modeling. It must:
■■ allow to simulate not only the software but also the
wider classes of systems and business applications using
object-oriented concepts.
■■ ensure the link between the basic concepts of
conceptual models and physical levels.
■■ provide a scalability of models, which is an important
feature of the complex multi-purpose systems.
■■ be understood by analysts and programmers and
supported by specific tools, implemented on different
computer platforms.
Development of a system of notation or notation for OOAD
appeared different from the development of a new programming
language. Firstly, it was necessary to solve two problems:
■■ Should the given notation include requirements
specification?
■■ Should the notation be extended to the visual
programming language level?
Secondly, it was necessary to find a fine balance between
expressiveness and simplicity of the language. On the one hand,
too simple notation limits the range of potential problems
that can be solved by an appropriate notation. On the other
hand, too complex notation creates additional difficulties for
its study and application by analysts and programmers. In
the case of unification of existing methods, it is necessary to
take into account the interests of the professionals who have
experience working with them because the introduction of major
changes in the new notation can lead to misunderstanding and
47
STEP Computer Academy

disapproval of those users, who work with previous techniques.

To eliminate the implicit resistance from individual experts,
it is necessary to consider the interests of the widest range of
users.
All those circumstances had to be considered in the subsequent
work on the UML language.
In that period, supporting the development of UML was
one of the goals of the consortium OMG (Object Management
Group). Although the consortium OMG was established in
1989 in order to work out proposals for the standardization of
object and component technologies CORBA, UML acquired
the status of the second strategic assignment in the activities
of OMG. A team of developers under the direction of Richard
Solei was created within the OMG. Their aim was to provide
further work on the unification and standardization of the
UML language. In June 1995, OMG organized a meeting of all
the major experts and representatives of the companies, who
formed the consortium on the OOAD methodology, where
the expediency of the search of the industry standards in the
field of modeling languages under the auspices of OMG was
geThe efforts of G. Booch, J. Rumbaugh and A. Jacobson led
to the first documents containing the description of UML
version 0.9 (June 1996) and version 0.91 (October 1996). With
the status of the request for proposals (RFP), those documents
served as a catalyst for a broad discussion of UML by various
categories of professionals. The first feedback and reaction to
the UML language pointed to the need to supplement it by
individual concepts and designs.
At the same time, it became clear that some companies
and organizations saw the line of strategic interest for their
48
 Lesson 1

business in UML. The Rational Software company, together

with several organizations wishing to allocate resources for
the development of strict definition of UML version 1.0,
established a consortium of the UML partners.
The companies included in this consortium provided support
of a further work on a more precise and strict definition of
notation that led to the release of UML version 1.0. In January
1997, a document describing the language UML 1.0 was
published as an elementary response to the request for the
RFP proposals. This version of the modeling language was
defined quite well; it provided the required expressiveness
and capacity and offered solution for a wide class of problems.
Instrumental CASE tools and the range of their practical
application are mostly dependent on the successful definition of
semantics and notation of the appropriate modeling language.
The UML specificity lies in the fact that it defines a semantic
metamodel, not a model of specific interface and ways to
represent or implement its components.
In January 1997, a number of other companies submitted
their own responses to the request for the RFP proposals to
the OMG. Later those companies joined the UML partners,
proposing to include some of their ideas into UML. A revised
UML version 1.1. was introduced after their collaboration with
the UML partners. Particular attention in the development
of UML 1.1 was given to achievement of a greater clarity of
the language semantics compared to UML 1.0, as well as the
integration of the proposals of the new partners. This version
of the language was introduced to the OMG and was approved
and adopted as an OMG standard in November 1997.

49
STEP Computer Academy

The next stage in the development of the language ended

in March 1999 when the consortium of OMG published the
description of the UML 1.3 language.
Status of UML is defined as open to all proposals for its
revision and improvement. UML is not anyone’s property and
not patented by anyone. At the same time, the abbreviation
UML is a trademark of its rightful owners.
The UML language is oriented for use as a modeling language
by different users and scientific communities for solving a
wide class of OOAD-related problems.

50