Agile Modelleme Pratikleri

Bu makalemizde daha önce bahsettiğimiz Agile Modellemenin pratik yani uygulama tarafına değineceğim. Bu uygulamaları anlatırken Agile Metotları içinden Extreme Programming(XP)i örnek alarak anlatacağım.

Agile modelleme uygulamaları çekirdek ve tamamlayıcı olarak aşağıda iki farklı bölümde anlatılmaktadır.

AMDD(Agile Model Driven Development) yaklaşımını gerçekten kullandığınızı iddia edebilmeniz için Çekirdek Uygulamaları benimsemelisiniz.

Tamamlayıcı Uygulamalar, ise yazılım gereksiniminiz tam anlamıyla karşılayabilmeniz için yazılım süreçlerine adapte etmeyi düşünmelisiniz. Aynı zamanda adapte etmeyi düşündüğünüz gerçekten iyi fikirlerde vardır fakat bunlar AMDD nin parçası değildirler.

Çekirdek Uygulamalar

• Proje Destekçilerinin Aktif Katılımı
• Doğru Öğelerin Uygulanması
• Ortak Mülkiyet
• Paralel Birkaç Model
• Basit İçerik
• Basit Model
• Modelin Herkese Gösterilmesi
• Bir Öğeyi Üzerinde Tekrar Çalışılmak Üzere Ertelemek(An itibariyle çözülemeyen bir problemle karşılaşıldığın başka bir öğe üzerinde çalışmaya başlamak ve belirli süre sonunda ilk öğeye geri dönmek)
• Küçük Adımlar İçinde Modelleme
• Takım ile Modelleme
• Kodlayarak Kanıtlama
• Tek Bilgi Kaynağı
• En Basit Araçları Kullanma

Proje Destekçilerinin Aktif Katılımı: XP nin müşteri tarafındaki genişlemesi şunu ifade eder; ihtiyacı gidermek için kullanıcılara ulaşmak, ihtiyaçlara ve bu ihtiyaçların önceliklendirilmesine göre sistem oluşturmak ve yerinde ve zamanında kararlar verebilmek için yetki ve yeteneğe sahip olmaktır. AM, XP nin müşteri yerindeki uygulaması proje destekçilerini(son kullanıcılar, yönetim, üst yönetim, operasyon çalışanları ve destek çalışanları) aktif bir şekilde projeye dâhil etmektedir. Bu, üst yönetim tarafından, zaman kaynaklı kararlar verilmesini, projeye genel ve özel destek verilmesini, operasyon ve destek çalışanlarının ise ihtiyaçların belirlenmesinde aktif katılımı ve modellerle ilgili onların düşüncelerini içerir. Eğer katılımlı modelleme tekniklerini benimserseniz, projenizde aktif proje destekçisi katılımını kolayca düzenleyebilirsiniz.

Doğru Öğelerin Uygulanması: Her öğe kendisine has özelliklere sahiptir. Örneğin, UML Activity Diagram, iş süreçlerini açıklamada kullanışlıdır, halbuki veritabanınızın statik yapısı, fiziksel veri ya da kalıcı model ile daha iyi ifade edilir. Genelde bir diagram kaynak koddan daha iyi bir seçimdir. Eğer bir resim bin sözcüğe bedelse, bir model 1024 satır koda bedeldir, doğru koşullar içinde uygulandığında(Bu ifade Karl Wieger in Software Requirements ından ödünç alınmıştır). Beyaz tahta üzerine birkaç diagram çizerek çalışma arkadaşlarınızla daha verimli dizayn alternatiflerini keşfedebilirsiniz daha sonra kod örneklerini geliştirebilirsiniz. Sonuçta her öğenin güçlü ve zayıf yönlerini bilmeniz gerekir böylece onları ne zaman kullanıp, kullanmayacağınızı bilirsiniz. Eğer çok sayıda model ile çalışıyorsanız bu zor olabilir.

Ortak Mülkiyet: Herkes her model üzerinde çalışabilir aslında eğer ihtiyaçları varsa her öğe üzerinde çalışabilirler.

Paralel Birkaç Model: Her tip modelin güçlü ve zayıf yönleri bulunur. Modelleme ihtiyaçlarınız için tek bir model yeterli olmayabilir.

Basit İçerik: Proje destekçilerinizin ihtiyaçlarını giderirken modellerinizin(ihtiyaçlarınızın, analizlerinizin, mimarinizin ya da dizaynınızın) içeriğini mümkün olduğunca basit şekilde oluşturmalısınız. Özetle eğer uygun nitelikte değilse modellerinize eklentiler yapmamalısınız. Eğer bir özelliğe ihtiyacınız yoksa o özelliği modellerinize eklemeyin. Bu özelliğe eğer ihtiyacınız olursa ve ne zaman ihtiyacınız olursa ekleyebileceğinize dair cesaretiniz olsun.

Basit Model: Uygulayabileceğiniz potansiyel diyagramları(UML Diyagramları, UI Diyagramları, Data Modeller, vb) düşünürken çabucak farkına varırsınız ki, zamanın çoğunda diyagram notasyon alt kümelerinin sizin için erişilebilir olmasına ihtiyacınız vardır. Basit bir model anlamaya çalıştığınız temel özellikleri gösterir, belki bir sınıf modeli sınıfların birincil sorumluluklarını ve birbirleri arasındaki ilişkileri gösteriyor olabilir. Evet, yazmak zorunda kalacağınız, kodlama standardınızın kullanmayı söylediği getter ve setter operasyonlarının tamamı bütün bu iskelet kodu modelleyebilirsiniz, peki ama bu ne kadar bir değer ekler? Çok az.

Modelin Herkese Gösterilmesi: Model Duvarı ya da Merak Duvarı diye adlandırabileceğiniz bir yerde modelinizi herkese göstermelisiniz. Bu takımınız üzerinde açık ve dürüst bir iletişimi destekler çünkü kullanılan modellere kolayca ulaşabilirler tıpkı proje destekçilerinize olduğu gibi, onlardan bir şey saklamamalısınız. Modelleme duvarınız, modellerinizi herkesin görmesi için kullandığınız yer, yazılım geliştirme takımınızın ve proje destekçilerinizin kolayca erişebileceği bir yer olmalıdır. Modelleme duvarınız fiziksel olabilir, belki mimari diyagramlarınızı için dizayn ettiğiniz beyaz tahta ya da fiziksel veri modeliniz için yazıcıdan aldığınız çıktıları bantladığınız bir yer. Modelleme duvarı sanal olabilir, örneğin taranmış resimlerle güncellenen şirket içi bir web sayfası bile işinizi görebilir.

Bir Öğeyi Üzerinde Tekrar Çalışılmak Üzere Ertelemek: Geliştirme öğeleri(örneğin use case, CRC kartları, dizi diyagramlar ve hatta kaynak kodu) üzerinde çalışırken sıkıştığınızı düşünün öyleyse bu zaman içinde başka bir öğe üzerinde çalışmayı düşünmelisiniz. Her öğe kendisinin güçlü ve zayıf yönlerine sahiptir. Her öğe belli bir iş tipi içindir. Ne zaman kendinizi bir öğe üzerinde çalışırken zorluklar içinde bulursanız, belki bir use case üzerinde çalışırken, tarif etmekte zorlandığınız bir iş mantığı üzerinde çalışırken bu başka bir öğeyi tekrar gözden geçirmeniz gerektiği anlamına gelir. Örneğin; eğer temel bir use case üzerinde çalışıyorsanız o zaman belki temel bir UI prototipi üzerinde, CRC model, iş kuralı, bir sistem use casei yada bir change casei üzerinde çalışmayı düşünmelisiniz. Başka bir öğe üzerinde tekrar çalışmaya başlamanız sizin sıkışmışlıktan kurtarır ve başka bir öğe üzerinde ilerlemeye başlarsınız. Zaman tanımak ve bakış açınızı değiştirmek genelde nerede sıkıştıysanız bunu keşfetmenizi sağlar.

Küçük Adımlar İçinde Modelleme: Büyük bir gayreti küçük bölümlere ayırarak organize ettiğiniz arttırımlı geliştirme, birkaç hafta, bir ya da iki aylık arttırımlı geliştirmeler sonunda çevikliğiniz arttırır böylece yazılımınızı kullanıcılarınıza daha hızlı ulaştırırsınız.

Takım ile Modelleme: Bir amaçla modelleme yaptığınızda genelde görürsünüz ki bir şeyi anlamak için modelleme yapıyorsunuz, sizin fikirlerinizle diğerlerinin fikirleri arasında iletişim kurmak için modelleme yapıyorsunuz ya da projenize genel bir vizyon geliştirme arayışındasınız. Bu bir grup etkinliğidir, birkaç kişinin verimlice beraber çalışmasını istediğiniz bir grup. Bununla sıklıkla karşılaşacaksınız projenizin kritik modellerinin çekirdek setlerinin yaratılması için yazılım takımınızın beraber çalışması gerekir. Örneğin; sisteminiz için bir örnek veya mimari geliştirme, genellikle bir grup insanla herkesin hem fikir olduğu ve aynı zamanda mümkün olduğunca basit olan bir çözüm üretebilmek için modellemeye ihtiyacınız olacak. Çoğu zaman bunu yapmanın en iyi yolu bir ya da birden fazla kişiyle bu konuyu konuşmaktır. Diğer kişilerle modelleme Non-Solo Development in bir örneğidir, tıpkı çifte programlama gibi.

Kodlayarak Kanıtlama: Model soyuttur, inşa ettiğiniz neyse onu doğru şekilde yansıtmalıdır. Fakat inşa ettiğiniz şey çalışacak mı? Buna karar verebilmek için, modelinizin kodlayarak sağlamasını yapmalısınız. Fatura adres bilgilerini almak için bir HTML sayfa taslağını geliştirdiniz. Kodlayın ve kullanıcı geri bildirimleri için bu ara yüzü kullanıcılarınıza gösterin. Karmaşık bir iş kuralını projenize uygulamak için bir UML Sequence Diagram geliştiriyorsunuz. Test kodunu, iş kodunu yazın ve doğru yaptığınızdan emin olabilmek için testi çalıştırın. Şunu asla unutmayın yazılım geliştirmeye yineleme yaklaşımıyla, projelerin büyük çoğunluğu için standart modelleme gerçekleştirilecek birçok görevden sadece biridir. Diğer yapılan işlerin yanında, biraz modelleme yapın, biraz kodlama yapın, biraz test yapın.

Tek Bilgi Kaynağı: Bilgi sadece ama sadece bir yerde saklanmalıdır. Başka bir deyişle sadece doğru öğelerin uygulanması değil aynı zamanda konsepti bir defa modellemelisiniz. Bilgiyi mümkün olan en iyi yerde saklayınız. Modelleme yaparken sürekli sorular sormalısınız. Bu bilgiyi kalıcı olarak saklamalı mıyım? Eğer saklayacaksam bu bilgiyi saklayabileceğim en iyi yer neresidir? Bu bilgiyi alabileceğim başka bir yerde saklıyor muyum? Bazen bir bilginin saklanabileceği en iyi yer agile dokümanıdır, genellikle kaynak kodunun içidir.

En Basit Araçları Kullanma: Modellerin büyük çoğunluğu beyaz tahta, kâğıt hatta peçetenin üzerine çizilebilir. Ne zaman bu diyagramlardan birini saklamak isterseniz dijital bir kamera ile resmini çekebilirsiniz ya da basit olarak açıklamasını yapıp metin şeklinde saklayabilirsiniz. Bu işe yarayabilir çünkü kâğıt üzerine çizilen birçok diyagram atılabilir, bu diyagramların gerçek değeri bir konu üzerine düşünerek çizilmelerinden gelir ve problem bir kere çözüldü mü, bu diyagramın pek bir değeri kalmaz. Sonuç olarak beyaz tahta ve kalemleri genelde sizin en iyi modelleme seçeneğinizdir,  proje destekçilerinize diyagram oluştururken ve bunun sunumunu yaparken çizim aletlerinden yararlanın ve bazen modelleme araçları kullanın fakat sadece ama sadece programlama emeğinize örneğin kod üretimi gibi bir katkısı bulunacaksa. Bunu şöyle düşünün; eğer basit modeller oluşturuyorsanız ve modelini oluşturduğunuz konuları anladıktan sonra o modeli saklamaya gerek yoktur daha sonra genelde karmaşık modelleme araçlarını kullanmaya ihtiyacınız olmayacaktır.

Tamamlayıcı Uygulamalar

• Modelleme Standartlarını Uygulama
• Şablonları Akıllıca Uygulama
• Geçici Modelleri Iskartaya Çıkarma
• İlişki Modellerini Şekillendirmek
• Sadece Sorun Olduğunda Güncelleme Yapmak

Modelleme Standartlarını Uygulama: Ana fikir şudur; yazılım geliştiriciler proje üzerinde çalışırken genel bir modelleme seti üzerinde anlaşmalı ve bunu takip etmelidirler. Tıpkı ortak kodlama kurallarında bir değer olduğu gibi, temiz kod, sizin seçtiğiniz kodlama rehberiniz kodunuzu anlaşılmasını kolaylaştırır ve böylece kod üzerinde yapılacak değişiklikleri kolaylaştırır. Ortak modelleme standartlarında da benzer bir değer bulunur. Ortak modelleme standartları geniş bir çeşitliliğe sahiptir, buna genel nesne yönelimli modeller için notasyon ve semantikleri tanımlayan Object Management Groupların UML i dâhildir. UML iyi bir başlangıç sağlar fakat yeterli değildir göreceğiniz gibi potansiyel modelleme öğelerini kapsamaz. Ayrıca UML iyi görünümlü diyagramlar oluşturma için modelleme stilleri rehberi hakkında bir şey anlatmaz. Stil rehberi ve standartlar arasındaki fark nedir? Kaynak kodunuzun yazımında nasıl yazılım standartlarınız bulunuyorsa modelinizi oluştururken de standartlarınız olmalı. Örneğin; kaynak kodunuzda değişkenleri tanımlarken Pascal Casing (productId) kullanıyorsanız modelinizi geliştirirken diyagramınızdaki bir kare bir sınıfı ifade etmelidir.

Şablonları Akıllıca Uygulama: İyi modelleyiciler önce araştırır, öğrenir ve sonra uygun bir şekilde genel mimari, tasarım ve analiz fikirlerini uygularlar. Yine de Martin Fowler ın işaret ettiği gibi Dizayn öldü mü? Yazılım geliştiriciler şablon uygulamaları kolaylaştırmayı ve bunları akıllıca uygulamayı düşünmelidirler. Bu sadeliğin değerini yansıtır. Diğer bir deyişle, şundan şüpheleniyorsanız, bunu modellemelisiniz örneğin bugün ihtiyacınız olan minimal eklentiyi yapmak gibi, bu daha sonra üzerinden geçtiğinizde işinizi kolaylaştırır. Yani, modeli tekrarlamayın. Örneğin, tasarımınız da GoF Strategy Şablonunu uygulayabileceğiniz iyi bir yer var fakat şuan uygulayabileceğiniz sadece iki algoritma bulunuyor. En iyi yaklaşım her stratejiyi kapsayacak kendi içinde bir sınıf ve bu sınıfları uygun şekilde seçip, seçtiğiniz sınıflara uygun verileri geçen bir operasyon oluşturmaktır. İleri de daha çok algoritmanın eklenmesi gerekirse, sizi tasarımınız üzerinden bir kez daha geçme durumunda bırakacak bir stratejinin bölümsel eklentisidir. Bu yaklaşım şablon uygulamayla kolayca etkileşime geçmenizi sağlar. Bu yapacağınız değişikliği her şablona ve sınıfa ayrı ayrı yapmanızın önüne geçer ve bütün şablonlar için değişikliği sadece bir yerde ve bir defa yaparsınız.

Geçici Modelleri Iskartaya Çıkarma: Geçici ve çalışan modellerin büyük çoğunluğu(tasarım çizimleri,  düşük seviyedeki prototipler, indeks kartları, potansiyel mimari ve tasarım alternatifleri vb) amaçlarını tamamlamış ve artık bir değer getirmeyen, işleri bitmiş demektir. Modeller çabucak kod ile senkronize olmaktan çıkar ve bundan yanlış hiçbir şey yoktur, bu durumda modelinizle kodunuzu senkronize hale getirmelisiniz. Eğer bu modelleri güncellemeniz size bir değer döndürmüyorsa bu negatif bir iş demektir. Bu pratik agile dokümantasyon için özellikle önemlidir.

İlişki Modellerini Şekillendirmek: Harici bir grup, veri kaynağını kontrol ederken ilişki modellerine genelde ihtiyaç duyar. Bir ilişki modeli şöyledir; zaman içinde eğer değişiklik gerekliyse iki grupta karşılıklı anlaşmalı ve değişik yapmalıdır. İlişki modeline örneklere, detaylandırılmış uygulama programlama ara yüzü(API) dokümantasyonu, bir dosya düzeninin açıklanması, bir XML DTD(Document Type Definition), paylaşımlı veritabanının fiziksel veri modelinin ifade edilmesi. Yasal bir sözleşme de olduğu gibi, bir ilişkinin geliştirilmesi ve bakımının yapılabilmesi için bir ilişki modelinde sıklıkla önemli kaynak yatırımına ihtiyaç duyulur, bu yatırım doğrulanır ve detaylandırılır. XP nin hafif ağırlıklar ile seyahat ilkesine sisteminizde uymak için amacınız ilişki modellerinin sayısını azalmak olmalıdır.

Sadece Sorun Olduğunda Güncelleme Yapmak: Bir modeli sadece ama sadece ihtiyacınız olduğunda güncellemelisiniz, bir modelin güncel olmaması, onu güncelleme çabasından daha can sıkıcıdır. Bu yaklaşım ile şunu keşfedersiniz; zamanla güncelleme sayınız azalacaktır. Çünkü gerçekte modellerinizin size bir değer kazandırabilmesi için mükemmel olmak zorunda değildirler. Örneğin şehir haritam 5 yıllıktır, bunu biliyorum çünkü yaşadığım sokak şuan harita da bulunmuyor ve burası 5 yıldan daha az bir zamandır yerleşim yeri yine de harita benim için kullanışlıdır. Evet, haritayı güncellemek için bir harcama yapabilirim, her yıl yeni bir tane piyasaya çıkar fakat neden böyle bir harcama yapayım? Birkaç sokağı bilmemek bu harcamayı yapmaya değmez. Elimdeki yeterince iyi olduktan sonra her yıl yeni bir harita almaya ve para, kaynak harcamaya gerek yoktur. Çok fazla zaman ve para modelleri ve dokümanları, kaynak kod ile senkronize tutmak için boş yere harcanmaktadır. Bu zaman ve para yeni bir yazılım geliştirmek için harcamak daha mantıklıdır. Bu uygulama özellikle agile dokümantasyon için önemlidir.

Kaynak : agilemodeling.com