SE311YAZILIM YAPIMI

BÖLÜM 2DEĞİŞİKLİĞİ BEKLEMEKYrd. Doç. Dr. Volkan TUNALIMühendislik ve Doğa Bilimleri Fakültesi / Maltepe Üniversitesi

Günün Sözü

«Nothing endures but change.»

- Heraclitus (535 BC - 475 BC)

2

Giriş

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

3

Efsane

İYİ YÖNETİLEN BİR YAZILIM PROJESİ yönteme dayalı birgereksinim analizi yapar ve sabit bir gereksinim listesitanımlar. Gereksinim analizini tasarım izler. Tasarım öylesinedikkatlice 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 tekzaman dilimi sadece bakım safhasıdır, yani sistemin ilk sürümü dağıtıldıktan sonra.

4

Gerçek

İ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.

5

Başka Bir Gerçek

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.

6

Çağlayan (Waterfall) Modeli7

Çağlayan (Waterfall) Modeli

Ç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.

8

Yazılımın Esnekliği

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

9

Yazılımın Değişimi & Evrimi

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.

10

Değişikliğin Nedenleri

İş kurallarında, koşullarında ve gereksinimlerinde değişiklik olabilir örn. Sosyal Güvenlik yasaları değişebilir

Kullanıcı beklentileri sürekli değişir ve kullanıcılar daha fazlasınıisterler 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. 32bit - 64bit 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

11

Yazılım Evriminin Önemi

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.

12

Yazılım Evrimiyle ilgili İstatistikler

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)

13

Spiral Evrim Modeli14

Yazılım Evrimleşme Süreci15

Değişikliğin Gerçekleştirilmesi

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.

16

Acil Onarım Süreci

Yazılım mühendisliği sürecinin tüm aşamaları izlenmeden bazı acildeğ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)

17

Program Evrim Dinamikleri

Program evrim dinamikleri sistem değişiklik süreçlerinin araştırılmasıdır.

Çeşitli büyük deneysel çalışmalardan sonra Lehman veBelady tarafından bütün sistemlere evrimleştikleri süreceuygulanabilecek 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üksistemlere uygulanabilir durumdadır. Bunların diğer yazılım sistemi türlerine uygulanabilir olup

olmadığı çok açık değildir.

18

Değişiklik Kaçınılmazdır

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.

19

Lehman Yasaları20

Law DescriptionContinuing 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ı

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.

21

Bakım Türleri

Yazılım hatalarının onarımı için yapılan bakım Gereksinimleri karşılamak üzere sistemdeki hataların giderilmesine

yönelik sistemde değişiklik yapılmasıdır.

Yazılımın farklı işletim ortamlarına uyumu için yapılan bakım 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.

22

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

Sistem Yeniden Yapılandırma (Reengineering)

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.

24

Yeniden Yapılandırmanın Avantajları

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 çok altındadır.

25

Yeniden Yapılandırma Süreci26

Yeniden Yapılandırma Etkinlikleri

Kaynak kod çevirisi Kodun başka bir programlama diline dönüştürülmesi

Tersine mühendislik (Reverse engineering) Programın anlaşılması için analiz edilmesi

Program yapısının iyileştirilmesi Anlaşılabilirlik için otomatik olarak yeniden yapılandırılması

Programın modülerleştirilmesi Program yapısının yeniden organize edilmesi

Veri tersine mühendisliği Sistem verisinin temizlenmesi ve yeniden yapılandırılması

27

Yeniden Yapılandırma Maliyet Faktörleri

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.

28

Değişikliğin Maliyeti - Geleneksel29

Değişikliğin Maliyeti – İdeal30

Değişiklikle Başedebilmek

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)

31

Prototipleme

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

32

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

Artımlı Geliştirme

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

34

Artımlı Geliştirmenin Yararları

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

35

Artımlı Geliştirmenin Sorunları

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

36

Yazılım Evriminin Birincil Kuralı

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).

37

Yeniden Düzenleme (Refactoring)

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.

38

Yeniden Düzenleme x Yeniden Yapılandırma

Yeniden Yapılandırma, sistemin bir süre bakımı yapıldıktansonra 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çinotomatize edilmiş araçlar ve yöntemler kullanılır.

Yeniden Düzenleme ise geliştirme ve evrim süresincegerçekleştirilen sürekli bir işlemdir. Sistemin bakımındakizorlukları ve maliyetleri azaltmaya yönelik olarak sisteminyapısında ve kodda olabilecek niteliksel bozulmaları en başından önlemeyi amaçlar.

39

«Kötü Kokular» (Code Smells)

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.

40

«Kötü Kokular» – Yeniden Düzenleme Nedenleri

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

41

«Kötü Kokular» – Yeniden Düzenleme Nedenleri

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

42

Yeniden Düzenleme Çeşitleri

Data Level Refactorings Statement Level Refactorings Routine Level Refactorings Class Implementation Refactorings Class Interface Refactorings System Level Refactorings

43

Data Level Refactorings

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

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

44

Statement Level Refactorings

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

45

Routine Level Refactorings

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

46

Class Implementation Refactorings

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

47

Class Interface Refactorings

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

48

System Level Refactorings

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

49

Güvenli Biçimde Yeniden Düzenlemek

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

50

Yeniden Düzenleme için Yanlış Zamanlar

Ufak tefek kodlama/düzeltme girişimlerini Yeniden Düzenleme adıyla örtbas etmeyin

Yeniden yazmak (rewrite) gerekiyorsa Yeniden Düzenlemeye girişmeyin

51

Yeniden Düzenleme Stratejileri

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 tokunduğ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

52

Özet

Program değişiklikleri hem geliştirme aşamasındahem de ilk sürümün teslim edilmesinden sonrahayatı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.

53

Kitap Önerisi

Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley, 1999

Software Engineering, Ian Sommerville, 8th Ed., Pearson, 2007 (Ch21 Software Evolution)

Beautiful Code, Andy Oram & Greg Wilson, O’Reilly, 2007

54