YAZILIM YAPIMI BLM 2 DEKL BEKLEMEK Manisa Celal

YAZILIM YAPIMI BÖLÜM 2 DEĞİŞİKLİĞİ BEKLEMEK Manisa Celal Bayar Üniversitesi

Günün Sözü 2 «Nothing endures but change. » - Heraclitus (535 BC - 475 BC)

Giriş 3 Yazılımın Değişimi & Evrimi (Change & Evolution) Yazılım Bakımı (Maintenance) Yazılım Yeniden Yapılandırma (Reengineering) Değişikliğin Maliyeti (Cost of Change) Yeniden Düzenleme (Refactoring) � Yeniden Düzenlemenin Nedenleri � Yeniden Düzenleme Çeşitleri � Güvenli Biçimde Yeniden Düzenlemek � Yeniden Düzenleme Stratejileri

Efsane 4 İYİ YÖNETİLEN BİR YAZILIM PROJESİ yönteme dayalı bir gereksinim analizi yapar ve sabit bir gereksinim listesi tanımlar. Gereksinim analizini tasarım izler. Tasarım öylesine dikkatlice yapılır ki kodlama doğrusal bir biçimde ilerler. Baştan sona kodun tamamı neredeyse bir kez yazılır, test edilir, ve unutulur. Bu efsaneye göre, kodun büyük ölçüde değiştirildiği tek zaman dilimi sadece bakım safhasıdır, yani sistemin ilk sürümü dağıtıldıktan sonra.

Gerçek 5 İlk geliştirme aşamasında kod büyük ölçüde evrimleşir. Bu geliştirme sürecindeki değişikliklerin çoğu bakım sürecinde yapılan değişiklikler kadar büyük, önemli ve etkilidir. Projenin boyutuna bağlı olarak, tipik bir projedeki emeğin/eforun %30 -65'i kodlama, hata ayıklama, ve birim testi için harcanır. Eğer kodlama ve birim testi basit ve kolay süreçler olsalardı projedeki emeğin/eforun en fazla %20 -30'u bunlar için harcanırdı. İyi yönetilen projelerde bile gereksinimler her ay %1 -4 oranında değişikliğe uğrar (Jones 2000). Gereksinimlerin değişmesi kodda – bazen çok büyük oranda – değişikliğe neden olur.

Başka Bir Gerçek 6 Modern yazılım geliştirme pratikleri, yazılım yapımı sırasında kodun değiştirilme potansiyelini arttırır. Eski yazılım yaşam döngüsü modellerinde – başarılı veya değil – kod değişikliğinden sakınılmasına odaklanılmaktadır. Güncel yaklaşımlar daha fazla kod merkezlidir ve projenin yaşam döngüsü süresince kodun her zamankinden fazla değişmesi/evrimleşmesi beklenir.

Çağlayan (Waterfall) Modeli 7

Çağlayan (Waterfall) Modeli 8 Çağlayan Modeli diğer mühendislik süreçlerine uygun bir modeldir. Her aşamasında dokümantasyon üretilir. Süreç görünürlüğü nedeniyle yöneticiler bu modeli severler. Bu model, gereksinimlerin çok iyi anlaşıldığı ve geliştirme sırasında değişme olasılığının düşük olduğu projelerde kullanılmalıdır. Değişen müşteri gereksinimlerine çabuk yanıt vermesi zor bir modeldir.

Yazılımın Esnekliği 9 Yazılım sistemleri esnektir Yazılımda her an değişiklik yapılabilir – geliştirme sırasında veya sonra Donanım üretimiyle karşılaştırıldığında bu yazılım geliştirmenin güçlü bir yanı olarak görülebilir

Yazılımın Değişimi & Evrimi 10 Sistem teslim edildikten sonra bile yazılım geliştirme sona ermez. Sistemin ömrü boyunca yazılım geliştirme devam eder. Bir yazılım sisteminin yararlı kalabilmesi için değişimi kaçınılmazdır. Tüm organizasyonlarda en önemli sorunlardan biri mevcut yazılım sistemlerinde değişikliğin nasıl gerçekleştirileceği ve yönetileceğidir.

Değişikliğin Nedenleri 11 İş kurallarında, koşullarında ve gereksinimlerinde değişiklik olabilir � Kullanıcı beklentileri sürekli değişir ve kullanıcılar daha fazlasını isterler � örn. Sosyal Güvenlik yasaları değişebilir kullanıcılar günlük işlerini daha kolay ve kısa zamanda yapabilmelerini sağlayacak yeni özellikler isterler İşletim sırasında hatalar bulunabilir ve giderilmesi gerekebilir Donanım veya yazılım platformlarındaki değişiklikler nedeniyle yazılımın adaptasyonu için değişiklik gerekebilir � örn. 32 bit - 64 bit CPU değişimi veri yapılarında değişiklik gerektirebilir � örn. Windows 7’deki arttırılmış güvenlik özellikleri nedeniyle yazılımın bazı bölümlerinde değişiklik gerekebilir Yazılımın performansında iyileştirmeye gerek duyulabilir

Yazılım Evriminin Önemi 12 Organizasyonlar yazılım sistemlerine çok fazla para yatırdılar ve şu anda tamamen bu sistemlere bağımlı durumdalar. Yeni bir sisteme yatırım yapmaktansa mevcut sistemlerinin değerini korumak adına yapılacak değişikliklere yatırım yapmaya devam etmekteler.

Yazılım Evrimiyle ilgili İstatistikler 13 Kullanışlı yazılım sistemleri genellikle uzun ömürlüdür � Askeri altyapılar ve hava trafik denetimi gibi büyük sistemler genellikle 30+ yaşındadır � İş sistemleri (bilgi sistemleri) genellikle 10+ yaşındadır Kurumsal yazılım maliyetlerinin %85 -90’ı yazılım evrimleşme maliyetidir (Erlickh tarafından 2000’de yapılan bir endüstri anketine göre)

Spiral Evrim Modeli 14

Yazılım Evrimleşme Süreci 15

Değişikliğin Gerçekleştirilmesi 16 Sistemde yapılacak revizyonun tasarlandığı, kodlandığı ve test edildiği yazılım geliştirme sürecinin bir tekrarı olarak görülebilir. Değişikliğin gerçekleştirilmesi, geliştirme sürecinden farklı olarak, programın anlaşılmasını da gerektirir. Özellikle değişikliğin gerçekleştirilmesinden sorumlu geliştiriciler sistemin ilk geliştiricileri değilse bu daha çok önem kazanır. Programın anlaşılması aşamasında programın nasıl yapılandırıldığı, sunduğu işlevselliği nasıl sağladığı, ve yapılacak değişikliğin programı nasıl etkileyebileceği iyice anlaşılmak zorundadır.

Acil Onarım Süreci 17 Yazılım mühendisliği sürecinin tüm aşamaları izlenmeden bazı acil değişikliklerin gerçekleştirilmesi gerekebilir � Sistemin normal işleyişine devam edebilmesi için ciddi bir sistem hatasının giderilmesi gerekiyorsa � Sistemin çalışma ortamındaki değişikliklerin beklenmeyen yan etkileri oluştuysa (örn. İşletim sistemi yükseltmesi) � Çabuk karşılanması gereken işle ilgili değişiklikler söz konusuysa (örn. rakip bir ürünün piyasaya girmesi)

Program Evrim Dinamikleri 18 Program evrim dinamikleri sistem değişiklik süreçlerinin araştırılmasıdır (Projelerdeki fizibilite çalışması gibi). Çeşitli büyük deneysel çalışmalardan sonra Lehman ve Belady tarafından bütün sistemlere evrimleştikleri sürece uygulanabilecek bazı ‘yasalar’ öne sürülmüştür. Aslında bunlar yasadan ziyade mantıklı gözlemlerdir. Bunlar büyük organizasyonlar tarafından geliştirilen büyük sistemlere uygulanabilir durumdadır. �Bunların diğer yazılım sistemi türlerine uygulanabilir olup olmadığı çok açık değildir.

Değişiklik Kaçınılmazdır 19 Sistem geliştirilirken sistem gereksinimlerinin değişmesi muhtemeldir çünkü ortam değişmektedir. Dolayısıyla teslim edilen sistem aslında gereksinimleri karşılamayacaktır. Sistemler kendilerini çevreleyen ortam ile sıkı bir etkileşim içindedir. Bir sistem kurulduğu ortamı da değiştirir, böylece bu değişiklik nedeniyle sistem gereksinimleri de değişir. Sistemler bulundukları ortamda yararlı kalabilmek için değişmek zorundadır.

Lehman Yasaları 20 Law Description Continuing change A program that is used in a real-world environment must necessarily change, or else become progressively less useful in that environment. Increasing complexity As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure. Large program evolution Program evolution is a self-regulating process. System attributes such as size, time between releases, and the number of reported errors is approximately invariant for each system release. Organizational stability Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development. Conservation of familiarity Over the lifetime of a system, the incremental change in each release is approximately constant. Continuing growth The functionality offered by systems has to continually increase to maintain user satisfaction. Declining quality The quality of systems will decline unless they are modified to reflect changes in their operational environment. Feedback system Evolution processes incorporate multiagent, multiloop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.

Yazılım Bakımı 21 Programın kullanıma başlandıktan sonra değiştirilmesidir. Bu terim genellikle özel geliştirilen yazılımlardaki değişiklik için kullanılır. Genel amaçlı (generic) yazılım ürünleri genellikle yeni sürümler şeklinde evrimleşir. Bakım genellikle sistemin mimari tasarımında büyük değişiklikler içermez. Değişiklikler mevcut bileşenlerde değişiklik yapılması ya da sisteme yeni bileşenler eklenmesi şeklinde gerçekleştirilir.

Bakım Türleri 22 Yazılım hatalarının onarımı için yapılan bakım � Yazılımın farklı işletim ortamlarına uyumu için yapılan bakım � Gereksinimleri karşılamak üzere sistemdeki hataların giderilmesine yönelik sistemde değişiklik yapılmasıdır. Sistemin başlangıçta planlanan çalışma ortamından farklı bir çalışma ortamında da (bilgisayar, işletim sistemi, vb. ) çalışabilmesi için gereken değişikliklerin yapılmasıdır Sistemin işlevselliğinde değişiklik ya da ekleme yapılması amacıyla yapılan bakım � Sistemin yeni gereksinimleri karşılayabilmesi için değişiklik yapılmasıdır.

Bakım Emek/Efor Dağılımı 23

Sistem Yeniden Yapılandırma (Reengineering) 24 Eski (legacy) bir sistemin işlevselliğini değiştirmeden yeniden yapılandırılması (re-structure) ya da kısmen veya tamamen yeniden yazılmasıdır (re-write). Büyük bir sistemin bazı alt sistemlerinde çok sık bakım yapılması gerekiyorsa yeniden yapılandırma uygulanabilir. Yeniden yapılandırma, sistemin daha kolay bakım yapılabilir hale gelmesi için çaba sarfedilmesidir. Sistemin yapısı yeni baştan düzenlenir ve yeniden dokümante edilir.

Yeniden Yapılandırmanın Avantajları 25 Azaltılmış risk � Yeni bir yazılım geliştirilmesinin riski çok yüksektir. Geliştirme problemleri, işgücü kaynağı problemleri, spesifikasyon problemleri yaşanabilir. Azaltılmış maliyet � Yeniden yapılandırma maliyeti genellikle yeni bir yazılım geliştirme maliyetinin çok altındadır.

Yeniden Yapılandırma Süreci 26

Yeniden Yapılandırma Etkinlikleri 27 Kaynak kod çevirisi � Tersine mühendislik (Reverse engineering) � Anlaşılabilirlik için otomatik olarak yeniden yapılandırılması Programın modülerleştirilmesi � Programın anlaşılması için analiz edilmesi Program yapısının iyileştirilmesi � Kodun başka bir programlama diline dönüştürülmesi Program yapısının yeniden organize edilmesi Veri tersine mühendisliği � Sistem verisinin temizlenmesi ve yeniden yapılandırılması

Yeniden Yapılandırma Maliyet Faktörleri 28 Yeniden yapılandırılacak yazılımın kalitesi. Yeniden yapılandırma için mevcut araç desteği Gerek duyulan veri dönüşümünün boyutu. Yeniden yapılandırmada çalışacak uzman kadronun durumu � Artık kullanımda olmayan eski teknolojiler ile geliştirilmiş sistemler için bu büyük bir sorun olabilir.

Değişikliğin Maliyeti - Geleneksel 29

Değişikliğin Maliyeti – İdeal 30

Değişiklikle Başedebilmek 31 Değişiklik nedeniyle yapılacak iş tekrarının (rework) maliyetini azaltıcı 2 yaklaşım söz konusudur: � Değişiklikten Sakınmak: çok fazla iş tekrarı gerekmeden önce olası küçük değişikliklere açık olmak (örn. Prototipleme) � Değişikliğe Tolerans Göstermek: değişikliklerin göreceli olarak çok düşük maliyetle gerçekleştirilebilir olması (örn. Artımlı Geliştirme)

Prototipleme 32 Prototip, yazılım sisteminin ilk başlangıç sürümüdür. Şu amaçlarla kullanılmak üzere hazırlanır: � � � Kavramların sunulması, Tasarım seçeneklerinin denenmesi ve, genellikle, sorunların keşfedilmesi ve olası çözümlerin geliştirilmesi. Kullanışlı olması için Prototiplerin çalışan ürün olması gerekli değildir � � Kullanıcı ara yüzünün kağıt üzerinde hazırlanmış taslakları da oldukça etkili olabilir Gerçek işlevleri sağlamadan, uygulamanın yalnızca kullanıcı ara yüzü geliştirilerek müşteriye sunulabilir

Artımlı Geliştirme (Incremental Development) 33

Artımlı Geliştirme 34 Ana fikir � Başlangıç olarak çalışan bir sürümün geliştirilmesi � Bu sürümün kullanıcı değerlendirmesine ve yorumuna tabi tutulması � Çeşitli sürümler boyunca evrimleştirilmesi Uç Programlama (Extreme Programming) gibi çevik (agile) yaklaşımlar tarafından kullanılır Yazılım henüz geliştirilirken değişiklik yapmak daha ucuz ve daha kolaydır

Artımlı Geliştirmenin Yararları 35 Değişen müşteri gereksinimlerini sağlamanın maliyeti nispeten daha düşüktür. Yapılan geliştirme sonucunda ortaya çıkan ürün üzerinde müşteriden geri-bildirim almak daha kolaydır. Kullanışlı bir yazılımın müşteriye daha hızlı teslimi ve kurulumu mümkündür.

Artımlı Geliştirmenin Sorunları 36 Yönetimsel bir bakış açısıyla 2 temel sorun vardır: � Süreç görünür değildir (düzenli hazırlanan dokümantasyon yoktur, sadece kod vardır) � Yeni eklemeler yapıldıkça sistem yapısı ve kalitesi bozulma eğilimindedir – kod dikkatli ve sürekli biçimde yeniden düzenlenmez ise

Yazılım Evriminin Birincil Kuralı 37 Yazılım Evriminin Birinci Kuralı: yazılımın evrimi yazılımın içsel kalitesini sürekli arttırmalıdır. Yazılım Evriminin Birinci Kuralı’nı sağlamadaki ana strateji Yeniden Düzenleme’dir (refactoring). Factoring = programı kendisini oluşturan parçalarına olabildiğince ayırmaktır (Yourdon & Constantine 1979).

Yeniden Düzenleme (Refactoring) 38 Yeniden Düzenleme, değişiklikler nedeniyle yazılımın bozulmasını azaltıcı/önleyici iyileştirmeler yapma sürecidir. Yeniden Düzenleme, gelecekte yapılacak değişikliklerin neden olabileceği sorunları azaltmaya yönelik bir çeşit ‘koruyucu bakım’ olarak da düşünülebilir. Yeniden Düzenleme, bir programın yapısını iyileştirmek, karmaşıklığını azaltmak, ve daha kolay anlaşılır hale getirmek üzere değişiklik yapmaktır. Bir programda yeniden düzenleme yaparken amaç programı iyileştirmek olmalıdır, yeni bir özellik/işlev eklemek değil.

Yeniden Düzenleme x Yeniden Yapılandırma 39 Yeniden Yapılandırma, sistemin bir süre bakımı yapıldıktan sonra bakım maliyetleri çok yüksek hale geldiği zaman yapılır. Eski bir sistemi (legacy) daha fazla bakım yapılabilir hale getirmek amacıyla işlenmesi ve yeniden yapılandırılması için otomatize edilmiş araçlar ve yöntemler kullanılır. Yeniden Düzenleme ise geliştirme ve evrim süresince gerçekleştirilen sürekli bir işlemdir. Sistemin bakımındaki zorlukları ve maliyetleri azaltmaya yönelik olarak sistemin yapısında ve kodda olabilecek niteliksel bozulmaları en başından önlemeyi amaçlar.

«Kötü Kokular» (Code Smells) 40 Bazen bakım nedeniyle kod dejenere hale gelir, bazen de daha en başında kötü yazılmış olabilir. Her iki durumda da yeniden düzenleme gerektiğine dair birtakım uyarı işaretleri ortaya çıkar — bu işaretler yazılım dünyasında “kokular” (kötü kokular) (Fowler 1999) olarak adlandırılır.

«Kötü Kokular» – Yeniden Düzenleme Nedenleri 41 Kod tekrarlanmışsa, çoklanmışsa � � “DRY prensibi”—Don’t Repeat Yourself ( Hunt & Thomas 2000). «Copy & Paste bir tasarım hatasıdır. » (David Parnas) Rutin çok uzunsa Döngü çok uzun ya da çok derinse Sınıf belli bir göreve odaklanmamışsa Rutine çok fazla parametre geçirilmişse Bir değişiklil birden çok sınıfta paralel değişikliğe neden oluyorsa case ifadelerinin paralel olarak değiştirilmesi gerekiyorsa

«Kötü Kokular» – Yeniden Düzenleme Nedenleri 42 Birlikte kullanılan veri öğeleri bir sınıf içerisinde düzgün organize edilmemişse Rutinin adı çok genelse ya da belirsizliğe neden oluyorsa Sınıfın veri üyeleri hep public ise Zor anlaşılır kodu açıklamak için yorum yazmak zorunda kalınıyorsa Global değişkenler kullanılıyorsa “Bir gün lazım olur” düşüncesiyle yazılmış ama henüz kullanılmayan program parçaları varsa

Yeniden Düzenleme Çeşitleri 43 Data Level Refactorings Statement Level Refactorings Routine Level Refactorings Class Implementation Refactorings Class Interface Refactorings System Level Refactorings

Data Level Refactorings 44 Replace a magic number with a named constant Rename a variable with a clearer or more informative name Move an expression inline Replace an expression with a routine Introduce an intermediate variable Convert a multi-use variable to multiple single-use variables Use a local variable for local purposes rather than a parameter Convert a data primitive to a class Convert a set of type codes to a class with subclasses Change an array to an object Encapsulate a collection Replace a traditional record with a data class

Statement Level Refactorings 45 Decompose a boolean expression Move a complex boolean expression into a well-named boolean function Consolidate fragments that are duplicated within different parts of a conditional Use break or return instead of a loop control variable Return as soon as you know the answer instead of assigning a return value within nested if-then-else statements Replace conditionals with polymorphism (especially repeated case statements) Create and use null objects instead of testing for null values

Routine Level Refactorings 46 Extract a routine Move a routine’s code inline Convert a long routine to a class Substitute a simple algorithm for a complex algorithm Add a parameter Remove a parameter Separate query operations from modification operations Combine similar routines by parameterizing them Separate routines whose behavior depends on parameters passed in Pass a whole object rather than specific fields Pass specific fields rather than a whole object Encapsulate downcasting

Class Implementation Refactorings 47 Change value objects to reference objects Change reference objects to value objects Replace virtual routines with data initialization Change member routine or data placement Extract specialized code into a subclass Combine similar code into a superclass

Class Interface Refactorings 48 Move a routine to another class Convert one class to two Eliminate a class Hide a delegate Replace inheritance with delegation Replace delegation with inheritance Remove a middle man Introduce a foreign routine Introduce an extension class Encapsulate an exposed member variable Remove Set() routines for fields that cannot be changed Hide routines that are not intended to be used outside the class Encapsulate unused routines Collapse a superclass and subclass if their implementations are very similar

System Level Refactorings 49 Create a definitive reference source for data you can’t control Change unidirectional class association to bidirectional class association Change bidirectional class association to unidirectional class association Provide a factory method rather than a simple constructor Replace error codes with exceptions or vice versa

Güvenli Biçimde Yeniden Düzenlemek 50 Değiştirmeye başlamadan önce kodu yedekleyin Yeniden düzenlemeleri küçük ölçekli tutun Her seferinde tek bir yeniden düzenleme yapın Yapmayı planladığınız değişikliklerin önceden bir listesini hazırlayın Sık sık kontrol noktaları oluşturun Derleyici uyarılarından yararlanın Yeniden test edin Yeni test durumları ekleyin Değişiklikleri gözden geçirin Yaklaşımınızı yeniden düzenlemenin risk düzeyine göre ayarlayın

Yeniden Düzenleme için Yanlış Zamanlar 51 Ufak tefek kodlama/düzeltme girişimlerini Yeniden Düzenleme adıyla örtbas etmeyin Yeniden yazmak (rewrite) gerekiyorsa Yeniden Düzenlemeye girişmeyin

Yeniden Düzenleme Stratejileri 52 Bir rutin eklediğinizde yeniden düzenleyin Bir sınıf eklediğinizde yeniden düzenleyin Bir hatayı düzelttiğinizde yeniden düzenleyin Hata çıkma olasılığı yüksek modülleri hedef alın Karmaşıklığı yüksek modülleri hedef alın Bakım sırasında dokunduğunuz parçaları iyileştirin Temiz kod ile kirli kod arasında bir sınır belirleyin ve kodu bir taraftan diğer tarafa taşıyın

Özet 53 Program değişiklikleri hem geliştirme aşamasında hem de ilk sürümün teslim edilmesinden sonra hayatın bir gerçeğidir Yazılım değiştirildikçe ya iyileşir ya da kötüleşir. Yazılım Evriminin Birincil Kuralı yazılımın içsel kalitesinin zamanla artmasıdır. Yeniden düzenlemede başarının anahtarı yeniden düzenleme gerektiğini haber veren çeşitli uyarı işaretlerine (smells) dikkat etmeyi öğrenmektir.

Ödev-2 Oyun Alanı 5*5 ila 9*9 arasında olacaktır.

Ödev-2 Devam Oyuncu yapacağı her bir hamle ile grid üzerinde bir alanı kapatır. Amacı daha önce kullanılmayan boş alanları kullanarak oyunda bulunan bütün alanları tamamlamaktır.

Ödev-2 Devam… Oyun Tamamlandığında bir mesaj ekranın alt kısmında kendini gösterecektir.

Kitap Önerisi 54 Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley, 1999 Software Engineering, Ian Sommerville, 8 th Ed. , Pearson, 2007 (Ch 21 Software Evolution) Beautiful Code, Andy Oram & Greg Wilson, O’Reilly, 2007