Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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.
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 wellknown: 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
Lesson 1
4. A review of existing
methodologies
4.1. The methodology
of procedure-oriented programming
Lesson 1
Start
Data input
Data handling
Calculation
Function call
End
A graphical representation of the program in sequential procedures
Lesson 1
11
Lesson 1
Lesson 1
The need for the analysis of the domain before writing the
program was recognized in the time of development of largescale 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
16
Lesson 1
17
18
Lesson 1
19
20
Lesson 1
input actions
e
n
t
r
a
n
c
e
SYSTEM
e
x
i
t
output actions
21
22
Lesson 1
24
Lesson 1
25
26
Lesson 1
28
Lesson 1
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.
Lesson 1
Dependent
ssociated
entity
entity
31
limited relationship
unlimited
relationship
works in
company
32
Lesson 1
works on
project
33
Employee
Works in
Company
Works on
Develops
Project
Lesson 1
Lesson 1
The process
(activity)
output
Mechanism
One of the most important features of the methodology IDEFSADT 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
38
Lesson 1
Credit regulations
Credit
application
from client
Preparation of credit
Credit
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
Lesson 1
41
Lesson 1
Data on the
customers credit
card
Bank
customer
Notification on
giving the amount
in cash
1.1
Bank
employee
Bank terminal
Amount in cash
An inquiry about
the state of the
customers current
account
D1
Service protocol
Data on the
customers current
account
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
46
Lesson 1
Lesson 1
50