Yazılım Tasarımı Nedir?


Lemi Orhan Ergin Hoca’nın sunumlarında tavsiye ettiği 1992 tarihli “What is Software Design” makalesi için bir çeviri denemesi yaptım. Tavsiyesi için Lemi Orhan Ergin’e ve çeviri için yardımlarını esirgemeyen Google Translate’e şükranlarımı sunuyorum.


Son zamanlarda yazılım dünyasında nesne yönelimli yazılım(OOP) ve C++ fırtınası esiyor. Çok sayıda makale ve kitap yayınlanıyor. OOP yöntemlerinin yalnızca hype olup olmadığı sorusu yerini, en az maliyet ile fayda sağlamanın nasıl olacağı gibi sorulara bıraktı. Ancak birden bire bu popülaritenin patlaması normal değil. Bu ani patlama için de çeşitli açıklamalar yapıldı. Muhtemelen tek bir sebebi yok. Birden fazla faktörün birleşmesi bardağı taşırdı. Bununla birlikte C++ bu devrimde önemli bir faktör.

C ++, yazılımın tasarımını ve programlamayı aynı anda yapmayı kolaylaştırdığı için popüler oldu.

Bu yorum biraz sıradışı görünebilir. Amacım programlama ve yazılım tasarımı arasındaki ilişkiyi incelemek. Yaklaşık 10 yıldır, yazılım endüstrisinin toplu olarak bir yazılım tasarımı geliştirmeyle gerçekten bir yazılım tasarlama arasındaki fark hakkında bir nüansı kaçırdığımı hissettim.

Bence gittikçe artan C ++ popülerliğinde, daha iyi yazılım mühendisleri olmak için neler yapabileceğimiz konusunda önemli bir ders var. Bu ders şu: Programlama, yazılımı build etmeyle, ayağa kaldırmayla değil; yazılımı tasarlamayla ilgilidir.

Yıllar önce, yazılım geliştirmenin bir mühendislik disiplini olup olmadığı sorusunun tartışıkdığı bir seminere katıldım. Tartışmanın sonucunu hatırlamasam da bir düşüncemi kuvvetlendirdiğini hatırlıyorum: yazılım endüstrisi donanım mühendisliği ile bazı yanlış paralellikler kurarken, bazı mükemmel geçerli paralellikleri kaçırıyor. Esasında biz yazılım mühendisi değiliz. Çünkü bir yazılım tasarımının gerçekte ne olduğunu bilmiyoruz. Bugün bu konuda daha da fazla ikna oldum.

Bir mühendislik faaliyetinin asıl hedefi bir tasarım dokümanı oluşturmak ve üreticiye(yazılımcı) vermektir. Üretim ekibi tasarımcılardan tamamen farklıdır. Eksiksiz bir tasarım ortaya çıkmışsa yazılımcı programı yazmaya başlayabilir. Aslında tasarımı yapan mühendis olmadan da yazılımcı bir sürü ürün geliştirebilir. Dolayısıyla bu, donanım veya inşaat mühendisliği gibi birşey değildir.

Yazılım geliştirme yaşam döngüsüne bakarsak, aslında bir mühendislik tasarımının kriterlerini karşılayan doküman, kaynak kodlardır.

Bu makalede de tasarımın esasında kaynak kod olduğunu varsayarak, yazılım endüstrisindeki bazı değişimleri anlamayı/anlatmayı umuyorum.

Çoğu yazılım organizasyonu için kör bir nokta var. Onlara göre yazılımı “build” etmek ucuz bir işlemdir. Hatta ucuz ne kelime? Neredeyse beleştir.

Eğer kaynak kod yazılımın tasarımıysa onu build eden, üreten derleyiciler ve bağlayıcılar(paketleyiciler)’dır. Biz genelde derleme ve bağlama sürecini build etmek diye adlandırırız. Yazılım, sermayesi düşük maliyetli, kaliteli bir çözümdür. Bir bilgisayar, bir editör, bir derleyici ve bir bağlayıcı yeterlidir(Günümüzde bir bilgisayar ve bir IDE de yeterli). Geliştirme ortamı hazır olunca kısa bir sürede yazılım geliştirilebilir. 50000 satır C++ kodunun derlenmesi sonsuza kadar sürecek gibi durabilir ama bu 50000 satır kodla aynı karmaşıklıktaki bir donanım sistemi oluşturmak ne kadar sürerdi?

Bir diğer konu yazılımın -en azından mekanik anlamda- nispeten kolay geliştirilmesidir. 50 ila 100 satırlık bir kod çok kısa bir sürede geliştirilebilir. Böyle kısa sürede yazılım gibi kompleks bir tasarımın üretilebileceği başka bir mühendislik disiplini yoktur muhtemelen. Ama bu karmaşıklığın(complexity) nasıl ölçüleceğini bulmamız gerekir. Çünkü yazılım tasarımları oldukça hızlı biçimde çok büyük boyutlara da ulaşmaktadır.

Yazılımın hızlıca büyümesiyle beraber karmaşıklığının da artması şaşırtıcı değildir. Ama çoğunlukla görmezden gelinir. Ödev projeleri belki birkaç bin satır koddan oluşabilir. Ama basit bir yazılımın çok ilgi gördüğü devirleri çoktan geçtik. Tipik ticari yazılımlar yüzbinlerce satır koddan oluşuyor. Ki bunlar da devamlı gelişmekte, büyümektedir.

Kesinlikle yazılım tasarımları kadar tartışmalı olarak donanım tasarımları örnekleri olsa da, modern donanımla ilgili iki olguyu not edelim.

İlki; Mikroişlemcilerdeki mantıksal hatalarla köprüler çöktü, barajlar yıkıldı, uçaklar düştü ve binlerce otomobil ve başka ürün geri çağrıldı. Hepsi hafızalarımızda tazeliğini koruyor ve hepsi tasarım hatalarının sonucu.

İkincisi, kompleks donanım tasarımları karmaşık ve pahalı yapım aşamalarına sahiptir. Sonuç olarak, bu tür sistemleri üretme kabiliyeti, gerçekten karmaşık donanım tasarımları üreten şirket sayısını sınırlar. Yazılım için böyle bir sınırlama yoktur. Yüzlerce yazılım şirketi ve binlerce oldukça karmaşık yazılım sistemi var. Sayı ve karmaşıklığın her ikisi de her geçen gün artıyor. Bu, yazılım endüstrisinin, donanım geliştiricileri taklit etmeye çalışarak, kendi sorunlarına çözüm bulmasının mümkün olmadığı anlamına geliyor. CAD ve CAM sistemleri donanım tasarımcılarına daha karmaşık tasarımlar oluşturmalarına yardımcı olduğu için, donanım mühendisliği gittikçe daha fazla yazılım geliştirmeye benziyor.

Yazılım tasarımı, karmaşıklığı(complexity) yönetmek için bir uygulamadır. Karmaşıklık, yazılım tasarımının kendisinde, şirketin yazılım organizasyonu içinde ve bir bütün olarak endüstri içinde bulunur. Sistem tasarımına çok benzer. Birden fazla teknolojiyi kapsar ve çoğu zaman birden çok alt disiplini içerir. Devamlı, hızlı ve sıklıkla değişir. Yazılım ekipleri de bu yönden değişime meyillidir ve geliştirmenin ortasında sirkülasyonlar olabilir. Birçok yönden yazılım, donanımdan ziyade karmaşık sosyal veya organik sistemlere daha fazla benzemektedir. Bütün bunlar yazılım tasarımını zor ve hataya açık bir süreç yapar.

Bu düşüncelerin hiçbirisi yeni değil. Yazılım mühendisliği devriminin başlangıcından yaklaşık 30 yıl sonra, yazılım geliştirme hala diğer mühendislik mesleklerine kıyasla disiplinsiz bir sanat olarak görülüyor.

Genel olarak, gerçek mühendisler bir tasarımla uğraştıklarında ne kadar karmaşık olursa olsun çalışacağı konusunda eminiz. Onlar da kabul görmüş inşa teknikleri kullanılarak yapılabileceğinden eminler. Bunu gerçekleştirmek amacıyla, donanım mühendisleri tasarımlarını doğrulamak ve iyileştirmek için oldukça zaman harcıyorlar. Örneğin bir köprü tasarımı düşünün. Böyle bir tasarım yapılmadan önce mühendisler yapısal analiz yapar; bilgisayar modelleri oluşturur ve simülasyonlar çalıştırır; ölçek modelleri oluşturur ve onları rüzgar tünellerinde veya başka yollarla test ederler. Kısacası, tasarımcılar, tasarımın oluşturulmadan önce iyi bir tasarım olduğundan emin olmak için düşünebilecekleri her şeyi yapar. 

Çoğu insanın, yazılım tasarımında donanım tasarımı kadar titiz bir mühendislik yapmadığı açıktır. Bununla beraber, kaynak kodu tasarım olarak kabul edersek, yazılım tasarımcılarının aslında tasarımlarını doğrulama ve iyileştirme konusunda önemli miktarda çalıştıklarını görürüz. Yazılım tasarımcıları buna mühendislik demiyor; test ve hata ayıklama(debugging) diyor. Çoğu kişi, test ve hata ayıklama işlemlerini gerçek “mühendislik” olarak görmüyor. Bu daha çok, yazılım endüstrisinin kodu, tasarım olarak herhangi bir gerçek mühendislik özelliği kabul etmemesiyle ilgili. Mock-up’lar, prototipler ve bread-boardlar aslında diğer mühendislik disiplinlerinin kabul gören bir parçasıdır. Yazılım tasarımcıları, yazılım oluşturma döngüsünün basit ekonomisi nedeniyle tasarımlarını doğrulamak için resmi yöntemlere ya sahip değildirler ya da böyle yöntemleri kullanmazlar.

İkinci ilham: Tasarımı test ederek build etmek daha basit ve ucuz bir yöntemdir. Testi yazmak zaman alsa da bakım ve tasarımın değişmesi gibi konularda maliyeti düşürecektir.

Testin sadece mevcut tasarımı doğru geliştirmekle ilgili olmadığını, tasarımın iyileştirilmesi(bakım) sürecinin bir parçası olduğunu unutmayın.

(Adam 1992’de test yazmaktan bahsediyor. Memleketimizde kaç yıldır gündemde acaba?)

Karmaşık sistemleri geliştiren donanım mühendisleri genellikle modeller oluşturur (en azından tasarımlarını bilgisayar grafiklerini kullanarak görsel olarak oluştururlar). Bu, tasarımın kendisini gözden geçirerek sınırlarını anlamaya çalışır. Yazılım için böyle bir model oluşturmak hem imkansız hem de gereksizdir. Ürünü sadece kendimiz build ediyoruz. Resmi yazılım kanıtları bir derleyici kadar otomatik olsa bile, biz yine de build / test döngüsünü uygulardık. Bundan dolayı, resmi deliller yazılım endüstrisi için hiç bu kadar pratik ilgiye sahip değildi.

Bugün yazılım geliştirme sürecinin realitesi budur. Her geçen gün artan sayıda kişi ve kuruluş tarafından daha karmaşık yazılım tasarımları oluşturulmaktadır. Bu tasarımlar bazı programlama dilleri ile kodlanacak ve daha sonra build/test döngüsüyle çalışır hale gelecek ve iyileştirilmiş olacaktır. Süreç hataya meyillidir ve başlarken titizlik ister. Pek çok yazılım geliştiricisi, bunun böyle olduğuna inanmak istemez. Problemi işte bu şekilde çok yönlü bileşenler oluşturuyor.

Üst düzey tasarım, herhangi bir kod yazılmadan tamamlanmalı ve dondurulmalıdır. Test ve debug sadece yapısal hataları ayıklamak için gereklidir. Programcılar arasında, yazılım endüstrisinin inşaat işçileri var. Bu tip programcılar eğer kendilerine verilen tasarımları “hackleme” yerine “build” etmeye başlarsa(ve bu süreçte daha az hata yaparsa), yazılım geliştirme de gerçek bir mühendislik disiplini haline gelebilir. Süreç, mühendislik ve ekonomik gerçekleri göz ardı ettiği sürece bu mümkün değil.

Örneğin, başka hiçbir modern sanayi, imalat sürecinde % 100’ün üzerinde bir yeniden işleme oranına tolerans göstermez. İnşaatta çalışan bir işçi ilk inşaatında yapacağı ilk hatasından ötürü işsiz kalabilir. Yazılımda, en küçük kod parçası bile, test etme ve hata ayıklama sırasında tamamen gözden geçirilecek veya tamamen yeniden yazılabilecektir. Bu iyileştirmeyi üretim sürecinin değil, tasarım sürecinin bir parçası olarak kabul ederiz. Hiç kimse bir mühendisin ilk seferde mükemmel bir tasarım yaratmasını beklemez. Yapıyor olsa bile, yine de mükemmel olduğunu ispatlamak için yine iyileştirme(refactoring) sürecine girmelidir.

Japon yönetim tekniklerinden başka hiçbir şey öğrenmezsek bile şunu öğrenmeliyiz: Üretim sürecindeki hatalardan dolayı işçiyi suçlamak üretkenliği azaltır. Yazılım geliştirmeyi hatalı bir süreç modeline uymaya zorlamak yerine veya daha iyi bir yazılım üretme çabasına engel olmak yerine bu işlemi kolaylaştırmak için süreci gözden geçirmeliyiz. Bu, “yazılım mühendisliği”nin turnusol kağıdı testidir. Mühendislik, sürecin nasıl gerçekleştirileceği ile ilgilidir; nihai tasarım belgesinin üretimi için bir CAD sistemine ihtiyacı olup olmadığıyla ilgili değildir.

Yazılım geliştirme ile ilgili en büyük sorun her şeyin tasarım sürecinin bir parçası olmasıdır. Kodlama tasarımdır, test ve hata ayıklama tasarımın bir parçasıdır ve genellikle yazılım tasarımı olarak adlandırdığımız şey de yine tasarımın bir parçasıdır. Yazılımı build edebilmek maliyetsiz bir iş olabilir, ancak tasarımı son derece pahalıdır. Yazılım çok karmaşıktır ve bol miktarda farklı tasarım yaklaşımı ve bunların sonucunda ortaya çıkan farklı tasarım görünümleri bulunmaktadır. Sorun, tüm farklı yaklaşımların birbiriyle iç içe geçmiş olmasıdır (tıpkı donanım mühendisliğinde olduğu gibi). Üst seviye tasarımcılar(top level designers), modül algoritması tasarımının detaylarını görmezden gelseler çok güzel olurdu. Aynı şekilde, eğer bir modülün dahili algoritmalarını tasarlarken programcılar üst seviye tasarım konularında endişelenmese de güzel olurdu. Ne yazık ki, bir tasarım katmanını yaklaşımı diğerlerine girmektedir. Verilen bir modül için algoritma seçimi, üst seviye tasarım bakış açılarından herhangi biri gibi yazılım sisteminin genel başarısı için önemli olabilir.

Bir yazılım tasarımının farklı yönleri arasında önem taşıyan bir hiyerarşi yoktur. En düşük modül seviyesindeki yanlış tasarım, en yüksek seviyedeki bir hata kadar ölümcül olabilir. Bir yazılım tasarımı tüm yönleriyle eksiksiz ve doğru olmalıdır. Yoksa tasarıma dayalı tüm yazılım yapıları hatalı olacaktır.

Yazılım, karmaşıklığı gidermek için katmanlar halinde tasarlanmıştır. Bir programcı bir modülün ayrıntılı tasarımı konusunda endişe ediyorsa, muhtemelen aynı anda endişelenemeyeceği yüzlerce başka modül ve binlerce ayrıntı vardır. Örneğin, veri yapısı ve algoritmaları kategorisine girmeyen önemli yazılım tasarım yaklaşımları vardır. İdeal olarak, programcılar kodu tasarlarken, tasarımın diğer yönleri hakkında endişelenmemelidir.

Ancak işler bu şekilde yürümez ve etraflıca düşünmek gerekir. Yazılım tasarımı, kodlanıp test edilene kadar tamamlanmamıştır.

Test, tasarım doğrulama ve iyileştirme sürecinin temel bir parçasıdır.

Üst düzey yapısal tasarım tam bir yazılım tasarımı değildir; sadece ayrıntılı tasarım için yapısal bir çerçevedir(framework). Üst düzey bir tasarımın titizlikle doğrulanması(validation) için çok sınırlı yeteneklere sahibiz. Ayrıntılı tasarım, en azından diğer faktörler kadar üst düzey tasarımı etkiler (yahut etkilemelidir). Bir tasarımın tüm yönlerini iyileştirmek(refactoring), tasarım döngüsü boyunca gerçekleşmesi gereken bir süreçtir. Tasarımın herhangi bir yönü iyileştirme sürecinden azade olursa, nihai tasarımın zayıf olması hatta çalışmaması şaşırtıcı olmaz.

Üst düzey yazılım tasarımı daha sıkı bir mühendislik süreci olabilseydi güzel olurdu, ancak yazılım sistemlerinin gerçek dünyası sıkı değildir. Yazılım çok karmaşıktır ve çok daha başka şeylere bağımlıdır. Belki bazı donanımlar tasarımcıların düşündüğü şekilde çalışmaz veya bir kütüphane(library) rutinin dokümante edilmemiş bir kısıtı vardır. Bunlar, her yazılım projesinin er ya da geç karşılaştığı türden sorunlardır. Bunlar, test sırasında keşfedilen sorun türleridir (eğer iyi bir test yaparsak), daha önce keşfetmenin hiçbir yolunun olmamasının basit bir nedeni vardır. Onlar keşfedildiğinde, tasarımda bir değişikliği zorlarlar. Şanslıysak, tasarım değişiklikleri lokaldir. Çoğu zaman, değişimler tüm yazılım tasarımının önemli bir kısmını etkiler(Murphy Kanunu). Etkilenmiş tasarımın bir kısmı herhangi bir nedenle değiştirilemediğinde, tasarımın diğer kısımlarını da buna uydurmak için zayıflatmalısınız. Bu genellikle yöneticilerin “hack” olarak algıladıkları şeydir ancak bir yazılım geliştirme realitesidir.

Örneğin, kısa bir süre önce, A modülünün iç bölümleri ile başka bir B modülü arasında zamanlama bağımlılığı keşfettiğim bir proje üzerinde çalıştım. Ne yazık ki, A modülünün iç kısımları, B modülünün uygun sıraya yerleştirilmesine herhangi bir şekilde izin vermeyen bir soyutlamanın arkasına gizlenmişti. Doğal olarak, sorun keşfedildiğinde, A’nın soyutlamasını değiştirmeye çalışmak için çok geçti. Tahmin edileceği üzere yapılan şey, A’nın iç tasarımına uygulanan giderek daha karmaşık bir “düzeltme” setiydi. İlk sürümü yayınlamadan önce, tasarımın bozulduğuna dair kötü bir his vardı. Her yeni düzeltme büyük olasılıkla bazı eski düzeltmeleri bozacaktı. Bu tipik bir yazılım geliştirme projesi idi. Sonunda, meslektaşlarım ve ben tasarımda bir değişiklik öne sürdük, ancak yönetimin kabul etmesi için gönüllü olarak, ücretsiz fazla mesai yapmak zorundaydık.

Tipik bir boyuttaki herhangi bir yazılım projesinde, bu gibi sorunların ortaya çıkması garantidir. Bütün önleme girişimlerine rağmen önemli ayrıntılar gözden kaçacak. Zanaat ile mühendislik arasındaki fark budur. Deneyim bizi doğru yönde götürebilir. Bu zanaattir. Deneyim sadece bizi şimdiden keşfedilmemiş bölgeye götürür. O zaman başlattığımız şeyleri alıp kontrollü bir iyileştirme süreci boyunca daha iyi hale getirmeliyiz. Bu ise mühendisliktir.

Küçük bir nüans olarak tüm programcılar, yazılım tasarım belgelerinin koddan önce yazmak yerine sonra yazılmasının çok daha doğru bir belge ürettiğini bilir. Nedeni açıktır. Build/ test döngüsü süresince iyileştirilen son tasarım koda yansır. İlk tasarımın bu döngüde değiştirilmeme ihtimali, bir projedeki modüllerin ve programcıların sayısıyla ters orantılıdır. Bu da hızla sıfıra yaklaşır. 

Yazılım mühendisliğinde, her seviyede aşırı derecede iyi tasarıma ihtiyaç duyuyoruz. Özellikle iyi yüksek seviye tasarıma ihtiyacımız var. Erken tasarım ne kadar iyi olursa, daha kolay detaylı tasarım olacaktır. Tasarımcılar yardımı olacak her şeyi kullanmalıdır. Yapı çizelgeleri, Booch diyagramları, durum tabloları, PDL, vb. yardımcı olacaksa bunları kullanın. Bununla birlikte, bu araçların ve gösterimlerin bir yazılım tasarımı olmadığını akılda tutmak zorundayız. Sonunda, gerçek yazılım tasarımını yaratmak zorundayız ve bu bazı programlama dilleriyle olacaktır. Bu nedenle, tasarımlarımızı onları türettikçe kodlamaktan korkmamalıyız. Onları gerektiği gibi iyileştirmeye istekli olmalıyız.

Hem üst seviye tasarımda hem de ayrıntılı tasarımda eşit derecede uygun bir tasarım notasyonu bulunmamaktadır. Sonuçta tasarım bazı programlama dilleri ile kodlanacak. Bu, detaylı tasarıma başlamadan önce üst seviye tasarım notlarının hedef programlama diline çevrilmesi gerektiği anlamına gelir. Bu çeviri aşaması zaman alır ve hatalar getirir. Programcıların tercih ettiği programlama dili içine net bir şekilde eşlenemeyebilecekleri bir gösterimden tercüme etmek yerine, sıklıkla gereksinimlere geri dönmeleri ve üst düzey tasarımlarını, uyguladıkları haliyle kodlamalarını yeniden yapmaları gerekir. Bu da yazılım geliştirme realitesinin bir parçasıdır.

Muhtemelen orijinal tasarımcıların orijinal kodu yazmalarına izin vermek daha iyidir, aksi halde bir başkası tarafından bir dilden bağımsız tasarıma çevirilmesi gerekir. İhtiyacımız olan şey, tasarımın her seviyesine uygun birleşik bir tasarım notasyonudur. Başka bir deyişle, üst düzey tasarım kavramlarını yakalamak için de uygun bir programlama diline ihtiyacımız var. Burada karşımıza C ++ çıkar. C ++ gerçek dünya projeleri için uygun bir programlama dilidir ve ayrıca daha belirgin bir yazılım tasarım dildir. C ++, tasarım bileşenleri hakkında üst düzey bilgileri doğrudan ifade etmemize izin verir. Bu, tasarımın üretilmesini kolaylaştırır ve daha sonra onu daha kolay iyileştirmemizi sağlar. Güçlü tip kontrolü sayesinde tasarım hatalarını tespit etme sürecine de yardımcı olur. Bu, daha sağlam bir tasarıma, sonuçta daha iyi tasarlanmış tasarıma neden olur.

Sonuç olarak, bir yazılım tasarımı bazı programlama dillerinde temsil edilmeli ve daha sonra bir build/test döngüsüyle doğrulanmalı ve iyileştirilmelidir. Aksi takdirde üretilen herhangi bir bahanenin sadece saçmalık olduğu söylenebilir. Hangi yazılım geliştirme araçlarının ve tekniklerinin popülerlik kazandığını düşünün. Yapısal programlama, zamanında bir atılım olarak düşünülmüştür. Pascal onu yaygınlaştırdı ve zamanla popüler hale geldi. Nesneye yönelik tasarım yeni moda ve onun da kalbinde C ++ var. Şimdi, neyin işe yarayıp, yaramadığını düşünün. CASE araçları? Popüler mi, evet; evrensel mi, hayır. Yapı planları? Aynı şey. Aynı şekilde, Warner-Orr diyagramları, Booch diyagramları, nesne diyagramları, adını siz verin.. Her biri güçlü araçlar ama tek bir temel zayıf yönleri var; gerçekten bir yazılım tasarımı değildir. Aslında, yaygın olarak adlandırılabilecek tek yazılım tasarım gösterimi PDL’dir.

Bu bize, yazılım endüstrisinin kolektif bilinçaltının içgüdüsel olarak, programlama tekniklerinin ve gerçek dünya programlama dillerinin iyileştirilmesinin, yazılım sektöründeki her şeyden çok daha önemli olduğunu bildiğini söylüyor. Aynı zamanda programcıların tasarımla ilgilendiğini söylüyor. Daha iyi ifade edici programlama dilleri hazır olduğunda, yazılım geliştiricileri bunları da benimser.

Ayrıca, yazılım geliştirme sürecinin nasıl değiştiğini düşünün. Bir zamanlar şelale sürecimiz vardı. Şimdi spiral gelişme ve hızlı prototiplendirme hakkında konuşuyoruz. Bu tür teknikler “risk azaltma” ve “ürün teslim sürelerinin kısaltılması” gibi terimlerle göze güzel gelse de, gerçekte yaşam döngüsünün başlarında kodlamaya başlamanın bahaneleri. Bu iyi bir şey. Bu, build / test döngüsünün tasarımın geçerliliğini doğrulamaya ve iyileştirmeye daha önce başlamasını sağlar. Aynı zamanda, üst düzey tasarım geliştiren yazılım tasarımcılarının detaylı tasarım yapmak için hazır olmaları daha olasıdır.

Yukarıda belirtildiği gibi-mühendislik, nihai ürünün neye benzediğinden daha çok sürecin nasıl işlediğiyle ilgilidir.

Yazılım işinde mühendis oluyoruz, ancak birkaç algısal değişikliğe ihtiyacımız var. Programlama ve build / test döngüsü, yazılım mühendisliği sürecinin merkezinde yer alır. Onları böyle yönetmeliyiz.

Build / test döngüsünün maliyeti ve ayrıca bir yazılım sisteminin pratik olarak her şeyi temsil edebileceği gerçeği, bir yazılım tasarımını doğrulamak için genel amaçlı yöntemler bulmamızı zorlaştırıyor. Bu süreci iyileştirebiliriz, ancak kaçamayız.

Son bir nokta: Herhangi bir mühendislik tasarım projesinin amacı, bazı dokümanların üretilmesidir. Açıkçası, güncel tasarım belgeleri en önemlisidir, ancak üretilmesi gereken sadece tasarım belgeleri değildir. Birinin sonunda yazılımı kullanması bekleniyor. Ayrıca, sistemin daha sonra değiştirilmesi ve geliştirilmesi gerekebilir. Bu, yardımcı bir dokümantasyonun bir yazılım projesi için bir donanım projesi kadar önemli olduğu anlamına gelir. Şimdilik kullanıcı el kitaplarını, kurulum kılavuzlarını ve tasarım süreciyle doğrudan bağlantılı olmayan diğer belgeleri göz ardı ediyorsanız, yardımcı tasarım belgeleriyle çözülmesi gereken iki önemli ihtiyaç vardır:

Yardımcı dokümantasyonun ilk kullanımı, tasarım alanına girmeyen önemli alanlardan gelen önemli bilgileri yakalamaktır. Yazılım tasarımı, problem alanındaki kavramları modellemek için yazılım konseptleri bulmayı etmeyi içerir. Bu süreç, problem alanı kavramlarının anlaşılmasını gerektirir. Genellikle bu anlayış, doğrudan yazılım alanına modellenmeden biten, ancak yine de tasarımcının temel kavramların ne olduğunu ve bunları nasıl en iyi modelleyebileceğini belirlemesine yardımcı olan bilgileri içerecektir. Bu bilgi, modelin daha sonra değiştirilmesi gerektiği ihtimaline karşı bir yerde bulunmalıdır.

Yardımcı belgelere ikinci önemli gereksinim, tasarımın kendisinden doğrudan çıkarılması güç olan tasarım yönlerini belgelemektir. Bunlar hem yüksek hem de düşük seviye yaklaşımlarını içerebilir. Bu yaklaşımların birçoğu grafiksel olarak en iyi şekilde tasvir edilmiştir. Bu, onları kaynak koda yorum eklemeyi zorlaştırır. Bu, bir programlama dili yerine bir grafiksel yazılım tasarım gösterimi için bir argüman değildir. Bu, donanım disiplinlerinin grafik tasarım dokümanlarına eşlik eden metinsel tanımlamalardan farksız değildir. Kaynak kodun yardımcı dokümantasyonu değil, asıl tasarımı belirlediğini asla unutmayın. İdeal olarak, bir kaynak kodu işleyip yardımcı belgeleri oluşturan yazılım araçları kullanılabilir olacaktır. Ama bunun gerçekleşmesi zaman alabilir. Bir sonraki en iyi şey, programcıların (veya teknik yazarların) daha sonra başka bir şekilde belgelendirilebilen kaynak kodundan belirli bilgileri çıkarmasına izin veren bazı araçlar olabilir. Kuşkusuz, bu dokümantasyonu elle güncel tutmak zordur. Bu, daha ifade edici programlama dillerine duyulan ihtiyaç için bir diğer argümandır. Ayrıca, bu gibi yardımcı dokümanları asgari seviyede tutmak ve olabildiğince projenin son haline kadar mümkün olduğunca gayri resmi tutmak için bir argümandır. Yine de daha iyi araçlar kullanabiliriz, aksi takdirde kurşun kalem, kağıt ve tebeşir panolarına döneriz.

Özet Olarak

  • Gerçek yazılım bilgisayarlarda çalışır. Bazı manyetik ortamlarda saklanan bir sıralı 1 ve 0 dizisidir. C ++’da (veya başka programlama dili) listelenen bir program değildir.
  • Bir program listesi, bir yazılım tasarımını temsil eden bir belgedir. Derleyiciler ve bağlayıcılar aslında yazılım tasarımları oluşturmaktadır.
  • Gerçek yazılımı oluşturmak inanılmaz derecede ucuzdur ve bilgisayarlar daha hızlı hale geldiğinde her zaman daha da ucuza gelirler.
  • Gerçek yazılım tasarımı inanılmaz pahalıdır. Bu doğrudur, çünkü yazılım inanılmaz derecede karmaşıktır ve bir yazılım projesinin tüm adımları tasarım sürecinin bir parçasıdır.
  • Programlama, bir tasarım aktivitesidir; iyi bir yazılım tasarım süreci bunu tanır ve kodlama gerektiği zaman kodlamaya çekinmez.
  • Kodlama gerçekten inanılandan daha anlamlıdır. Çoğu zaman tasarımın koda dönüştürülmesi süreci gözden kaçırılır ve ek tasarım gayreti gerektirir. Ne kadar erken gerçekleştirilirse, tasarım o kadar iyi olur.
  • Yazılım çok ucuz olduğundan, biçimsel mühendislik doğrulama(validation) yöntemleri gerçek dünya yazılım geliştirmesinde çok fazla uygulanmaz. Tasarımı oluşturmak ve ispatlamaya çalışmak yerine test etmek daha kolay ve daha ucuzdur.
  • Test ve hata ayıklama, tasarım faaliyetleridir; bunlar, diğer mühendislik alanlarının tasarım doğrulama ve iyileştirme süreçlerinin yazılım eşdeğeridir. İyi bir yazılım tasarım süreci bunun farkındadır ve bu adımları değiştirmeye çalışmaz.
  • Başka tasarım etkinlikleri de vardır; onlara üst düzey tasarım, modül tasarımı, yapısal tasarım, mimari tasarım veya benzeri adları verebilirsiniz. İyi bir yazılım tasarım süreci bunun farkındadır ve kasıtlı olarak bu adımları içerir.
  • Tüm tasarım etkinlikleri etkileşime girer. İyi bir yazılım tasarım süreci bunun farkındadır ve tasarımın çeşitli aşamalarında gerektikçe -bazen radikal şekilde- değişmesine izin verir.
  • Birçok farklı yazılım tasarım notasyonu, yardımcı dokümantasyon ve tasarım sürecini kolaylaştırmaya yardımcı araçlar olarak potansiyel olarak yararlıdır. Onlar bir yazılım tasarımı değildir.
  • Yazılım geliştirme hala bir mühendislik disiplininden daha çok bir zanaattir. Bu önerme öncelikle, bir tasarımın geçerliliğini doğrulamak ve iyileştirmek için kritik süreçlerde gerekli titizlik gösterilmediği için ortaya çıkmaktadır.
  • Sonuçta, yazılım geliştirmedeki gerçek gelişmeler, programlama tekniklerinin ilerlemesine bağlıdır ve bu da programlama dillerinde ilerlemeler anlamına gelmektedir. C ++ da böyle bir gelişmedir. Doğrudan daha iyi yazılım tasarımını destekleyen ana programlama dili olduğu için popülerliği patladı.
  • C ++, doğru yönde atılmış bir adımdır, ancak yine de daha fazla gelişmelere ihtiyaç vardır. (Modern nesne tabanlı diller -java, c# etc.- bu isteği karşılıyor olmalı)

Bu sayfa 577 kez görüntülendi

It's only fair to share...Share on LinkedInShare on FacebookShare on Google+Tweet about this on TwitterShare on Tumblr
Benzer Konular

Yorum Yap


Not - Bunları KullanabilirsinizHTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>