View
12
Download
0
Category
Preview:
Citation preview
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
Recommended