yazılım mühendisliği eğitim programları ve biçimsel yöntemlerin rolü

İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Yıl:9
Sayı:18
Güz 2010
s. 1-29
YAZILIM MÜHENDİSLİĞİ EĞİTİM PROGRAMLARI VE
BİÇİMSEL YÖNTEMLERİN ROLÜ
Zeynep ALTAN1
Geliş: 06/05/2010
Kabul: 08/11/2010
ÖZET
Yazılım mühendisliği kavramının yazılım geliştirme problemine çözüm olarak önerilmesi ve yazılım
mühendisliğinin farklı bir disiplin olarak kabul edilmesi 1968 yılında yapılan NATO konferansına
dayanır. Yazılım mühendisliğinin bilgisayar bilimleri ile ilişkisi yıllarca tartışılmasına rağmen, bağımsız
bir meslek olarak kabulünde son 10 yılda büyük ilerlemeler kaydedilmiştir. Biçimsel yöntemler
üniversitelerin hemen hemen tüm yazılım mühendisliği programlarında ders olarak okutulmasına rağmen,
endüstriyel ve ticari projelerde pek yaygın kullanılmamaktadır. Biçimsel yöntemler dersinin programlarda
yer almasının en olumlu etkisi, öğrencilerin doğrudan kodlamaya başlamak yerine, belirtimler üzerinde
düşünmeye zorlanmalarıdır. Ayrıca bu disiplinden endüstriyel projelerde yararlanıldığında, yazılımın
niteliği ve finansal yapılanmaya büyük katkısı olmaktadır. Biçimsel yöntemlerin başarısına erişebilecek
ölçümlerin oluşturulması güçtür. Her bin satırlık kod için hata sayısı ölçüm olarak değerlendirildiğinde,
biçimsel yöntemlerden yararlanılıyorsa, hatalar geliştirme sürecinin ilk adımlarında düzeltilebilir. Bu
çalışmada yazılım mühendisliği eğitim programlarının bilgisayar programları içindeki yeri ve yazılım
sistemlerinin geliştirilmesi sürecinde biçimsel yöntemlerin önemi araştırılmakta; öğrencilerin yazılım
sistemleri üzerindeki pratik becerilerini geliştirmelerinde teorik modellerin etkisi açıklanmaktadır.
Anahtar Sözcükler: Biçimsel Yöntemler, Ölçüm, Yazılım Betimlemesi, Soyutlama
SOFTWARE ENGINEERING EDUCATION PROGRAMS AND THE ROLE OF
FORMAL METHODS
ABSTRACT
The proposal of software engineering notation as a solution to the software development problems and
the acknowledgement of it as a stand-alone discipline are dated to NATO conference held in 1968.
Although the relationship of software engineering to computer science has been discussed over many
years, there has been great progress in establishing software engineering as a mature profession in the last
10 years. Although the course formal method is taught about at all of the software engineering degree
programs, they are not widely applied to the industrial and commercial projects. One of the most
advantages of formal methods is that the students are obligated to think in detail about the software
specification, and they don’t attempt to begin the coding immediately. The huge contribution of formal
methods to the software quality and also to the financial implications is it’s another benefit. Moreover it
seems difficult to set up metrics that can access the success of the formal methods. If the number of errors
per thousand lines of code is considered as a measurement for any project utilizing formal methods, the
major errors will be detected at an earlier stage of the development process. This paper describes the
position of software engineering education programs on other computer discipline programs and
researches the importance of formal methods on the developing process of software systems. The impact
of theoretical models is also explained while the students develop their practical skills at software
systems.
Keywords: Formal Methods, Measurement, Software Specification, Abstraction
1
Beykent Üniversitesi Mühendislik- Mimarlık Fakültesi Yazılım Mühendisliği Bölümü, İstanbul,
[email protected]. Zeynep ALTAN
1.GİRİŞ
60’lı yılların sonlarında başlayan yazılım geliştirme çalışmalarında kesin çözümleri
olan, bakılabilirlik özelliği ile sürekliliği sağlanmış ve yeniden kullanılabilir ürünler
geliştirmenin ileriki yıllarda bir zorunluluk olacağı fark edildi. Donanımla ilgili
uzmanların, üniversitelerin, yazılım firmalarının, bilgisayar kullanıcılarının ve
yazılım problemleri ile uğraşan farklı alanlardan 50 kadar bilim insanının katıldığı
ünlü NATO konferansı 1968 yılında “yazılım tasarımı”, “yazılım üretimi” ve
“yazılım hizmeti” olmak üzere üç ana başlıkta düzenlenmiştir (Naur ve Randell,
1968). Yazılım ürünlerinin geliştirilmesi için bir mühendislik yaklaşımına
gereksinim olduğu ilk defa 70’li yılların başında ifade edilmiştir; diğer mühendislik
çalışmalarında olduğu gibi bu alanda da geliştirilecek sisteme uygulanacak
yöntemler, geliştirme araçları ve yapılacak işlemler sistematik bir şekilde
gerçekleştirilmelidir. Ürün geliştirme süreçlerine katkıda bulunmak, süreçleri
kontrol etmek ve nitelikli ürünler elde etmek, ancak tüm bu ölçütler sağlandığı
sürece mümkündür (Royce,1970). Bu tanım aslında günümüzde şelale yöntemi
olarak bilinen yazılım geliştirme döngüsünün özgün bir betimlemesidir. O yıllarda
mühendislikteki bu eğilim, yazılım geliştiricilerinin eğitimine de yansımıştır.
Yazılım geliştirme eğitimi zaman içerisinde bilimsel bir özellik kazanmış;
mühendislik yöntembilimlerinin modellenmesi, ürün geliştirme süreçleri ve tekrar
edilebilirlik üzerinde yoğunlaşma görülmüştür. Böylesi bir yaklaşımın temel nedeni
iyi-tanımlanmış (well-defined) yazılımlar geliştirmektir; bu da ancak bilimsel
araştırma yöntemlerinin uygulanması ile başarılabilir (Pfleeger,1999).
Uygulanacak teknolojilere karar vermek kolay değildir. Uzun süre devam eden
ölçüm ve deneyimler olmaksızın hiç bir bilim dalında ilerlenemeyeceği açıktır. Bir
yazılımın süreç aktiviteleri, geliştirme araçları ve ölçümlerinin nasıl
yapılandırılacağı bilinirse, iyi-tanımlanmış ürünün elde edileceği etkin süreç
tanımlanmış demektir. Bu tür ürün geliştirme sistemlerinde neden-sonuç ilişkisine
dayalı araştırmalar önem kazanır. Ampirik yazılım mühendisliğinde modellerin ve
ölçümlerin oluşturulması için gerekli olan bilgi teorik bilimsel bilgi, mühendislik
bilgisi, biyomedikal ve epidemiyolojik bilgi, sosyal, ekonomik ve kurumsal bilgi
olarak dört farklı tipte sınıflandırılır (Pfleeger, 1999).
70’li yılların başlarından 21. yüzyılın ilk yıllarına kadar yazılım mühendisliği
disiplininde yapılan çalışmaların günümüzdeki yansımaları yaygın kullanılan
yazılım ürünleridir.
Böylece önceleri ferdi olarak yapılan pek çok işin
otomatikleştiği ve hızlandığı açıktır. Bu uygulamalar genellikle model-sürücülü,
hizmet odaklı ya da duruma-yönelik nesne tabanlı geliştirme sistemleri ile
tasarlanmaktadır. Bu teknik olanaklara kurumsal düzeyde modelleme, uygulama ve
veri tabanı analiz/tasarımı, kod üretimi ve proje yönetimi de eklenebilir.
Yazılım mühendisliği eğitim programlarının geliştirilmeye başlaması NATO
konferansının gerçekleştiği 60’lı yılların sonlarına uzanır. Curriculum 1968, ACM2
tarafından bilgisayar bilimleri disiplininde eğitim programlarının düzenlenmesi ile
2
Association for Computing Machinery (kuruluş 1947) 2
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
ilgili ilk çalışmadır. CSEET (Conference on Software Engineering Education and
Training) 1987 yılında SEI3 tarafından gerçekleştirilen ilk yazılım mühendisliği
konferansıdır. 80’li yılların sonlarında ACM ve IEEE-CS4 birlikteliği ile, bilgisayar
bilimleri ve bilgisayar mühendisliği lisans programlarını açıklaştıran Computing
Curricula 1991 (CC’91) çalışması
gerçekleştirilmiştir. Bu ortak çalışmalar
Computing Curricula 2001 (CS’2001) ile,
bilgisayar bilimleri, bilgisayar
mühendisliği, bilgi sistemleri ve yazılım mühendisliği disiplinlerine ait lisans
programlarının belirlenmesi şeklinde devam etmiştir. SE2004 (Curriculum
Guidelines for Undergraduate Degree Programs in Software Engineering)5 yine
ACM ve IEEE-CS birlikteliğinde bir çalışmadır ve sadece yazılım mühendisliği
lisans programlarının akreditasyonu ölçütlerini
belirlemek üzere derslerin
sınıflandırmasını gerçekleştirmektedir. Programlarının sınıflandırılması ile ilgili
son çalışma olan GSwE2009 (Graduate Software Engineering 2009- Curriculum
Guidelines for Graduate Degree Programs in Software Engineering)6 , iSSEc
(Integrated Software & Systems Engineering Curriculum) projesinin ilk ürünüdür ve
önceki lisans ve
yüksek lisans programları temeline oturtulmuş, güncel
gereksinmelere cevap verecek uygulamalı bir eğitim programı oluşturulması
çalışmalarını yürütmektedir. Burada gerçek dünya problemlerinin çözümünde sistem
mühendisliği ve yazılım mühendisliği arasında güçlü bir bağ olduğu
vurgulanmaktadır.
Yazılım mühendisliği eğitimi, yüksek lisans programı ile ilk defa 1978 yılında
Seattle Üniversitesi’nde başlamış olup, 1988 yılından itibaren Carnegie Melon
Üniversitesi’nde SEI’nün çalışmalarına başlaması ile hızla şekilde yaygınlaşmasını
sürdürmüştür (Tomayko, 1998). İlk yazılım mühendisliği lisans programının
Amerika Birleşik Devletleri’nde 1996 yılında Rochester Üniversitesi’nde başladığı
bilinmektedir. 90’lı yıllarda özellikle İngiltere ve Avustralya’da da yazılım
mühendisliği lisans programları yaygınlaşmaya başlamıştır. Türkiye’de ise ilk defa
2005 yılında Bahçeşehir Üniversitesi’nde yazılım mühendisliği lisans programı
açılmış olup, Fırat Üniversitesi 2010 eğitim-öğretim yılında yazılım mühendisliği
lisans programına öğrenci kabul eden ilk devlet üniversitesi olmuştur.
Çalışma, başlığından da anlaşılabileceği gibi, birbirini tamamlayan iki farklı
kısımdan meydana gelmektedir.
Bunlar, lisans programı olarak yazılım
mühendisliği ve yazılım mühendisliği eğitiminde biçimsel yöntemlerin rolü olarak
özetlenebilir.
2. Bölüm’de yazılım mühendisliği eğitiminin günümüzde niçin
zorunlu bir program haline geldiği ve bu programın uygulanmasında karşılaşılan
güçlükler anlatılmaktadır. 3. Bölüm’de yazılım mühendisliğinin farklı bir disiplin
olarak incelenmesine devam edilmekte; yazılım ölçümünün bu disiplin içindeki
önemi ve eğitim programlarının hazırlanmasına katkıları araştırılmaktadır.
3
Carnegie Mellon, Software Engineering Institute (kuruluş 1984) The Computer Society of the Institute for Electrical and Electronic Engineers (kuruluş 1946) http://sites.computer.org/ccse/ 6
http://www.gswe2009.org/ 4
5
3
Zeynep ALTAN
4. Bölüm’de çalışmanın ilk kısmını tamamlayan bilgisayar bilimleri eğitim
programlarının temeli olan biçimsel yöntemler anlatılmaktadır. Burada biçimsel
yöntemlerin yazılım ve donanım sistemlerinin geliştirilmesindeki güçlü katkısı
kronolojik bir yapıda özetlenmektedir. Son bölümde ise yazılım mühendisliği lisans
programlarının geleceği ve biçimsel yöntemlerin eğitim programlarının her
aşamalarında mevcut olması gerekliliği vurgulanmaktadır.
2.YAZILIM MÜHENDİSLİĞİ EĞİTİMİ GEREKLİ MİDİR?
Ülkemizde olduğu gibi Amerika Birleşik devletleri dahil dünyanın pek çok
ülkesinde, mühendislik ve fen dallarındaki programlardan mezun olan öğrenciler bir
süre sonra yazılım ile ilgili işlere ilgi duymakta ve bu sektörlere yönelmektedirler.
Fakat bu kişilerin pek çoğunun ya hiç bir yazılım eğitimi yoktur; ya da minimum
düzeydedir. Örneğin Amerikan Fizik Enstitüsü İstatistiksel Araştırmalar
Merkezi’nin7 2001 yılında yayınladığı “Physics Trends” isimli rapora göre fizik
alanında lisans diplomasına sahip olanların %24’i, 5 ile 7 yıl sonra yazılım
sektöründe herhangi bir iş yapmaya başlamaktadır. Bu kişilerin pek çoğunun lisans
süresince bu alandan hiç bir eğitimleri bulunmamaktadır. Diğer mühendislik
bölümleri ve fen bilimleri dallarından mezun olan öğrenciler, hatta mühendislik dışı
disiplinlerden kişiler de profesyonel yaşamlarında bir süre sonra yazılım
geliştirmeye ilgi duyabilmektedir. Bu öğrencilerin mezuniyetlerinden önce,
bilgisayar eğitiminin en azından ilk sınıflarında verilen temel kavramlar konusunda
bilgilendirilmeleri şarttır.
Teknolojideki sürekli ve hızlı gelişmeler insanları günlük hayatlarında
otomatikleştirmektedir; bugün bilgisayarlar tarafından gerçekleştirilen pek çok
yaşamsal aktivitenin önceleri tahmin bile edilmesi mümkün değildi. Yazılım sektörü
buna bağlı olarak, endüstriyel yazılım mühendisliği adı altında yeni bir araştırma
alanını doğurmuştur. Yazılım sistemlerinin günümüzdeki karşılığı endüstriyel olarak
güçlü yazılım sistemlerinin geliştirilmesi anlamındadır (Jalote, 2008). 2000’li
yılların başlarında bile farklı mühendislik alanlarından kişilerin yönelebildiği
yazılım dünyası, günümüzde her bir farklı uygulama için ayrıca uzmanlaşma
gerektirmektedir. Sadece tıp, fen ve sosyal bilimler dallarında değil; spor, sanat ve
edebiyat dahil hemen hemen tüm alanlarda günümüz teknolojilerinden yararlanma,
dolayısı ile bilgisayar yazılımları birinci derecede önemlidir. Bu farklı disiplinlerin
tümüne ait uygulamaların İnternet üzerinden kullanımı ve devingenliği de
endüstriyel yazılım mühendisliğinin yükümlülüğünü arttırmaktadır. Tüm bu
ürünlerin geliştirilmesi için, çok büyük miktarda bilgiye erişim ve bunların sürekli
güncellenmesi gereksinimi, bilginin farklı ortamlarda kullanılabilmesi olanağı
konunun uzmanlarının teknolojik gelişmeleri yakından izlemelerini doğrudan
zorunlu kılmaktadır.
Sonuç olarak, büyük ölçekli yazılım problemlerinin
çözümlerinde uzman kişiler yetiştiren yazılım mühendisliği, bugün dünyanın her
7
http://www.aip.org/statistics/trends/reports/spring01a.pdf 4
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
yerinde aranılan bir meslek grubudur. Yazılım mühendisleri karmaşık problemleri
çözebilmeli, ekip içerisinde etkin çalışabilme becerisine sahip olmalıdır. Ayrıca
birbirleri ile çok iyi iletişim kurabilmeli ve sürekli olarak öğrenmeye açık olmalıdır.
Yukarıda açıklananlar günümüzde yazılım mühendisliğinin niçin ayrı bir eğitim
programı olarak verilmesi zorunluluğunu cevaplamaktadır. Haberleşme,
veritabanları, İnternet ve web teknolojileri, elektronik ticaret, grafik uygulamaları,
görselleştirme ve güvenlik gibi alanlarda yazılım geliştirilmesi günümüzde gerek
kamu, gerekse özel sektörün ilgi odağıdır. Finansal yazılımların geliştirilmesi ve
bakımı ile ilgili kuruluşlar da yazılım mühendisleri için diğer bir iş kolunu
oluştururlar. Özel ve kamu sektörü, ağ sistemleri ve bunların yönetimi için de bu
meslek grubuna başvurulur. Ayrıca çeşitli mühendislik dallarında araştırma ve
geliştirme çalışmaları yapan kuruluşlar yazılım mühendislerinden yararlanırlar.
Bunlara en açık örnek olarak tıbbi yazılım mühendisliği verilebilir.
2.1 Yazılım Mühendisliği Eğitiminin Zorunluluğu
Bilgisayar yazılımlarının cep telefonlarından büyük askeri sistemlere kadar
yaşamımızda hemen her yerde mevcut olması nedeni ile, bilgisayar bilimleri ve
bilgisayar mühendisliği eğitim programları bu geniş yelpazeli ürünlerin
geliştirilmesi ve sürekliliğinin sağlanmasında yeterli olamamaktadır. Çünkü imalat,
bankacılık, seyahat, iletişim, savunma, tıp, araştırma, kamu, eğitim, eğlence, hukuk
gibi birbirileri ile hiç ilişkisi olmayan pek çok sektörde yazılım konusunda
uzmanlaşmak artık bir zorunluluktur. Bu sistemlerin pek çoğunda karmaşıklığın
hızla artması ve kullanıcılar için güvenilirliğin ön planda olması yapılacakları daha
da güçleştirmektedir. Ayrıca bilgisayar mühendisliği ve bilgisayar bilimleri
programlarındaki aşağıda özetlenen eksiklikler bu eğitimleri sınırlandırmaktadır
(Knight ve Leveson, 2006):
i.
ii.
Bilgisayar mühendisliği ve bilgisayar bilimleri programları yazılımın
geliştirilmesi ilkelerine çok fazla önem vermez. Programların özelliklerinin
betimlenmesi, test teknikleri gibi önemli kavramlar farklı dersler olarak
okutulmadığı için bu konulardaki bilgiler yetersiz kalır. Bu bölümlerin
mezunları, eğer yazılım geliştiriyorlarsa, sadece kullandıkları programlama
dilinin sözdizimini ve yazdıkları kodlara ait kütüphane fonksiyonlarının
ayrıntılarını bilirler; sistemi tasarlamak ya da test etmek için diğer
mühendislerle nasıl bir işbirliği yapılması gerektiğini bilmezler. Bunun için
yazılım geliştirmede önemli kavramlar olan yazılım gereksinmelerinin
belirlenmesi, yazılımın belirtimi, yazılımın tasarımı ve yazılımın
doğrulanması lisans programlarında ayrı ayrı bulunmalıdır. Ancak bu
koşullar sağlandığında bilgisayar mühendisliği ve bilgisayar bilimleri
mezunları yazılım problemlerinin çözümünde ne gibi teknolojik seçim
yapacaklarını ve bu seçimlerini nasıl hayata geçireceklerine sağlıklı olarak
karar verebilirler.
Öğrencilerin eğitimleri süresince diğer mühendislik disiplinleri ile ortak
çalışma yapmaları zorunlu olmalıdır; böylece disiplinler arası projelerde
5
Zeynep ALTAN
iii.
iv.
çalışarak kendileri için çok önemli deneyimler edinebilirler. Alan dışı ders
alımları ile öğrenciler, farklı bilgisayar sistemlerinin kullanılması
örneklerini inceleyebilirler. Bilgisayar mühendisliği ve bilgisayar bilimleri
bölümlerinde böyle geniş perspektifli ders seçimi yapabilmek her zaman
mümkün olmayabilir.
Bilgisayar mühendisliği ve bilgisayar bilimleri programlarında yazılım
geliştirme ile ilgili kavramlar oldukça genel bir bakış açısından incelendiği
için, öğrenciler nesneye-yönelik tasarımın ayrıntıları, olay güdümlü
sistemler, yazılım mimarisi gibi pek çok konuda fazla bilgi edinemeyebilir.
Aslında eğitim süresince yazılım mühendisliği disiplininden seçilmiş birkaç
farklı tekniğin, öğrencilere çok iyi öğretilmesi ve uygulatılması şart
olmalıdır. Öğrenciler aynı zamanda bu tekniklerin karşılaştırmalı analizini
yapabilmeli, öğrendiklerinin tümünü birbirinden farklı mühendislik
uygulamaları ile değerlendirebilmeli ve tartışabilmelidir.
Yazılım mühendisliği disiplininde gerçek-zamanlı sistemler, gömülü
sistemler gibi farklı uygulama alanları vardır. Öğrencilerin bu tür
uygulamalarla çok fazla karşılaşmayacakları şeklindeki genel düşünce
nedeni ile bilgisayar bilimleri eğitim programlarında bunlara fazla yer
verilmez veya yüzeysel olarak okutulur. Oysa günümüzde pek çok
bilgisayar sistemi gömülüdür ve bu sistemlerin pek çoğu da işlemlerini
gerçek-zamanlı gerçekleştirmektedir. Yazılım mühendisliği programı
mezunlarının bu tür sistemleri her yönü ile inceleyebilmeleri için, gerçekzamanlı sistemlerin nasıl tasarlanacağını ve oluşturulacağını, bu tür
uygulamalar için ne tür tekniklerin kullanılabileceğini öğrenmeleri bir
zorunluluktur.
Özetle; yazılım mühendisliği eğitimi alan mezunların gelecekte karşılaşacakları
problemleri çözümleyebilen bireyler olarak, temel yazılım kavramları ile ilgili
önemli bilgileri edinmeleri profesyonel sorumluluklarıdır. Bu sorumluluğun
ayrıntıları geniş kapsamlı öğretilemez. Yazılım mühendisliği programları doğru
temeller üzerinde hazırlandığında, öğrenciler dört yıllık eğitimleri süresince doğru
yönlendirildiklerinde, problemi doğru çözümleyerek ürün geliştiren mühendisler
olarak aranmaları kaçınılmazdır. Ayrıca öğrencilerin yazılım mühendisliği
programlarından mezuniyetlerinden sonra, bu alanda uzmanlaşmalarını sağlayacak
yüksek lisans ve doktora programlarının hazırlanması da gereklidir.
3. YAZILIM MÜHENDİSLİĞİ VE YAZILIM ÖLÇÜMÜ
Yazılım ölçümünün yazılım mühendisliğindeki önemi gittikçe artmasına rağmen, bu
alanda kullanılan terminoloji ve kavramların pek çoğunda hala tam bir uzlaşma
sağlanamamıştır. Ölçüm, mühendislik disiplinlerinin tümünde temel kavramdır.
Projelerinde yazılım ölçümünden yararlanan pek çok araştırmacının kaynak ve
referanslarında ortak olan sözcük dağarcığının (vocabulary) uyuşmazlığı,
karşılaşılması istenmeyen en kötü durumdur. Oysa yüksek nitelikli yazılım ürünleri
elde etmede standardizasyonun rolü büyüktür ve yazılım mühendisliğini ustalık ya
6
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
da beceri değil de, bir mühendislik disiplini olarak değerlendirmede çok önemlidir.
Standartlar mühendislik alanındaki kuruluşları, iyi bilinen uygulamaları (ürünleri) ve
kullandığı teknolojileri ile güçlendirir. Ayrıca İnternet, iş dünyasını doğrudan
değiştirmiş, şirketlerin küresel ekonomide rekabet edebilmesi ve şirketler arasında
işbirliğinin gerçekleşebilmesi için bilgi ve kaynakların paylaşımını gerektirmiştir.
Standardizasyon ise, böyle bir işbirliğinin yapı taşını oluşturmaktadır.
Bir bilgi içeriğinin (Body of Knowledge–BOK) varlığı herhangi bir mesleğin
oluşturulmasında ilk adımdır; bunun için de içeriğinin geniş katılımlı bir uzlaşma ile
belirlenmiş olması gerekir.
2004 yılında IEEE CS tarafından endüstriden
katılımcıların da desteği ile hazırlanan ve yazılım mühendisliğinin sınıflandırıldığı
SWEBOK (Software Engineering Body of Knowledge)8 kılavuzunda ölçüm, temel
mühendislik aracı olarak kullanılmıştır.
SWEBOK kılavuzunda bilgi alanı
(Knowledge Area- KA) olarak sınıflandırılan ve her bir alana uygun ölçüm olarak
belirlenen ölçütler, yazılım geliştiricilerini de birleştirmiştir (Abran ve Moore,
2004). Bilgi alanlarının biçimlenmesinde ölçüm, nitelik ve diğer yazılım araçları ile
birlikte üç temel temadan birini oluşturur.
3.1 ”Software Engineering Body of Knowledge” Girişimi ve Yazılım Ölçümü
SWEBOK girişimi aşağıdaki beş temel hedefi gerçekleştirmeyi amaçlar:
i.
ii.
iii.
iv.
v.
Yazılım mühendisliğinin dünya ölçeğinde en iyi şekilde yaygınlaşması,
Yazılım mühendisliğinin sınırlarının belirlenmesi; bilgisayar bilimleri,
proje yönetimi, bilgisayar mühendisliği ve matematik gibi disiplinlerin
arasında yerinin açıklaştırılması,
Yazılım mühendisliği disiplininin içeriklerinin tanımlanması,
SWEBOK‘e konu düzeyinde erişimin sağlanması,
Öğretim programının geliştirilmesi, sertifikasyon ve lisans alma işlemleri
için bir esasın oluşturulması.
Yukarıdaki amaçları gerçekleştirmek üzere, dünya genelinde 41 ülkeden 500
katılımcının katkısı ile yazılım mühendisliğinin organize edildiği bilgi alanları
Tablo’1 de 10 temel grupta sınıflandırılmaktadır. Bu bilgi alanlarının her biri
SWEBOK içinde ayrıntılı olarak açıklanmaktadır. Bilgi alanlarının sınırları
belirlenirken yazılım mühendisliği ile ortak alanı olan diğer disiplinlerin
açıklaştırılması da önemlidir. Bu amaçla, eğitim programları hazırlanırken bilgi
alanı tanımlamalarında Tablo 2 ‘de verilmiş olan 7 farklı çalışma alanı, yazılım
mühendisliği ile doğrudan ilişkilendirilebilecek disiplinler olarak belirtilmiştir. Her
bir bilgi alanı kapsamındaki konuların yerleştirilmesi sıradüzensel bir yapı içinde
oluşturulur. Araştırılan alana göre konuları belirlemenin en uygun yolu, bunların
iki ya da üç düzeyli dokümanının oluşturulmasıdır. Konuların sınıflandırılmasında
8
http://www.computer.org/portal/web/swebok 7
Zeynep ALTAN
hem endüstrinin, hem yazılım mühendisliğinin literatür ve standartlarından, hem de
deneyimli üniversitelerin fikir ve tecrübelerinden yararlanılmıştır.
Tablo 1. SWEBOK Bilgi Alanları (KA)
1
Yazılım Gereksinmeleri
2
Yazılım Tasarımı
3
Yazılımın Oluşturulması
4
Yazılım Testi
5
Yazılım Bakımı
6
Yazılım Düzenleşim Yönetimi
Tablo 2.Yazılım Mühendisliği ile İlişkili
Disiplinler
1
Bilişsel Bilimler ve İnsan Faktörleri
2
Bilgisayar Mühendisliği
3
Bilgisayar Bilimleri
7
Yazılım Mühendisliği Yönetimi
8
Yazılım Mühendisliği Süreci
4
Yönetim ve Yönetim Bilimleri
Yazılım Mühendisliği Araçları
ve Yöntemleri
Yazılımın Niteliği
5
Matematik
6
Proje Yönetimi
7
Sistem Mühendisliği
9
10
3.2 Ölçüm Tanımı ve Temel Standartlar
Ölçüm, fizik, kimya ve biyoloji gibi disiplinlerin günlük aktivitelerinin bir
parçasıdır. Yazılım mühendisliğinde ise ölçüm, uzun kuralları olan gelişmiş bir
çalışma alanıdır. Ölçüm standartları hayatı kolaylaştırmayı amaçlar. Örneğin litre ve
metre doğudan batıya her yerde aynı değeri olan, tüm ülkelerin kabul ettiği
birimlerdir. Bilim ve mühendislik disiplinlerinde metroloji, diğer bir ifade ile ölçüm
bilgisi, ölçüm aygıtları ve ölçüm süreçlerinin geliştirilmesi ve kullanımı üzerinde
odaklanır. Yazılım mühendisliği eğitim programının hazırlandığı SWEBOK
kılavuzunda Tablo 1’de verilmiş olan on temel bilgi alanı aşağıdaki üç bakış açısına
göre belirlenmiştir:
i.
Vincenti Mühendislik Bilgisi (Engineering Knowledge)
(Vincenti,1990),
ii.
Metrolojide ISO (ISO Vocabulary of Basic and General Terms in
Metrology- VIM) söz varlığının temel ve genel terimleri (ISO VIM, 1993),
Ölçüm yönteminin herhangi özel bir tipinin analizi, bir başka ifade ile
fonksiyonel boyutlandırma.
iii.
sınıflandırması
3.2.1 Vincenti Mühendislik Bilgisi Sınıflandırması
8
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
Vincenti mühendislik bilgisi sınıflandırması uzay mühendisliği için hazırlanmış
olmasına rağmen, uygulamalı mühendislik alanlarında da kullanılmaktadır. Yazılım
mühendisliği programı için her bir bilgi alanı belirlenirken, başlangıç aşamasında
Tablo 3’te verilen Vincenti sınıflandırmasından yararlanılmıştır. Bu sınıflandırma
fazla ayrıntılı olmadığı için, pek çok bilgi alanı taksonomisi ve tanımlamasına
doğrudan uygulanamamıştır; fakat bilgi alanlarına ait bazı mühendislik konularının
ayrıntılarının belirlenmesinde analitik açıdan faydalı olmuştur. Örneğin 2001 yılında
yapılan çalışmada yazılım mühendisliği yüksek lisans programında seminer dersi
olarak tanımlanmış bilgi alanlarının tümünde “ölçüm” sözcüğü olmasına rağmen,
her bir bilgi alanı içinde tanımlanmış olan konular için “niceliksel veri” anahtar
terimi referans olarak yer almamaktaydı. Benzer şekilde, analitik araştırma
yöntemlerinin analizi, SWEBOK içindeki bilgi alanlarının çoğunda tüm referanslar
için mevcuttur. Fakat “yazılım mimarisi” dersi bağlamında verilen bilgilerin pek
çoğu deneysel yöntemler içermez. Bu ders kapsamında aktarılan bilgi, yapılan
deneylerin sonuçlarının irdelendiği dokümantasyonlardan ziyade, iddialar ve uzman
kararlarıdır. Bu nedenle de Tablo 3’teki Vincenti Sınıflandırması bilgi alanlarının
sıradüzensel ayrıştırmasında oldukça önemlidir.
Tablo 3. Mühendislik Bilgi Sınıflandırması
Sınıflandırması- Vincenti
Tablo 4. ISO Metroloji Söz
Varlığı Sınıflandırması
1
Temel Tasarım Kavramları
1
2
Kriterler ve Betimlemeler
2
Ölçümler
3
Teorik Araçlar
3
Ölçüm Sonuçları
Miktarlar ve Birimler
4
Niceliksel Veri
4
Ölçüm Aletleri
5
Pratik Düşünceler
5
Ölçüm Aletlerinin Karakteristikleri
6
Tasarım Organları
6
Ölçüm Standartları –Etalon9
3.2.2 Metrolojide ISO Sözcük Varlığının Temel ve Genel Terimleri
ISO dokümanı, ulusal ve uluslararası yasal bir uzlaşma ile oluşturulmuş metrolojide
kullanılan genel ve temel terimlerin ISO söz varlığıdır (ISO VIM, 1993). Anahtar
ISO dokümanları metroloji alanında yaygın olarak bilinmesine rağmen, yazılım
metriği kullanıcıları bunlardan çok düşük oranda yararlanırlar. VIM birbirleri ile
ilişkili 120 ölçüm tanımlar; bunlar Tablo 4’de verildiği gibi 6 temel kategoride
düzenlenmiştir. Uluslararası söz varlığına göre standart bir etalon “malzeme ölçümü,
ölçüm aleti, referans malzemesi veya ölçüm sistemi” olarak değerlendirilir ve bir
birimin ya da bir niceliğin bir veya daha fazla değerine referans oluşturmak üzere
betimlenmesi, gerçekleştirilmesi, korunması veya yeniden oluşturulması amacı ile
9
Analitik ölçüm ya da deneylerde birim değer ya da ayar; ağırlık ya da değerin ölçümü için model 9
Zeynep ALTAN
tasarlanır. Yazılım geliştirmede yazılım metriklerinin henüz tam bir olgunluğa
erişememiş olması nedeni ile, nitelikli ürünler elde etmek için gerekli kavram ve
etalonlardan çok seyrek yararlanılmaktadır (Şekil 1). Yazılım için standart bir
etalon olmaması, bunun hiç bir şekilde gerçekleştirilemeyeceği anlamına
gelmemelidir. SWEBOK kılavuzu Ek C‘ nin içeriğini, hem IEEE ve ISO/IEC
(International Organization for Standardization/International Electrotechnical
Commission) tarafından oluşturulmuş JTC1/SC7 Yazılım ve Sistem Mühendisliği
standartları, hem de farklı kaynaklardan seçilmiş bazı standardizasyon listeleri
oluşturmaktadır. Burada 51 farklı standart, Bloom taksonomisine (Bloom ve
diğerleri, 1984) göre üç düzeyde sınıflandırılmış olan Tablo 1’deki 10 farklı bilgi
alanına özelliklerine göre dağıtılmaktadır.
Yazılım soyut bir
üründür
Yazılım sıra dışı bir
üründür
Yazılım özniteliklerinin ölçümleri
üzerinde uzlaşma çok düşüktür
Ölçümlerin tasarımı çok zor
ve uygulanabilirliği çok
düşüktür
Şekil 1: Yazılım Ölçümlerinin Tasarımındaki Güçlükler
Genel bir yazılım ölçümü ontolojisinin oluşturulduğu uluslararası projede (Garcia ve
diğerleri, 2006), ölçüm için uygun bir terminoloji oluşturmak üzere ontoloji
öncelikle İspanyolca oluşturulmuş ve İspanyolca yazılım ölçüm terimleri üzerinde
uzlaşma sağlanması hedeflenmiştir. Bu ontoloji daha sonra İngilizceye çevrilerek,
farklı iki dildeki her bir kavram için en uygun terim seçilerek ontoloji
standartlaştırılmıştır. Sonuçta bu karma çalışmanın, önceden tanımlanmış ISO ve
VIM standartları ile tam olarak eşleşmesi pek mümkün olmamıştır.
3.2.3 Fonksiyonel Büyüklük Ölçüm Yöntemi
Yazılım ölçüm standartlarının tasarımındaki süreçlerden bir diğeri, fonksiyonel
büyüklük ölçüm (functional size measurement- FSM) yöntemidir. Fonksiyonel
büyüklük için, bir başlangıç yazılım ölçüm standart etalonunun önerilmesi sebebi,
yazılım ölçüm grubu içinde izlenebilir ve iyi tanınır bir standarda olan
gereksinimdir. Büyüklük, hem araştırmacılar hem de satıcılar tarafından ölçümleri
otomatikleştirmek üzere geliştirilen yazılım araçlarının doğrulanmasında ya da
karşılıklı yapılan sözleşmelerde referans materyali olarak kullanılabilir (Khelifi ve
Abran, 2007). FSM tanımı, fonksiyonel olarak yazılımın nicelendirilmesi yaklaşımı
10
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
olarak verilebilir. FSM, ortaya çıkan ürünü kullanıcılarına teknik ve niteliksel
bakımdan bağımsız olarak teslim eder; üretkenlik, teslimat hızı, nitelik gibi
ölçümleri normalleştiren bir yöntem sağlar.
Pratikte fonksiyonel yazılım ölçüm uygulamaları, kullanılacak olan yazılım ölçüm
metodunu tanımayı ve yazılımla ilgili belirlenebilecek bilginin mümkün
olabildiğince yorumlanabilmesi tecrübesi gerektirir.
Örneğin COSMIC-FFP
(Common Software Measurement International Consortium -a Functional Sizing
Method) metodu ile ölçüm sürecinde yazılım düzeyleri, sistem sınırı, kullanıcılar,
fonksiyonel süreçleri tetikleyici olaylar, veri grupları ve veri hareketleri gibi
sağlanabilir bilgilerin belirlenmesi istenir. Dokümantasyonun tam ve doğru olması
durumunda ölçüm adımları kolaylaşacaktır. Fakat dokümantasyon pratikte bir türlü
tamamlanamaz; çünkü istenilen bilgilerin bir kısmı ya eksiktir ya da belirsizdir.
UML10 olay kullanım (use case) diyagramları sistemin tüm fonksiyonelliğini, ardışık
(sequence) diyagramlar ise yazılımın zaman içindeki davranışını sıralanmış olarak
betimler. Bu tür diyagramların oluşturulması yazılım fonksiyonlarının kapsamını
geliştirebilir ve ölçüm üzerinde çalışanların ölçüm süreçlerine daha doğru ve uygun
dokümanlar iletmeleri sağlanabilir.
3.3 Türkiye’de Yazılım Mühendisliği Programları
Bu bölümde yazılım mühendisliği programlarının nasıl hazırlandığı, 2008-2009
akademik yılında eğitim-öğretime başlamış olan Beykent Üniversitesi Yazılım
Mühendisliği Lisans programının hazırlanışı örnek verilerek anlatılmaktadır.
Türkiye’deki diğer üniversitelerin yazılım mühendisliği bölümlerinin ders
programları incelendiğinde aşağıdaki sınıflandırmaya benzer bir yapıda
hazırlandıkları görülebilir.
Beykent Üniversitesi’nin Yazılım Mühendisliği
programı SWEBOK ve SE2004 kılavuzundan yararlanılarak hazırlanmıştır (Altan,
2010). Seçilen senaryoya göre öğretim programı
i.
ii.
iii.
Yazılım mühendisliği, bilgisayar bilimleri&matematiksel esasları içeren
başlangıç dersleri,
Yazılım mühendisliği çekirdek dersleri,
Öğretim planını tamamlayan diğer dersler
olmak üzere üç grupta sınıflandırılmıştır (Tablo 5). Birinci gruptaki “yazılım
mühendisliği, bilgisayar bilimleri ve matematiksel esasları içeren başlangıç
dersleri” temel bilgisayar dersleri şeklinde, bilgisayar bilimleri (bilgisayar
mühendisliği) programları ile çoğunlukla aynı zorunlu bilgisayar derslerini içerir.
Tablo 5 : Beykent Üniversitesi Yazılım Mühendisliği Lisans Programı
10
Birleştirilmiş modelleme dili (Unified Modelling Language) OMG (Object Management Group)
tarafından geliştirilmiş; Grady Booch, J ames Rumbaugh ve Ivar Jacobson’ nun katkıları ile 1999
yılında dokümanlaştırılmıştır. 11
Zeynep ALTAN
YM, BB, BM11
ve
matematiksel
esasları
içeren başlangıç dersleri
YM Giriş (Sadece YM
bölümü
Yapısal ve Nesneye Yönelik
Programlama Dilleri (ilk 3
sınıf
farklı
diller
ve
yarıyıllarda tüm bölümler )
Veri Yapıları ve
Algoritmalar (tüm bölümler
Ayrık
Matematik
(tüm
bölümler, YM bölümü 2
yarıyıl)
Olasılık ve İstatistik (tüm
bölümler)
YM çekirdek dersleri
Öğretim Planını
Tamamlayan Diğer Dersler
İnsan-Bilgisayar
Etkileşimi
Veri Tabanı Yönetimi -DTD
Yazılım
Arayüzü
Tasarımının Temelleri
İşletim Sistemleri -DTD
Yazılım
Gereksinmeleri Analizi
Sistem Analizi ve Tasarımı DTD
Yazılım Tasarımı ve
Mimarisi
Bilgisayar Mimarisi -DTD
Yazılım
Dilleri
Bilgisayar Haberleşme ve Ağ
Teknolojileri - DTD
Modelleme
Yazılım Mühendisliği
Projesi
Mühendislik ekonomisi -TOD
Biçimsel
Diller ve
Otomat Teorisi
İşletmeye Giriş - TOD
Yazılım
Yönetimi
Profesyonel Etik- TOD
Projesi
Bilgisayar
Destekli
Yazılım Tasarımı
Girişimcilik -TOD
Yazılım
Niteliğinin
Sağlanması ve Testi
Matematik I-II –
Lineer Cebir - SD
İnternet
Tabanlı
Yazılım Tasarımı
Diferansiyel Denklemler -SD
Bitirme Projesi
Teknik Seçimli Dersler - SD
Bu derslerin tümü SEEK (Software Engineering Education Knowledge)12
kapsamındadır. Türkiye’de bilgisayar mühendisliği bölümlerinin pek çoğunun
programları gerçekte bilgisayar bilimleri programı olması nedeni ile,
sınıflandırmada her iki dal da ifade edilebilir. Bu gruptaki ayrık matematik dersi,
11
YM Yazılım Mühendisliği, BB Bilgisayar Bilimleri, BM Bilgisayar Mühendisliği SEEK, yazılım mühendisinin bilmesi gereken her şeyin sınıflandırmasıdır. Bunlar bilgi alanı (yapısal
elemanların yüksek düzeyli kodlaması), birimler (tematik parçaların tanımlandığı küçük alanlar) ve en
düşük düzeyi veren konular olmak üzere üç farklı düzeyde ve Bloom taksonomisine göre hazırlanmıştır.
Örneğin bilgi alanı CMP Computing Essentials, birimi CMP.fm Formal Construction Methods ve
konusu CMP.fm.1 Application of Abstract Machines ya da CMP.fm.2. Application of Specification
Languages and Methods gibi.
12
12
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
çalışmanın konu başlığında açık olarak verildiği gibi, yazılım mühendisliği
programlarında diğerlerinden farklı olarak iki yarıyıl okutulmalıdır.
“Yazılım mühendisliği çekirdek dersleri” başlangıç derslerinin tamamlanmasından
sonra programda yer alan derslerdir. Bu gruptaki dersler aslında yazılım
mühendisliğinin tanımını oluştururlar. Kısaca, müşterinin isterleri doğrultusunda,
minimum zamanda, düşük maliyetli ve yüksek nitelikli ürünler geliştiren yazılım
mühendisinin yetiştirilmesini hedefleyen dersler bu grupta yer alır.
Son gruptaki “öğrenim planını tamamlayan dersler”, sınıflandırma dışında kalan
zorunlu dersler ve SEEK dışı dersler (SD) olarak iki grupta incelenir.
Sınıflandırmaya girmemiş zorunlu dersler, diğer temel bilgisayar bilimleri
/bilgisayar mühendisliği dersleri (DTD), teknik olmayan dersler (TOD) adı altında
sınıflandırılır.
SEEK sıralanışında bulunmayan teknik seçimli dersler 3. ve 4. sınıfların tüm
yarıyıllarında öğrencilerin ilgi alanlarına göre seçim yapabildikleri derslerdir. Bu
dersler hem endüstriden uygulamalı konuları içerecek şekilde belirlenmekte, hem de
bilgisayar mühendisliği seçimlik dersleri ile ortak olarak düzenlenmektedir.
Yazılım mühendisliğinin bilimsel temeli öncelikli olarak bilgisayar bilimleridir. Bir
başka ifade ile bilgisayar bilimleri ve yazılım mühendisliği disiplinleri birbirini
tamamlamaktadır. Bilgisayar mühendisliği (bilgisayar bilimleri) bölümlerinin
çoğunda yazılım mühendisliğinin öğretildiği düşünülür. Oysa Tablo 5’in orta
sütununda da görüldüğü gibi çekirdek yazılım mühendisliği derslerinin hiç biri bu
bölümlerin programında yer almaz. Kısaca yazılım, öğrencilerin eğitimlerini
tamamladıktan sonra, çalıştıkları her projenin çözüm yollarını geçici yöntemlerle
öğrenecekleri bir disiplin değildir; yazılım ayrıca diğer mühendislik ürünlerinden de
ayrı tutulamaz. Sistemin bir parçası olarak çeşitli fiziksel bileşenler içerir ve bu
bileşenlerle ilgili bilgiyi hesaplar. Bilgisayar mühendisliği ise, yazılım ve donanımın
genel kavramlarını içeren bir disiplin olması nedeni ile, bilgisayar mühendisleri
hem yazılım, hem donanım içeren bilgisayar sistemlerinin analiz ve tasarımı ile
ilgilenir.
4. BİÇİMSEL YÖNTEMLER VE YAZILIM MÜHENDİSLİĞİNDE ÖNEMİ
Mühendislik çalışmalarının tümünün temeli, planlanan sistem tasarımlarının
modellenmesi ve bu modellerin sistem özelliklerinin tanımlanmasıdır. Bunlardan
bazıları fiziksel modellerdir; pek çoğu ise tasarım kararlarının sonuçlarının analizi
ve betimlenmesi için büyük ölçüde matematikten yararlanır. Geleneksel
matematiksel disiplin sürekli matematik, yani analiz ve diferansiyel denklemler
kullanır. Oysa yazılım mühendisliğinde modeller daha çok ayrık matematik, mantık
ve küme teorisine dayalı teknikler ile şekillenir. Problemlerin çözümlerinin bu
13
Zeynep ALTAN
şekilde modellenmesi yaklaşımları biçimsel yöntemler13 olarak adlandırılır ve bu
yöntemler genellikle geliştirme araçlarının kullanılması ile uygulanır. Gömülü
yazılım içeren karmaşık sistemlerin sayısı hızla arttıkça, yazılım-yoğun bu
sistemlerde güvenilirliğin sağlanması ve korunması da gittikçe güçleşmektedir.
Pek çok üniversitede gerek bilgisayar bilimleri ve bilgisayar mühendisliği
bölümlerinde, gerekse yazılım mühendisliği bölümlerinde yazılım geliştirmeye
yardımcı olmak üzere, eğitim programları en az bir tane biçimsel yöntemler dersi
içerir.
Biçimsel yöntemlerin teknik ilerlemesini yıllardır sürdürmesine ve pek çok sistemin
geliştirilmesindeki başarısına rağmen, ne endüstride ne de ticari yazılım geliştirme
ortamlarında standart ve etkin bir yöntembilim olarak tanınmakta ve kabul
edilmektedir. Oysa biçimsel yöntemlerin temel teknik üstünlükleri göz önüne
alınırsa, bu yöntemlerden yararlanılması gerektiği gerçeği önemli ölçüde
anlaşılacaktır. Biçimsel yöntemlerin kullanımında endüstrideki isteksizliğin en
önemli nedeni, yeni teknolojiler konusundaki bilgisizliktir. Bu nedenle bu
yöntemlerin endüstride gerçek yazılım geliştirme uygulamaları için gerekliliği
mutlaka araştırılmalıdır. Bu da yazılım mühendislerinin yöneticilerle birlikte ortak
davranmaları ve uyumlu kararlar almaları ile sağlanabilir. Endüstriyel yazılım
mühendisliğinde biçimsel yöntemlerden yararlanmanın sürekli tartışılmasının diğer
nedeni de, yazılım maliyetini çok yükseltmesidir.
Diğer taraftan güvenlik ve
gizliliğin önemli olduğu yüksek düzeyde yazılım tamlığı (bozulmamışlık) içeren
sistemlerinin geliştirilmesinde biçimsel yöntemlerden her dönemde daha fazla
yararlanılmıştır. Biçimsel yöntemler üzerindeki yeni araştırmalar, fonksiyonel
davranışı modellemede kullanılan herhangi bir tekniğin sadece bazı kısımlarından
yararlanılması yönünde değişmektedir. Böylece tekniğin tümünün değil, problem
için gerekli olan bölümlerinin uygulanması kullanımı kolaylaştırmaktadır. Bu
yaklaşım yalın (lightweight) biçimsel yöntemler olarak adlandırılır (Jackson ve
Wing, 1996). Yalın yaklaşım ile problemin çözümünde dilde, modellemede,
analizde ve birleşimde biçimsel yöntemler kısmi olarak, bir başka ifade ile
uygulamanın gerektirdiği kadar kullanılır. Böylece hem yazılımın maliyeti düşer;
hem de uygulamadan daha fazla yarar sağlanır.
Yazılım mühendisliği
araştırmalarından endüstrideki gerçek kullanıma mutlaka bir yol olması gerekliliği
araştırmacılar için oldukça zorlayıcıdır. Buna rağmen yazılım geliştiricileri daha
gerçekçi ve verimli ürünler oluşturmak üzere araştırmacıların fikirlerinden
yararlanabilirler. Bu nedenle de biçimsel yöntemlerin herhangi bir problemin
araştırılması aşamasında bir çözüm olup olmayacağı sorusu mutlaka
cevaplandırılmalıdır.
13
Bilgisayar bilimlerinin temeli hesaplama teorisine giriş olan biçimsel yöntemler lojik, diller ve
otomatlar, hesaplanılabilirlik ve karmaşıklık kavramlarını inceler. Bilgisayar yazılımı, donanımı ve
bunların belirli uygulamalarının temel matematiksel özellikleri araştırılır. Hesaplanabilir ya da
hesaplanamayan işlemler, hesaplanabilir olanların ne kadar bellek ile ne kadar hızlı
gerçekleştirilebileceği başlıca konularıdır. 14
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
Matematiksel düşünce tarzı, yazılım davranışının biçimsel modellerini geliştirmek
için gereklidir; aynı düşünce mühendislik bakış açısına göre ise, çalışan bir yazılım
geliştirmek amacı ile biçimsel yöntemlerin gereksiniminin fark edilmesidir (Offutt,
2008). Burada yazılım mühendisliği ve matematik eğitimleri arasındaki fark da
açıklaştırılabilir. Bilinmesi gereken mühendislerin pragmatik davrandıkları ve
problemi daha iyi anlamalarına ve tasarım sonuçlarına erişmelerine yardımcı olacak
bir hesaplama aracının kullanımına güvendikleridir. Oysa matematikçiler için bir
hesaplama aracının kullanılması yararlı olmasına rağmen, yeterli değildir.
4.1 Temel Biçimsel Belirtim Yöntemleri
Herhangi bir yazılım sisteminin oluşturulması tamamen bir tasarım aktivitesidir.
Yazılım genellikle ya çok kötü ya da büyük güçlüklerle mükemmel olarak tasarlanır.
Çünkü çalışma takviminde tasarım aşamaları eksiksiz tamamlanmış olsa bile,
geliştirme sırasında bazı durumların ihmal edilmesi söz konusu olabilir. Tasarım
sürecini oluşturmada ve bu sürecin kontrolünde temel rol ayrıştırma ve soyutlama
şeklinde problemin parçalara bölünmesidir. Problemin alt problemlere bölümünde
iyi bir ayrıştırma yapmak için, alt problemlerin tümünün aynı ayrıntı düzeyinde
olmasına, her bir alt problemin bağımsız olarak çözülebilmesine ve bu çözümlerin
birleştirilerek problemin asıl çözümünün elde edilmesine dikkat edilmelidir.
Biçimsel Belirtim Yöntemleri
Biçimsel
Biçimsel İspatlar
Belirtimler
Model Denetimi
Soyutlama
Şekil 2: Temel Biçimsel Belirtim Yöntemleri
Yazılım tasarımı soyuttur; bu nedenle elle tutulamaz. Fakat farklı parçaların
tasarımları gerçekleştirilirken, bunların birbirleri ile iletişim halinde olmaları
gerekir. Bu da yazılım geliştirmede önemli bir aşama olan yazılımın belirtimi, bir
sistemin ve özelliklerinin tanımlanması sürecidir. Belirtim, uygulama programından
bağımsız olarak soyutlamanın ne olduğunu tanımlar; bunun için de biçimsel
yöntemlerden yararlanılır. Biçimsel belirtim yöntemleri Şekil 2‘de verildiği gibi
biçimsel belirtimler, biçimsel ispatlar, model denetimi ve soyutlama olarak dört
farklı şekilde gerçekleştirilir; bu yöntemlerin tümünde sözdizimi ve semantiği
matematiksel olarak tanımlanmış herhangi bir dil kullanılır. Z (Davies ve
Woodcock, 1996), VDM (Vienna Development Method) (Fitzgerald ve diğerleri,
15
Zeynep ALTAN
2005) ve Larch (Guttag ve Horning, 1993) gibi bazı temel biçimsel yöntemler
ardışık sistemlerin davranışlarının betimlenmesi üzerine odaklanmıştır.
4.1.1 Z Belirtim Dili
Z, en yaygın kullanılan ve başarılı yazılımlardan biri olan CICS (Customer
Information Control System) programının fonksiyonelliğini arttırmak amacı ile
70’li yıllarda IBM laboratuarlarında bilgi yönetimini gerçekleştirmek üzere
geliştirilmiştir. O yıllarda veri erişimi, iletişim, bütünleşme ve güvenli hizmetler
sunan sistemlerin geliştirilmesi önemliydi. Bu gösterim ilk uygulamalarda hiç
matematik bilgisi olmayan programcılar tarafından bile kolaylıkla öğrenilebiliyordu.
Sonuç ise, elde edilen kodun niteliği ve güvenilirliğinde açık olarak bir gelişme
gözlenmesiydi.
Z gösterimi aslında güçlü yapısal mekanizması olan matematiksel bir dildir. Doğal
dille birleştirilerek biçimsel belirtimlerin oluşturulmasında kullanılır. Bu belirtimler
matematiksel mantığın ispat teknikleri kullanılarak gerçekleştirilmiştir. Çalışan
koda daha yakın bir başka tanımlamanın verilmesi ile belirtim yenilenebilir. Z ile
kullanılabilirlik, performans, güvenilirlik gibi fonksiyonel olmayan özellikler
betimlenemez; zamana bağlı ve dönemdeş davranışın betimlemesi de yapılamaz.
Tablo 6 ‘da verilen örnekten görülebileceği gibi, Z dilinde matematiksel dil ve şema
dili olmak üzere iki farklı dil kullanılır. Matematiksel dille nesneler ve nesneler
arasındaki ilişkiler gibi tasarımın farklı şekilleri betimlenir. Şema dili ise bilgi
parçalarının harmanlanması, kılıflanması ve yeniden kullanmak üzere
isimlendirilmesi gibi betimlemeleri gerçekleştirmek ve bunları birleştirmek üzere
kullanılır. Yeniden kullanılabilirlik bir biçimsel tekniğin yeniden kullanımında çok
önemlidir. Ortak bileşenlerin tanımlanması ve paylaşılması ile betimlemelerin hem
esnek, hem de yönetilebilir olması sağlanır. Şema dili, bölümleri paylaşan
belirtimler, parametreleri paylaşan kanıtlar, soyutlamaları paylaşan teoriler, genel
durumları paylaşan problemlerden oluşur. Önemli olan basit teorilerin geliştirilerek
bunları betimleyen anlaşılabilir, sade şemaların kullanılmasıdır.
4.1.2 Vienna Development Method
VDM (Vienna Development Method), Z belirtim dili gibi ilk defa 70’li yıllarda
IBM Viyana Laboratuarı’nda geliştirilmiştir; bu belirtim dili ile yapılan ilk
uygulamalarda dil tanımlamaları ve derleyici çalışmalarına odaklanılmıştır. VDM
biçimsel betimleme ve hesaplama sistemlerinin geliştirilmesi için kullanılan
tekniklerin bir derlemidir ve biçimsel gösterim olarak nesneye yönelik modellerin
sınıf yapısı görünümü ile probleme fonksiyonel bakış arasındaki çözümün
geliştirilmesi ve tamamlanması amaçlanır. Biçimsel yöntemlerin gelişimleri boyunca
VDM oldukça uzun bir yaşam süresi geçirmiştir. Birbirinden farklı pek çok
geliştirme araçları somutlaştırma amaçlı kullanılmış; sonraları bunların bir kısmı
16
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
Tablo 6. Tiyatro biletleri satışının Z belirtim dili ile gerçekleştirilmesi
TİYATRO BİLETİ
ŞEMA ÖRNEĞİ
[OTURMA DÜZENİ]
[KİŞİ]
Sınırlayıcı Yüklemler
OyunBiletleri() //Şema Formunun İsmi
oturacakyer : P14 OturmaDuzeni
satılan: OturmaDüzeni→Kişi
dom15 satılan ⊆ oturacakyer
Biletlerin
Formal
Olmayan Belirtimi
Z dili ile Belirtim
Tiyatro: İlk gece performansının biletleri sadece yakınlara
satılır
Durum::=standard | ilkGece16
Sembolik Bildirimler
Sembolik Bildirimler
Sınırlayıcı Yüklemler
Arkadaşlar
/ /Şema Formunun İsmi
arkadaşlar : P Kişi
durum : Durum
satılan:OturmaDüzeni →Kişi
durum= ilkGece ⇒ ran satılan⊆arkadaşlar
Tiyatro : İlk performansı ise, sadece arkadaşlara satılması
Sembolik Bildirimler
? Giriş
Sınırlayıcı Yüklemler
Sembolik Bildirimler
Sınırlayıcı Yüklemler
Z dili ile Belirtim
Sembolik Bildirim
Sınırlayıcı Yüklem
SatınAlma1 //Şema Formunun İsmi
Δ17OyunBiletleri1 s?: OturmaDüzeni
p?: Kişi
s?∈oturacakyer \ dom18 satılan
durum = ilkGece ⇒ (p?∈arkadaşlar)
satılan′ =satılan ∪ {s?→p?}
oturacakyer′ = oturacakyer
arkadaşlar′ =arkadaşlar
MevcutOlmama
//Şema Formunun İsmi
Ξ19OyunBiletleri1 s?:OturmaDüzeni
p?:Kişi
s?∈ dom satılan∨(durum=ilkGece ∧¬ p?∈arkadaşlar)
Karşılık:= alımGerçekleşti | üzgünüm
Başarısızlık
/ /Şema Formunun İsmi
r!: Karşılık
r!=üzgünüm
Başarı
/ /Şema Formunun İsmi
Sembolik Bildirim
r!: Karşılık
Sınırlayıcı Yüklem
r!=alımGerçekleşti
OyunBiletleriHizmet= (SatınAlma1 ∧ Başarı) ∨ (MevcutOlmama ∧ Başarısızlık)
14
OturmaDüzeni tipindeki elemanlar kümelerinin tipi. Benzeri tanım aşağıda Kişi tipindeki elemanlar
kümelerinin tipi olarak yapılmıştır.
P OturmaDüzeni′ = P OturmaDüzeni ⇔ OturmaDüzeni′ ⊆ OturmaDüzeni 15
R Tanım Aralığı: dom R={a : S , b : T \ a→ b∈ R• a } 16
İsim ::= SembolikBildirim \ SınırlayıcıYüklem 17
ΔOyunBiletleri1= OyunBiletleri1∧ OyunBiletleri1′ 18
R Değer Aralığı: ran R={a : S, b : T \ a→ b∈ R• b } 19
Ξ şema =Δ şema ∧ (x1=x1’ ∧ …..∧xn’) x1,x2,….,xn şema değişkenleri. Bu operatör durumu
değiştirmez.
17
Zeynep ALTAN
terk edilmiştir. VDM-SL (VDM Specification Language) nesneye yönelik bir
belirtim dilidir. Bu belirtim dilinde, soyut gereksinim belirtimleri ile ayrıntılı tasarım
belirtimleri arasındaki bağlantıları sağlamak üzere veri ve işlemlerin ayrıştırıldığı
kurallar verilir. VDM-SL dilinin biçimsel semantiği ve sözdizimi 1996 yılında ISO
tarafından onaylanmıştır.
Tablo 7’de VDM-SL belirtimleri kullanılarak otomatik test verilerinin oluşturulduğu
çalışmadan bir özet verilmektedir (Atterer, 2000). Bu çalışmada VDM belirtimlerine
yüksek düzeyde önem verilerek geleneksel yazılım geliştirme yöntemlerine göre,
daha az yanlış içeren nitelikli ürün oluşturulması amaçlanmıştır. Bu da her bir
bileşenin nasıl gerçekleştirildiği değil, her bileşenin ne yaptığının kesin belirtimi ile
sağlanmıştır. Ayrıca testlerin gerçekleştirimi için insana gereksinim olmadığından
ürün maliyeti düşmüştür.
Tablo 7. VDM-SL dilinde bir belirtim örneği
Bir
fonksiyon
için
VDM-SL
dilinde
belirtim örneği
Fonksiyonun
Bölümlenmesi Tanım kümesinin
tanımlanması
Alt bölümlemelerin tüm
olası
durumlarının
birleştirilmesi
İmplementasyon
İmplementasyon
Yazılan
fonksiyonun
testi
Functions
ornek(x: int) r: bool – – x tamsayı argümanı, r boolean veri tipinde dönen
değer
pre x <> 5
– – fonksiyon hiçbir zaman x=5 olarak çağrılmayacak
post r <=> (x > 1) – – x değeri 1 değerinden büyük ise, true döndür.
Fonksiyonun ön koşulu x≠ 5 ile x∈Ζ x<5 ve x>5 alt koşullarını doğurur
X
Dört denklik sınıfı
x < 5 ∧ r ∧ x > 1, x > 5∧ r ∧ x > 1, x < 5∧ ¬r ∧ x ≤1 ve x > 5∧ ¬r ∧ x
≤1.
Son öngörüm çelişkili olduğu için, bu durum için hiçbir test durumu
oluşturulmaz.
Functions
a(i: int) r: int
pre i = 0
post r = i ;
x(x: int) r: bool
pre x <> 5
post r <=> (x > 1)
operations
o() i: int
ext wr x: int
post i = 5
– lokal durum kapanmadan önce, durum test edilir
1 functions
2 f() r: bool
3 post r or n;
4
5 g(r: int)
6 r: bool
7 post true
18
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
VDM++ miras ve birliktelik ilişkileri ile de bağlanabilen sınıfların bir derlemidir ve
ESPRIT projesinin bir parçası olarak Avrupa Komisyonu Afrodite (Goldsack ve
diğerleri, 1996) projesi ile başlatılan bir dil çalışmasıdır; VDM-SL dilinin nesneye
yönelik, dönemdeş ve gerçek zamanlı bir genişlemesidir. VDM sürekli ve melez
davranışın belirtimlerini destekler; burada zaman değişkenleri bir sınıfa ya bir giriş
ya da bir çıkış oluştururlar. VDM++ modelleme biçimsel yöntemlere bağlı olmasına
rağmen, yazılım geliştirmenin gerçek dünyasından ayrılan matematiksel bir
kullanım değildir.
Bugün kullanılan en güncel geliştirme araçları VDM++ ve VDM-SL,
dokümantasyon özelliği güçlü nesneye yönelik modellerin sezgisel biçimsel belirtim
dilleridir. Dillerin ikisi de, basit veri tipi tanımlamalarından, bilgisayarda birden
fazla yürütüm yolunun işlemesi olan çoklu izleğe ve izlek dönemdeşliğine kadar
birbirinden farklı pek çok özelliği geniş bir havuzda bulundurur. VDM geliştirme
araçlarının özelliklerinin Java ve C++ dillerinde yazılması oldukça uygundur. Ayrıca
sentaks ve tip kontrolü ile sözdizimsel olarak doğru modellerin oluşturulmasını
sağlanır. Yorumlayıcı ve özellikle hata ayıklayıcı program ile model testi
gerçekleştirilir ve hatanın kaynağının bulunmasını sağlanır. VDM araçlarının
olumsuz özelliği kullanılabilirlikteki boşluğudur. Modeller için bir iç editör mevcut
değildir. Bu nedenle kullanıcının belirtimleri değiştirmek için herhangi bir editör
kullanması gerekebilir. Bir başka olumsuz özellik ise, hata listesinin hiçbir şekilde
boşalmamasıdır. Bu da hangi hataların yeni, hangilerinin kontrol altında olduğunu
görmeyi oldukça güçleştirmektedir.
4.1.3 Larch Belirtim Dili
70’li yıllarda sadece cebirsel yaklaşımlı betimlemenin pratik olmadığı görülerek,
hem cebirsel yaklaşımlı, hem de işlemsel betimlemelerin birleşimi olan iki işlenenli
(dyadic) betimleme önerilmiştir (Guttag,1974). 1983 yılına kadar iki katmanlı
betimlemenin temelleri üzerinde araştırmalar devam etmiş ve LSL dili (Larch
Shared Language) ortaya çıkmıştır. Bu çalışmalar soyutlama ve betimleme temelli
olarak MIT Laboratuarlarında gerçekleştirilmiştir. 1987 yılında Larch çözümleyici
ilk defa MIT dışında kullanılmış; sonraki yıllarda çözümleyicinin kullanımı farklı
araştırma laboratuarlarına da yayılmıştır.
Larch iki-düzeyli bir belirtim yaklaşımıdır. Her bir Larch belirtiminin iki farklı dilde
yazılmış bileşenleri vardır: bunlardan biri belirli bir programlama dili için
tasarlanmıştır ve Larch arayüz dilidir; diğeri ise herhangi bir programlama dilinden
bağımsızdır ve LSL (Larch Shared Language) olarak adlandırılır. Arayüzün kritik
tarafı bileşenlerin arayüz ile nasıl iletişimde bulunduğunun betimlenmesidir. Bu
iletişim mekanizması programlama diline göre değişir. Örneğin bazı programlama
dillerinin kural dışı durumları işaretleyen mekanizmaları varken, bazılarının yoktur.
Arayüz betimleme dili bir programlama dilini yansıttığında iletişimin gerçekleşmesi
daha kolaydır. LSL belirtimleri ise arayüz belirtimlerindeki terimlerin belirli
matematiksel tanımlarını gerçekleştirir. LSL katmanındaki temel yapılarla, arayüz
katmanındaki programlama ayrıntıları arasındaki ilgi alanlarının ayrılması esastır.
19
Zeynep ALTAN
LSL, pek çok programlama diline göre daha basit semantik içerir. Bu nedenle de
hata yapma olasılığı daha azdır; yapılan hataların bulunması da daha kolaydır.
Larch/C++, C++ sınıflarının ve fonksiyonlarının davranış ve arayüzlerini biçimsel
olarak betimleyen bir gösterimdir. Amacı C++ programlama diline yakın olarak
miras özelliklerini ve davranışsal tiplemeleri (subtyping) desteklemektir. Tablo 8’de
bankadan para aktarımı ile ilgili bir belirtim örneği
Larch/C++ dilinde
verilmektedir (Leavens, 1997). 90’lı yıllarda Larch/C++ ile başlayan nesneye
yönelik programlama için nesnelerin davranışlarını betimleme dili çalışmaları
Larch/Smalltalk ve Larch/CORBA arayüz tanımlama dilleri ile devam etmiştir.
Tablo 8. Kaynak hesaptan havuz hesabına 100 dolar transfer eden Larch/C++
betimleme örneği20
#include "BankAccount.lh"
extern void transfer
(BankAccount& source,
BankAccount& sink,
Money amt)
throw();
//@ behavior {
//@
requires source ~= sink /\ assigned(sink, pre)/\
assigned(source, pre)
//@
/\ source^.credit^ >= amt /\ amt >= 0;
//@
modifies source^.credit, sink^.credit;
//@
ensures sink'.credit' = sink^.credit^ + amt
//@
//@
//@
/\ source'.credit' = souce^.credit^ - amt;
example amt = money(100/1)
/\ source^.credit^ = money(500/1) /\ sink^.credit^ =
money(200/1)
//@
/\ source'.credit' = money(400/1) /\ sink'.credit' =
money(300/1);
//@ }
20
Biçimsel olmayan deyimler Larch/C++ biçimsel betimleme dilinde yorum olarak yazılabilir. Bu
bildirimlerin implementasyonda görülmesine gerek yoktur. 20
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
4.2 Biçimsel Yöntemlerin Uygulamaları
Biçimsel yöntemler programların doğruluğunu ispatlamak üzere kullanılabileceği
gibi, programların tüm olarak fonksiyonel davranışının belirtimi ya da yazılım
davranışındaki herhangi bir özelliğin kısmen belirtimi için de kullanılabilir. Yazılım
mühendisliği lisans programlarının çoğunda tasarım ile birlikte biçimsel
matematiksel modellemeye de önem verilmektedir; özellikle 90‘lı yılların ikinci
yarısından itibaren programların çoğunda amaç, yazılımın yaşam döngüsü süresince
ürün geliştirecek yeni bir mühendis tipinin yetiştirilmesi olmuştur. Örneğin
Rochester Institute Technology (RIT) eğitim programlarında biçimsel yöntemlere
yalın yaklaşan örneklerden biri olan Alloy nesne modelleme sistemini kullanır
(Jackson,2002). Öğrenciler eğitimleri süresince geliştirecekleri sistemlerin
modelleme ve analiz gereksinmelerini Alloy kullanarak gerçekleştirmektedir (Lutz,
2006). Bu sistem, örnek olay- kullanım sürücülü geliştirme ile Z işaretleme
sisteminin bazı durumlarının sentezini gerçekleştirir. Alloy nesne modellemede
kullanılan bir başka yalın örnek, yine Z sistemine benzer belirtimleri olan VDM
araçlarıdır. Bir yazılım çalışmasında geliştirilen modelin özellikleri, Z ve VDM
gibi dillerin bazı aksiyomlarını, teorem çıkarım kurallarını ve ispat tekniklerini
kullanarak analiz edilir. Bu tür sistemlerin en büyük yararı, her bilgi düzeyindeki
kullanıcının yararlanabilmesidir. Geliştirme aracı basit bir model denetim programı
olabildiği gibi, kişinin derin matematik bilgisine sahip olmasını gerektiren bir
teorem çözücü de olabilir.
Biçimsel yöntemlerden genellikle soyutlama amacı ile yararlanılır. Soyutlamalar
karmaşıklığı yok etmek değil, karmaşıklığına egemen olmak üzere oluşturulur.
Yazılım modellerini belirleyen ve bunları tasarlayanlar soyutlamaları çok iyi analiz
etmeli ve biçimsel mühendislik yöntemlerini kullanarak programcıların gerçek
yazılımları daha hızlı, daha ucuza hayata geçirmelerine yardımcı olmalıdır.
Diğer bir biçimsel yöntem olan donanımın doğrulanması ise, model denetimi ve
teorem kanıtı tekniklerinin endüstriye uyarlanarak şartlara daha uygun bir
benzetimin gerçekleştirilmesidir. Model denetimi ile sistemin sonlu bir modeli
oluşturularak, modelin özellikleri kontrol edilir. Denetim modeli, sonlu olduğu için
Şekil 3’te görüldüğü gibi, kesin olarak sınırlanmış tam kapsamlı bir durum-uzay
aramadır. Model denetimindeki ilk uygulamalar donanım ve protokol doğrulanması
şeklinde gerçekleşmiştir.
Teorem kanıtı ise, sistem ve sistemin özelliklerinin matematiksel mantıkla formüle
edilmesidir. Biçimsel sistem olarak adlandırılan bu mantık, bir dizi aksiyom ve
çıkarım kurallarından oluşur. Teorem kanıtı mevcut aksiyom sisteminden
özelliklerin kanıtının bulunması işlemidir. Problem kanıtlayıcılar genel amaçlı
programların kullanıldığı otomatik sistemlerden, matematiğin sistematik biçimsel
gelişiminin uygulandığı özel amaçlı etkileşimli sistemlere kadar çok geniş bir
yelpazede sınıflanırlar.
21
Zeynep ALTAN
A
B
C
Her bileşen bir sonlu durum makinesi ile modellenir
kilitlenme
Şekil 3. Model Denetimi
Tam kapsamlı test =sistematik durum uzay açınsam
4.2.1 Yazılımın Belirtimi ve Donanımın Doğrulanması Örnekleri
Yazılım mühendisliği uygulamalarında yazılımın belirtimi ve donanımın
sağlanmasında biçimsel yöntemlerden yararlanılmasıyla, hem araştırmacılar hem de
uygulayıcılar için oldukça verimli endüstriyel yazılım ürünleri geliştirilmiştir.
Biçimsel belirtim 90’lı yıllarda öncelikli olarak ticari ve güvenlik açısından kritik
sistemler üzerinde uygulanmıştır. O yıllarda endüstride biçimsel yöntemlerin farklı
uygulama alanlarında kullanıldığı büyük proje örnekleri aşağıda verilmektedir:
i.
ii.
iii.
iv.
Veritabanı: Hasta bilgilerini depolayan ve bunları izleyen gerçek-zamanlı
“HP Medical Instruments” ürünü veri tabanı (Bear ,1991),
Aygıt: Tektronix ailesinin geliştirdiği osiloskop (Delisle ve Garlan 1990),
Schlumberger hattında evlerin elektrik saatlerinin geliştirilmesi (Arnold ve
diğerleri, 1996),
Donanım: INMOS kayan nokta işlemcisi (Barrett, 1989), INMOS T9000
taşıyıcısındaki sanal kanal işlemcisi (Barrett , 1995).
Tıp: 1995 yılında Washington Üniversitesi’nde geliştirilen “The Clinical
Neutron Therapy System”. (Jacky,1995),
22
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
v.
vi.
vii.
viii.
Güz 2010
Güvenlik: NATO Hava Komuta ve Kontrol sistemi için güvenlik politikası
modeli (Boswell, 1995) ,
Nükleer: Argonne Ulusal Laboratuarı’nın reaktör güvenlik sistemleri
çalışması (Chisolm ve diğerleri 1987), Kanada’da Darlington nükleer
üretme sistemini kapatan sistem (Archinoff ve diğerleri, 1990),
Telefon: AT&T firmasının Esterel kullanarak oluşturduğu 5ESS telefon
anahtarlama sistemi (Jagadeesan ve diğerleri 1996),
Taşımacılık: Paris metrosu için otomatik tren koruma sistemi (Carnot ve
diğerleri , 1992), İngiliz tren sinyalleşme kuralları (King, 1994).
Model denetimi tamamen otomatik ve çok hızlı gerçekleşir; ayrıca kısmi
betimlemelerin denetimi de yapılabilir. Böylece sistem tümü ile tanımlanmamış olsa
bile, doğruluğu ile ilgili gerekli bilgi edinilebilir. Model denetiminde en büyük
sorun durum sayısındaki ani artıştır. Geliştirilen sistemin genellikle 100- 200 durum
değişkeni ile kontrolü şeklinde yapılır. Bazı büyük sistemler 10120 erişilebilir durum
ile denetlenmektedir. Denetimlerde uygun soyutlama tekniklerinden yararlanılır;
böylece sistem sınırsız sayıda durum ile denetlenebilir. Aşağıda yeni tasarımların
doğrulanmasına yardımcı olmak üzere endüstriyel uygulamalarda model denetimi
uygulanan örnekler özetlenmektedir.
i.
ii.
iii.
IEEE Futurebus +: 1992 yılında Carnegie Mellon’da SMV (Symbolic
Model Verifier) kullanılarak IEEE Futurebus + Standard 896.1 adında ön
bellek eşevrelik protokolü geliştirildi. SMV dilinde protokolün kusursuz
bir modeli oluşturuldu ve elde edilen çeviri sisteminin ön bellek
eşevreliğinin biçimsel bir betimlemesini sağladığını göstermek üzere SMV
kullanıldı. Bu IEEE standardında hataları bulmak üzere kullanılan ilk
otomatik doğrulama aracıdır. Protokol geliştirilme çalışmalarının önceki
yıllarda başlamış olmasına rağmen, bunlar tamamen biçimsel olmayan
teknikler içermekteydi (Clarke ve diğerleri, 1995) .
IEEE SCI: 1992 yılında Stanford Üniversitesi’nde Murphi sonlu durum
doğrulama sistemi geliştirilerek, Scalable Coherent Interface (SCI) IEEE
Standard 1956-1992 olarak adlandırılan ön bellek eşevrelik protokolü
doğrulanmıştır (Dill ve diğerleri, 1992). SCI standardı her biri sonrakinin
alt kümesi olan pek çok protokol tanımlar. Model hataların önlenmesi için
doğrudan C dilinde geliştirilmiştir. Modeldeki durum sayısının çok fazla
olması olasılığına rağmen, sistem geliştirilirken sadece küçük örnekler
doğrulanmıştır. Bu basitleştirmelere rağmen protokolde değişenlerin
başlatılmasından, yapılan mantıksal hatalara kadar pek çok hata
bulunmuştur.
Stereo Bileşenler: Hem ayrık, hem de sürekli bileşenler içeren melez
sistemlerin tasarımında otomatik doğrulama sağlar. 1994 yılında Philips
stereo bileşenlerindeki kontrol protokolünün doğruluğunu elle çözümleyen
çalışma en iyi makale ödülünü almıştır (Bosscher ve diğerleri, 1994) . 1995
yılında ise sembolik model doğrulayıcı HyTech ile protokol soyutlaması
doğrulanarak, çıkarım tamamen otomatikleştirilmiştir (Ho ve Wong, 1995).
23
Zeynep ALTAN
4.2.2 Günümüzde Biçimsel Yöntemler
Gerek model denetimi, gerekse teorem kanıtının kullanıldığı örneklerden donanım
ve yazılım tasarımlarında günümüzde artan şekilde yararlanılmaktadır. Bunlar
çoğunlukla güvenlikle ilgili kritik özelliklerin mekanik olarak doğrulanması
örnekleridir. Örneğin NASA21 mevcut yazılım sistemlerinin doğrulanma ve
onaylanması için model denetimi ve teorem çözümü başta olmak üzere pek çok
biçimsel metodu içeren otomatik araçlar geliştirmiştir. Bu analitik araçlar,
gereksinmeler ve tasarımlarla uygunluğun sağlanması için belirtimleri matematik
olarak analiz eden algoritmalara, modellere ve kodlarına dayanır. Yazılım
gereksinmelerinin belirtiminde uygunluk denetimi metodu ile tip hataları,
belirlenimcilik durumu,
gözden kaçmış durumlar, dolaylı tanımlamalar
araştırılabilir. 2010 yılında Washington D.C.’de düzenlenecek 2.NASA biçimsel
yöntemler sempozyumunda teorem çözümü, model denetimi, istatistiksel analizi
içeren biçimsel doğrulama, otomatik test oluşturulması, kritik sistemlerin biçimsel
testi, biçimsel yöntemleri ölçekleyen teknik ve algoritmalar başta olmak üzere pek
çok biçimsel teknik teorileri, mevcut kapasiteleri ve sınırlamaları ile tartışılacak;
bunların uzay bilimlerine uygulamaları ve kritik güvenlik kavramları tartışılacaktır.
Bir başka örnek olarak VeriSoft yazılımı verilebilir (Godefroid, 1997). Burada
model denetimi, sistemin eşzamanlı süreçlerin çalışmasını gözlemler ve kontrol
eder. İşlemler iletişim, programın sonlanması, bozulmalar gibi denetlenen sistem
çağrıları ile test edilir. Spin (Ben-Ari, 2008) ise dünya ölçeğinde yaygın olarak
kullanılan açık kaynak yazılım aracıdır; dağıtık yazılım sistemlerinin biçimsel olarak
doğrulanmasını sağlar. Pek çok yazılım analizi modeline model denetimi
uygulanabilir. Bunlar genellikle C, C++, Java gibi dillerde yazılmış ve oldukça fazla
kod satırından meydana gelmişlerdir.
Problem çözümünde biçimsel yöntemlerin başlıca yararı, geliştirilen ürünlerdeki
belirsizlik ve kesin olmama durumlarının kaldırılarak tümüyle nitelikli ürünler elde
edilmesidir. Ayrıca analiz işlemlerinin otomatik olarak gerçekleşmesi istenilen
özelliklerin görüntülenmesini, istenmeyenlerin ise kaldırılmasını sağlar. Örneğin
hava trafik kontrolü gibi hatanın hiçbir şekilde toleransının mümkün olmadığı
yüksek nitelikli ürünlerin geliştirilmesinde biçimsel yöntemlerin kullanımı çok
önemlidir. Ayrıca bazı yöntemlerdeki soyutlama gücü ve otomasyon etkisi gittikçe
karmaşıklaşan yazılımlara karşı biçimsel yöntemler çözümleyici önemli bir silahtır.
Model-Sürücülü yazılım geliştirmede, biçimsel yazılım yöntemleri ve gereksinmeler
tarafından desteklenen herhangi bir geliştirme yöntembilimi OMG ve IBM
tarafından gerçekleştirilen uygulamalarda birincil yapay olguları, yani bozulma
etkisini kodun otomatik yaratılmasından oluşturur.
21
LFM - NASA Langley Formal Methods
http://shemesh.larc.nasa.gov/fm/index.html 24
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
5. SONUÇ: LİSANS PROGRAMLARININ GELECEĞİ
4. Bölüm’de biçimsel yöntemlerin yazılım uygulamalarındaki önemi örnekleri ile
ayrıntılı olarak anlatılmaktadır.
Günümüzde çok basit yazılım sistemlerinin
geliştirilmesinde bile, teorik yapının yazılım geliştirme evrelerinin içerisine
gömüldüğü görülebilir. Eğer herhangi bir sistem en temel düzeyde fonksiyonel
doğruluğu sağlayacak şekilde geliştirilecek ise, problemin pratik çözümünde
kullanılacak süreç bazı biçimsel yöntem elemanlarını mutlaka içermelidir. Bu da
yazılım mühendisliği eğitim programlarının hazırlanmasında biçimsel yöntemlerin
önemini açık olarak ortaya koymaktadır.
Öğrencilere eğitimleri sırasında biçimsel yöntemlerin öğretilmesinin bir başka
olumlu katkısı ise, problemlerin çözümüne hesaplanabilir bir düşünce yapısında
yaklaşabilmeleridir. SE2004 kılavuzunda yazılım mühendisliği bölümlerinde
başlangıç dersleri sınıflandırmasındaki ayrık matematik dersinin iki yarıyıl
önerilmesi de bu disiplinin önemini ispatlamaktadır.
Pratikte herhangi bir sistem için biçimsel betimlemeden gereksinmeler analizinin
tamamlanmasına kadar yararlanılmaz. Oysa gerçekte problemin etkin bir çözümünü
elde etmek için, ürünün geliştirme aşamalarının başlangıcından itibaren biçimsel
yöntemlerden yararlanılması gerekir. Böylesi bir uygulamanın günümüzde artık bir
zorunluluğa dönüşmesi nedeni ile yazılım mühendisliği eğitim programlarında bu
durum gözden geçirilmektedir (Cowling, 2010). Türkiye’deki pek çok kurum ve
kuruluş yazılım ürünlerinin kullanılmasına hızla artan bir şekilde ilgi
göstermektedir. Bu ilgi göz önüne alınarak endüstriyel yazılım mühendisliğinin
geleceği için, eğitim programları hizmet sektörü ve endüstri ile işbirliği halinde
olacak şekilde yeniden değerlendirilmelidir.
Yazılım mühendisliği eğitiminin gelecekteki sorunları düşünüldüğünde, günümüz
eğitim programları hazırlanırken göz önüne alınması gerekenler şöyle özetlenebilir
(Hislop, 2009):
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
Programların öğrenciler için cazip olacak şekilde hazırlanması,
En etkili şekilde eğitime odaklanılması,
Endüstri ile iletişimin daha aktif gerçekleştirilmesi,
İleriye yönelik öğretim programlarının tanımlanması,
Eğitimin mevcut öğrencilerin koşullarına göre gerçekleştirilmesi,
Eğitime daha çok gösterim odaklı bir yapı kazandırılması,
Yazılım mühendisliği eğitimi için temel altyapı gerektiğinin kabul edilmesi,
Yazılım mühendisliği eğitim araştırmalarının nitelik ve saygınlığının
arttırılması.
Yukarıdaki koşulların tümünün, hatta birkaçının sağlanması bile hesaplama disiplini
açısından çok olumludur. 90’lı yılların ikinci yarısından itibaren eğitim
programlarını hazırlayanlar, olgunluk düzeyinde bir meslek edinimi için temel taşlar
olan profesyonel eğitimin başlangıcı, akreditasyon, becerilerin geliştirilmesi,
25
Zeynep ALTAN
sertifikasyon, lisans alma, profesyonel gelişim, kodların etiği, profesyonel toplum
gibi faktörleri göz önüne alarak çalışmışlardır (Ford, 1996). Fakat günümüze
bakıldığında hem dünyada, hem de Türkiye’de tam olarak olgunlaşmış bir meslek
düzeyine henüz erişilemediği, programların temel yapı taşlarının pek çoğunun
oturmadığı görülebilir. Bu nedenle de şimdiye kadar görülen başarılarla yetinmeyip,
bu yeni disiplini ilerletmeye devam edilmelidir. Programların teknik
sınıflandırmasında fazla yer almamasına rağmen, ekip çalışması ve iletişime önem
veren ve endüstri ile bütünleşmiş bir yazılım mühendisliği eğitim programı günümüz
öğrencilerini daha fazla mutlu edebilir.
Ayrıca, SWEBOK 2010 takımının Software Engineering 2004 programlarını
güncelleme çalışmaları devam etmektedir. Programlarındaki en önemli yeniliğin
güvenlik olması çok doğaldır. Zira amatör korsanlar, ticari rakipler, kişisel suçlular,
küçük suçlu grupları, içeriden saldıranlar, organize suç konsorsiyumu, psikopat ve
sosyopatlar, sosyal protestocular ve teröristler potansiyel hücum sahiplerinden
bazılarıdır.
KAYNAKÇA
Abran, A., Moore, J.M., (2004). “Guide to the Software Engineering Body of
Knowledge: 2004 Version”, ACM SIGCSE Bulletin v.36, n.2, IEEE Press.
Archinoff, G.H., Hohendorf R.J., Wassyng A., Quigley B. Borsch M.R., (1990).
“Verification of the shutdown system software at the Darlington Nuclear
Generating System”. In Int. Conference on Control and Instrumentation in
Nuclear Installations.
Altan, Z. (2010). “Beykent Üniversitesi Yazılım Mühendisliği Lisans Programı”,
Akademik Bilişim Konferansları (AB2010), sf. 461-468.
Arnold, A., Begay, D., Radoux, J-P. (1996). “The embedded software of an
electricity meter: An experience in using Formal Methods in an industrial
project” Lecture Notes in Computer Science, vol. 1101, pp.19-32.
Atterer, R. (2000). Automatic Test Data Generation from VDM-SL Specifications,
Ph.D.Thesis, The Queen’s University of Belfast.
Barrett, G. (1989). “Formal methods applied to a floating-point number system”.
IEEE Transaction Software Engineering vol. 15, num.5. pp. 611–621.
Barrett, G. (1995). “Model checking in practice: The t9000 virtual channel
processor”. IEEE. Software. Engineering . vol 21, num 2, pp 69–78.
26
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
Bear ,S. (1991). “An overview of HP-SL”. Lecture Notes in Computer Science vol.
551, pp.571-587.
Ben-Ari, M. (2008). Principles of the Spin Model Checker, Springer Verlag.
Bloom B.S., Krathwohl D.R., Masia B.B. (1984). Taxonomy of Educational
Objectives: The Classification of Educational Goals, NewYork Longman.
Bosscher, D., Polak, I., Vaandrager, F., (1994). ”Verification of an audio-control
Protocol”, Theories and experiences for real-time system development (book
content) pp. 147–176.
Boswell, A. (1995). “Specification and validation of a security policy model”. IEEE
Transaction of Software Engineering vol. 21, num. 2, pp. 63–68.
Carnot , M., Dasilva, C., Dehbonei, B., Meija, F. (1992). “Error-free software
development for critical systems using the B-methodology”. In Third International
IEEE Symposium on Software Reliability, pp.274-281.
Chisolm, G., Kljaich, J., Smith, B., Wojcik A. (1987). “An approach to the
verification of a fault-tolerant, computer-based reactor safety system: A case
study using automated Reasoning”. Technical Report 4924 , vol. 2, Electric
Power Research Institute. Argonne National Laboratory.
Clarke, E.M., Grumberg ,O., Hiraishi ,H., Ness, L.A. (1995). “Verification of the
Futurebus+ cache coherence protocol”. Formal Methods in System Design,
vol. 6, pp. 217-232.
Cowling, A.J. (2010). ”Stages in Teaching Formal Methods”,23rd IEEE
Conference on Software Engineering Education and Training, pp.17-24.
Davies, J., Woodcock , J. (1996). Using Z: Specification, Refinement and Proof.
Prentice Hall.
Delisle, N., Garlan, D. (1990). “A formal specification of an Oscilloscope.” IEEE
Software vol. 7,num. 5, pp. 29–36.
Dill, D.L., Drexler, A.J., Hu, A.J., Yang, C.H. (1992). “Protocol verification as a
hardware design aid”.In IEEE Int. Conference on Computer Design: VLSI in
Computers and Processors, pp. 522–525.
Fitzgerald, J.S. , Larsen, P.G. , Mukherjee, P., Plat, N., Verhoef, M. (2005).
Validated Designs for Object-Oriented Systems. Springer Verlag.
Ford, G.A., Gibbs, N., (1996). “A Mature Profession of Software Engineering”,
27
Zeynep ALTAN
SEI, Technical Report CMU/SEI-96-TR-04.
Garcia F., Bertoa M.F. , Calero C., Vallecillo A., Ruiz F., Piattini M., Genero M.
(2006). “Towards a Consistent Terminology for Software Measurement“.
Information and Software Technology 48, pp. 631-644.
Godefroid, P. (1997) “Model checking for programming languages using
VeriSoft”. In Proc. of the 24th ACM SIGPLAN-SIGACT symposium on
Principles of Programming Languages, pp.174-186.
Goldsack, S., Lano, K., Sanchez, A. (1996). “Transforming continuous into
discrete specifications with VDM++”, Colloquium Digest on Hybrid Control for
Real Time Systems, UK.
Guttag, J.V. (1974) . “Dyadic specification and its Impact on reliability,” in Three
Approaches to Reliable Software: Language Design Dyadic Specification,
Complementary Semantics. TR CSRG-45, University of Toronto.
Guttag, J., Horning, J. (1993). Larch: Languages and Tools for Formal
Specification. Springer-Verlag.
Hislop G.W., (2009). “Software Engineering Education: Past, Present and
Future”, in Software Engineering Effective Teaching and Learning Approaches
and Practices, Information Science chapter 1, pp.1-14.
Ho, P-H., Wong-Toi, H. (1995). “Automated analysis of an audio control
protocol”. proc. of the 7th Int. Conference on Computer Aided Verification pp.
381 – 394.
ISO VIM. (1993). “International Vocabulary of Basic and General Terms in
Metrology”, International Organization of Standartization Geneva, Switzerland.
Jackson, D. (2002). “Alloy: a Lightweight Object Modeling Notation”, ACM
Transactions on Software Engineering and Methodology (TOSEM), pp.256-290..
Jackson D., Wing J. (1996). “Lightweight Formal Methods”, IEEE Computer,
pp.21-22.
Jacky, J. (1995). “Specifying a safety-critical control system in Z”. IEEE Trans.
Software Engineering vol.21, num. 2 . pp. 99–106.
Jagadeesan, L., Puchol, C., Olnhausen , J.V. (1996). “A formal approach to
reactive systems software: A telecommunications application in Esterel”.
Formal Methods in System Design vol. 8, num.2 , pp. 123–151.
Jalote, P. (2008). A Concise Introduction to Software Engineering, pp.2. Springer.
28
İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi
Güz 2010
Khelifi A., Abran A., (2007), “Software Measurement Standard Etalons: A
DesignProcess”, International Journal of Computers, issue 3, vol 1.
King , T. (1994). “Formalising British Rail’s signaling rules”. In FME’94:
Industrial Benefit of Formal Methods, Lecture Notes in Computer Science vol:
873, pp. 45–54.
Knight, J.C., Leveson, N.G. (2006). “Software and Higher Education inside Risks
Column”. Communications of ACM, vol. 49.
Leavens, G.T. (1997). “Larch/C++ An Interface Specification Language for C++”,
Technical Report, Iowa State University.
Lutz, M.J. (2006). “Alloy, Software Engineering, and Undergraduate Education” ,
Proc. of the 3rd Int. Workshop on Software Quality Assurance.
Naur , P., Randell, B. (editors) (1968). Software Engineering Report, NATO
Software Engineering Conference. , pp.8.
Offutt, J. (2008) . “Programmers ain’t mathematicians and neither testers”.
Lecture Notes in Computer Science 5256, pp.2.
Pfleeger, S. L. (1999). “Albert Einstein and Empirical Software Engineering”. IEEE
Computer 32, pp.32-37.
Royce, W.W. (1970). “Managing the development of large software systems:
Concepts and Techniques”. ICSE '87: Proceedings of the 9th International
Conference on Software Eng., IEEE Computer Society Press, pp. 328-338.
Tomayko, J.E. (1998) . “Forging a discipline: An outline history of software
engineering education”. Annals of Software Engineering 6 , pp. 3-18.
Vincenti, G.W. (1990) .”What Engineers Know and How They Know It” .Analytical
Studies from Aeronautical History” John Hopkins University Press.
29