YAZILIM MÜHENDİSLİĞİ EĞİTİM PROGRAMLARI VE BİÇİMSEL YÖNTEMLERİN ROLÜ

Transkript

1 İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi Yıl:9 Sayı:18 Güz 2010 s YAZILIM MÜHENDİSLİĞİ EĞİTİM PROGRAMLARI VE BİÇİMSEL YÖNTEMLERİN ROLÜ Zeynep ALTAN 1 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 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, zeynepaltan@beykent.edu.tr.

2 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, ACM 2 tarafından bilgisayar bilimleri disiplininde eğitim programlarının düzenlenmesi ile 2 Association for Computing Machinery (kuruluş 1947) 2

3 İ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 SEI 3 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-CS 4 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 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) 4 The Computer Society of the Institute for Electrical and Electronic Engineers (kuruluş 1946)

4 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 nin 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) 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 4

5 İ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. 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. ii. Öğ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

6 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

7 İ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 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. Yazılım mühendisliğinin dünya ölçeğinde en iyi şekilde yaygınlaşması, ii. 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ı, iii. Yazılım mühendisliği disiplininin içeriklerinin tanımlanması, iv. SWEBOK e konu düzeyinde erişimin sağlanması, v. Öğ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 7

8 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 7 Yazılım Mühendisliği Yönetimi 8 Yazılım Mühendisliği Süreci 9 Yazılım Mühendisliği Araçları ve Yöntemleri 10 Yazılımın Niteliği 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 4 Yönetim ve Yönetim Bilimleri 5 Matematik 6 Proje Yönetimi 7 Sistem Mühendisliği 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) sınıflandırması (Vincenti,1990), ii. iii. 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 Vincenti Mühendislik Bilgisi Sınıflandırması 8

9 İ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 Miktarlar ve Birimler 2 Kriterler ve Betimlemeler 2 Ölçümler 3 Teorik Araçlar 3 Ölçüm Sonuçları 4 Niceliksel Veri 4 Ölçüm Aletleri 5 Pratik Düşünceler 5 Ölçüm Aletlerinin Karakteristikleri 6 Tasarım Organları 6 Ölçüm Standartları Etalon 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

10 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 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

11 İ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. UML 10 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ığı, 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. Yazılım mühendisliği, bilgisayar bilimleri&matematiksel esasları içeren başlangıç dersleri, ii. Yazılım mühendisliği çekirdek dersleri, iii. Öğ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

12 Zeynep ALTAN YM, BB, BM 11 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 İnsan-Bilgisayar Etkileşimi Yazılım Arayüzü Tasarımının Temelleri Yazılım Gereksinmeleri Analizi Yazılım Tasarımı ve Mimarisi Yazılım Dilleri Modelleme Yazılım Mühendisliği Projesi Biçimsel Diller ve Otomat Teorisi Öğretim Planını Tamamlayan Diğer Dersler Veri Tabanı Yönetimi -DTD İşletim Sistemleri -DTD Sistem Analizi ve Tasarımı - DTD Bilgisayar Mimarisi -DTD Bilgisayar Haberleşme ve Ağ Teknolojileri - DTD Mühendislik ekonomisi -TOD İşletmeye Giriş - TOD Yazılım Yönetimi Projesi Profesyonel Etik- TOD Bilgisayar Destekli Yazılım Tasarımı Yazılım Niteliğinin Sağlanması ve Testi İnternet Tabanlı Yazılım Tasarımı Bitirme Projesi Girişimcilik -TOD Matematik I-II Lineer Cebir - SD Diferansiyel Denklemler -SD 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 12 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

13 İ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

14 Zeynep ALTAN şekilde modellenmesi yaklaşımları biçimsel yöntemler 13 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

15 İ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 Belirtimler Biçimsel İspatlar 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

16 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 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 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

17 İ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Ğİ Sembolik Bildirimler Sınırlayıcı Yüklemler [OTURMA DÜZENİ] [KİŞİ] OyunBiletleri() //Şema Formunun İsmi oturacakyer : P 14 OturmaDuzeni satılan: OturmaDüzeni Kişi dom 15 satılan oturacakyer Biletlerin Formal Tiyatro: İlk gece performansının biletleri sadece yakınlara Olmayan Belirtimi satılır Z dili ile Belirtim Durum::=standard ilkgece 16 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 SatınAlma1 //Şema Formunun İsmi? Giriş Δ 17 OyunBiletleri1 s?: OturmaDüzeni p?: Kişi s? oturacakyer \ dom 18 satılan Sınırlayıcı Yüklemler durum = ilkgece (p? arkadaşlar) satılan =satılan {s? p?} oturacakyer = oturacakyer arkadaşlar =arkadaşlar Sembolik Bildirimler MevcutOlmama //Şema Formunun İsmi Ξ 19 OyunBiletleri1 s?:oturmadüzeni p?:kişi Sınırlayıcı Yüklemler Z dili ile Belirtim Sembolik Bildirim Sınırlayıcı Yüklem Sembolik Bildirim Sınırlayıcı Yüklem 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 r!: Karşılık 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 (x 1=x 1.. x n ) x 1,x 2,.,x n şema değişkenleri. Bu operatör durumu değiştirmez. 17

18 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

19 İ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 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) 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 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

20 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ği 20 #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