yazılım mühendisliği eğitim programları ve biçimsel yöntemlerin rolü
Transkript
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, zeynepaltan@beykent.edu.tr. 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