SE311 YAZILIM YAPIMI BÖLÜM 3 YAPIM TASARIMI. Yrd. Doç. Dr. Volkan TUNALI Mühendislik ve Doğa Bilimleri Fakültesi / Maltepe Üniversitesi

Transkript

1 SE311 YAZILIM YAPIMI BÖLÜM 3 YAPIM TASARIMI Yrd. Doç. Dr. Volkan TUNALI Mühendislik ve Doğa Bilimleri Fakültesi / Maltepe Üniversitesi

2 Giriş 2 Yazılım Tasarımı Tasarımın Zorlukları Temel Tasarım Kavramları Tasarım Seviyeleri Tasarımın Yapı Taşları Tasarım Uygulamaları

3 Yazılım Tasarımı 3 Yazılım Tasarımı" bir bilgisayar yazılımı spesifikasyonunun çalışan bir yazılıma dönüştürülmesi için gerekli plan ve yöntemin düşünülmesi ve yaratılmasıdır. Tasarım, gereksinimleri kodlama ve hata ayıklamaya bağlayan yazılım geliştirme etkinliğidir. İyi bir üst-düzey tasarım, alt-düzey tasarımların güvenli bir biçimde kapsanacağı iyi bir yapı sağlar. İyi bir tasarım küçük projelerde yararlıdır, büyük projelerde ise kesinlikle zorunludur.

4 Tasarımın Zorlukları 4 Tasarım Zor (Wicked) Bir Problemdir Tasarım Dağınık ve Karışık Bir Süreçtir Tasarım İkilemler ve Önceliklerle İlgilidir Tasarım Kısıtlamalar İçerir Tasarım Deterministik Değildir Tasarım Sezgisel Bir Süreçtir Tasarım Yavaş Yavaş Ortaya Çıkar

5 Tasarım Zor (Wicked) Bir Problemdir 5 Zor (wicked) problem: yalnızca çözüldüğü zaman ya da bir parçası çözüldüğü zaman açıkça tanımlanabilen problem (Rittel & Webber, 1973). Bu paradoksa göre önce açıkça tanımlayabilmek için problemi bir kez çözmek ve sonra işe yarayan bir çözüm üretmek için yeniden çözmek gerekir. Dramatik gerçek bir örnek: orijinal Tacoma Narrows köprüsünün tasarımı.

6 6 Tacoma Narrows Köprüsü

7 Tasarım Dağınık ve Karışık Bir Süreçtir 7 Tamamlanmış tasarım düzenli ve temiz görünmeliyken tasarımı geliştirme süreci ortaya çıkan sonuç kadar düzenli değildir. Tasarım dağınık ve karışık ilerleyen bir süreçtir çünkü pek çok yanlış adım atılır ve pek çok hata yapılır. Aslında tasarımın özünde hata yapmak vardır. Hataları tasarım sırasında yapmak ve düzeltmek, aynı hataları kodlama sırasında yapmak ve kodlamadan sonra farkedip düzeltmeye çalışmaktan daha az maliyetlidir. Tasarım dağınık ve karışık bir süreçtir çünkü genellikle iyi bir çözümle kötü bir çözüm arasında çok ince bir farklılık vardır. Tasarımın "yeterince iyi" olduğunu bilmek zordur. Ne kadar ayrıntı yeterli olur? Tasarımın ne kadarı formal tasarım notasyonuyla yapılmalı, ve ne kadarı klavye başında yapılmak üzere bırakılmalı?

8 Tasarım İkilemler ve Önceliklerle İlgilidir 8 İdeal bir dünyada, bütün sistemler göz açıp kapayıncaya kadar çalışır, sıfır depolama alanı tüketir, sıfır ağ bant genişliği kullanır, asla hata içermez, ve bu sistemleri yapmanın maliyeti sıfırdır. Gerçek dünyada ise tasarımcının işinin önemli bir bölümü tasarım karakteristiklerini ölçüp tartmak ve bu karakteristikler arasında bir denge sağlamaktır. Eğer yüksek tepki/yanıt hızı, geliştirme zamanını azaltmaktan daha önemliyse tasarımcı belli bir tasarımı seçecektir. Eğer geliştirme zamanını azaltmak daha önemliyse tasarımcı başka bir tasarım hazırlayacaktır.

9 Tasarım Kısıtlamalar İçerir 9 Tasarımın temelinde kısmen olasılıklar yaratmak ve kısmen de olasılıkları kısıtlamak/sınırlandırmak vardır. Eğer sınırsız zaman, kaynak, ve boş alan olsaydı, çevremizde inanılmaz binalar ve çeşitli fiziksel yapılar görürdük. Sınırlı kaynakların getirdiği kısıtlar, çözümü basitleştirmeye ve sonuçta iyileştirmeye zorlar. Yazılım tasarımının amacı da bunun aynısıdır.

10 Tasarım Deterministik Değildir 10 Bir bilgisayar yazılımı için tek bir doğru tasarım yoktur. Aynı problemin çözümü için mükemmel derecede kabul edilebir pek çok tasarım olabilir.

11 Tasarım Sezgisel Bir Süreçtir 11 Tasarım deterministik olmadığı için, tasarım teknikleri de tahmin edilebilir çıktılar üreten tekrarlanabilir süreçlerden ziyade sezgisel olma eğilimindedir. Tasarım deneme-yanılma ile olur. Bir projede iyi sonuç veren bir tasarım aracı ya da tekniği bir diğer projede işe yaramayabilir. Herşey için kullanılabilecek doğru bir araç maalesef yok.

12 Tasarım Yavaş Yavaş Ortaya Çıkar 12 Tasarımlar şu yollardan geçerek evrimleşir ve iyileşir: Tasarımın gözden geçirilmesiyle, Resmî olmayan tartışmalarla, Kodun yazılmasıyla kazanılan deneyimle, Kodun revize edilmesiyle kazanılan deneyimle.

13 Temel Tasarım Kavramları 13 İyi bir tasarım birkaç temel kavramın iyi anlaşılmasına bağlıdır: Karmaşıklığın rolü (complexity) Tasarımdan beklenen karakteristik özellikler Tasarım seviyeleri

14 Karmaşıklığı Yönetmek 14 Bir yazılımı tasarlamanın iki yolu vardır: Birincisi açıkça hiçbir kusuru olmayacak kadar basit yapmak, ve diğeri ise kusurları açıkça görülemeyecek kadar karmaşık yapmak. C. A. R. Hoare Karmaşıklığın yönetilmesi yazılım geliştirmedeki en önemli teknik konudur. Aşırı yüksek maliyetli ve başarısız tasarımların 3 temel kaynağı vardır: Basit bir probleme karmaşık bir çözüm uygulamak Karmaşık bir probleme basit ve yanlış bir çözüm uygulamak Karmaşık bir probleme uygun olmayan ve karmaşık bir çözüm uygulamak

15 Tasarımdan Beklenen Karakteristik Özellikler 15 En az seviyede karmaşıklık Kolay bakım yapılabilirlik Gevşek bağlılık (loose coupling) Genişletilebilirlik Yeniden kullanılabilirlik High fan-in Low-to-medium fan-out Taşınabilirlik Yalınlık Katmanlaşma Standart teknikler

16 16 Tasarım Seviyeleri

17 Seviye 1: Yazılım Sistemi 17 Birinci seviye bütün sistemdir. Bazı programcılar sistem seviyesinden hemen sınıf tasarlama seviyesine geçme eğilimindedir. Ancak, alt-sistemler ya da paketler gibi sınıfların daha yüksek seviyeli kombinasyonları üzerinden düşünmek daha yararlıdır.

18 Seviye 2: Altsistemlere ya da Paketlere Bölünme 18 Bu seviyedeki tasarımın ana ürünü tüm başlıca altsistemlerin tanımlanmasıdır. Altsistemler büyük olabilir: Veritabanı, kullanıcı arayüzü, iş kuralları, komut yorumlayıcı, raporlama motoru, vb. Bu seviyedeki temel tasarım etkinliği: Programın başlıca altsistemlere nasıl bölüneceğine karar vermek Her bir alt sistemin diğer altsistemleri nasıl kullanabileceğine karar vermek Bu seviyenin önemli işlerinden biri de çeşitli altsistemlerin nasıl iletişim kuracağına dair kuralların konulmasıdır. Eğer tüm altsistemler diğer tüm altsistemlerle doğrudan iletişim kurabilirse, bunları birbirinden ayırmanın yararı ortadan kalkar. Altsistemlerin iletişimi sınırlandırılarak bölünme anlamlı hale getirilmelidir.

19 19 Seviye 2: Altsistemlere ya da Paketlere Bölünme

20 20 Seviye 2: Altsistemlere ya da Paketlere Bölünme

21 Seviye 2: Altsistemlere ya da Paketlere Bölünme 21 Eğer her altsistem diğer tüm altsistemlerle doğrudan iletişim kurabilirse, bazı önemli sorular ortaya çıkar: Bir programcı sadece grafik altsistemindeki küçük bir şeyi değiştirmek için sistemin kaç farklı noktasının nasıl çalıştığını anlamak zorunda? Buradaki iş kurallarını başka bir sistemde kullanmak istesek ne olur? Sisteme yeni bir kullanıcı arayüzü eklemek istesek ne olur? Mesela test amacıyla komut satırı arayüzü? Veri depolamayı uzak bir makine üzerinde yapmak istesek ne olur? Altsistemler arasındaki iletişime sadece "bilmesi gerekir" mantığıyla izin verilmeli gerçekten iyi bir nedeni olmalı. Eğer şüphede kalınıyorsa, önce iletişimi kısıtlamalı ve daha sonra ihtiyaca göre izin vermeli.

22 22 Seviye 2: Altsistemlere ya da Paketlere Bölünme

23 Yaygın Altsistemler 23 İş kuralları Kullanıcı arayüzü Veri erişimi Sistem bağımlılıkları

24 Seviye 3: Sınıflara Bölünme 24 Bu seviyedeki tasarım sistemdeki tüm sınıfların belirlenmesini içerir. Sınıflar belirlendikçe her bir sınıfın sistemin geri kalanıyla nasıl etkileştiğine dair ayrıntılar da belirlenir: Sınıfların arabirimleri (interface) tanımlanır. Bu seviyedeki temel hedef tüm altsistemlerin bireysel sınıflar halinde programlanabilecek kadar ayrıntılı biçimde bölümlendiğinden emin olmaktır.

25 Seviye 4: Rutinlere Bölünme 25 Bu seviyedeki tasarım her bir sınıfın rutinlere bölünmesini içerir. Seviye 3 te tanımlanan sınıf arabirimleri zaten bazı rutinleri de halihazırda tanımlamış durumdadır. Seviye 4 teki tasarımda sınıfların özel (private) rutinleri de detaylandırılır. Bir sınıfın rutinlerinin tamamen tanımlanması genellikle sınıfın arabiriminin daha iyi anlaşılmasını sağlar. Bu sayede sınıfın arabiriminde yapılması gereken değişiklikler de ortaya çıkmış olur yani Seviye 3 e geri dönüş. Bu seviyedeki bölümlendirme ve tasarım genellikle bireysel programcıya bırakılır, ve genellikle büyük projelerde gereklidir. Resmî olarak yapılmasa bile en azından zihinsel olarak yapılması gerekir.

26 Seviye 5: İçsel Rutin Tasarımı 26 Rutin seviyesinde tasarımın amacı tek tek rutinlerin işlevselliğini ayrıntılı olarak düzenlemektir. İçsel rutin tasarımı genellikle rutin üzerinde çalışan programcıya bırakılır ve genellikle Seviye 4 teki işlemi yapan programcı tarafından yapılır. Bu seviyede genellikle şunlar gerçekleştirilir Sözde kod (pseudocode) yazılması, Referans kitaplarından algoritma araştırılması, Rutin içindeki kod paragraflarının organize edilmesi, Kodun seçilmiş programlama diliyle yazılması. Bu seviyedeki tasarım daima yapılır.

27 Tasarımın Temel Taşları 27 Gerçek Hayat Nesneleri Bulun Tutarlı Soyutlamalar Oluşturun Uygulama Detaylarını Gizleyin Tasarımı Basitleştiriyorsa Kalıtım Kullanın Sırları Saklayın (Information Hiding) Değişmesi Muhtemel Alanları Belirleyin Bağlılığı Gevşek Tutun Yaygın Tasarım Kalıpları Bulmaya Çalışın Diğer Sezgisel Yaklaşımlar

28 Gerçek Hayat Nesneleri Bulun 28 Nesneleri ve bunların niteliklerini belirleyin (methods & data). Nesnelere ne yapılabileceğini belirleyin. Nesnelerin diğer nesnelere ne yapabileceğini belirleyin. Nesnelerin diğer nesneler tarafından görülebilir ve erişilebilir olan kısımlarını belirleyin hangi kısımlar public hangi kısımlar private olacak? Her bir nesnenin public arabirimini tanımlayın.

29 29 Gerçek Hayat Nesneleri Bulun

30 Tutarlı Soyutlamalar Oluşturun 30 Soyutlama, bir kavramı ayrıntılarını güvenli bir biçimde gözardı ederek ele almaktır ya da farklı ayrıntılarla farklı seviyelerde ilgilenmektir. Karmaşıklık noktasından bakıldığında soyutlamanın temel faydası konuyla ilgisiz ayrıntıları görmezden gelme olanağı sağlamasıdır. Temel sınıflar (base class), türetilmiş sınıfların (derived class) ortak nitelikleri üzerinde odaklanmaya olanak sağlayan ve temel sınıf üzerinde çalışırken spesifik sınıfların ayrıntılarını gözardı etme imkanı veren soyutlamalardır. İyi bir sınıf arabirimi (class interface) sınıfın içsel çalışma düzeni hakkında endişe etmeden sadece sunulan arabirim üzerinde odaklanmayı sağlayan bir soyutlamadır.

31 Tutarlı Soyutlamalar Oluşturun 31 Soyutlama, karmaşık bir kavramın basit bir görünümünü elde etme olanağı sağlar.

32 Uygulama Detaylarını Gizleyin 32 Soyutlama (abstraction): "Nesnenin yalnızca yüksek seviyeli ayrıntılarına bakabilirsin." Sarmalama (encapsulation): "Ayrıca, nesneye bundan daha ayrıntılı bir seviyede bakamazsın." Sarmalama, karmaşıklığın görülmesine izin vermeyerek karmaşıklığın yönetilmesine yardımcı olur.

33 Uygulama Detaylarını Gizleyin 33 Ne görüyorsan o, daha fazlası değil!

34 Tasarımı Basitleştiriyorsa Kalıtım Kullanın 34 Bir yazılım sistemi tasarlanırken birkaç küçük fark dışında diğer nesnelere benzeyen nesnelerle karşılaşılabilir. Bu durumdaki nesneler arasındaki benzerliklerin ve farklılıkların tanımlanması "kalıtım" olarak adlandırılır. Kalıtım, soyutlama kavramıyla sinerji oluşturacak şekilde çalışır. Soyutlama nesnelerle farklı ayrıntı seviyelerinde ilgilenir. Kalıtım, programlamayı basitleştirir çünkü nesnelerin genel özelliklerine dayalı şeyler için genel rutinler yazılır ve spesifik nesne türleri için ise spesifik rutinler yazılır. Çok biçimlilik (polymorphism).

35 Sırları Saklayın (Information Hiding) 35 Bilgi Saklama (Information Hiding) karmaşıklığın gizlenmesini vurgulayan bir kavramdır. Sınıf tasarımındaki önemli görevlerden biri sınıfın hangi özelliklerinin dışarıya açık olacağını ve hangilerinin sır olarak kalacağına karar vermektir. Bir sınıfın 25 rutini olabilir ancak yalnızca 5 tanesi dışarıya açılabilir, diğerleri içsel kullanım için olabilir. Bir sınıf çeşitli veri tipleri kullanabilir ama dışarıya bununla ilgili hiçbir bilgi vermeyebilir. Bir sınıfın arabirimi sınıfın içsel çalışma mekanizmasıyla ilgili mümkün olduğunca az bilgiyi açık etmelidir. Daima "Bu sınıf neyi gizlemeli?" diye sorun.

36 36 Sırları Saklayın (Information Hiding)

37 Değişmesi Muhtemel Alanları Belirleyin 37 Değişikliklere uyum sağlamak iyi program tasarımının en zor yanlarından biridir. Temel amaç değişikliğin etkisi yalnızca bir rutin, sınıf ya da paketle sınırlı kalacak şekilde kararsız alanları izole etmektir. Nasıl? Değişmesi muhtemel şeyleri belirle Değişmesi muhtemel şeyleri ayır Değişmesi muhtemel şeyleri izole et

38 Değişmesi Muhtemel Alanlar 38 İş kuralları Donanım bağımlılıkları Girdi ve çıktılar Standart olmayan dil özellikleri Zor tasarım ve yapım alanları Durum değişkenleri Veri boyutu sınırlamaları

39 Bağlılığı Gevşek Tutun 39 Bağlılık (coupling) bir sınıf ya da rutinin diğer sınıf ya da rutinlere ne kadar sıkı bir şekilde bağlı olduğunu tanımlayan kavramdır. Temel amaç, diğer sınıf ve rutinlerle küçük, doğrudan, görünür ve esnek ilişkileri olan sınıf ve rutinler oluşturmaktır gevşek bağlılık (loose coupling). Bir modül başka modüller tarafından kolayca kullanılabiliyorsa modüller arasında iyi bir bağlılık var demektir. Diğer modüllere çok az bağımlı modüller oluşturmaya çalışın.

40 Bağlılık Türleri 40 Basit-veri-parametre bağlılığı (Simple-dataparameter coupling) Basit-nesne bağlılığı (Simple-object coupling) Nesne-parametre bağlılığı (Object-parameter coupling) Anlamsal bağlılık (Semantic coupling)

41 Yaygın Tasarım Kalıpları Bulmaya Çalışın 41 Çoğu problem geçmiş problemlere benzer ve benzer yöntemlerle/kalıplarla çözülebilir: Tasarım Kalıpları (Design Patterns). Yaygın kalıplar şunlardır: Adapter, Bridge, Decorator, Facade, Factory Method, Observor, Singleton, Strategy, Template Method

42 Yaygın Tasarım Kalıpları Bulmaya Çalışın 42 Kalıplar hazır soyutlamalar sağlayarak karmaşıklığın azaltılmasına yardımcı olurlar Kalıplar yaygın çözümlerin ayrıntılarını kurumsallaştırarak hataları azaltırlar Kalıplar tasarım alternatifleri sağlamak suretiyle sezgisel değere sahiptirler Kalıplar tasarım diyaloğunu daha üst düzeye taşıyarak iletişimi arttırmaya yardımcı olurlar

43 Diğer Sezgisel Yaklaşımlar 43 Yüksek Uyumu (Cohesion) Amaçlayın Hiyerarşiler Oluşturun Sınıf Sözleşmelerini Resmîleştirin Sorumluluklar Atayın Test Edilebilirlik için Tasarlayın Başarısızlıktan Sakının Kaba Kuvvet Kullanmayı Düşünün Diyagram Çizin Tasarımınızı Modülerliğini Koruyun

44 Tasarım Uygulamaları 44 Yineleme ve Döngüsellik (Iterate) Böl ve Yönet (Divide and Conquer) Yukarıdan-Aşağı ve Aşağıdan-Yukarı Tasarım Yaklaşımları (Top-Down and Bottom-Up Design Approaches) Deneysel Prototipleme (Experimental Prototyping) İşbirliğine Dayalı Tasarım (Collaborative Design)

45 Tasarım Çalışmasını Kaydetmek 45 Tasarım dokümantasyonunu doğrudan kodun içine yerleştirin Tasarım görüşmelerini ve kararlarını bir Wiki üzerinde saklayın Özet e-postalar yazın Dijital kamera kullanın Tahtadaki tasarımları kaydedin CRC (Class, Responsibility, Collaborator) kartları kullanın Uygun seviyede ayrıntı içeren UML diyagramları oluşturun

46 Sonuç Tasarımın kalitesi başarıyı garantilemez, ama tasarımın yetersizliği başarısızlığı garantiler.

47 Kitap Önerisi 47 UML ile Nesne Tabanlı Çözümleme ve Tasarım, Bora Güngören, Seçkin Yayıncılık, 2009 Object-Oriented Software Development Using Java, 2 nd Ed., Xiaoping Jia, Addison-Wesley, 2003 Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, & John Vlissides, Addison-Wesley, 1995