bile en tabanl uygulama geli tirme s reci n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Bileşen tabanlı Uygulama Geliştirme Süreci PowerPoint Presentation
Download Presentation
Bileşen tabanlı Uygulama Geliştirme Süreci

Loading in 2 Seconds...

play fullscreen
1 / 8

Bileşen tabanlı Uygulama Geliştirme Süreci - PowerPoint PPT Presentation


  • 171 Views
  • Uploaded on

Bileşen tabanlı Uygulama Geliştirme Süreci. Component Based Application Development Methodology. 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_...(...)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Bileşen tabanlı Uygulama Geliştirme Süreci' - katina


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
bile en tabanl uygulama geli tirme s reci

Bileşen tabanlı Uygulama Geliştirme Süreci

Component Based

Application Development Methodology

component modeli

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

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

DATA MODEL

LOGIC

--------------- BUSINESS LOGIC ---------------

component ler

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

  • PKG_UTIL_COMPONENT
  • P_UTIL_genelservis(...)
  • PKG_HES_COMPONENT
  • P_HES_oku(...)
  • P_HES_musbkybul(...)

Diğer COMPONENT

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.

DATA MODEL

LOGIC

--------------- BUSINESS LOGIC ---------------

uygulama modeli client

MODULERISK.fmb

Triggers

-

-

-

-

-

MODULEbaşka.fmb

Uygulama Modeli - Client
  • 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

CLIENT

WINDOW

--- USER INTERFACE ---

uygulama modeli server

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;

MODULERISK.fmb

Triggers

-

-

-

-

-

Uygulama Modeli - Server
  • 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

SERVER

CLIENT

WINDOW

------------------- USER INTERFACE -------------------

server

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
  • 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
  • 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

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

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;

MODULERISK.fmb

Triggers

-

-

-

-

-

  • PKG_UTIL_COMPONENT
  • P_UTIL_genelservis(...)
  • PKG_HES_COMPONENT
  • P_HES_oku(...)
  • P_HES_musbkybul(...)

Diğer COMPONENT

MODULEbaşka.fmb

DATA MODEL

LOGIC

SERVER

CLIENT

WINDOW

------------------- USER INTERFACE -------------------

--------------- BUSINESS LOGIC ---------------

Genel Model

HESOKU

BKYBUL

SAVE

WAN

LAN

genel model1

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

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;

MODULERISK.fmb

Triggers

-

-

-

-

-

  • PKG_UTIL_COMPONENT
  • P_UTIL_genelservis(...)
  • PKG_HES_COMPONENT
  • P_HES_oku(...)
  • P_HES_musbkybul(...)

Diğer COMPONENT

MODULEbaşka.fmb

DATA MODEL

LOGIC

SERVER

CLIENT

WINDOW

------------------- USER INTERFACE -------------------

--------------- BUSINESS LOGIC ---------------

Genel Model

HESOKU

BKYBUL

SAVE

WAN

LAN