Bileşen tabanlı Uygulama Geliştirme Süreci Component Based Application Development Methodology

Component Modeli Öncelikle yapılan analiz sonucunda geliştirilecek uygulamanın data modeli ve bunun parallelinde de bu model üzerinde çalışacak metodlar yani business model’i belirlenir. Bu yönteme parallel decomposition adı verilir. Ardından her metod içerisindeki logic kodlanır ve test edilir. Bu metodlar business açısından consistent olmalıdırlar. Metodlar genelde non-transactional‘dır, yani kendi başlarına bir transaction değil, bir transaction’ın parçaları olarak kullanılırlar. Ancak gerekiyorsa transactional metodlar da geliştirilir ve test edilir. Bunların kendilerine ait bir window’ları da bulunur. Örn. Risk tipleri listeleme, Müşteri adından araştırma, Müşteri nuymarasına ait hesapların listelenmesi, Hesap görüntüleme Uygulama metodları bir arada bir package içerisinde toparlanır. Bu package başka bir açıdan bir component‘tir. Geliştirme de bu şekilde component tabanlı (component based development) yapılır. Bu component’in veri modeline başka hiç bir yerden ulaşılamaz. Eğer bu tip bir ihtiyaç varsa o component’ler için lazım olan metodlar da burada geliştirilir. Bu component için geliştirilen bir metodun başka bir yerdeki bir veriye ulaşması gerekiyorsa o işle ilgili başka bir componen’tin var olan bir metodu kullanılır veya işimize yarayan bir metod yoksa yoksa geliştirilmesi istenir. Her component en azından kendi hata kodundan kendi hata mesajını geri veren bir metod içermelidir PKG_RISK_COMPONENT P_RISK_READ(...) P_RISK_UPD(...) P_RISK_INS(...) P_RISK_LST(...) P_RISK_DEL(...) P_RISK_CRE(...) P_RISK_HESAPLA(...) P_RISK_...(...) F_RISK_errmsgbul(...) ... RISK COMPONENT RISK TYPE HRK DATA MODEL LOGIC --------------- BUSINESS LOGIC ---------------

Component’ler Bu şekilde geliştilen component kendi veri modellerini gizleyerek (encapsulation) dışarıya metodlar sağlarlar. Bu şekilde arka tarfta veri modeli değiştirilmesi gerektiğinde sadece metodların içi değişeceğinden bunları kullanan diğer component’ler veya uygulamalar’ın değiştirilmesi gerekmez. Bir metod’un argumanları yani arayüzü (interface) değiştiğinde tabi ki bunu kullanan dış dünyanın da buna uyması gerekebiliri. Ancak bu bir şekilde, en azından belli bir süre için birden fazla metod sürümü (version) ile sağlayarak idare edilebilir. Bu şekilde geliştirilen component’ler yeri geldiğinde bu compoennt’in başka bir sürümü (version) ile yer değiştirebilir. Ayrıca dışarıdan hazır alınabilecek bir component ile de yer değiştirebilir. Eğer satın alınan component’in arayüzü farklı ise basit bir component ile metodlarının etrafı sarılarak (wrap) edilerek içeriye yansıtılmaması mümkün olabilir. Gelkiştirilen bu component’ler başlangıçta uygulama geliştirme sürecinin yavaşlatsa bile kısa zamanda geliştirme sürecini kat kat hızlandırar. Bu component’ler business için birer assest haline gelirler. Ve uzun erimde business’in rekabet gücüne değişen koşullara hızla adapte olmasını sağlayarak katkıda bulunurlar. PKG_RISK_COMPONENT P_RISK_READ(...) P_RISK_UPD(...) P_RISK_INS(...) P_RISK_LST(...) P_RISK_DEL(...) P_RISK_CRE(...) P_RISK_HESAPLA(...) P_RISK_...(...) F_RISK_errmsgbul(...) ... RISK COMPONENT RISK TYPE HRK Diğer COMPONENT PKG_UTIL_COMPONENT P_UTIL_genelservis(...) PKG_HES_COMPONENT P_HES_oku(...) P_HES_musbkybul(...) DATA MODEL LOGIC --------------- BUSINESS LOGIC ---------------

Uygulama Modeli - Client MODULERISK.fmb Triggers - Uygulama (application) kullanıcıların kullandığı arayüzdür. Yeri geldiğinde iş kurallarına (business model’i veya business rules) etki etmeden değiştirilebilmesi gerekir. Bir uygulama component’lerden tamamen bağımsız bir şekilde geliştirilmelidir. Hatta etki altında kalınmasını engellemek için component geliştirenler ile uygulama geliştirenler belli bir zamanda farklı kişiler olmalıdır. Uygulama içerisinde kesinlikle iş kararları olmamalıdır. Uygulama transaction’lardan meydana gelir. Her transaction’ın genelde bir penceresi (window) vardır. Bu pencerenin arkasında çalışan kod bir istemci yani client’tır. Genelde kullanıcı PC’sinde çalışan bu client’a modul adı da verilebilir. Client, içerisinde sadece window’un nasıl boyanacağını kontrol eden trigger veya diğer bir adla event’ler olmalıdır. Her event’te ne yapılması gerektiği uygulamanın analiz aşamasında ortaya çıkartılır. Gerektiğinde bir client’tan bir diğer clien’ta geçilebilir. Bu diğer client ya aynı uygulamanın bir client’ı veya başka bir uygulama nın bir client’ı olabileceği gibi bir component’in transactional bir metodu da olabilir. Başka bir client’a geçerken isteği ayrıdedebilmek için belli bir command ve extra argumanlar da verilebilir. Geri dönüş varsa gerektiğinde ayrıdedebilmek amacı ile aynı command ile bazı argumanlar da geri alınabilir. HESLIST MODULEbaşka.fmb CLIENT WINDOW --- USER INTERFACE ---

Uygulama Modeli - Server MODULERISK.fmb Triggers - P_SRV_RISK_MODULERISK if COMMAND=‘HESOKU’ then P_HES_oku(...) elsif COMMAND=‘BKYBUL’ then P_HES_musbkybul(...) elsif COMMAND=‘SAVE’ then F_RISK_UPD(...) P_UTIL_genelservis(...) end if; if error then F_RISK_errmsgbul(...) ROLLBACK else COMMIT Event’ler genelde ekranda bazı değişiklikler yaratırlar. Bunları event’in kendisi yapabileceği ekrana koyacağı bir veri parçası için business modelindeki bazı component’lardan bazı metodlar’ın kullanılması da gerekebilir. Ancak event’ler imkanları dahilinde olsa da bu metodlar’ı doğrudan kullanmamaları gerekir. Bunun yerine arka tarafta yani server makinada çalışacak olan ve bu client’a karşılık gelen ve server adı verilen bir programı geliştirilmeli ve istekler sadece buna yönlendirilmelidir. Her istek server tarafından ayırdedilebilmesi için bir command ve gerekiyorsa bazı argumanlar ile hazırlanan bir mesaj şeklinde geçirilmelidir. Bu mesaj ileride client modul’un şimdikinden daha farklı bir uygulama geliştirme ürünü ile (Visual Basic, Delfi, Visual C, Forms, Power Builder vs) yeni baştan geliştirilebileceği düşünülerek mümkün olduğunca standart (ör. string) tasarlanmalıdır. Bu server program gerektiğinde başka bir ortamdan aynı mesajlarla iletişim sağlayacak başka client’lara hizmet verebilir. Ör. Kullanıcı PC’sindeki bir virman client modulune hizmet verebileceği gibi bir ATM makinasından veya internet şubesi kullanıcı arayüzünden gelecek isteklere de hizmet verebilmelidir. Bir anlamda kullanıcı arayüzü (user interface) PC’deki ve server makinadaki server modul’ün ikisinden beraber meydana gelir. İki modül LAN üzerinden iletişim sağlayabileceği gibi aralarından WAN da bulunabilir HESOKU BKYBUL SAVE WAN CLIENT SERVER WINDOW ------------------- USER INTERFACE -------------------

Server Server’ın içi çok basit design edilmelidir, genelde client’taki event’lere karşılık gelen ve mekanik iş yapan bölümlerden meydana gelmelidir. Hangi bölümün çalıştırılacağı ise client’tan gelen mesajın içerisindeki command’dan anlaşılabilir. Her kısımda mesaj içerisinde gelen arguman’lar kullanılarak bu isteğe karşılık gelen bir veya daha fazla component metodu çağrılır. Yapılan iş sadece bu metod’lara aktarılacak argumanların belirlenip metodların çağrılması, varsa metod’dan geri gelen argumanların alınması, gerekiyorsa ikinci bir metod’a geçirilmesi, ve sonunda da client’a aktarılacak mesajın hazırlanmasıdır P_SRV_RISK_MODULERISK if COMMAND=‘HESOKU’ then P_HES_oku(...) elsif COMMAND=‘BKYBUL’ then P_HES_musbkybul(...) elsif COMMAND=‘SAVE’ then F_RISK_UPD(...) P_UTIL_genelservis(...) end if; if error then F_RISK_errmsgbul(...) ROLLBACK else COMMIT Server’da yapılan önemli bir iş daha vardır. Herşeyden önce her metod çağrıldıktan sonra o metod’un hata kodu return edip etmediği kontrol edilir ve bir sonraki metod buna göre çağrılır. Eğer bir metod hata deödürdü ise bu metod’un compoent’in sağlaması gereken hata mesajı bulan metod kullanılarak hata mesajı alınır ve client’a gönderilir. Hata durumunda ROLLBACK yapılarak metodların yapmış olduğu işler geri alınır, normal durumda ise COMMIT yapılarak iş (transaction) gerçekleştirilmiş olur. Client business logic içermediğinden two phase commit sözkonusu değildir. SERVER ------------------- USER INTERFACE -------------------

Genel Model WAN LAN --------------- BUSINESS LOGIC --------------- MODULERISK.fmb Triggers - P_SRV_RISK_MODULERISK if COMMAND=‘HESOKU’ then P_HES_oku(...) elsif COMMAND=‘BKYBUL’ then P_HES_musbkybul(...) elsif COMMAND=‘SAVE’ then F_RISK_UPD(...) P_UTIL_genelservis(...) end if; if error then F_RISK_errmsgbul(...) ROLLBACK else COMMIT PKG_RISK_COMPONENT P_RISK_READ(...) P_RISK_UPD(...) P_RISK_INS(...) P_RISK_LST(...) P_RISK_DEL(...) P_RISK_CRE(...) P_RISK_HESAPLA(...) P_RISK_...(...) F_RISK_errmsgbul(...) ... RISK COMPONENT RISK TYPE HRK HESOKU BKYBUL SAVE Diğer COMPONENT WAN PKG_UTIL_COMPONENT P_UTIL_genelservis(...) LAN PKG_HES_COMPONENT P_HES_oku(...) P_HES_musbkybul(...) MODULEbaşka.fmb --------------- BUSINESS LOGIC --------------- WINDOW CLIENT SERVER ------------------- USER INTERFACE ------------------- LOGIC DATA MODEL

Genel Model WAN LAN --------------- BUSINESS LOGIC --------------- MODULERISK.fmb Triggers - P_SRV_RISK_MODULERISK if COMMAND=‘HESOKU’ then P_HES_oku(...) elsif COMMAND=‘BKYBUL’ then P_HES_musbkybul(...) elsif COMMAND=‘SAVE’ then F_RISK_UPD(...) P_UTIL_genelservis(...) end if; if error then F_RISK_errmsgbul(...) ROLLBACK else COMMIT PKG_RISK_COMPONENT P_RISK_READ(...) P_RISK_UPD(...) P_RISK_INS(...) P_RISK_LST(...) P_RISK_DEL(...) P_RISK_CRE(...) P_RISK_HESAPLA(...) P_RISK_...(...) F_RISK_errmsgbul(...) ... RISK COMPONENT RISK TYPE HRK HESOKU BKYBUL SAVE Diğer COMPONENT WAN PKG_UTIL_COMPONENT P_UTIL_genelservis(...) LAN PKG_HES_COMPONENT P_HES_oku(...) P_HES_musbkybul(...) MODULEbaşka.fmb --------------- BUSINESS LOGIC --------------- WINDOW CLIENT SERVER ------------------- USER INTERFACE ------------------- LOGIC DATA MODEL