İşletme Veri İşlemede Bilgisayarlar İçin Otomatik Programlamanın İşlevi
R. J. Rossheim
Endüstriyel Programlama Araştırmaları Sorumlusu
Remington Rand, Sperry Rand Corp. Bölümü, Philadelphia 3, Pa.
(14–16 Eylül 1955 tarihlerinde Philadelphia, Pennsylvania’da Association for Computing Machinery önünde sunulmuştur)
Bu bildiri, büyük, genel amaçlı bilgisayarlar için otomatik programlama sistemlerinin, bu donanımların işletme veri işleme sorunlarına uygulanmasında oynayabileceği rolle ilgilidir.
Bu tartışma amacıyla otomatik programlama tanımım son derece geniştir ve makineleri programlamak için şu anda gereken zaman ve çabayı önemli ölçüde azaltabilen herhangi bir programlama sistemini kapsamaktadır. Tanım, makine kodlamasının tamamen bürokratik bölümlerinin bilgisayarın kendisine bırakılması kavramını kesinlikle içerir, ancak bununla sınırlı değildir.
Bu bildirinin, işletme kullanımı için daha gelişmiş otomatik programlama sistemlerinin geliştirilmesine ilgi uyandırmasını ve çabayı teşvik etmesini umuyorum.
Eğitim
Bilgisayar kurulumundan önce normal olarak gelen eğitim aşamasıyla başlayacağım. Artık neredeyse bir klişe hâline gelmiş olan şu varsayımı yapacağım: Bilgisayar girişimine başlayan şirket, donanımın kullanımında kendi personelini eğitmeye karar vermiştir; şirket dışından eğitimli programcıları alıp veri işleme prosedürlerinin sonsuz ayrıntıları konusunda eğitmek yerine.
Acil sorun, esneklik, güç ve hız açısından alışık olabilecekleri her şeyin çok ötesinde olan bir makinenin kullanımında insanları eğitmektir. Çoğu zaman, seçilen kişilerin genel sistem planlamasında üstün yeteneğe sahip olmalarını isteriz; çünkü donanımın prosedürlerimiz üzerinde önemli bir etkisi olmasını bekleriz. Buna karşın, bu kişilerin yapmak zorunda oldukları ilk şey, bordro muhasebesi gibi bir işlevin yürütülmesini denetlemek üzere bit bit düzenlenmesi gereken elektronik ikililerin dönen kalabalığına kendilerini gömmektir.
Temel sorun şudur: Donanım teslim edildiğinde, içine yerleşik olarak yalnızca tek bir temel yeteneğe sahiptir; o da makinenin komut kodu olan belirli bir dili yorumlama yeteneğidir. Bu kod mantıksal olarak tamdır ve kullanıcının akla gelebilecek her gereksinimine uyarlanabilir. Aynı zamanda ilkel bir yapıya sahiptir; başka bir deyişle, tek heceli bir dildir.
Donanımın, prosedür analistinin günlük dilini yorumlayabilmesi ve bu yolla aktarılan anlamı kendi ikili düzenlemelerine çevirebilmesi durumunda eğitim sorunu önemli ölçüde azalırdı. Bu elbette bir idealdir. Bu, böyle bir dilin varlığına; ayrıca kesin anlamlara ve evrenselliğe de bağlıdır. Kavram ne o kadar yeni ne de o kadar idealdir ki, şu anda bile bu alanda çalışan bazı araştırma grupları bulunmasın.
Bence hedef, kullanıcıyı tek heceli makine konuşmasını benimsemeye zorlamak yerine, makinenin anlama düzeyini kullanıcının diline yükseltmek şeklinde ifade edilebilir.
Programlama yeteneği, veri akış diyagramı çizimi veya prosedür el kitabı yazımı gibi, görece basit bir operasyonel araç hâline gelirdi. Bu da prosedür analistinin, bir sistem içindeki veri akışına geniş açıdan bakmaya daha fazla zaman ayırmasına ve iyi bir sistem tasarımı hedefine yoğunlaşmasına olanak tanırdı.
Bu alanda çalışmak üzere seçilen kişilerin çok azı profesyonel programcı olma konusunda istekli olacaktır; dolayısıyla gereksinim, donanımı bu kişilere mesleklerinin diğer araçlarıyla tutarlı bir temelde sunmaktır.
Başlangıç eğitim aşamalarında otomatik programlama tekniklerinin hedefinin, mümkün olan ölçüde kullanıcının dilini kullanan, görece basit bir sözde kod geliştirilmesi olabileceğini öneriyorum. Bilgisayar, bu dilde yazılmış programları temel makine kodlarına çevirecektir. Bunun hemen görülecek etkisi, kursiyerlerin çok daha kısa sürede kullanılabilir programlar yazmayı öğrenebilmesi olacaktır.
Aynı zamanda eğilim, yüksek düzeyde eğitimli uzmanlar yetiştirmekten uzaklaşıp, makineler için hazırlanacak işlerde uzman olan kişilerden yarı zamanlı veya geçici programcılar geliştirilmesi yönünde olacaktır.
Şunu da belirtmeliyim ki, bildiğim kadarıyla işletme uygulamaları için bir sözde kod sistemi bulunmamaktadır; ancak aynı ilkeyi içeren bir deney iki yıl önce
Otomatik Programlamanın İşlevi
M.I.T.’deki Whirlwind bilgisayar grubu tarafından başarıyla gerçekleştirilmiştir.
Sözde Yaz Okulu Bilgisayarı, Whirlwind’in programlanmış bir değişikliğiydi ve programlama ilkelerinin, kolayca öğrenilip uygulanabilen bir sözde koda dayanarak, ilgi ve geçmişleri farklı bir öğrenci grubuna öğretilmesine olanak tanıyordu.
Yaklaşım ve Deneyleme
Sonraki olarak, otomatik programlamanın, bir bilgisayar sistemi için veri işleme prosedürlerinin zaman alıcı ve maliyetli hazırlanmasındaki rolünü ele alacağım. Bu bağlamda otomatik programlamayı kendi başına tartışmadan önce, ticari işler için programlama prosedürlerinden söz edeceğim.
Önce yaklaşım kavramı. Bu yaklaşım, bir bilgisayar veri işleme prosedürüne yerleştirilmesi gereken ayrıntılı bilginin çok büyük olmasından esinlenmiştir. Bilgiler, bazen yoruma açık olan prosedür el kitaplarından, kural ve yönetmeliklerden ya da bilgili ancak bazen kendini ifade etmekte zorlanan büro personelinden gelebilir. Bilginin niteliği ve kaynakları nedeniyle, programlamanın temel bir gereği karşılanamaz; yani “problem” ya da iş, tamamen önceden tanımlanamaz. Bu nedenle programlama çoğu zaman eksik ya da yanlış bilgilerle başlamak zorundadır ve ilk program zorunlu olarak yalnızca bir ilk yaklaşımdır.
Araştırma ve bilgi toplama ziyaretleri sırasında sessiz kalan sesler, ilk yaklaşım hedefi ıskaladığında gerekli eleştiriyi sunmakta genellikle hızlı davranır. Ardından sert gerçekler ortaya çıkmaya başlar, düzenli akış şemaları yayılıp her türlü karmaşık ağı geliştirir ve programlar mevcut depolama alanını aşmaya başlar. Eğer fikri yeterince aktardıysam, ikinci yaklaşımın da son olmadığı, üçüncünün de olmadığı söylenmeye gerek yoktur; ancak sonunda, mükemmel olmasa bile, hem büyük öneme sahip her şeyi hem de çoğu küçük ayrıntıyı kapsayan kabul edilebilir bir sürüm geliştirilir. Gerçek şu ki, yukarıda açıklanan yaklaşım tekniği bilinçli olarak kullanılmasa bile, gerçekte olan bitenin iyi bir betimlemesini sunmaktadır.
Aynı madalyonun öteki yüzü olan başka bir yaklaşım ise deneyleme fikrini içerir. Yaklaşım yöntemleri tek bir doğru ve en iyi prosedüre kademeli olarak ilerleme düşüncesini verirken, deneyleme bakış açısı, elektronik veri işleme sistemlerini tasarlamak için kullandığımız analitik araçların son derece ilkel olduğu gerçeğini kabul eder; dolayısıyla bugünkü ilerlememiz büyük ölçüde deneme-yanılma yöntemlerinin sonucudur.
Günümüzde, aynı uygulama için birden fazla farklı yaklaşımı denemek çok pahalıdır; özellikle bu, ikinci kez programlama yapılmasını gerektiriyorsa. Ayrıca, tasarladığımız sistemler, büyük değişiklikler yapma olasılığını azaltmak için genellikle çok tutucu olmaktadır. Böylece, zaman baskısı bizi en uygun olmaktan uzak olabilecek prosedürlerde karar kılmaya zorladığı için, bu yeni donanımı nasıl kullanacağımız konusunda daha fazla şey öğrenme fırsatlarının çoğunu kaçırmış oluruz.
Bu fikirler, bilgisayarlar için ticari veri işleme programlarının tasarımında yaklaştırma tekniklerinin ve denemenin kullanılmasını içerdiği ölçüde makul ise, otomatik programlama birkaç önemli rol oynayabilir. Gerçekte, yeniden kodlama yapmadan bir yaklaştırmadan bir sonrakine geçme sürecine yardımcı olacak herhangi bir sistematik programlama yaklaşımının, toplam kodlama miktarını önemli ölçüde azaltacağı açıktır.
Akış Şeması Çizimi
Şimdi, bir uygulamanın ya da işin, bilgisayar için çalışır bir program hazır hâle gelmeden önce geçmesi gereken çeşitli aşamaları ele alacağım. Bana göre, ortaya çıkan sorunların tüm alanlarda, tanımıma giren otomatik programlama tekniklerinden biri ya da birkaçı ile tamamen ya da kısmen çözülebilmiş olması anlamlıdır.
Önce akış şeması çizimini ele alalım. Görünüşe göre akış şeması, çok çeşitli biçimleriyle, veri işlemenin tanımlanmasında en kolay uyarlanabilen ve en evrensel olarak kabul edilen yöntemdir. Gereksinim, büyük ayrıntı yığınlarını hem bütünü hem de ayrıntıları aynı anda görebileceğimiz şekilde düzenlemenin bir yoludur. Tipik olarak, tüm uygulamayı ana hatlarıyla gösteren en geniş düzeydeki akış şemasından başlanır; ardından her biri ayrıntı ekleyen birkaç ardışık düzeyden geçilerek, bazı durumlarda şemadaki her bloğu gerçekleştirmek için gereken makine komutlarını neredeyse açıkça gösteren çizelgeler çizilir.
Bu tür şemaların, bilgisayar komut kodu konusunda eğitilmiş kişilere verilebileceği ve onların ayrıntılı akış şemasını herhangi bir takdir ya da yargı kullanmadan bir makine programına çevirebileceği söylenmiştir. Bu kişiler bürokratik bir işlev yerine getirirlerdi. Öyleyse neden ayrıntılı akış şemalarını makine komut dizilerine dönüştürme gibi bürokratik işlevi bizzat bilgisayarın kendisine yaptırmayalım? Akış şemalarının makine kodlarına çevrilmesinin, ticari veri işleme için bir otomatik programlama sisteminin temel amaçlarından biri olması gerektiğine inanıyorum.
Bunu yapmaya çalışırken karşılaşılan sorunların bazıları son derece zorludur. İlk olarak, akış şemasını bilgisayara besleyebilmemiz için bir “akış-şemasından-dijital-bilgisayara” dönüştürücüye gereksinim vardır. İkinci olarak, düşünebildiğim herhangi bir otomatik programlama sistemi, makine kodu kadar kesinliğe sahip, ancak aynı zamanda akış şemalarının, programcıların ve uygulamaların gereksinimlerine uyum sağlayabilen çok özel bir “dil” üzerinden çalışmak zorundadır. Önerdiğim şeyi başarmanın diğer sorunlarını tek tek sıralamayacağım, ancak belki bir noktayı açıkça belirtmeliyim. Programcıların, makine kodlarını yazma baskısı altında akış şemasını geride bırakmaları kesinlikle doğrudur; fakat benim önerdiğim şeyin, makine kodu yazımının yerini alması gerektiğini unutmayın.
Ayrıca, programcı ile büro kodlayıcısının çoğu zaman aynı kişi olduğu durumlarda, ayrıntılı akış şemasının tamamen atlandığı gerçeğini de kabul ediyorum. Bununla birlikte, veri işlemenin öğeleri hakkında daha fazla şey öğrendikçe, her bloğun yalnızca bir ya da iki değil, birçok makine komutu içeren işlevsel bir alt yordamı temsil ettiği, daha üst düzey akış şemalarını yorumlayabilen otomatik programlama sistemleri geliştirebileceğimizi beklerim. Bana göre bu yöndeki ilk adım gerçekten zor olanıdır.
Kodlama
Geleneksel sırada, akış şeması çiziminden sonra kodlama gelir ve akış şemasının yarın kodlamanın yerini almayacağı düşünüldüğünde, kodlama aşamasında otomatik programlama için önemli ölçüde çalışma alanı vardır. Günümüzde bazı cesaret verici ilerlemelerin kaydedildiği alan da burasıdır. Otomatik programlama sistemlerinin ticari veri işleme uygulamalarına yapabileceği katkılardan yalnızca birkaçını anacağım.
Birincisi, otomatik programlama sistemleri, kodlamanın biçimini belirleyerek ve geçerli oldukları her yerde programlara kopyalanan bir alt yordamlar kütüphanesi sağlayarak programların standartlaştırılmasına yardımcı olabilir. İkincisi, yinelenen alt yordamlar hakkında daha fazla bilgi edinildikçe, bu tür yordamların kütüphaneleri geliştirilebilir ve programlar, bu yordamları çağıran bir kısaltılmış sahte kodla yazılabilir; böylece daha önce yazılmış kodların yinelenmesi önlenir ve sonuç olarak her yeni programdaki yeni kodlama miktarı azaltılır. Üçüncüsü, tamamlanmış kodlamanın hazırlanmasıyla ilişkili sıkıcı kayıt tutma işleri tamamen ya da kısmen bilgisayara devredilebilir; böylece programcı, kodlama ayrıntılarıyla yüklenmek yerine, eksiksiz ve verimli bir bilgisayar yordamının tasarımına odaklanabilir.
Veri işlemenin teknik dili hakkında şu anda yeterince bilgi sahibi olunmaması, ilk otomatik kodlama sistemlerinin geliştirilmesini engellememelidir. Bazı işlem işlevleri tanımlandıkça, standart yordamlar yazılabilir ve bu yordamları çağırmak için sahte kodlar tasarlanabilir. Ancak, şu anda ve bir süre daha, herhangi bir otomatik kodlama sistemi, sahte kodlamanın yanı sıra geleneksel makine kodlamasını da kabul etmek zorundadır.
Otomatik bir sisteme tasarlanabilecek programlama yordamlarındaki bir başka iyileştirme, birden fazla kişinin, iletişimle ilgili olağan sorunlar olmaksızın, aynı programın farklı bölümleri üzerinde çalışabilmesidir.
Program Denetimi ya da Hata Ayıklama
Program hazırlandıktan sonra denetlenmeli ya da hata ayıklaması yapılmalıdır; bu da çoğu zaman birçok ek insan-saat ve makine-saat gerektirir. Bilgisayar sistemlerinin uygulanma maliyetine yönelik sert eleştirilerin büyük bölümü, işlemin bu aşamasına yöneliktir.
Temel olarak, bu noktada harcanan çabanın iki tür programlama hatasından kaynaklandığı söylenebilir. Birincisi, kodlama süreci sırasında yetersiz ya da eksik kayıt tutmadan, donanımın çalışma biçiminin hafifçe yanlış anlaşılmasından ya da yazım hatası türünden kaynaklanan basit hatalardır. İkincisi ise, akış şemasının yanlış çevrilmesinden ya da programcının belirli durumları veya durum birleşimlerini göz önünde bulundurmamasından doğabilen mantıksal hatalardır.
Programcıya sempati duymak çok kolaydır; çünkü onun hem en ince ayrıntılarla çalışabilme yeteneğine sahip olması hem de programın tüm çerçevesi içindeki karmaşık karşılıklı ilişkileri aynı anda aklında tutması gerekir. Ancak sempatiyi bir kenara bırakırsak, bazı hatalardan kaçınmak ve aynı zamanda verimli hata düzeltme yöntemleri sağlamak için programlama yöntemlerini iyileştirmeye yönelik acil bir gereksinim vardır. Bu da, otomatik programlama sisteminin ilk “yaklaşık” programın üretilmesiyle işlevini durdurmaması anlamına gelir. Her tür ve düzeydeki hataların düzeltilmesine yardımcı olmak için sistematik hata düzeltme teknikleri sağlanmalıdır. Tipik ticari kurulumlar, donanımın işletim özellikleri ve programcının gereksinimleri göz önünde bulundurularak hata ayıklama yordamları üzerine bazı çalışmalar yapılmalıdır.
Bir otomatik programlama sisteminin varlığı, hata ayıklama aşamasında ortaya çıkan birçok tuzağı önleyebilir. Örneğin, yaklaştırma fikri kullanılırsa, bir programcının, birçok ucu açık nokta olduğunu bilerek yalnızca ana veri akışıyla ilgili bir yordam hazırlaması düşünülebilir. Kısmi yordamı hata ayıklayarak, başlangıçta daha küçük ve daha az karmaşık bir programla çalışma avantajına sahip olur. Bu denetlendikten sonra, yordamı tamamlamak için ek yordamlar eklendikçe hataları denetlemek ve yalıtmak nispeten basit olmalıdır.
Burada da otomatik programlama teknikleri zaman ve çabayı önemli ölçüde azaltacaktır; çünkü tamamlanmış, doğru ve test edilmiş program bölümlerinden en iyi şekilde yararlanarak yeni alt yordamları eklemek ve mevcut yordamları düzeltmek mümkün olmalıdır.
Test aşamasına ilişkin olarak, bir otomatik programlama sisteminin yapabileceği en önemli katkı, ilk yaklaştırma için gereken toplam geçen sürenin azaltılmasıdır. Eleştirel bir bakışın atıldığı ve bilgi geri beslemesinin etkinleştirildiği ilk denetim noktasına mümkün olan en erken tarihte ulaşmak hayati öneme sahiptir. Hiçbir doğruluk derecesi ve hiçbir özen, program ya da yordamın zayıf yönlerini ortaya çıkaran ilk testin yerini tutamaz.
Test
Program çalışabilir hâle gelecek ölçüde hata ayıklandıktan sonra, sistemin diğer koşullu bölümlerine karşı denetlenmelidir. Gerçek işletme koşulları ve veriler en azından benzetilmelidir. Bu noktadaki programlama başarısızlıkları ne kadar da yürek parçalayıcıdır!
Yine de bu, gerçek anlamda ilk denetim noktasıdır; çünkü bazı gerçek veriler işlenir ve programlanmış yordamın, giriş ile çıkış arasındaki tüm gereksinimleri karşılayıp karşılamadığı daha kolay denetlenebilir. Bu ilk yaklaştırmadır. Kodlamanın kendisini denetlemek son derece elverişsiz olduğundan, girişin işlenmesi ve çıkışın üretilmesi gerekir; her ikisi de ya kaynak belgeleri oluşturan ya da raporları kullanan iş birimlerindeki kişilere sunulmalıdır. Bunlar, yordamların önemli eleştirmenleridir. Üretim hattının sonundaki denetçiler onlardır.
Yordam ilk kez belirlendiğinden ve başlangıç akış şemaları çizildiğinden beri, önemli ölçüde kestirme hesap yapılmıştır. Geleneksel programlama ve kodlama yöntemleri kullanıldığında, önemli ölçüde zaman da harcanmıştır. Şimdi bilgi geri beslemesi başlar ve yordam inceltilmeye başlanır. İkinci, üçüncü ve sonraki yaklaştırmalar yazılır; her biri, önceki adımların bir kısmının ya da tamamının yinelenmesini gerektirir.
Düzeltmeler, Değişiklikler, Revizyonlar
İlk yaklaştırmanın sonuçları denetlendikten sonra, sürekli bir değişiklik, düzeltme ve ek yordam akışı, özgün programla birleştirilmelidir. Çoğu zaman bu değişiklikler hassas dengeyi bozar ve sonraki hata ayıklama, ilkine göre daha da zor hâle gelir. Umulur ki otomatik bir sistem, geleneksel yöntemlerin gerektireceği kapsamlı yeniden kodlama olmaksızın, programın yeni bölümlerinin mevcut organizasyona uyum sağlamasına olanak tanır.
Bununla ilişkili olarak, daha sonraki bir tarihte, yordamlarındaki değişiklikleri karşılamak üzere programın gözden geçirilmesi fikri vardır. Bana göre, ticari uygulamaları durağan olarak görmek bir hatadır. İş dünyasının kendisi dinamik olduğu gibi, veri işleme gereksinimleri de sürekli değişmektedir ve bir veri işleme sistemini, değişen koşullara yanıt verebilme yeteneği açısından değerlendirmek makul görünmektedir. Otomatik kodlama bu yeteneğin anahtarı olabilir.
Bu, başka bir sorundan söz etmek için uygun bir nokta olabilir.
Bir programcı belirli bir yordamın ortasındayken yazdığı kodlamayı oldukça kolay izleyebilir; ancak başka bir kodlama görevine geçsin ve bir hafta sonra ilk programı büyük ölçüde unutmuş olur. Kodlamayı adım adım izlemek, onu daha önce hiç görmemiş biri için olduğu kadar zor hâle gelir. Herhangi bir programlama sistemi, programın farklı bölümlerinin hangi işlevleri yerine getirdiğine ilişkin sözel açıklamaları birlikte taşıyacak bir yöntem sağlamalıdır.
Bu, alt yordam alt yordam akış şemasıyla ilişkilendirilebilirse, birlikte programın yeterli belgelendirmesini sağlayabilirler. Sözel açıklama, programcı olmayan kişilere programın tam olarak ne yaptığını gösterecek ve denetim amacıyla kullanılabilecektir. Ayrıca, haftalar ya da aylar sonra programın gözden geçirilmesini büyük ölçüde kolaylaştıracaktır.
Kapanıştan önce, yönetimin, henüz yapmamışsa bile, yakında dikkatini çekebilecek başka bir alandan söz etmek yerinde olabilir.
Günümüzde, elektronik veri işlemcilerin yönetsel kararları desteklemek üzere bilgi sağlama yeteneği hakkında çok şey yazılmakta ve söylenmektedir. Bunun alabileceği biçimlerden biri, hâlihazırda yüksek hızlı bir ortamda depolanmış dosya ve kayıtların işlenmesidir. Bu tür işlerin iki önemli yönü vardır. Birincisi, zaman son derece kritiktir; burada sözünü ettiğim zaman, ilk isteğin yapılmasından sonuçların yönetime sunulmasına kadar geçen süredir. İkincisi, bu isteklerin önceden öngörülebileceği ve talepten önce programların hazırlanabileceği varsayılamaz. Aynı zamanda, bu tür istekler tek seferlik işler olabileceğinden, programlama maliyetleri aşırı olmamalıdır. Açıkça görülmektedir ki, bu, yeterli bir otomatik programlama sistemiyle karşılanabilecek bir meydan okumadır.
Sonuç
Bu makalenin kısa hacmi içinde, otomatik programlama tekniklerinin büyük ölçekli ticari veri işleme uygulamalarının tümünde neden önemli olduğunu göstermeye çalıştım.
Otomatik Programlamanın İşlevi
(9. sayfadan devam)
Eğitim süreciyle başlayıp programlama ve kodlamadan geçerek, değişen koşullara uyum sağlamak için programların sürekli gözden geçirilmesiyle biten çeşitli sorun alanlarına işaret ettim. Programlama prosedürüne baştan sona bakarak öğrenilecek bir şeyler olduğuna inanıyorum. Nihai otomatik sistemi, tüm süreci kapsayan bir bütün olarak düşünebiliriz.
Şu anda sürecin ayrı bölümlerine saldırmak yararlı ve mantıklıdır; nitekim bazı gruplar bunu yapmaktadır. Bahsettiğim sorunların bir kısmının, bir grup ya da diğeri tarafından kısmen çözümlenmiş olması cesaret vericidir. Programlama sorununun, onu çözebilecek yetenekteki kişilerin dikkatini ve çabasını çekecek kadar önemli olduğunun yaygın biçimde kabul edilmesini umuyorum.
Genel amaçlı veri işleme ekipmanlarının yaygın ve ekonomik kullanımı, gerçekte, daha verimli, çok daha hızlı ve çok daha ucuz programlama yöntemlerinin geliştirilmesine yakından bağlı olabilir.