YAZILIM BUNALIMI VE
KARMAŞIKLIK
Nesneye Yönelik Programlamayı Doğuran Sebepler
Yılmaz Kılıçaslan
Sunum Planı
 Yazılım Bunalımı
 Programlama
 Karmaşıklık
 Çözüm Yolları
2
Yazılım Bunalımının İlanı: 1968
3
Yazılım Bunalımının Sonuçları
 The software crisis manifested itself in
several ways:
–
–
–
–
–
–
Projects running over-budget.
Projects running over-time.
Software was very inefficient.
Software was of low quality.
Software often did not meet requirements.
Projects were unmanageable and code difficult
to maintain.
4
– Software was never delivered.
Programlama Nedir?
 Sanat?
 Mühendislik?
 Problem Çözme?
Yazılım Projesi Etkinlikleri
PLANLAMA
TASARIM
ANALİZ
KODLAMA
VE
TEST
YKY/YKG
BİRLEŞTİRME
VE
TEST
TEST PLANI
HAZIRLAMA
TEST
PROSEDÜRÜ
HAZIRLAMA
KULLANIM
HAZIRLIĞI
6
Yazılım Geliştirme Evreleri
 Analiz
 Tasarım
 Kodlama
 Entegrasyon
7
Analiz
 Ne yapacağız?
– Gereklilikler
– Problem sahası
8
Tasarım
 Nasıl yapacağız?
– Genel / mantıksal tasarım
– Soyut düşün!
– Ayrıntılı / fiziksel tasarım
– Somuta dönüştür!
9
Kodlama
 Programı yazmaya bilgisayar başında
başlama!
 Azar azar kodla – sık sık test et!
 İlk önce, ilk derleme hatasını düzelt!
10
Entegrasyon
 Birleştirilebilir
ve sınanmış kod
parçaları elde eder etmez, bunları
birleştir!
 Her birleştirme sonrasında, mutlaka
test yap!
11
Yazılım Karmaşıklığı
 "Einstein argued that there must be simplified
explanations of nature, because God is not
capricious or arbitrary. No such faith comforts the
software engineer. Much of the complexity that he
must master is arbitrary complexity.”
Fred Brooks, 1986
 "The complexity of software is an essential
property, not an accidental one."
Fred Brooks, 1995
12
Yazılım Karmaşıklığının Dört Öğesi
 Problem sahasının karmaşıklığı
 Yazılım
geliştirme
sürecini
yönetme
güçlüğü
 Yazılımın mümkün kıldığı esneklik
 Ayrık sistemlerin beklenmeyen davranışları
13
Problem sahasının karmaşıklığı
 Çatışan talepler
 Çelişen talepler
 Anlatılamayan talepler
 Değişen talepler
 ...
14
Yazılım geliştirme sürecini yönetme güçlüğü
15
Yazılımın mümkün kıldığı esneklik
 Bir yazılımcı herşeyi programlayabilir!
16
Ayrık sistemlerin beklenmeyen davranışları
 “When we say that a system is described by a
continuous function, we are saying that it can
contain no hidden surprises. Small changes in
inputs will always cause correspondingly small
changes in outputs.” Parnas (1985)
 “On the other hand, discrete systems by their very
nature have a finite number of possible states; in
large systems, there is a combinatorial explosion
that makes this number very large.” Booch (1998)
17
İnsanı aşan karmaşıklık
“The distinguishing characteristic of industrialstrength software is that it is intensely difficult, if
not impossible, for the individual developer to
comprehend all the subtleties of its design. Stated
in blunt terms, the complexity of such systems
exceeds the human intellectual capacity. Alas, this
complexity we speak of seems to be an essential
property of all large software systems. By
essential we mean that we may master this
complexity, but we can never make it go away.” 18
Grady Booch, 1998
Yazılım Mühendislerinin Kapasitesi
"The world is only sparsely populated with
geniuses. There is no reason to believe that
the software engineering community has an
inordinately large proportion of them.”
Lawrence Peters, 1981
19
Kontrolsüz Karmaşıklığın Sonuçları
 “Bir sistem ne kadar karmaşık olursa, top
yekûn çökme olasılığı o kadar yüksek olur.”
Shankar (1984)
 NYP öncesi karmaşıklık-maliyet ilişkisi:
20
How to program a computer to play good chess
1990s chess-playing computer
It used to be thought in the 1950's
and on into the 1960's-that the trick
to making a machine play well was
to make the machine look further
ahead into the branching network
of possible sequences of play than
any chess master can.
However, as this goal gradually became
attained, the level of computer chess did
not have any sudden spurt, and surpass
human experts. In fact, a human expert can
quite soundly and confidently trounce the
best chess programs of this day.
Hofstadter, 1979
Grandmaster Garry Kasparov,
former World Chess Champion
Chunking and Chess skill
In the 1940's, the Dutch psychologist Adriaan
de Groot made studies of how chess novices
and chess masters perceive a chess situation.
Put in their starkest terms, his results imply that
chess masters perceive the distribution of
pieces in chunks.
Computer Systems
When a computer program is running, it can
be viewed on a number of levels. On each
level, the description is given in the
language of computer science, which makes
all the de descriptions similar in some ways
to each other-yet there are extremely
important differences between the views
one gets on the different levels.
Instructions and Data
The words of memory
contain not only data
to be acted on, but
also the program to act
on the data.
The base sequence for the chromosome of
bacteriophage OX174
Machine Language vs. Assembly Language
84, 0, 184, 142, 216, 198, 6, 158, 15, 36, 205, 32
If you were to enter these numbers
into your computer's memory and
run them under MS-DOS, you would
see a dollar sign placed in the lower
right hand corner of your screen,
since that is what these numbers tell
the computer to do.
MOV AX, 47104
MOV DS, AX
MOV [3998], 36
INT 32
A "stratified" picture of Al
FIGURE 59. To create intelligent
programs, one needs to build up a
series of levels of hardware and
software, so that one is spared the
agony of seeing everything only on
the lowest level. Descriptions of a
single process on different levels
will sound very different from each
other, only the top one being
sufficiently chunked that it is
comprehensible to us. [Adapted
from P. H. Winston, Artificial
Intelligence
(Reading,
Mass.:
Addison-ifele'', 1977)]
Bilişsel Sınıflandırma
Eleanor Rosch ve arkadaşları, bilişsel sınıflandırmanın
ortogonal iki eksen tarafından belirlendiğini saptadırlar:
Level of Inclusiveness
vehicle
mammal
furniture
Segmentation of Categories
car
saloon
dog
chair
collie
rocking chair
28
Yazılım Karmaşıklığına Çözüm Arayışları
• Three major innovations in programming
have been devised to cope with the problem
of complexity:
- Object-oriented programming (OOP)
- The Unified Modeling Language (UML)
- Improved software development processes
Robert Lafore, 2002
29
ÖZET
 Yazılım bunalımı,
süreyi ve bütçeyi aşan, müşteri
beklentilerini karşılamayan projelere yol açmıştır.
 Bunalımın nedeni, yazılımın doğasında
süreçlerinde mevcut olan karmaşıklıktır.
ve geliştirme
 Nesneye Yönelik Programlama, karmaşıklık ile mücadele
amacıyla geliştirilmiş araçlardan birisidir.
30
Kaynaklar







Booch, G. 1998. Object-Orinted Analysis and Design. Addison-Wesley.
Brooks, F. April 1986. No Silver Bullet: Essence and Accidents of
Software Engineering. IEEE Computer vol. 20(4), p. 12.
Brooks, F. 1995. "Chap. 17". "'No Silver Bullet' Refined" (Anniversary
Edition with four new chapters ed.) Addison-Wesley.
Hofstadter, D. 1979. Gödel, Escher, Bach: An Eternal Golden Braid,
Basic Books.
Parnas, D. july 1985. Software Aspects of Strategic Defense System
Victoria, Canada: University of Victoria, Report DCS-47-IR.
Peters, L. 1981. Software Design. New York, NY: Yourdon Press, p. 22.
Shankar, K. 1984. Data Design: Types, Structures, and Abstractions.
Handbook of Software Engineering. New York, NY: Van Nostrand
Reinhold, p. 253.
31