Etkileşim Odaklı Mimari

Etkileşim odaklı mimarinin birincil amacı, kullanıcının etkileşimini veri soyutlamasından ve ticari veri işlemeden ayırmaktır. Etkileşim odaklı yazılım mimarisi, sistemi üç ana bölüme ayırır -

  • Data module - Veri modülü, veri soyutlama ve tüm iş mantığını sağlar.

  • Control module - Kontrol modülü, kontrol akışını ve sistem yapılandırma eylemlerini tanımlar.

  • View presentation module - Görünüm sunum modülü, veri çıkışının görsel veya sesli sunumundan sorumludur ve ayrıca kullanıcı girişi için bir arayüz sağlar.

Etkileşim odaklı mimarinin iki ana stili vardır: Model-View-Controller (MVC) ve Presentation-Abstraction-Control(PAC). Hem MVC hem de PAC, üç bileşen ayrıştırma önerir ve çoklu konuşma ve kullanıcı etkileşimleri içeren web uygulamaları gibi etkileşimli uygulamalar için kullanılır. Kontrol ve organizasyon akışlarında farklıdırlar. PAC, aracı tabanlı hiyerarşik bir mimaridir ancak MVC'nin açık bir hiyerarşik yapısı yoktur.

Model-Görünüm-Denetleyici (MVC)

MVC, belirli bir yazılım uygulamasını, bilginin dahili temsillerini kullanıcıya sunulan veya kullanıcı tarafından kabul edilen bilgilerden ayırmaya yardımcı olan birbirine bağlı üç parçaya ayırır.

Modül Fonksiyon
Modeli Altta yatan verilerin ve iş mantığının kapsüllenmesi
Kontrolör Kullanıcı eylemine yanıt verin ve uygulama akışını yönetin
Görünüm Modelden kullanıcıya verileri biçimlendirir ve sunar.

Modeli

Model, bir uygulamanın verilerini, mantığını ve kısıtlamalarını doğrudan yöneten MVC'nin merkezi bir bileşenidir. Arayüz için ham uygulama verilerini ve uygulama mantığını koruyan veri bileşenlerinden oluşur.

  • Bağımsız bir kullanıcı arayüzüdür ve uygulama sorunu etki alanının davranışını yakalar.

  • Alana özgü yazılım simülasyonu veya uygulamanın merkezi yapısının uygulanmasıdır.

  • Durumunda değişiklik olduğunda, güncellenmiş çıktı üretmek için ilişkili görünümüne ve mevcut komut setini değiştirmesi için denetleyiciye bildirimde bulunur.

Görünüm

Görünüm, herhangi bir bilgi çıktısını şema veya çizelge gibi grafik biçiminde temsil etmek için kullanılabilir. Verilerin görsel temsillerini sağlayan sunum bileşenlerinden oluşur.

  • Görünümler modellerinden bilgi ister ve kullanıcıya bir çıktı sunumu oluşturur.

  • Yönetim için bir çubuk grafik ve muhasebeciler için bir tablo görünümü gibi aynı bilgilerin birden çok görünümü mümkündür.

Kontrolör

Bir kontrolör bir girişi kabul eder ve onu model veya görünüm için komutlara dönüştürür. Modeli değiştirerek kullanıcıdan gelen girdileri işleyen girdi işleme bileşenlerinden oluşur.

  • İlişkili modeller ve görünümler ile giriş cihazları arasında bir arayüz görevi görür.

  • Modelin durumunu güncellemek için modele ve görünümün modelin sunumunu değiştirmek için ilişkili görünümüne komutlar gönderebilir.

MVC - I

Sistemin iki alt sisteme bölündüğü MVC mimarisinin basit bir sürümüdür -

  • The Controller-View - Denetleyici görünümü, giriş / çıkış arabirimi olarak hareket eder ve işlem yapılır.

  • The Model - Model, tüm verileri ve etki alanı hizmetlerini sağlar.

MVC-I Architecture

Model modülü, herhangi bir veri değişikliğini denetleyici görünümü modülüne bildirir, böylece herhangi bir grafik veri ekranı buna göre değiştirilir. Kontrolör ayrıca değişiklikler üzerine uygun önlemi alır.

Denetleyici görünümü ve model arasındaki bağlantı, denetleyici görünümünün modele abone olduğu ve herhangi bir değişikliğin denetleyicinin görüntüsünü bildirdiği abonelik bildirme düzeninde (yukarıdaki resimde gösterildiği gibi) tasarlanabilir.

MVC - II

MVC – II, görünüm modülünün ve denetleyici modülünün ayrı olduğu MVC-I mimarisinin bir geliştirmesidir. Model modülü, veritabanı tarafından desteklenen tüm temel işlevleri ve verileri sağlayarak MVC-I'deki gibi aktif bir rol oynar.

Görünüm modülü, kontrolör modülü giriş talebini kabul ederken, giriş verilerini doğrularken, modeli, görünümü, bağlantılarını başlatırken ve ayrıca görevi gönderirken verileri sunar.

MVC-II Architecture

MVC Uygulamaları

MVC uygulamaları, tek bir veri modeli için birden çok görünümün gerekli olduğu ve yeni veya değiştirilmiş bir arayüz görünümünün takılmasının kolay olduğu etkileşimli uygulamalar için etkilidir.

MVC uygulamaları, modüller arasında açık ayrımların olduğu uygulamalar için uygundur, böylece farklı profesyoneller bu tür uygulamaların farklı yönleri üzerinde aynı anda çalışmak üzere atanabilir.

Advantages

  • Birçok MVC satıcı çerçevesi araç takımı mevcuttur.

  • Aynı veri modeliyle senkronize edilmiş birden çok görünüm.

  • Yeni veya değiştirilmiş arayüz görünümlerini eklemek kolaydır.

  • Grafik uzmanları, programlama uzmanları ve veri tabanı geliştirme uzmanlarının tasarlanmış bir proje ekibinde çalıştığı uygulama geliştirme için kullanılır.

Disadvantages

  • Etkileşimli mobil ve robotik uygulamalar gibi aracı odaklı uygulamalar için uygun değildir.

  • Aynı veri modeline dayalı birden fazla denetleyici çifti ve görünüm, herhangi bir veri modeli değişikliğini pahalı hale getirir.

  • Görüntü ve Denetleyici arasındaki ayrım bazı durumlarda net değildir.

Sunum-Soyutlama-Kontrol (PAC)

PAC'de, sistem birçok işbirliği yapan temsilciden (üçlü) oluşan bir hiyerarşiye göre düzenlenmiştir. MVC'den etkileşimli gereksinimlere ek olarak birden çok aracının uygulama gereksinimlerini desteklemek için geliştirilmiştir.

Her temsilcinin üç bileşeni vardır -

  • The presentation component - Verilerin görsel ve işitsel sunumunu biçimlendirir.

  • The abstraction component - Verileri alır ve işler.

  • The control component - Diğer iki bileşen arasındaki kontrol akışı ve iletişim gibi görevleri yerine getirir.

PAC mimarisi, sunum modülünün MVC'nin görünüm modülü gibi olması açısından MVC'ye benzer. Soyutlama modülü, MVC'nin model modülüne benzer ve kontrol modülü, MVC'nin kontrolör modülü gibidir, ancak kontrol ve organizasyon akışlarında farklılık gösterirler.

Her aracıda soyutlama bileşeni ile sunum bileşeni arasında doğrudan bağlantı yoktur. Her bir aracıdaki kontrol bileşeni, diğer aracılarla iletişimden sorumludur.

Aşağıdaki şekil, PAC tasarımında tek bir ajan için bir blok diyagramı göstermektedir.

Çoklu Temsilcili PAC

Birden çok aracıdan oluşan PAC'lerde, en üst düzey aracı, temel verileri ve iş mantığını sağlar. Alt düzey aracılar, ayrıntılı özel verileri ve sunumları tanımlar. Orta seviye veya orta seviye aracı, düşük seviyeli temsilcilerin koordinatörü olarak hareket eder.

  • Her temsilcinin kendine özgü atanmış işi vardır.

  • Bazı orta düzey aracılar için etkileşimli sunumlar gerekli değildir, bu nedenle sunum bileşeni yoktur.

  • Kontrol bileşeni, tüm aracıların birbiriyle iletişim kurduğu tüm aracılar için gereklidir.

Aşağıdaki şekil PAC'de yer alan Çoklu Temsilcileri göstermektedir.

Applications

  • Sistemin hiyerarşik bir şekilde birçok işbirliği yapan aracıya ayrıştırılabildiği etkileşimli bir sistem için etkilidir.

  • Ajanlar arasındaki bağlantının gevşek olması beklendiğinde etkilidir, böylece bir ajan üzerindeki değişiklikler diğerlerini etkilemez.

  • Tüm aracıların uzaktan dağıtıldığı ve her birinin veri ve etkileşimli arayüz ile kendi işlevlerine sahip olduğu dağıtılmış sistem için etkilidir.

  • Her birinin kendi güncel verilerini ve etkileşimli arayüzünü tuttuğu ve diğer bileşenlerle iletişim kurması gereken zengin GUI bileşenlerine sahip uygulamalar için uygundur.

Avantajlar

  • Çoklu görev ve çoklu görüntüleme desteği

  • Aracı yeniden kullanılabilirliği ve genişletilebilirliği için destek

  • Yeni aracı eklemek veya mevcut bir aracı değiştirmek kolaydır

  • Birden çok aracının farklı iş parçacıklarında veya farklı cihazlarda veya bilgisayarlarda paralel olarak çalıştığı durumlarda eşzamanlılık desteği

Dezavantajları

  • Sunum ve soyutlama arasındaki kontrol köprüsü ve temsilciler arasındaki kontrollerin iletişimi nedeniyle ek yük.

  • Ajanlar arasında gevşek bağlantı ve yüksek bağımsızlık nedeniyle doğru ajan sayısını belirlemek zordur.

  • Temsilciler arasındaki iletişim yalnızca aracıların kontrolleri arasında gerçekleştiğinden, sunum ve soyutlamanın her bir aracıdaki kontrol tarafından tamamen ayrılması geliştirme karmaşıklığı yaratır.