Bileen tabanl Uygulama Gelitirme Sreci Component Based Application
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 geliştirilmesi istenir. • Her component en azından kendi hata kodundan kendi hata mesajını geri veren bir metod içermelidir • • RISK COMPONENT 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(. . . ). . . LOGIC RISK TYPE HRK DATA MODEL -------- 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 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. • • RISK COMPONENT 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 TYPE HRK Diğer COMPONENT PKG_UTIL_COMPONENT • P_UTIL_genelservis(. . . ) • PKG_HES_COMPONENT • P_HES_oku(. . . ) • P_HES_musbkybul(. . . ) • LOGIC DATA MODEL -------- BUSINESS LOGIC --------
Uygulama Modeli - Client MODULERISK. fmb Triggers - HESLIST MODULEbaşka. fmb CLIENT WINDOW --- USER INTERFACE --- • 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. • •
Uygulama Modeli - Server P_SRV_RISK_MODULERISK. fmb HESOKU Triggers - BKYBUL SAVE WAN CLIENT 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 end if; SERVER WINDOW ---------- USER INTERFACE ---------- • 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 • •
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 end if; SERVER ---------- USER INTERFACE ---------- • 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. • •
Genel Model MODULERISK. fmb HESOKU Triggers - RISK COMPONENT P_SRV_RISK_MODULERISK BKYBUL SAVE WAN PKG_RISK_COMPONENT 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 end if; 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 TYPE HRK Diğer COMPONENT PKG_UTIL_COMPONENT LAN • P_UTIL_genelservis(. . . ) • PKG_HES_COMPONENT • P_HES_oku(. . . ) • P_HES_musbkybul(. . . ) • MODULEbaşka. fmb CLIENT SERVER LOGIC DATA MODEL WINDOW ---------- USER INTERFACE ---------- BUSINESS LOGIC --------
Genel Model MODULERISK. fmb HESOKU Triggers - RISK COMPONENT P_SRV_RISK_MODULERISK BKYBUL SAVE WAN PKG_RISK_COMPONENT 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 end if; 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 TYPE HRK Diğer COMPONENT PKG_UTIL_COMPONENT LAN • P_UTIL_genelservis(. . . ) • PKG_HES_COMPONENT • P_HES_oku(. . . ) • P_HES_musbkybul(. . . ) • MODULEbaşka. fmb CLIENT SERVER LOGIC DATA MODEL WINDOW ---------- USER INTERFACE ---------- BUSINESS LOGIC --------
- Slides: 8