Hızlı rehber

Bir sistemin mimarisi, ana bileşenlerini, ilişkilerini (yapılarını) ve birbirleriyle nasıl etkileşime girdiklerini tanımlar. Yazılım mimarisi ve tasarımı, İş stratejisi, kalite özellikleri, insan dinamikleri, tasarım ve BT ortamı gibi birçok katkıda bulunan faktörü içerir.

Yazılım Mimarisi ve Tasarımını iki farklı aşamaya ayırabiliriz: Yazılım Mimarisi ve Yazılım Tasarımı. İçindeArchitectureişlevsel olmayan kararlar, işlevsel gereksinimler tarafından oluşturulur ve ayrılır. Tasarımda işlevsel gereksinimler yerine getirilir.

Yazılım mimarisi

Mimarlık bir blueprint for a system. Sistem karmaşıklığını yönetmek ve bileşenler arasında bir iletişim ve koordinasyon mekanizması kurmak için bir soyutlama sağlar.

  • Bir structured solution performans ve güvenlik gibi ortak kalite özelliklerini optimize ederken tüm teknik ve operasyonel gereksinimleri karşılamak için.

  • Ayrıca, kuruluş hakkında yazılım geliştirmeyle ilgili bir dizi önemli karar içerir ve bu kararların her biri, nihai ürünün kalitesi, sürdürülebilirliği, performansı ve genel başarısı üzerinde önemli bir etkiye sahip olabilir. Bu kararlar aşağıdakilerden oluşur:

    • Sistemin oluşturulduğu yapısal elemanların ve bunların arayüzlerinin seçimi.

    • Bu unsurlar arasındaki işbirliğinde belirtilen davranış.

    • Bu yapısal ve davranışsal unsurların büyük bir alt sistemde bileşimi.

    • Mimari kararlar iş hedefleriyle uyumludur.

    • Organizasyona mimari tarzlar rehberlik eder.

Yazılım Tasarımı

Yazılım tasarımı, design planbir sistemin unsurlarını, nasıl uyduklarını ve sistemin gereklerini yerine getirmek için birlikte çalıştıklarını açıklar. Bir tasarım planına sahip olmanın amaçları aşağıdaki gibidir:

  • Sistem gereksinimlerini müzakere etmek ve müşteriler, pazarlama ve yönetim personeli ile beklentileri belirlemek.

  • Geliştirme sürecinde bir plan olarak hareket edin.

  • Ayrıntılı tasarım, kodlama, entegrasyon ve test dahil olmak üzere uygulama görevlerine rehberlik edin.

Ayrıntılı tasarım, kodlama, entegrasyon ve testten önce ve alan analizi, gereksinim analizi ve risk analizinden sonra gelir.

Mimarinin Hedefleri

Mimarinin birincil amacı, uygulamanın yapısını etkileyen gereksinimleri belirlemektir. İyi tasarlanmış bir mimari, teknik bir çözüm oluşturmayla ilgili iş risklerini azaltır ve iş ile teknik gereksinimler arasında bir köprü oluşturur.

Diğer hedeflerden bazıları şu şekildedir:

  • Sistemin yapısını ortaya çıkarın, ancak uygulama ayrıntılarını gizleyin.

  • Tüm kullanım durumlarını ve senaryoları gerçekleştirin.

  • Çeşitli paydaşların gereksinimlerini ele almaya çalışın.

  • Hem işlevsel hem de kalite gereksinimlerini karşılayın.

  • Sahiplik hedefini azaltın ve kuruluşun pazar konumunu iyileştirin.

  • Sistemin sunduğu kaliteyi ve işlevselliği iyileştirin.

  • Organizasyonda veya sistemde dış güveni artırın.

Sınırlamalar

Yazılım mimarisi, yazılım mühendisliği içinde hala gelişmekte olan bir disiplindir. Aşağıdaki sınırlamalara sahiptir -

  • Mimariyi temsil etmek için araçların ve standartlaştırılmış yolların eksikliği.

  • Mimarinin, gereksinimleri karşılayan bir uygulama ile sonuçlanıp sonuçlanmayacağını tahmin etmek için analiz yöntemlerinin eksikliği.

  • Yazılım geliştirmede mimari tasarımın önemi konusunda bilinç eksikliği.

  • Yazılım mimarının rolünün anlaşılmaması ve paydaşlar arasında zayıf iletişim.

  • Tasarım sürecinin, tasarım deneyiminin ve tasarımın değerlendirilmesinin anlaşılmaması.

Yazılım Mimarının Rolü

Bir Yazılım Mimarı, teknik ekibin tüm uygulama için oluşturabileceği ve tasarlayabileceği bir çözüm sunar. Bir yazılım mimarı aşağıdaki alanlarda uzmanlığa sahip olmalıdır -

Tasarım Uzmanlığı

  • Nesne odaklı tasarım, olay odaklı tasarım vb. Gibi çeşitli yöntemler ve yaklaşımlar dahil olmak üzere yazılım tasarımında uzman

  • Tasarımın bütünlüğü için geliştirme ekibine liderlik edin ve geliştirme çabalarını koordine edin.

  • Tasarım önerilerini ve kendi aralarında değiş tokuşu gözden geçirebilmelidir.

Alan uzmanlığı

  • Geliştirilmekte olan sistem konusunda uzman ve yazılım evrimi için planlama.

  • İhtiyaç araştırma sürecine yardımcı olarak eksiksizlik ve tutarlılık sağlar.

  • Geliştirilmekte olan sistem için alan modelinin tanımını koordine edin.

Teknoloji Uzmanlığı

  • Sistemin uygulanmasına yardımcı olan mevcut teknolojiler konusunda uzman.

  • Programlama dili, çerçeve, platformlar, veritabanları vb. Seçimini koordine edin.

Metodolojik Uzmanlık

  • SDLC (Yazılım Geliştirme Yaşam Döngüsü) sırasında benimsenebilecek yazılım geliştirme metodolojileri konusunda uzman.

  • Tüm takıma yardımcı olacak uygun geliştirme yaklaşımlarını seçin.

Yazılım Mimarının Gizli Rolü

  • Ekip üyeleri arasında teknik çalışmayı kolaylaştırır ve ekipte güven ilişkisini güçlendirir.

  • Bilgiyi paylaşan ve engin deneyime sahip bilgi uzmanı.

  • Ekip üyelerini, dikkatlerini dağıtacak ve projeye daha az değer katacak dış güçlerden koruyun.

Mimarın Teslimatları

  • Açık, eksiksiz, tutarlı ve ulaşılabilir bir dizi işlevsel hedef

  • En az iki ayrıştırma katmanıyla sistemin işlevsel bir açıklaması

  • Sistem için bir konsept

  • En az iki ayrışma katmanına sahip sistem biçiminde bir tasarım

  • Zamanlama, operatör özellikleri ve uygulama ve operasyon planları hakkında bir fikir

  • İşlevsel ayrıştırmayı sağlayan bir belge veya süreç takip edilir ve arayüzlerin şekli kontrol edilir

Kalite Özellikleri

Kalite, bir mükemmellik ölçüsü veya eksiklik veya kusurlardan arınmış olma durumudur. Kalite nitelikleri, sistemin işlevselliğinden ayrı olan sistem özellikleridir.

Kalite niteliklerinin uygulanması, iyi bir sistemi kötü sistemden ayırt etmeyi kolaylaştırır. Öznitelikler, çalışma zamanı davranışını, sistem tasarımını ve kullanıcı deneyimini etkileyen genel faktörlerdir.

Şu şekilde sınıflandırılabilirler -

Statik Kalite Özellikleri

Doğrudan mimari, tasarım ve kaynak kodu ile ilgili bir sistemin ve organizasyonun yapısını yansıtın. Son kullanıcı tarafından görünmezler, ancak geliştirme ve bakım maliyetini etkilerler, örneğin: modülerlik, test edilebilirlik, sürdürülebilirlik vb.

Dinamik Kalite Özellikleri

Sistemin yürütülmesi sırasındaki davranışını yansıtır. Sistem mimarisi, tasarımı, kaynak kodu, yapılandırması, dağıtım parametreleri, ortamı ve platformu ile doğrudan ilgilidir.

Son kullanıcı tarafından görülebilirler ve çalışma zamanında var olurlar, ör. İş hacmi, sağlamlık, ölçeklenebilirlik vb.

Kalite Senaryoları

Kalite senaryoları, bir hatanın arızaya dönüşmesinin nasıl önleneceğini belirtir. Özellik özelliklerine göre altı bölüme ayrılabilirler -

  • Source - Teşvik eden kişiler, donanım, yazılım veya fiziksel altyapı gibi dahili veya harici bir varlık.

  • Stimulus - Bir sisteme geldiğinde dikkate alınması gereken bir durum.

  • Environment - Uyaran belirli koşullar altında gerçekleşir.

  • Artifact - İşlemciler, iletişim kanalları, kalıcı depolama, işlemler vb. Gibi bir sistemin tamamı veya bir kısmı.

  • Response - Arızaların tespiti, arızanın giderilmesi, olay kaynağının devre dışı bırakılması gibi uyaranın gelmesinden sonra gerçekleştirilen bir faaliyet.

  • Response measure - Gereksinimlerin test edilebilmesi için oluşan yanıtları ölçmelidir.

Ortak Kalite Özellikleri

Aşağıdaki tablo, bir yazılım mimarisinin sahip olması gereken ortak kalite özelliklerini listelemektedir -

Kategori Kalite Özelliği Açıklama
Tasarım Nitelikleri Kavramsal Bütünlük Genel tasarımın tutarlılığını ve tutarlılığını tanımlar. Bu, bileşenlerin veya modüllerin tasarlanma şeklini içerir.
Sürdürülebilirlik Sistemin değişikliklere bir derece kolaylıkla girebilme yeteneği.
Tekrar Kullanılabilirlik Bileşenlerin ve alt sistemlerin diğer uygulamalarda kullanıma uygun olma özelliğini tanımlar.
Çalışma Zamanı Nitelikleri Birlikte çalışabilirlik Bir sistemin veya farklı sistemlerin, dış taraflarca yazılan ve çalıştırılan diğer dış sistemlerle iletişim kurarak ve bilgi alışverişinde bulunarak başarılı bir şekilde çalışabilme becerisi.
Yönetilebilirlik Sistem yöneticilerinin uygulamayı yönetmesinin ne kadar kolay olduğunu tanımlar.
Güvenilirlik Bir sistemin zaman içinde çalışır durumda kalma yeteneği.
Ölçeklenebilirlik Bir sistemin, ya sistemin performansını etkilemeden yük artışını ya da kolaylıkla genişletilebilme yeteneğini idare etme yeteneği.
Güvenlik Bir sistemin tasarlanan kullanımların dışında kötü niyetli veya kazara eylemleri önleme kabiliyeti.
Verim Belirli bir zaman aralığı içinde herhangi bir eylemi gerçekleştirmek için bir sistemin duyarlılığının göstergesi.
Kullanılabilirlik Sistemin işlevsel ve çalışır durumda olduğu zaman oranını tanımlar. Önceden tanımlanmış bir süre boyunca toplam sistem kapalı kalma süresinin yüzdesi olarak ölçülebilir.
Sistem Kaliteleri Desteklenebilirlik Sistemin, düzgün çalışmadığında sorunları tespit etmek ve çözmek için yararlı bilgiler sağlama yeteneği.
Test edilebilirlik Sistem ve bileşenleri için test kriterleri oluşturmanın ne kadar kolay olduğunu ölçün.
Kullanıcı Nitelikleri Kullanılabilirlik Uygulamanın sezgisel olarak kullanıcı ve tüketicinin gereksinimlerini ne kadar iyi karşıladığını tanımlar.
Mimari Kalitesi Doğruluk Sistemin tüm gereksinimlerini karşılama sorumluluğu.
Çalışma Zamanı Dışı Kalite Taşınabilirlik Sistemin farklı bilgi işlem ortamında çalışabilme yeteneği.
Bütünlük Sistemin ayrı ayrı geliştirilen bileşenlerinin birlikte doğru çalışmasını sağlayabilme.
Değiştirilebilirlik Her bir yazılım sisteminin, yazılımındaki değişiklikleri barındırma kolaylığı.
İş kalitesi özellikleri Maliyet ve zamanlama Pazara sunma süresi, beklenen proje ömrü ve mirasın kullanımı açısından sistemin maliyeti.
Pazarlanabilirlik Sistemin piyasa rekabetine göre kullanılması.

Yazılım mimarisi, sistemin tanımlanan işlevleri gerçekleştiren bir dizi bileşeni temsil ettiği bir sistemin organizasyonu olarak tanımlanır.

Mimari tarz

architectural styleolarak da adlandırılır architectural pattern, bir uygulamayı şekillendiren bir dizi ilkedir. Yapısal organizasyon modeli açısından bir sistem ailesi için soyut bir çerçeve tanımlar.

Mimari tarzın sorumluluğu -

  • Nasıl birleştirilebileceklerine dair kurallar içeren bir bileşen ve bağlayıcı sözlüğü sağlayın.

  • Sıklıkla ortaya çıkan sorunlara çözümler sunarak bölümlemeyi geliştirin ve tasarımın yeniden kullanımına izin verin.

  • Bir bileşen koleksiyonunu (iyi tanımlanmış arabirimlere sahip, yeniden kullanılabilir ve değiştirilebilir bir modül) ve konektörleri (modüller arasındaki iletişim bağlantısı) yapılandırmanın belirli bir yolunu açıklayın.

Bilgisayar tabanlı sistemler için oluşturulan yazılım birçok mimari tarzdan birini sergilemektedir. Her stil, aşağıdakileri içeren bir sistem kategorisini tanımlar:

  • Sistem tarafından gerekli bir işlevi yerine getiren bir dizi bileşen türü.

  • Farklı bileşenler arasında iletişim, koordinasyon ve işbirliğini mümkün kılan bir dizi bağlayıcı (alt yordam çağrısı, uzaktan prosedür çağrısı, veri akışı ve soket).

  • Bileşenlerin sistemi oluşturmak için nasıl entegre edilebileceğini tanımlayan anlamsal kısıtlamalar.

  • Çalışma zamanı karşılıklı ilişkilerini gösteren bileşenlerin topolojik düzeni.

Ortak Mimari Tasarım

Aşağıdaki tablo, ana odak alanlarına göre organize edilebilen mimari tarzları listeler -

Kategori Mimari tasarım Açıklama
İletişim Mesaj veriyolu Bir veya daha fazla iletişim kanalı kullanarak mesaj alabilen ve gönderebilen bir yazılım sistemi kullanımını anlatır.
Servis Odaklı Mimari (SOA) Sözleşmeleri ve mesajları kullanan bir hizmet olarak işlevselliği ortaya çıkaran ve tüketen uygulamaları tanımlar.
Dağıtım Müşteri sunucusu Sistemi, istemcinin sunucuya istekte bulunduğu iki uygulamaya ayırın.
3 katmanlı veya N katmanlı İşlevselliği, her bölüm fiziksel olarak ayrı bir bilgisayarda bulunan bir katman olacak şekilde ayrı bölümlere ayırır.
Alan adı Alan Odaklı Tasarım Bir iş alanını modellemeye ve iş alanındaki varlıkları temel alan iş nesnelerini tanımlamaya odaklandı.
Yapısı Bileşen Bazlı Uygulama tasarımını, iyi tanımlanmış iletişim arayüzlerini açığa çıkaran yeniden kullanılabilir işlevsel veya mantıksal bileşenlere ayırın.
Katmanlı Uygulamanın endişelerini yığılmış gruplara (katmanlara) bölün.
Nesne odaklı Bir uygulamanın veya sistemin sorumluluklarının nesnelere bölünmesine dayanır, her biri nesneye ilişkin verileri ve davranışı içerir.

Mimari Türleri

Bir işletme açısından dört tür mimari vardır ve toplu olarak bu mimariler olarak adlandırılır. enterprise architecture.

  • Business architecture - Bir işletme içindeki iş, yönetişim, organizasyon ve temel iş süreçlerinin stratejisini tanımlar ve iş süreçlerinin analizi ve tasarımına odaklanır.

  • Application (software) architecture - Bireysel uygulama sistemleri, etkileşimleri ve kuruluşun iş süreçleriyle olan ilişkileri için ayrıntılı bir plan görevi görür.

  • Information architecture - Mantıksal ve fiziksel veri varlıklarını ve veri yönetimi kaynaklarını tanımlar.

  • Information technology (IT) architecture - Kuruluşun genel bilgi sistemini oluşturan donanım ve yazılım yapı taşlarını tanımlar.

Mimari Tasarım Süreci

Mimari tasarım süreci, işlevsel ve işlevsel olmayan gereksinimleri karşılamak için bir sistemin farklı bileşenlere ayrıştırılmasına ve bunların etkileşimlerine odaklanır. Yazılım mimarisi tasarımının temel girdileri şunlardır:

  • Analiz görevleri tarafından üretilen gereksinimler.

  • Donanım mimarisi (sırayla yazılım mimarı, donanım mimarisini yapılandıran sistem mimarına gereksinimleri sağlar).

Mimari tasarım sürecinin sonucu veya çıktısı bir architectural description. Temel mimari tasarım süreci aşağıdaki adımlardan oluşur -

Sorunu Anlayın

  • Bu en önemli adımdır çünkü takip eden tasarımın kalitesini etkiler.

  • Sorunun net bir şekilde anlaşılması olmadan, etkili bir çözüm yaratmak mümkün değildir.

  • Pek çok yazılım projesi ve ürünü, geçerli bir iş sorununu gerçekten çözemedikleri veya fark edilebilir bir yatırım getirisine (ROI) sahip oldukları için başarısızlık olarak kabul edilir.

Tasarım Öğelerini ve İlişkilerini Tanımlayın

  • Bu aşamada, sistemin sınırlarını ve bağlamını tanımlamak için bir temel oluşturun.

  • Sistemin fonksiyonel gereksinimlere göre ana bileşenlerine ayrıştırılması. Ayrıştırma, öğelerin ayrıntı düzeyini belirtmeden tasarım öğeleri arasındaki bağımlılıkları gösteren bir tasarım yapısı matrisi (DSM) kullanılarak modellenebilir.

  • Bu adımda, mimarinin ilk doğrulaması bir dizi sistem örneğini açıklayarak yapılır ve bu adım, işlevselliğe dayalı mimari tasarım olarak adlandırılır.

Mimari Tasarımın Değerlendirilmesi

  • Her kalite özelliğine bir tahmin verilir, böylece nitel ölçümler veya nicel veriler toplamak için tasarım değerlendirilir.

  • Mimari kalite özellikleri gereksinimlerine uygunluk için mimarinin değerlendirilmesini içerir.

  • Tüm tahmin edilen kalite nitelikleri gerekli standarda uygunsa mimari tasarım süreci tamamlanmış demektir.

  • Değilse, yazılım mimarisi tasarımının üçüncü aşaması girilir: mimari dönüşüm. Gözlemlenen kalite özelliği gereksinimlerini karşılamıyorsa, yeni bir tasarım yaratılmalıdır.

Mimari Tasarımın Dönüşümü

  • Bu adım, mimari tasarımın bir değerlendirmesinden sonra gerçekleştirilir. Mimari tasarım, kalite özelliği gereksinimlerini tamamen karşılayana kadar değiştirilmelidir.

  • Alan işlevselliğini korurken kalite özelliklerini iyileştirmek için tasarım çözümlerini seçmekle ilgilenir.

  • Bir tasarım, tasarım operatörleri, stiller veya desenler uygulanarak dönüştürülür. Dönüşüm için mevcut tasarımı alın ve ayrıştırma, çoğaltma, sıkıştırma, soyutlama ve kaynak paylaşımı gibi tasarım işleci uygulayın.

  • Tasarım yeniden değerlendirilir ve aynı işlem gerekirse birden çok kez tekrarlanır ve hatta yinelemeli olarak gerçekleştirilir.

  • Dönüşümler (yani kalite öznitelik optimizasyon çözümleri) genellikle bir veya bazı kalite özelliklerini iyileştirirken diğerlerini olumsuz yönde etkiler

Anahtar Mimari İlkeler

Bir mimari tasarlarken dikkate alınması gereken temel ilkeler şunlardır:

Sona Kadar İnşa Etmek Yerine Değişim İçin İnşa Edin

Uygulamanın yeni gereksinimleri ve zorlukları ele almak için zaman içinde nasıl değişmesi gerekebileceğini düşünün ve bunu destekleyecek esnekliği oluşturun.

Analiz Edilecek Riski ve Modeli Azaltın

Gereksinimleri yakalamak ve kararları tasarlamak için tasarım araçlarını, görselleştirmeleri, UML gibi modelleme sistemlerini kullanın. Etkiler de analiz edilebilir. Modeli, tasarımı kolayca yineleme ve uyarlama yeteneğini ortadan kaldıracak ölçüde resmileştirmeyin.

Modelleri ve Görselleştirmeleri İletişim ve İşbirliği Aracı olarak Kullanın

Tasarımın, kararların ve tasarımda devam eden değişikliklerin verimli iletişimi iyi mimari için kritiktir. Tasarımı tüm paydaşlarla verimli bir şekilde iletişim kurmak ve paylaşmak için mimarinin modellerini, görünümlerini ve diğer görselleştirmelerini kullanın. Bu, tasarımdaki değişikliklerin hızlı iletişimini sağlar.

Temel mühendislik kararlarını ve hataların en sık yapıldığı alanları tanımlayın ve anlayın. Tasarımı daha esnek hale getirmek ve değişikliklerden etkilenme olasılığını azaltmak için temel kararları ilk seferde doğru almaya yatırım yapın.

Artımlı ve Yinelemeli Bir Yaklaşım Kullanın

Temel mimariyle başlayın ve ardından mimariyi iyileştirmek için yinelemeli testlerle aday mimarileri geliştirin. Büyük veya doğru resmi elde etmek için tasarıma yinelemeli olarak ayrıntılar ekleyin ve ardından ayrıntılara odaklanın.

Anahtar Tasarım İlkeleri

Maliyet, bakım gereksinimlerini en aza indirmek ve genişletilebilirliği, mimarinin kullanılabilirliğini en üst düzeye çıkarmak için dikkate alınması gereken tasarım ilkeleri aşağıdadır -

Kaygıların Ayrılması

Sistem bileşenlerini belirli özelliklere bölün, böylece bileşenlerin işlevselliği arasında örtüşme olmaz. Bu, yüksek kohezyon ve düşük bağlantı sağlayacaktır. Bu yaklaşım, sistemin kolay bakımına yardımcı olan sistem bileşenleri arasındaki karşılıklı bağımlılığı önler.

Tek Sorumluluk İlkesi

Bir sistemin her modülünün, kullanıcının sistemi açıkça anlamasına yardımcı olan belirli bir sorumluluğu olmalıdır. Ayrıca, bileşenin diğer bileşenlerle entegrasyonuna da yardımcı olmalıdır.

En Az Bilgi Prensibi

Herhangi bir bileşen veya nesne, diğer bileşenlerin dahili ayrıntıları hakkında bilgiye sahip olmamalıdır. Bu yaklaşım, karşılıklı bağımlılığı önler ve sürdürülebilirliğe yardımcı olur.

Büyük Tasarımı Önceden Küçültün

Bir uygulamanın gereksinimleri net değilse, büyük tasarımı önceden en aza indirin. Gereksinimleri değiştirme olasılığı varsa, tüm sistem için büyük bir tasarım yapmaktan kaçının.

İşlevselliği Tekrar Etmeyin

Yineleme işlevi, bileşenlerin işlevselliğinin tekrarlanmaması gerektiğini ve bu nedenle bir kod parçasının yalnızca bir bileşende uygulanması gerektiğini belirtir. Bir uygulama içindeki işlevselliğin kopyalanması, değişikliklerin uygulanmasını zorlaştırabilir, netliği azaltabilir ve olası tutarsızlıklara neden olabilir.

İşlevi Yeniden Kullanırken Kalıtım yerine Kompozisyonu Tercih Edin

Miras, çocuklar ve üst sınıflar arasında bağımlılık yaratır ve bu nedenle alt sınıfların ücretsiz kullanımını engeller. Aksine, kompozisyon büyük bir özgürlük seviyesi sağlar ve kalıtım hiyerarşilerini azaltır.

Bileşenleri Tanımlayın ve Mantıksal Katmanlarda Gruplayın

Gereksinimleri karşılamak için sistemde ihtiyaç duyulan kimlik bileşenleri ve ilgi alanı. Daha sonra, bu ilgili bileşenleri mantıksal bir katmanda gruplayın; bu, kullanıcının sistemin yapısını yüksek düzeyde anlamasına yardımcı olur. Aynı katmanda farklı türden sorunları karıştırmaktan kaçının.

Katmanlar Arası İletişim Protokolünü Tanımlayın

Devreye alma senaryoları ve üretim ortamı hakkında eksiksiz bilgi gerektiren bileşenlerin birbirleriyle nasıl iletişim kuracağını anlayın.

Bir Katman için Veri Biçimini Tanımlayın

Çeşitli bileşenler, veri formatı aracılığıyla birbirleriyle etkileşime girecektir. Veri formatlarını karıştırmayın, böylece uygulamaların uygulanması, genişletilmesi ve bakımı kolaydır. Veri formatını bir katman için aynı tutmaya çalışın, böylece çeşitli bileşenler birbiriyle iletişim kurarken verileri kodlamak / kodunu çözmek zorunda kalmaz. İşleme ek yükünü azaltır.

Sistem Hizmet Bileşenleri Soyut olmalıdır

Güvenlik, iletişim veya günlük kaydı, profil oluşturma ve yapılandırma gibi sistem hizmetleriyle ilgili kod, ayrı bileşenlerde özetlenmelidir. Tasarımı genişletmek ve sürdürmek kolay olduğundan, bu kodu iş mantığıyla karıştırmayın.

Tasarım İstisnaları ve İstisna İşleme Mekanizması

İstisnaların önceden tanımlanması, bileşenlerin hataları veya istenmeyen durumları zarif bir şekilde yönetmesine yardımcı olur. İstisna yönetimi sistem genelinde aynı olacaktır.

Adlandırma Kuralları

Adlandırma kuralları önceden tanımlanmalıdır. Kullanıcıların sistemi kolayca anlamalarına yardımcı olan tutarlı bir model sağlarlar. Ekip üyelerinin başkaları tarafından yazılan kodu doğrulaması daha kolaydır ve dolayısıyla sürdürülebilirliği artıracaktır.

Yazılım mimarisi, mimari stil ve kalite nitelikleri ile ayrıştırma ve kompozisyon kullanarak yazılım sistemi soyutlamasının üst düzey yapısını içerir. Bir yazılım mimarisi tasarımı, sistemin temel işlevsellik ve performans gereksinimlerine uymanın yanı sıra güvenilirlik, ölçeklenebilirlik, taşınabilirlik ve kullanılabilirlik gibi işlevsel olmayan gereksinimleri karşılamalıdır.

Bir yazılım mimarisi, bileşen grubunu, bağlantılarını, aralarındaki etkileşimleri ve tüm bileşenlerin dağıtım konfigürasyonunu açıklamalıdır.

Bir yazılım mimarisi birçok şekilde tanımlanabilir -

  • UML (Unified Modeling Language) - UML, yazılım modelleme ve tasarımında kullanılan nesne yönelimli çözümlerden biridir.

  • Architecture View Model (4+1 view model) - Mimari görünüm modeli, yazılım uygulamasının işlevsel ve işlevsel olmayan gereksinimlerini temsil eder.

  • ADL (Architecture Description Language) - ADL, yazılım mimarisini biçimsel ve anlamsal olarak tanımlar.

UML

UML, Birleşik Modelleme Dili anlamına gelir. Yazılım planları yapmak için kullanılan resimli bir dildir. UML, Object Management Group (OMG) tarafından oluşturulmuştur. UML 1.0 spesifikasyon taslağı, Ocak 1997'de OMG'ye önerildi. Bir yazılım geliştirmenin temeli olan yazılım gereksinim analizi ve tasarım belgeleri için bir standart olarak hizmet eder.

UML, bir yazılım sistemini görselleştirmek, belirlemek, yapılandırmak ve belgelemek için genel amaçlı bir görsel modelleme dili olarak tanımlanabilir. UML genellikle yazılım sistemini modellemek için kullanılsa da, bu sınırla sınırlı değildir. Ayrıca, bir üretim birimindeki süreç akışları gibi yazılım olmayan sistemleri modellemek için de kullanılır.

Öğeler, tam bir UML resmi oluşturmak için farklı şekillerde ilişkilendirilebilen bileşenler gibidir. diagram. Bu nedenle, bilgiyi gerçek hayattaki sistemlerde uygulamak için farklı diyagramları anlamak çok önemlidir. İki geniş diyagram kategorimiz var ve bunlar alt kategorilere ayrılmıştır, ör.Structural Diagrams ve Behavioral Diagrams.

Yapısal Diyagramlar

Yapısal diyagramlar, bir sistemin statik yönlerini temsil eder. Bu statik yönler, ana yapıyı oluşturan ve dolayısıyla kararlı olan bir diyagramın bölümlerini temsil eder.

Bu statik parçalar, sınıflar, arayüzler, nesneler, bileşenler ve düğümlerle temsil edilir. Yapısal diyagramlar aşağıdaki gibi alt bölümlere ayrılabilir -

  • Sınıf diyagramı
  • Nesne diyagramı
  • Bileşen diyagramı
  • Dağıtım şeması
  • Paket şeması
  • Kompozit yapı

Aşağıdaki tablo, bu diyagramların kısa bir açıklamasını sağlar -

Sr.No. Diyagram ve Açıklama
1

Class

Bir sistemin nesne yönelimini temsil eder. Sınıfların statik olarak nasıl ilişkili olduğunu gösterir.
2

Object

Çalışma zamanındaki bir dizi nesneyi ve ilişkilerini ve ayrıca sistemin statik görünümünü temsil eder.
3

Component

Sistemin tüm bileşenlerini, ilişkilerini, etkileşimlerini ve arayüzünü açıklar.
4

Composite structure

Bileşenin tüm sınıfları, arabirimleri vb. Dahil olmak üzere bileşenin iç yapısını açıklar.
5

Package

Paket yapısını ve organizasyonunu açıklar. Paketteki sınıfları ve başka bir paket içindeki paketleri kapsar.
6

Deployment

Dağıtım diyagramları bir dizi düğüm ve bunların ilişkileridir. Bu düğümler, bileşenlerin konuşlandırıldığı fiziksel varlıklardır.

Davranış Diyagramları

Davranış diyagramları temelde bir sistemin dinamik yönünü yakalar. Dinamik yönler temelde bir sistemin değişen / hareketli parçalarıdır. UML, aşağıdaki davranış diyagramlarına sahiptir -

  • Durum şemasını kullan
  • Sıra diyagramı
  • İletişim diyagramı
  • Durum şeması diyagramı
  • Etkinlik şeması
  • Etkileşime genel bakış
  • Zaman dizisi diyagramı

Aşağıdaki tablo, bu diyagramın kısa bir açıklamasını sağlar -

Sr.No. Diyagram ve Açıklama
1

Use case

İşlevsellikler ile iç / dış denetleyicileri arasındaki ilişkileri açıklar. Bu denetleyiciler, aktörler olarak bilinir.
2

Activity

Bir sistemdeki kontrol akışını açıklar. Aktivitelerden ve bağlantılardan oluşur. Akış, sıralı, eşzamanlı veya dallanmış olabilir.
3

State Machine/state chart

Bir sistemin olay odaklı durum değişikliğini temsil eder. Temel olarak bir sınıfın, arayüzün vb. Durum değişikliğini tanımlar. Bir sistemin tepkisini iç / dış faktörlerle görselleştirmek için kullanılır.
4

Sequence

Belirli bir işlevi gerçekleştirmek için bir sistemdeki çağrıların sırasını görselleştirir.
5

Interaction Overview

Sistem ve iş sürecine ilişkin bir kontrol akışına genel bakış sağlamak için aktivite ve sıra diyagramlarını birleştirir.
6

Communication

Nesnenin rolüne odaklanması dışında sıra diyagramı ile aynıdır. Her iletişim bir sıra sırası, numara ve geçmiş mesajlarla ilişkilendirilir.
7

Time Sequenced

Durum, durum ve olaylardaki mesajlara göre değişiklikleri açıklar.

Mimari Görünüm Modeli

Bir model, belirli bir perspektif veya bakış açısından birden çok görünümden oluşan yazılım mimarisinin eksiksiz, temel ve basitleştirilmiş bir açıklamasıdır.

Bir görüş, ilgili bir dizi endişenin perspektifinden bütün bir sistemin temsilidir. Son kullanıcılar, geliştiriciler, proje yöneticileri ve test uzmanları gibi farklı paydaşların bakış açısından sistemi tanımlamak için kullanılır.

4 + 1 Modeli Görüntüle

4 + 1 Görünüm Modeli, Philippe Kruchten tarafından çoklu ve eşzamanlı görünümlerin kullanımına dayalı yazılım yoğun bir sistemin mimarisini tanımlamak için tasarlanmıştır. Bu birmultiple viewsistemin farklı özelliklerini ve endişelerini ele alan model. Yazılım tasarım belgelerini standartlaştırır ve tasarımın tüm paydaşlar tarafından anlaşılmasını kolaylaştırır.

Yazılım mimarisi tasarımını incelemek ve belgelemek için bir mimari doğrulama yöntemidir ve tüm paydaşlar için yazılım mimarisinin tüm yönlerini kapsar. Dört temel görünüm sağlar -

  • The logical view or conceptual view - Tasarımın obje modelini açıklar.

  • The process view - Sistemin faaliyetlerini açıklar, tasarımın eşzamanlılık ve senkronizasyon yönlerini yakalar.

  • The physical view - Yazılımın donanımla eşleştirilmesini açıklar ve dağıtılmış yönünü yansıtır.

  • The development view - Ortamın geliştirilmesinde yazılımın statik organizasyonunu veya yapısını tanımlar.

Bu görünüm modeli, adı verilen bir görünüm daha eklenerek genişletilebilir. scenario view veya use case viewyazılım sistemlerinin son kullanıcıları veya müşterileri için. Diğer dört görünümle uyumludur ve "artı bir" görünüm, (4 + 1) görünüm modeli olarak hizmet veren mimariyi göstermek için kullanılır. Aşağıdaki şekil beş eşzamanlı görünüm (4 + 1) modelini kullanan yazılım mimarisini açıklamaktadır.

Neden 5 yerine 4 + 1 deniyor?

use case viewBir sistemin üst düzey gereksinimlerini ayrıntılarıyla anlatırken diğer ayrıntıları - bu gereksinimlerin nasıl gerçekleştirildiğini gördüğü için özel bir öneme sahiptir. Diğer dört görünümün tümü tamamlandığında, etkin bir şekilde gereksizdir. Ancak, diğer tüm görüşler onsuz mümkün olmazdı. Aşağıdaki resim ve tablo 4 + 1 görünümünü ayrıntılı olarak göstermektedir -

Mantıklı İşlem Geliştirme Fiziksel Senaryo
Açıklama Sistemin bileşenini (Nesneyi) ve bunların etkileşimini gösterir Sistemin süreçlerini / iş akışı kurallarını ve bu süreçlerin nasıl iletişim kurduğunu gösterir, sistemin dinamik görünümüne odaklanır Sistemin yapı taşı görünümlerini verir ve sistem modüllerinin statik organizasyonunu tanımlar Yazılım uygulamasının kurulumunu, yapılandırmasını ve dağıtımını gösterir Doğrulama ve illüstrasyon gerçekleştirerek tasarımın tamamlandığını gösterir
Görüntüleyici / Pay sahibi Son Kullanıcı, Analistler ve Tasarımcı Entegratörler ve geliştiriciler Programcı ve yazılım proje yöneticileri Sistem mühendisi, operatörler, sistem yöneticileri ve sistem kurucuları Görüş ve değerlendiricilerin tüm görüşleri
Düşünmek İşlevsel gereksinimler İşlevsel Olmayan Gereksinimler Yazılım Modülü organizasyonu (Yazılım yönetimi yeniden kullanımı, araçların kısıtlanması) Temel donanımla ilgili işlevsel olmayan gereksinim Sistem Tutarlılığı ve geçerliliği
UML - Diyagram Sınıf, Durum, Nesne, Sıra, İletişim Şeması Etkinlik şeması Bileşen, Paket şeması Dağıtım şeması Durum şemasını kullan

Mimari Açıklama Dilleri (ADL'ler)

ADL, bir yazılım mimarisini tanımlamak için sözdizimi ve anlambilim sağlayan bir dildir. Bir yazılım sisteminin kavramsal mimarisini modellemek için özellikler sağlayan, sistemin uygulanmasından farklı bir gösterim spesifikasyonudur.

ADL'ler, mimari tanımlamanın yapı taşı olan mimari bileşenleri, bunların bağlantılarını, arayüzlerini ve konfigürasyonlarını desteklemelidir. Mimari tanımlamalarda kullanım için bir ifade biçimidir ve bileşenleri ayrıştırma, bileşenleri birleştirme ve bileşenlerin arayüzlerini tanımlama yeteneği sağlar.

Bir mimari açıklama dili, işlemler, iş parçacıkları, veriler ve alt programlar gibi yazılım özelliklerinin yanı sıra işlemciler, aygıtlar, veri yolları ve bellek gibi donanım bileşenlerini tanımlayan resmi bir belirtim dilidir.

Bir ADL'yi ve bir programlama dilini veya bir modelleme dilini sınıflandırmak veya ayırt etmek zordur. Bununla birlikte, bir dilin ADL olarak sınıflandırılması için aşağıdaki gereksinimler vardır:

  • Mimariyi tüm ilgili taraflara iletmek için uygun olmalıdır.

  • Mimari oluşturma, iyileştirme ve doğrulama görevleri için uygun olmalıdır.

  • Daha fazla uygulama için bir temel sağlamalıdır, bu nedenle nihai sistem spesifikasyonunun ADL'den türetilmesini sağlamak için ADL spesifikasyonuna bilgi ekleyebilmelidir.

  • Yaygın mimari tarzların çoğunu temsil etme yeteneğine sahip olmalıdır.

  • Analitik yetenekleri desteklemeli veya hızlı üretim prototip uygulamaları sağlamalıdır.

Nesne yönelimli (OO) paradigma, şeklini yeni bir programlama yaklaşımının ilk konseptinden alırken, tasarım ve analiz yöntemlerine ilgi çok daha sonra geldi. OO analizi ve tasarım paradigması, OO programlama dillerinin geniş çapta benimsenmesinin mantıksal sonucudur.

  • Nesne yönelimli ilk dil, Simula (Gerçek sistemlerin simülasyonu), 1960 yılında Norveç Bilgi İşlem Merkezi'ndeki araştırmacılar tarafından geliştirilmiştir.

  • 1970 yılında Alan Kay ve Xerox PARC'daki araştırma grubu adlı kişisel bir bilgisayar oluşturdu. Dynabook ve ilk saf nesne yönelimli programlama dili (OOPL) - Smalltalk, Dynabook'u programlamak için.

  • 1980'lerde, Grady BoochAda programlama dili için bir tasarım sunan Nesneye Yönelik Tasarım başlıklı bir makale yayınladı. Sonraki baskılarda, fikirlerini tam bir nesneye yönelik tasarım yöntemine genişletti.

  • 1990'larda, Coad davranışsal fikirleri nesneye yönelik yöntemlerle birleştirdi.

Diğer önemli yenilikler, Nesne Modelleme Teknikleri (OMT) idi. James Rum Baugh ve Nesne Tabanlı Yazılım Mühendisliği (OOSE) tarafından Ivar Jacobson.

OO Paradigmasına Giriş

OO paradigması, herhangi bir yazılımın geliştirilmesi için önemli bir metodolojidir. Boru ve filtre, veri havuzu ve bileşen tabanlı gibi mimari tarzların veya modellerin çoğu bu paradigma kullanılarak uygulanabilir.

Nesne yönelimli sistemlerin temel kavramları ve terminolojileri -

Nesne

Bir nesne, fiziksel veya kavramsal bir varoluşa sahip olabilen, nesne yönelimli bir ortamda gerçek dünya unsurudur. Her nesnede -

  • Onu sistemdeki diğer nesnelerden ayıran kimlik.

  • Bir nesnenin karakteristik özelliklerini ve aynı zamanda nesnenin sahip olduğu özelliklerin değerlerini belirleyen durum.

  • Durumundaki değişiklikler açısından bir nesne tarafından gerçekleştirilen harici olarak görünür etkinlikleri temsil eden davranış.

Uygulamanın ihtiyacına göre nesneler modellenebilir. Bir nesnenin müşteri, araba vb. Gibi fiziksel bir varlığı olabilir; veya bir proje, süreç vb. gibi soyut bir kavramsal varoluş

Sınıf

Bir sınıf, ortak davranış sergileyen aynı karakteristik özelliklere sahip nesnelerin bir koleksiyonunu temsil eder. Ondan oluşturulabilecek nesnelerin planını veya açıklamasını verir. Bir sınıfın üyesi olarak bir nesnenin yaratılmasına somutlaştırma denir. Dolayısıyla, bir nesne birinstance bir sınıfın.

Bir sınıfın bileşenleri şunlardır:

  • Sınıftan somutlaştırılacak nesneler için bir öznitelik kümesi. Genel olarak, bir sınıfın farklı nesnelerinin özniteliklerin değerlerinde bazı farklılıkları vardır. Nitelikler genellikle sınıf verileri olarak adlandırılır.

  • Sınıfın nesnelerinin davranışını gösteren bir dizi işlem. İşlemler ayrıca işlevler veya yöntemler olarak adlandırılır.

Example

İki boyutlu bir uzayda geometrik şekilli daireyi temsil eden basit bir sınıf olan Circle'ı ele alalım. Bu sınıfın nitelikleri şu şekilde tanımlanabilir -

  • x koordinat, merkezin x koordinatını belirtmek için
  • y koordinat, merkezin y koordinatını belirtmek için
  • a, dairenin yarıçapını belirtmek için

İşlemlerinden bazıları şu şekilde tanımlanabilir -

  • findArea (), alanı hesaplamak için bir yöntem
  • findCircumference (), çevreyi hesaplamak için bir yöntem
  • scale (), yarıçapı artırmak veya azaltmak için bir yöntem

Kapsülleme

Kapsülleme, bir sınıf içinde hem öznitelikleri hem de yöntemleri birbirine bağlama işlemidir. Kapsülleme yoluyla, bir sınıfın iç detayları dışarıdan gizlenebilir. Sınıfın öğelerine, yalnızca sınıf tarafından sağlanan arabirim aracılığıyla dışarıdan erişilmesine izin verir.

Polimorfizm

Polimorfizm, başlangıçta, birden çok biçim alma yeteneği anlamına gelen Yunanca bir kelimedir. Nesne yönelimli paradigmada, polimorfizm, üzerinde çalıştıkları örneklere bağlı olarak işlemleri farklı şekillerde kullanmayı gerektirir. Çok biçimlilik, farklı iç yapılara sahip nesnelerin ortak bir dış arayüze sahip olmasına izin verir. Çok biçimlilik, kalıtımı uygularken özellikle etkilidir.

Example

Her biri findArea () yöntemine sahip Circle ve Square adlı iki sınıfı ele alalım. Sınıflardaki yöntemlerin adı ve amacı aynı olsa da dahili uygulama yani bir alan hesaplama prosedürü her sınıf için farklıdır. Circle sınıfının bir nesnesi findArea () yöntemini çağırdığında, işlem, Square sınıfının findArea () yöntemiyle herhangi bir çakışma olmadan dairenin alanını bulur.

Relationships

Bir sistemi tanımlamak için, bir sistemin hem dinamik (davranışsal) hem de statik (mantıksal) spesifikasyonu sağlanmalıdır. Dinamik belirtim, örneğin mesaj geçişi gibi nesneler arasındaki ilişkileri tanımlar. Ve statik belirtim, sınıflar arasındaki ilişkileri, örneğin toplama, ilişkilendirme ve kalıtım gibi tanımlar.

İleti geçişi

Herhangi bir uygulama, uyumlu bir şekilde etkileşimde bulunan birkaç nesne gerektirir. Bir sistemdeki nesneler birbirleriyle mesaj geçişini kullanarak iletişim kurabilir. Bir sistemin iki nesnesi olduğunu varsayalım - obj1 ve obj2. Obj1, obj2'nin yöntemlerinden birini yürütmesini isterse, obj1 obj2 objesine bir mesaj gönderir.

Bileşim veya Toplama

Toplama veya kompozisyon, bir sınıfın diğer sınıfların nesnelerinin herhangi bir kombinasyonundan oluşabileceği, sınıflar arasındaki bir ilişkidir. Nesnelerin doğrudan diğer sınıfların bünyesine yerleştirilmesine izin verir. Toplama, bütünden kendi parçalarına gitme yeteneği ile bir "parçası" veya "bir-bir" ilişkisi olarak adlandırılır. Bir toplu nesne, bir veya daha fazla başka nesneden oluşan bir nesnedir.

bağlantı

İlişkilendirme, ortak yapıya ve ortak davranışa sahip bir bağlantı grubudur. İlişki, bir veya daha fazla sınıfın nesneleri arasındaki ilişkiyi gösterir. Bir bağlantı, bir ilişkilendirmenin bir örneği olarak tanımlanabilir. Bir ilişkinin derecesi, bir bağlantıya dahil olan sınıfların sayısını gösterir. Derecesi tekli, ikili veya üçlü olabilir.

  • Tekli bir ilişki, aynı sınıftaki nesneleri birbirine bağlar.
  • İkili ilişki, iki sınıftaki nesneleri birbirine bağlar.
  • Üçlü bir ilişki, üç veya daha fazla sınıfın nesnelerini birbirine bağlar.

Miras

Yeteneklerini genişleterek ve iyileştirerek mevcut sınıflardan yeni sınıfların oluşturulmasına izin veren bir mekanizmadır. Mevcut sınıflar temel sınıflar / üst sınıflar / süper sınıflar olarak adlandırılır ve yeni sınıflar türetilmiş sınıflar / alt sınıflar / alt sınıflar olarak adlandırılır.

Alt sınıf, süper sınıfın izin vermesi koşuluyla, süper sınıfın / sınıfların özniteliklerini ve yöntemlerini miras alabilir veya türetebilir. Ayrıca, alt sınıf kendi niteliklerini ve yöntemlerini ekleyebilir ve süper sınıf yöntemlerinden herhangi birini değiştirebilir. Kalıtım, bir "eşittir" ilişkisini tanımlar.

Example

Bir Memeli sınıfından, İnsan, Kedi, Köpek, İnek vb. Gibi bir dizi sınıf türetilebilir. İnsanlar, kediler, köpekler ve inekler, memelilerin farklı özelliklerine sahiptir. Ek olarak, her birinin kendine özgü özellikleri vardır. Bir ineğin bir memeli "olduğu" söylenebilir.

OO Analizi

Yazılım geliştirmenin nesneye yönelik analiz aşamasında sistem gereksinimleri belirlenir, sınıflar belirlenir ve sınıflar arası ilişkiler onaylanır. OO analizinin amacı, sistemin uygulama alanını ve özel gereksinimlerini anlamaktır. Bu aşamanın sonucu, bir sistemin mantıksal yapısı ve fizibilitesinin gereksinim spesifikasyonu ve ilk analizidir.

Nesneye yönelik analiz için birbiriyle bağlantılı olarak kullanılan üç analiz tekniği, nesne modelleme, dinamik modelleme ve işlevsel modellemedir.

Nesne Modelleme

Nesne modelleme, yazılım sisteminin nesneler açısından statik yapısını geliştirir. Nesneleri, içinde gruplanabilecek nesnelerin sınıflarını ve nesneler arasındaki ilişkileri tanımlar. Ayrıca, her bir sınıfı karakterize eden ana öznitelikleri ve işlemleri tanımlar.

Nesne modelleme süreci aşağıdaki adımlarda görselleştirilebilir -

  • Nesneleri tanımlayın ve sınıflar halinde gruplayın
  • Sınıflar arasındaki ilişkileri tanımlayın
  • Kullanıcı nesnesi modeli diyagramı oluşturun
  • Bir kullanıcı nesnesi niteliklerini tanımlama
  • Sınıflarda yapılması gereken işlemleri tanımlayın

Dinamik Modelleme

Sistemin statik davranışı incelendikten sonra zamana ve dışsal değişikliklere göre davranışının incelenmesi gerekir. Dinamik modellemenin amacı budur.

Dinamik Modelleme, "bireysel bir nesnenin diğer nesneler tarafından tetiklenen iç olaylara veya dış dünya tarafından tetiklenen harici olaylara, olaylara nasıl tepki verdiğini açıklamanın bir yolu" olarak tanımlanabilir.

Dinamik modelleme süreci aşağıdaki adımlarda görselleştirilebilir -

  • Her nesnenin durumlarını tanımlayın
  • Olayları tanımlayın ve eylemlerin uygulanabilirliğini analiz edin
  • Durum geçiş diyagramlarından oluşan dinamik bir model diyagramı oluşturun
  • Her durumu nesne nitelikleri açısından ifade edin
  • Çizilen durum geçiş diyagramlarını doğrulayın

Fonksiyonel Modelleme

Fonksiyonel Modelleme, nesne yönelimli analizin son bileşenidir. İşlevsel model, bir nesne içinde gerçekleştirilen işlemleri ve yöntemler arasında hareket ederken verilerin nasıl değiştiğini gösterir. Bir nesne modelleme işlemlerinin anlamını ve dinamik bir modellemenin eylemlerini belirtir. Fonksiyonel model, geleneksel yapılandırılmış analizin veri akış diyagramına karşılık gelir.

Fonksiyonel modelleme süreci aşağıdaki adımlarda görselleştirilebilir -

  • Tüm giriş ve çıkışları tanımlayın
  • İşlevsel bağımlılıkları gösteren veri akışı diyagramları oluşturun
  • Her işlevin amacını belirtin
  • Kısıtlamaları belirleyin
  • Optimizasyon kriterlerini belirtin

Nesne Tabanlı Tasarım

Analiz aşamasından sonra kavramsal model, nesne yönelimli tasarım (OOD) kullanılarak nesne yönelimli bir modele dönüştürülür. OOD'de, analiz modelindeki teknolojiden bağımsız kavramlar, uygulama sınıfları ile eşleştirilir, kısıtlamalar belirlenir ve arayüzler tasarlanarak çözüm alanı için bir model elde edilir. OO tasarımının temel amacı, bir sistemin yapısal mimarisini geliştirmektir.

Nesneye yönelik tasarım aşamaları şu şekilde tanımlanabilir:

  • Sistemin bağlamını tanımlama
  • Sistem mimarisinin tasarlanması
  • Sistemdeki nesnelerin tanımlanması
  • Tasarım modellerinin yapımı
  • Nesne arayüzlerinin spesifikasyonu

OO Tasarım iki aşamaya ayrılabilir - Kavramsal tasarım ve Ayrıntılı tasarım.

Conceptual design

Bu aşamada, sistemi kurmak için gerekli olan tüm sınıflar belirlenir. Ayrıca, her sınıfa belirli sorumluluklar verilir. Sınıf diyagramı, sınıflar arasındaki ilişkileri netleştirmek için kullanılır ve olayların akışını göstermek için etkileşim diyagramı kullanılır. Olarak da bilinirhigh-level design.

Detailed design

Bu aşamada, her sınıfa etkileşim diyagramlarına göre nitelikler ve işlemler atanır. Durum makinesi diyagramı, tasarımın diğer ayrıntılarını açıklamak için geliştirilmiştir. Olarak da bilinirlow-level design.

Tasarım ilkeleri

Aşağıda ana tasarım ilkeleri verilmiştir -

Principle of Decoupling

Bir sınıftaki değişiklik diğer sınıfların kademeli güncellemelerine neden olabileceğinden, bir dizi birbirine bağımlı sınıftan oluşan bir sistemi sürdürmek zordur. Bir OO tasarımında, yeni sınıflar veya kalıtım getirilerek sıkı bağlantı ortadan kaldırılabilir.

Ensuring Cohesion

Uyumlu bir sınıf, yakından ilişkili bir dizi işlevi yerine getirir. Uyum eksikliği, tüm sistemin işleyişini etkilemese de, bir sınıf ilgisiz işlevleri yerine getirir. Yazılımın tüm yapısını yönetmeyi, genişletmeyi, sürdürmeyi ve değiştirmeyi zorlaştırır.

Open-closed Principle

Bu ilkeye göre, bir sistem yeni gereksinimleri karşılayacak şekilde genişletilebilmelidir. Sistemin genişletilmesi sonucunda mevcut uygulama ve sistem kodu değiştirilmemelidir. Ek olarak, aşağıdaki yönergelerin açık-kapalı ilkesine uyulması gerekir -

  • Her somut sınıf için, ayrı arayüz ve uygulamalar sürdürülmelidir.

  • Çok iş parçacıklı bir ortamda, öznitelikleri gizli tutun.

  • Global değişkenlerin ve sınıf değişkenlerinin kullanımını en aza indirin.

Veri akışı mimarisinde, tüm yazılım sistemi, veri ve işlemlerin birbirinden bağımsız olduğu ardışık parçalar veya girdi verileri kümesi üzerinde bir dizi dönüşüm olarak görülür. Bu yaklaşımda, veriler sisteme girer ve daha sonra bazı nihai hedefe (çıktı veya veri deposu) atanana kadar modüllerden birer birer akar.

Bileşenler veya modüller arasındaki bağlantılar, G / Ç akışı, G / Ç arabellekleri, borulu veya diğer bağlantı türleri olarak uygulanabilir. Veriler, çevrimlerle grafik topolojisinde, çevrimsiz doğrusal bir yapıda veya ağaç tipi bir yapıda uçurulabilir.

Bu yaklaşımın temel amacı, yeniden kullanım ve değiştirilebilirlik niteliklerine ulaşmaktır. Derleyiciler ve ticari veri işleme uygulamaları gibi düzenli olarak tanımlanmış girdi ve çıktılar üzerinde iyi tanımlanmış bağımsız veri dönüşümleri veya hesaplamaları içeren uygulamalar için uygundur. Modüller arasında üç tür yürütme dizisi vardır−

  • Toplu sıralı
  • Boru ve filtre veya sıralı olmayan boru hattı modu
  • Süreç kontrolü

Toplu Sıralı

Toplu sıralı, klasik bir veri işleme modelidir; burada bir veri dönüştürme alt sistemi, sürecini ancak önceki alt sistemi tamamen tamamlandıktan sonra başlatabilir -

  • Veri akışı, bir alt sistemden diğerine bir bütün olarak bir veri yığını taşır.

  • Modüller arasındaki iletişim, ardışık alt sistemler tarafından kaldırılabilen geçici ara dosyalar aracılığıyla gerçekleştirilir.

  • Verilerin toplu olarak işlendiği ve her alt sistemin ilgili girdi dosyalarını okuyup çıktı dosyalarını yazdığı uygulamalar için geçerlidir.

  • Bu mimarinin tipik uygulaması, bankacılık ve hizmet faturalandırması gibi iş verilerini işlemeyi içerir.

Avantajlar

  • Alt sistemlerde daha basit bölümler sağlar.

  • Her alt sistem, girdi verileri üzerinde çalışan ve çıktı verileri üreten bağımsız bir program olabilir.

Dezavantajları

  • Yüksek gecikme süresi ve düşük verim sağlar.

  • Eşzamanlılık ve etkileşimli arayüz sağlamaz.

  • Uygulama için harici kontrol gereklidir.

Boru ve Filtre Mimarisi

Bu yaklaşım, verilerin birbirini izleyen bileşenlerle aşamalı olarak dönüştürülmesine vurgu yapmaktadır. Bu yaklaşımda, veri akışı veriler tarafından yönlendirilir ve tüm sistem veri kaynağı, filtreler, kanallar ve veri havuzlarının bileşenlerine ayrıştırılır.

Modüller arasındaki bağlantılar, baytlar, karakterler veya bu türden herhangi bir başka türden akış olabilen ilk giren / ilk çıkar arabelleği olan veri akışıdır. Bu mimarinin temel özelliği, eşzamanlı ve artırılmış yürütülmesidir.

Filtrele

Bir filtre, bağımsız bir veri akışı transformatörü veya akış dönüştürücüleridir. Girdi veri akışının verilerini dönüştürür, işler ve dönüştürülen veri akışını bir sonraki filtrenin işlenmesi için bir boru üzerine yazar. Verilerin bağlı borudan gelir gelmez çalışmaya başladığı artımlı bir modda çalışır. İki tür filtre vardır -active filter ve passive filter.

Active filter

Aktif filtre, bağlı kanalların verileri içeri ve dönüştürülmüş verileri dışarı aktarmasına izin verir. Çekme ve itme için okuma / yazma mekanizmaları sağlayan pasif boru ile çalışır. Bu mod UNIX boru ve filtre mekanizmasında kullanılır.

Passive filter

Pasif filtre, bağlı kanalların verileri içeri aktarmasına ve veri çekmesine olanak tanır. Bir filtreden veri çeken ve verileri bir sonraki filtreye gönderen aktif boru ile çalışır. Okuma / yazma mekanizması sağlamalıdır.

Avantajlar

  • Aşırı veri işleme için eşzamanlılık ve yüksek verim sağlar.

  • Yeniden kullanılabilirlik sağlar ve sistem bakımını basitleştirir.

  • Filtreler arasında değiştirilebilirlik ve düşük bağlantı sağlar.

  • Boruyla bağlanan herhangi iki filtre arasında net ayrımlar sunarak basitlik sağlar.

  • Hem sıralı hem de paralel yürütmeyi destekleyerek esneklik sağlar.

Dezavantajları

  • Dinamik etkileşimler için uygun değil.

  • ASCII formatlarında veri iletimi için düşük bir ortak payda gereklidir.

  • Filtreler arasında veri dönüştürme ek yükü.

  • Filtrelerin bir sorunu çözmek için işbirliği içinde etkileşim kurması için bir yol sağlamaz.

  • Bu mimariyi dinamik olarak yapılandırmak zor.

Boru

Borular durumsuzdur ve iki filtre arasında var olan ikili veya karakter akışını taşır. Bir veri akışını bir filtreden diğerine taşıyabilir. Borular biraz bağlamsal bilgi kullanır ve örnekler arasında durum bilgisini tutmaz.

Proses Kontrol Mimarisi

Verilerin ne sıralı dizilimli ne de ardışık düzenlenmiş akış olmadığı bir veri akışı mimarisi türüdür. Veri akışı, işlemin yürütülmesini kontrol eden bir dizi değişkenden gelir. Tüm sistemi alt sistemlere veya modüllere ayırır ve bunları birbirine bağlar.

Alt Sistem Türleri

Bir süreç kontrol mimarisinin bir processing unit proses kontrol değişkenlerini değiştirmek için ve bir controller unit değişiklik miktarını hesaplamak için.

Bir kontrol ünitesi aşağıdaki unsurlara sahip olmalıdır -

  • Controlled Variable- Kontrollü Değişken, temeldeki sistem için değerler sağlar ve sensörler tarafından ölçülmelidir. Örneğin, hız sabitleme sistemindeki hız.

  • Input Variable- Sürece bir girdiyi ölçer. Örneğin, sıcaklık kontrol sistemindeki dönüş havasının sıcaklığı

  • Manipulated Variable - Değiştirilmiş Değişken değeri, kontrolör tarafından ayarlanır veya değiştirilir.

  • Process Definition - Bazı süreç değişkenlerini işlemek için mekanizmalar içerir.

  • Sensor - Kontrolle ilgili proses değişkenlerinin değerlerini alır ve işlenen değişkenleri yeniden hesaplamak için bir geri bildirim referansı olarak kullanılabilir.

  • Set Point - Kontrollü bir değişken için istenen değerdir.

  • Control Algorithm - Süreç değişkenlerinin nasıl değiştirileceğine karar vermek için kullanılır.

Uygulama alanları

Proses kontrol mimarisi aşağıdaki alanlarda uygundur -

  • Sistemin proses kontrol değişken verileriyle manipüle edildiği gömülü sistem yazılım tasarımı.

  • Süreç çıktılarının belirli özelliklerini verilen referans değerlerinde tutmayı amaçlayan uygulamalar.

  • Araba seyir kontrolü ve bina sıcaklık kontrol sistemleri için geçerlidir.

  • Otomobil kilitlenme önleyici frenleri, nükleer santralleri vb. Kontrol etmek için gerçek zamanlı sistem yazılımı.

Veri merkezli mimaride, veriler merkezileştirilir ve verileri değiştiren diğer bileşenler tarafından sık sık erişilir. Bu stilin temel amacı, verilerin bütünlüğünü sağlamaktır. Veri merkezli mimari, paylaşılan veri havuzları aracılığıyla iletişim kuran farklı bileşenlerden oluşur. Bileşenler, paylaşılan bir veri yapısına erişir ve nispeten bağımsızdır, bu nedenle, yalnızca veri deposu aracılığıyla etkileşim kurarlar.

Veri merkezli mimarinin en iyi bilinen örnekleri, ortak veritabanı şemasının veri tanımlama protokolü ile oluşturulduğu bir veritabanı mimarisidir - örneğin, bir RDBMS'deki alanlar ve veri türleri ile ilgili bir dizi tablo.

Veri merkezli mimarilere bir başka örnek, ortak bir veri şemasına (yani Web'in meta-yapısına) sahip olan ve hiper ortam veri modelini izleyen ve süreçler, paylaşılan web tabanlı veri hizmetlerinin kullanılmasıyla iletişim kuran web mimarisidir.

Bileşen Türleri

İki tür bileşen vardır -

  • Bir central datakalıcı veri depolamasından sorumlu olan yapı veya veri deposu veya veri havuzu. Mevcut durumu temsil eder.

  • Bir data accessor veya merkezi veri deposunda çalışan, hesaplamalar yapan ve sonuçları geri getirebilecek bağımsız bileşenlerden oluşan bir koleksiyon.

Veri erişimcileri arasındaki etkileşimler veya iletişim yalnızca veri deposu aracılığıyla yapılır. Veriler, müşteriler arasındaki tek iletişim aracıdır. Kontrol akışı, mimariyi iki kategoriye ayırır:

  • Depo Mimarisi Stili
  • Karatahta Mimarisi Stili

Depo Mimarisi Stili

Depo Mimarisi Stilinde, veri deposu pasiftir ve mantık akışını kontrol eden veri deposunun istemcileri (yazılım bileşenleri veya aracıları) etkindir. Katılan bileşenler veri deposundaki değişiklikleri kontrol eder.

  • İstemci, eylemleri gerçekleştirmek için sisteme bir istek gönderir (örn. Veri eklemek).

  • Hesaplama süreçleri bağımsızdır ve gelen talepler tarafından tetiklenir.

  • Bir işlem giriş akışındaki işlem türleri yürütülecek işlemlerin seçimini tetiklerse, bu geleneksel veritabanı veya depo mimarisi veya pasif depodur.

  • Bu yaklaşım, DBMS, kütüphane bilgi sistemi, CORBA'daki arayüz deposu, derleyiciler ve CASE (bilgisayar destekli yazılım mühendisliği) ortamlarında yaygın olarak kullanılmaktadır.

Avantajlar

  • Veri bütünlüğü, yedekleme ve geri yükleme özellikleri sağlar.

  • Birbirleriyle doğrudan iletişim içinde olmadıkları için aracıların ölçeklenebilirliğini ve yeniden kullanılabilirliğini sağlar.

  • Yazılım bileşenleri arasındaki geçici verilerin ek yükünü azaltır.

Dezavantajları

  • Arızaya karşı daha savunmasızdır ve veri çoğaltma veya çoğaltma mümkündür.

  • Veri deposunun veri yapısı ve aracıları arasında yüksek bağımlılık.

  • Veri yapısındaki değişiklikler müşterileri oldukça etkilemektedir.

  • Verilerin evrimi zor ve pahalıdır.

  • Dağıtılmış veriler için ağ üzerinde veri taşıma maliyeti.

Karatahta Mimarisi Stili

Blackboard Architecture Style'da, veri deposu etkindir ve istemcileri pasiftir. Bu nedenle mantıksal akış, veri deposundaki mevcut veri durumuna göre belirlenir. Merkezi bir veri deposu olarak görev yapan bir karatahta bileşenine sahiptir ve farklı hesaplama unsurları tarafından bir iç temsil oluşturulur ve buna göre hareket edilir.

  • Ortak veri yapısı üzerinde bağımsız olarak hareket eden bir dizi bileşen, tahtada saklanır.

  • Bu tarzda, bileşenler yalnızca karatahta aracılığıyla etkileşime girer. Veri deposu, bir veri deposu değişikliği olduğunda istemcileri uyarır.

  • Çözümün mevcut durumu karatahtada saklanır ve işlem karatahtanın durumu tarafından tetiklenir.

  • Sistem olarak bilinen bildirimler gönderir trigger ve verilerde değişiklik olduğunda müşterilere veri.

  • Bu yaklaşım, belirli AI uygulamalarında ve konuşma tanıma, görüntü tanıma, güvenlik sistemi ve iş kaynağı yönetim sistemleri gibi karmaşık uygulamalarda bulunur.

  • Merkezi veri yapısının mevcut durumu, yürütülecek işlemlerin seçilmesinin ana tetikleyicisi ise, depo bir kara tahta olabilir ve bu paylaşılan veri kaynağı aktif bir aracıdır.

  • Geleneksel veritabanı sistemlerinden önemli bir fark, bir karatahta mimarisindeki hesaplama öğelerinin çağrılmasının, karatahtanın mevcut durumu tarafından tetiklenmesi, harici girdiler tarafından tetiklenmemesidir.

Karatahta Modelinin Parçaları

Yazı tahtası modeli genellikle üç ana bölümden oluşur -

Knowledge Sources (KS)

Bilgi Kaynakları olarak da bilinir Listeners veya Subscribersfarklı ve bağımsız birimlerdir. Bir problemin parçalarını çözerler ve kısmi sonuçları toplarlar. Bilgi kaynakları arasındaki etkileşim, karatahta aracılığıyla benzersiz bir şekilde gerçekleşir.

Blackboard Data Structure

Problem çözme durumu verileri, uygulamaya bağlı bir hiyerarşi halinde düzenlenmiştir. Bilgi kaynakları, karatahta üzerinde, soruna aşamalı olarak bir çözüme götüren değişiklikler yapar.

Control

Kontrol, görevleri yönetir ve çalışma durumunu kontrol eder.

Avantajlar

  • Bilgi kaynağının eklenmesini veya güncellenmesini kolaylaştıran ölçeklenebilirlik sağlar.

  • Tüm bilgi kaynaklarının birbirlerinden bağımsız oldukları için paralel çalışmasına izin veren eşzamanlılık sağlar.

  • Hipotezler için deney yapmayı destekler.

  • Bilgi kaynağı aracılarının yeniden kullanılabilirliğini destekler.

Dezavantajları

  • Yazı tahtası ile bilgi kaynağı arasında yakın bir bağımlılık olduğundan, karatahtanın yapı değişikliğinin tüm aracıları üzerinde önemli bir etkisi olabilir.

  • Yalnızca yaklaşık bir çözüm beklendiği için, muhakemenin ne zaman sona erdirileceğine karar vermek zor olabilir.

  • Birden çok aracının senkronizasyonundaki sorunlar.

  • Sistemin tasarımında ve test edilmesinde büyük zorluklar.

Hiyerarşik mimari, tüm sistemi bir hiyerarşi yapısı olarak görür; burada yazılım sistemi, hiyerarşinin farklı seviyelerinde mantıksal modüllere veya alt sistemlere ayrıştırılır. Bu yaklaşım tipik olarak ağ protokolleri ve işletim sistemleri gibi sistem yazılımlarının tasarlanmasında kullanılır.

Sistem yazılımı hiyerarşi tasarımında, düşük seviyeli bir alt sistem, alt seviyedeki yöntemleri çağıran komşu üst seviye alt sistemlerine hizmetler verir. Alt katman, G / Ç hizmetleri, işlem, programlama, güvenlik hizmetleri, vb. Gibi daha spesifik işlevsellik sağlar. Orta katman, iş mantığı ve çekirdek işleme hizmetleri gibi daha fazla etki alanına bağlı işlevler sağlar. Üst katman, GUI'ler, kabuk programlama olanakları vb. Gibi kullanıcı arayüzü biçiminde daha soyut işlevsellik sağlar.

Ayrıca ad alanı hiyerarşisindeki .NET sınıf kitaplığı gibi sınıf kitaplıklarının organizasyonunda da kullanılır. Tüm tasarım türleri bu hiyerarşik mimariyi uygulayabilir ve genellikle diğer mimari stillerle birleşebilir.

Hiyerarşik mimari tarzlar şu şekilde ayrılır:

  • Main-subroutine
  • Master-slave
  • Sanal makine

Ana alt program

Bu stilin amacı, modülleri yeniden kullanmak ve bağımsız modülleri veya alt programları özgürce geliştirmektir. Bu tarzda bir yazılım sistemi, sistemin istenen işlevselliğine göre yukarıdan aşağıya iyileştirme kullanılarak alt yordamlara bölünür.

Bu iyileştirmeler, ayrıştırılmış modüller kendi bağımsız sorumluluğuna sahip olacak kadar basit olana kadar dikey olarak yönlendirir. İşlevsellik, üst katmanlardaki birden çok arayan tarafından yeniden kullanılabilir ve paylaşılabilir.

Verilerin parametreler olarak alt yordamlara aktarılmasının iki yolu vardır:

  • Pass by Value - Alt programlar yalnızca geçmiş verileri kullanır, ancak değiştiremez.

  • Pass by Reference - Alt rutinler, parametre tarafından referans verilen verilerin değerini kullanır ve değiştirir.

Avantajlar

  • Hiyerarşi iyileştirmesine dayalı olarak sistemi ayrıştırmak kolaydır.

  • Nesne yönelimli tasarımın bir alt sisteminde kullanılabilir.

Dezavantajları

  • Küresel olarak paylaşılan verileri içerdiği için savunmasızdır.

  • Sıkı bağlantı, değişikliklerin daha fazla dalgalanma etkisine neden olabilir.

Köle başı

Bu yaklaşım, 'böl ve yönet' ilkesini uygular ve hata hesaplamayı ve hesaplama doğruluğunu destekler. Sistemin güvenilirliğini ve hata toleransını sağlayan ana alt yordam mimarisinin bir modifikasyonudur.

Bu mimaride, köleler ana bilgisayara yinelenen hizmetler sağlar ve ana birim, belirli bir seçim stratejisine göre köleler arasından belirli bir sonucu seçer. Bağımlılar aynı işlevsel görevi farklı algoritmalar ve yöntemlerle veya tamamen farklı işlevsellikle gerçekleştirebilir. Tüm bağımlıların paralel olarak yürütülebildiği paralel hesaplamayı içerir.

Master-Slave modelinin uygulanması beş adımı izler -

  • Görevin hesaplanmasının nasıl eşit alt görevler kümesine bölünebileceğini belirtin ve bir alt görevi işlemek için gereken alt hizmetleri belirleyin.

  • Tek tek alt görevlerin işlenmesinden elde edilen sonuçların yardımıyla tüm hizmetin nihai sonucunun nasıl hesaplanabileceğini belirtin.

  • 1. adımda tanımlanan alt hizmet için bir arabirim tanımlayın. Bu arabirim, bağımlı tarafından uygulanacak ve ana kişi tarafından alt görevlerin işlenmesini devretmek için kullanılacaktır.

  • Bağımlı bileşenleri önceki adımda geliştirilen spesifikasyonlara göre uygulayın.

  • Master'ı adım 1 ila 3'te geliştirilen spesifikasyonlara göre uygulayın.

Uygulamalar

  • Yazılımın güvenilirliğinin kritik bir konu olduğu uygulamalar için uygundur.

  • Paralel ve dağıtılmış hesaplama alanlarında yaygın olarak uygulanır.

Avantajlar

  • Daha hızlı hesaplama ve kolay ölçeklenebilirlik.

  • Köleler çoğaltılabildiğinden sağlamlık sağlar.

  • Slave, anlamsal hataları en aza indirmek için farklı şekilde uygulanabilir.

Dezavantajları

  • İletişim ek yükü.

  • Tüm sorunlar bölünemez.

  • Uygulaması zor ve taşınabilirlik sorunu.

Sanal Makine Mimarisi

Sanal Makine mimarisi, üzerinde uygulandığı donanım ve / veya yazılıma özgü olmayan bazı işlevleri varsayar. Bir sanal makine, mevcut bir sistem üzerine inşa edilir ve sanal bir soyutlama, bir dizi öznitelik ve işlem sağlar.

Sanal makine mimarisinde, master, slave'den 'aynı' alt hizmeti 'kullanır ve bölünmüş çalışma, slave çağırma ve sonuçları birleştirme gibi işlevleri gerçekleştirir. Geliştiricilerin henüz inşa edilmemiş platformları simüle etmelerine ve test etmelerine ve gerçek sistemle test etmek için çok karmaşık, maliyetli veya tehlikeli olabilecek "felaket" modlarını simüle etmelerine olanak tanır.

Çoğu durumda, bir sanal makine, bir programlama dilini veya uygulama ortamını bir yürütme platformundan ayırır. Temel amaç sağlamaktırportability. Bir Sanal Makine aracılığıyla belirli bir modülün yorumlanması şu şekilde algılanabilir:

  • Yorum motoru, yorumlanmakta olan modülden bir talimat seçer.

  • Talimata bağlı olarak, motor sanal makinenin dahili durumunu günceller ve yukarıdaki işlem tekrarlanır.

Aşağıdaki şekil, tek bir fiziksel makinede standart bir VM altyapısının mimarisini göstermektedir.

hypervisor, ayrıca denir virtual machine monitor, ana bilgisayar işletim sisteminde çalışır ve eşleşen kaynakları her konuk işletim sistemine tahsis eder. Konuk bir sistem çağrısı yaptığında, hiper yönetici araya girer ve bunu ana işletim sistemi tarafından desteklenen karşılık gelen sistem çağrısına çevirir. Hiper yönetici, her sanal makinenin CPU'ya, belleğe, kalıcı depolamaya, I / O cihazlarına ve ağa erişimini kontrol eder.

Uygulamalar

Sanal makine mimarisi, aşağıdaki alanlarda uygundur -

  • Doğrudan bir çözüm yoksa simülasyon veya çeviri yoluyla bir problemi çözmek için uygundur.

  • Örnek uygulamalar arasında mikro programlama, XML işleme, komut dosyası komut dili yürütme, kural tabanlı sistem yürütme, Smalltalk ve Java yorumlayıcı türü programlama dili yorumlayıcıları yer alır.

  • Sanal makinelerin yaygın örnekleri, yorumlayıcılar, kural tabanlı sistemler, sözdizimsel kabuklar ve komut dili işlemcileridir.

Avantajlar

  • Taşınabilirlik ve makine platformundan bağımsız.

  • Yazılım geliştirmenin basitliği.

  • Programı kesme ve sorgulama yeteneği sayesinde esneklik sağlar.

  • Afet çalışma modeli için simülasyon.

  • Çalışma zamanında değişiklikleri tanıtın.

Dezavantajları

  • Tercümanın doğası gereği tercümanın yavaş çalışması.

  • Yürütmeye dahil olan ek hesaplama nedeniyle bir performans maliyeti vardır.

Katmanlı Stil

Bu yaklaşımda, sistem bir hiyerarşide birkaç üst ve alt katmana ayrıştırılır ve her katmanın sistemde kendi sorumluluğu vardır.

  • Her katman, bir pakette, konuşlandırılmış bir bileşende veya yöntem kitaplığı veya başlık dosyası biçiminde bir alt yordam grubu olarak kapsüllenmiş bir grup ilişkili sınıftan oluşur.

  • Her katman, üstündeki katmana hizmet sağlar ve aşağıdaki katmana bir istemci olarak hizmet eder, yani katman i + 1'e yönelik talep, katman i'nin arabirimi aracılığıyla katman i tarafından sağlanan hizmetleri çağırır. Görev tamamlanırsa yanıt i +1 katmanına geri dönebilir; aksi takdirde, katman i sürekli olarak aşağıdaki i-1 katmanından hizmetleri çağırır.

Uygulamalar

Katmanlı stil aşağıdaki alanlarda uygundur -

  • Hiyerarşik olarak organize edilebilen farklı hizmet sınıflarını içeren uygulamalar.

  • Uygulamaya özel ve platforma özel bölümlere ayrıştırılabilen herhangi bir uygulama.

  • Çekirdek hizmetler, kritik hizmetler ve kullanıcı arabirimi hizmetleri vb. Arasında net bölümlere sahip uygulamalar.

Avantajlar

  • Artımlı soyutlama seviyelerine dayalı tasarım.

  • Bir katmanın işlevindeki değişiklikler en fazla iki diğer katmanı etkilediği için geliştirme bağımsızlığı sağlar.

  • Standart arayüzün ayrılması ve uygulanması.

  • Sistemin yeni bileşenlerin tak ve çalıştırına izin vermesini çok daha kolay hale getiren bileşen tabanlı teknoloji kullanılarak gerçekleştirilir.

  • Her katman, taşınabilirliği destekleyen bağımsız olarak konuşlandırılan soyut bir makine olabilir.

  • Yukarıdan aşağıya iyileştirme tarzında görevlerin tanımına göre sistemi ayrıştırmak kolaydır

  • Aynı katmanın farklı uygulamaları (aynı arayüzlerle) birbirinin yerine kullanılabilir

Dezavantajları

  • Çoğu uygulama veya sistem katmanlı bir şekilde kolayca yapılandırılmaz.

  • Bir istemcinin isteği veya istemciye verilen yanıt potansiyel olarak birkaç katmandan geçmesi gerektiğinden daha düşük çalışma süresi performansı.

  • Ayrıca, her katman tarafından veri sıralama ve arabelleğe alma konusunda ek yüklerle ilgili performans endişeleri vardır.

  • Katmanlar arası iletişimin açılması kilitlenmelere neden olabilir ve "köprüleme" sıkı bağlantıya neden olabilir.

  • İstisnalar ve hata işleme, katmanlı mimaride bir sorundur, çünkü bir katmandaki hatalar yukarı doğru tüm çağrı katmanlarına yayılmalıdır.

Etkileşim odaklı mimarinin temel amacı, kullanıcının etkileşimini veri soyutlamasından ve iş verilerini 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 işlemlerini 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 birden çok konuşma ve kullanıcı etkileşimi içeren web uygulamaları gibi etkileşimli uygulamalar için kullanılır. Kontrol ve organizasyon akışlarında farklıdırlar. PAC, ajan 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ı arabirimidir 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ştirmek 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 girdiyi 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.

Kontrolör-görünümü ve model arasındaki bağlantı, kontrolör-görünümü modele abone olur ve herhangi bir değişikliğin kontrolör-görüntüsünü bilgilendirir, abonelik bildirme modelinde (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.

View 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ünüm 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 temsilcideki 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ği için, her bir aracıda sunum ve soyutlamanın kontrol tarafından tam olarak ayrılması geliştirme karmaşıklığı yaratır

Dağıtık mimaride, bileşenler farklı platformlarda sunulur ve belirli bir hedefe veya hedefe ulaşmak için birkaç bileşen bir iletişim ağı üzerinden birbiriyle işbirliği yapabilir.

  • Bu mimaride, bilgi işleme tek bir makineyle sınırlı değildir, birkaç bağımsız bilgisayara dağıtılır.

  • Dağıtılmış bir sistem, çok katmanlı mimarilerin temelini oluşturan istemci-sunucu mimarisi tarafından gösterilebilir; alternatifler CORBA gibi aracı mimarisi ve Servis Odaklı Mimari (SOA).

  • NET, J2EE, CORBA, .NET Web hizmetleri, AXIS Java Web hizmetleri ve Globus Grid hizmetleri dahil olmak üzere dağıtılmış mimarileri desteklemek için çeşitli teknoloji çerçeveleri vardır.

  • Middleware, dağıtılmış uygulamaların geliştirilmesini ve yürütülmesini uygun şekilde destekleyen bir altyapıdır. Uygulamalar ve ağ arasında bir tampon sağlar.

  • Sistemin ortasında yer alır ve dağıtılmış bir sistemin farklı bileşenlerini yönetir veya destekler. Örnekler, işlem işleme monitörleri, veri dönüştürücüleri ve iletişim denetleyicileri vb.

Dağıtılmış sistem altyapısı olarak ara yazılım

Dağıtılmış bir mimarinin temeli şeffaflığı, güvenilirliği ve kullanılabilirliğidir.

Aşağıdaki tablo, dağıtılmış bir sistemdeki farklı şeffaflık biçimlerini listeler -

Sr.No. Şeffaflık ve Açıklama
1

Access

Kaynaklara erişim şeklini ve veri platformundaki farklılıkları gizler.
2

Location

Kaynakların bulunduğu yeri gizler.
3

Technology

Kullanıcıdan programlama dili ve işletim sistemi gibi farklı teknolojileri gizler.
4

Migration / Relocation

Kullanımda olan başka bir yere taşınabilecek kaynakları gizleyin.
5

Replication

Birkaç konumda kopyalanabilecek kaynakları gizleyin.
6

Concurrency

Diğer kullanıcılarla paylaşılabilecek kaynakları gizleyin.
7

Failure

Kullanıcıdan kaynakların arızasını ve kurtarılmasını gizler.
8

Persistence

Bir kaynağın (yazılım) bellekte mi yoksa diskte mi olduğunu gizler.

Avantajlar

  • Resource sharing - Donanım ve yazılım kaynaklarının paylaşılması.

  • Openness - Farklı satıcıların donanım ve yazılımlarını kullanma esnekliği.

  • Concurrency - Performansı artırmak için eşzamanlı işleme.

  • Scalability - Yeni kaynaklar ekleyerek artan iş hacmi.

  • Fault tolerance - Bir arıza meydana geldikten sonra çalışmaya devam etme yeteneği.

Dezavantajları

  • Complexity - Merkezi sistemlerden daha karmaşıktırlar.

  • Security - Dış saldırılara karşı daha duyarlı.

  • Manageability - Sistem yönetimi için daha fazla çaba gerekir.

  • Unpredictability - Sistem organizasyonuna ve ağ yüküne bağlı olarak öngörülemeyen yanıtlar.

Merkezi Sistem ve Dağıtılmış Sistem

Kriterler Merkezi sistem Dağıtımlı sistem
Ekonomi Düşük Yüksek
Kullanılabilirlik Düşük Yüksek
Karmaşıklık Düşük Yüksek
Tutarlılık Basit Yüksek
Ölçeklenebilirlik Yoksul İyi
Teknoloji Homojen Heterojen
Güvenlik Yüksek Düşük

İstemci-Sunucu Mimarisi

İstemci-sunucu mimarisi, sistemi iki ana alt sisteme veya mantıksal sürece ayıran en yaygın dağıtılmış sistem mimarisidir -

  • Client - Bu, ikinci işleme, yani sunucuya bir istek gönderen ilk işlemdir.

  • Server - Bu, talebi alan, yerine getiren ve müşteriye cevap gönderen ikinci işlemdir.

Bu mimaride uygulama, sunucular ve bu hizmetleri kullanan bir dizi istemci tarafından sağlanan bir dizi hizmet olarak modellenmiştir. Sunucuların istemciler hakkında bilgi sahibi olması gerekmez, ancak istemciler sunucuların kimliğini bilmelidir ve işlemcilerin işlemlerle eşleştirilmesi ille de 1: 1 olmak zorunda değildir.

İstemci-sunucu Mimarisi, istemcinin işlevselliğine göre iki model halinde sınıflandırılabilir -

İnce istemci modeli

İnce istemci modelinde, tüm uygulama işleme ve veri yönetimi sunucu tarafından gerçekleştirilir. Müşteri, sunum yazılımını çalıştırmaktan sorumludur.

  • Eski sistemler, bir istemcide uygulanan grafik arabirimle, eski sistemin kendi başına bir sunucu olarak hareket ettiği istemci sunucu mimarilerine taşındığında kullanılır

  • Önemli bir dezavantajı, hem sunucuya hem de ağa ağır bir işlem yükü yüklemesidir.

Kalın / Şişman müşteri modeli

Yoğun istemci modelinde, sunucu yalnızca veri yönetiminden sorumludur. İstemci üzerindeki yazılım, uygulama mantığını ve sistem kullanıcısı ile olan etkileşimleri uygular.

  • İstemci sistemin yeteneklerinin önceden bilindiği yeni C / S sistemleri için en uygun olanı

  • Özellikle yönetim için ince bir istemci modelinden daha karmaşık. Uygulamanın yeni sürümleri tüm istemcilere yüklenmelidir.

Avantajlar

  • Kullanıcı arayüzü sunumu ve iş mantığı işleme gibi sorumlulukların ayrılması.

  • Sunucu bileşenlerinin yeniden kullanılabilirliği ve eşzamanlılık potansiyeli

  • Dağıtılmış uygulamaların tasarımını ve geliştirilmesini basitleştirir

  • Mevcut uygulamaları dağıtılmış bir ortama taşımayı veya entegre etmeyi kolaylaştırır.

  • Ayrıca, çok sayıda istemci yüksek performanslı bir sunucuya eriştiğinde kaynakların verimli bir şekilde kullanılmasını sağlar.

Dezavantajları

  • Gereksinim değişiklikleriyle başa çıkmak için heterojen altyapı eksikliği.

  • Güvenlik sorunları.

  • Sınırlı sunucu kullanılabilirliği ve güvenilirliği.

  • Sınırlı test edilebilirlik ve ölçeklenebilirlik.

  • Sunum ve iş mantığı ile şişman müşteriler.

Çok Katmanlı Mimari (n katmanlı Mimari)

Çok katmanlı mimari, sunum, uygulama işleme ve veri yönetimi gibi işlevlerin fiziksel olarak ayrıldığı bir istemci-sunucu mimarisidir. Geliştiriciler, bir uygulamayı katmanlara ayırarak, tüm uygulamayı yeniden çalışmak yerine belirli bir katmanı değiştirme veya ekleme seçeneğine sahip olur. Geliştiricilerin esnek ve yeniden kullanılabilir uygulamalar oluşturabileceği bir model sağlar.

Çok katmanlı mimarinin en genel kullanımı üç katmanlı mimaridir. Üç katmanlı bir mimari tipik olarak bir sunum katmanından, bir uygulama katmanından ve bir veri depolama katmanından oluşur ve ayrı bir işlemci üzerinde çalıştırılabilir.

Sunum Katmanı

Sunum katmanı, kullanıcıların web sayfası veya İşletim Sistemi GUI (Grafik Kullanıcı arayüzü) gibi doğrudan erişebilecekleri uygulamanın en üst düzeyidir. Bu katmanın birincil işlevi, görevleri ve sonuçları kullanıcının anlayabileceği bir şeye çevirmektir. Diğer katmanlarla iletişim kurarak sonuçları tarayıcı / istemci katmanına ve ağdaki diğer tüm katmanlara yerleştirir.

Uygulama Katmanı (İş Mantığı, Mantık Katmanı veya Orta Katman)

Uygulama katmanı, uygulamayı koordine eder, komutları işler, mantıksal kararlar verir, değerlendirir ve hesaplamalar yapar. Ayrıntılı işlem gerçekleştirerek bir uygulamanın işlevselliğini kontrol eder. Ayrıca, verileri çevreleyen iki katman arasında taşır ve işler.

Veri Katmanı

Bu katmanda bilgi depolanır ve veritabanından veya dosya sisteminden alınır. Bilgi daha sonra işlenmek üzere geri gönderilir ve ardından kullanıcıya geri gönderilir. Veri kalıcılığı mekanizmalarını (veritabanı sunucuları, dosya paylaşımları, vb.) İçerir ve depolanan verileri yönetme yöntemlerini sağlayan uygulama katmanına API (Uygulama Programlama Arayüzü) sağlar.

Advantages

  • İnce istemci yaklaşımından daha iyi performans ve kalın istemci yaklaşımından daha kolay yönetilebilir.

  • Yeniden kullanılabilirliği ve ölçeklenebilirliği geliştirir - talepler arttıkça ekstra sunucular eklenebilir.

  • Çoklu iş parçacığı desteği sağlar ve ayrıca ağ trafiğini azaltır.

  • Sürdürülebilirlik ve esneklik sağlar

Disadvantages

  • Test araçlarının eksikliğinden dolayı Yetersiz Test Edilebilirlik.

  • Daha kritik sunucu güvenilirliği ve kullanılabilirliği.

Broker Mimari Tarzı

Broker Architectural Style, kayıtlı sunucular ve istemciler arasındaki iletişimi koordine etmek ve etkinleştirmek için dağıtılmış hesaplamada kullanılan bir ara yazılım mimarisidir. Burada nesne iletişimi, nesne istek aracısı (yazılım veriyolu) adı verilen bir ara yazılım sistemi aracılığıyla gerçekleşir.

  • İstemci ve sunucu birbiriyle doğrudan etkileşime girmez. İstemci ve sunucunun, aracı-aracı ile iletişim kuran proxy'sine doğrudan bir bağlantısı vardır.

  • Bir sunucu, aracıya arabirimlerini kaydederek ve yayımlayarak hizmetler sağlar ve istemciler, hizmetleri aracıdan statik veya dinamik olarak arayarak talep edebilir.

  • CORBA (Ortak Nesne İsteği Aracısı Mimarisi), aracı mimarisinin iyi bir uygulama örneğidir.

Broker Mimari Stilinin Bileşenleri

Broker mimari tarzının bileşenleri aşağıdaki başlıklar aracılığıyla tartışılmaktadır:

Broker

Broker, sonuçların ve istisnaların iletilmesi ve gönderilmesi gibi iletişimin koordinasyonundan sorumludur. Çağrı odaklı bir hizmet, istemcilerin bir mesaj gönderdiği bir belge veya mesaj odaklı bir aracı olabilir.

  • Hizmet taleplerine aracılık etmekten, uygun bir sunucuyu bulmaktan, istekleri iletmekten ve istemcilere yanıtları geri göndermekten sorumludur.

  • İşlevleri ve hizmetleri ile konum bilgileri dahil olmak üzere sunucuların kayıt bilgilerini tutar.

  • İstemcilerin talep etmesi, sunucuların yanıt vermesi, sunucu bileşenlerini kaydetmesi veya kaydını iptal etmesi, mesajları aktarması ve sunucuları bulması için API'ler sağlar.

Stub

Stub'lar statik derleme zamanında oluşturulur ve ardından istemci için bir proxy olarak kullanılan istemci tarafına dağıtılır. İstemci tarafı proxy, müşteri ile aracı arasında bir arabulucu görevi görür ve müşteri ile aralarında ek şeffaflık sağlar; uzak nesne yerel bir nesne gibi görünür.

Proxy, protokol düzeyinde IPC'yi (süreçler arası iletişim) gizler ve parametre değerlerinin sıralanmasını ve sunucudan gelen sonuçların sırasının kaldırılmasını gerçekleştirir.

Skeleton

İskelet, servis arayüzü derlemesi tarafından üretilir ve ardından sunucu için bir proxy olarak kullanılan sunucu tarafına dağıtılır. Sunucu tarafı proxy, düşük düzeyli sisteme özgü ağ işlevlerini kapsüller ve sunucu ile aracı arasında arabuluculuk yapmak için üst düzey API'ler sağlar.

İstekleri alır, istekleri paketten çıkarır, yöntem argümanlarını unmarshals, uygun servisi çağırır ve istemciye geri göndermeden önce sonucu sıralar.

Bridge

Bir köprü, farklı iletişim protokollerine dayalı olarak iki farklı ağı birbirine bağlayabilir. DCOM, .NET uzaktan kumanda ve Java CORBA aracıları dahil olmak üzere farklı aracılara aracılık eder.

Köprüler, iki aracı kurum birlikte çalışıp istekleri ve parametreleri bir formatta alıp başka bir formata çevirdiğinde uygulama ayrıntılarını gizleyen isteğe bağlı bir bileşendir.

Broker implementation in CORBA

CORBA, OMG (nesne yönetimi grubu) tarafından tanımlanan dağıtılmış nesneler arasındaki iletişimi yönetmek için bir ara yazılım olan Nesne İstek Aracısı için uluslararası bir standarttır.

Servis Odaklı Mimari (SOA)

Bir hizmet, iyi tanımlanmış, bağımsız, bağımsız, yayınlanmış ve standart bir programlama arayüzü aracılığıyla kullanılabilen bir iş işlevselliği bileşenidir. Hizmetler arasındaki bağlantılar, talepleri ve yanıtları hizmetler arasında gevşek bir şekilde teslim edebilen SOAP Web hizmet protokolü gibi ortak ve evrensel mesaj odaklı protokollerle gerçekleştirilir.

Hizmet odaklı mimari, bir uygulamanın yazılım hizmetlerinden ve yazılım hizmeti tüketicilerinden (istemciler veya hizmet talep edenler olarak da bilinir) oluştuğu iş odaklı BT yaklaşımını destekleyen bir istemci / sunucu tasarımıdır.

SOA'nın özellikleri

Hizmet odaklı bir mimari aşağıdaki özellikleri sağlar:

  • Distributed Deployment - Kurumsal verileri ve iş mantığını, hizmetler adı verilen gevşek, birleştirilmiş, keşfedilebilir, yapılandırılmış, standart tabanlı, kaba taneli, durumsuz işlev birimleri olarak ortaya çıkarın.

  • Composability - İyi tanımlanmış, yayınlanmış ve standart şikayet arayüzleri aracılığıyla istenen bir ayrıntı düzeyinde açığa çıkan mevcut hizmetlerden yeni süreçleri bir araya getirin.

  • Interoperability - Altta yatan protokollerden veya uygulama teknolojisinden bağımsız olarak bir ağda yetenekleri paylaşın ve paylaşılan hizmetleri yeniden kullanın.

  • Reusability - Bir hizmet sağlayıcı seçin ve hizmet olarak gösterilen mevcut kaynaklara erişin.

SOA Operasyonu

Aşağıdaki şekil, SOA'nın nasıl çalıştığını göstermektedir -

Advantages

  • Hizmet oryantasyonunun gevşek bağlantısı, kuruluşlara, platform ve teknoloji kısıtlamalarından bağımsız olarak mevcut tüm hizmet kaynaklarından yararlanmaları için büyük esneklik sağlar.

  • Her hizmet bileşeni, durum bilgisi olmayan hizmet özelliği nedeniyle diğer hizmetlerden bağımsızdır.

  • Bir hizmetin uygulanması, görünen arabirim değiştirilmediği sürece hizmetin uygulamasını etkilemeyecektir.

  • Bir müşteri veya herhangi bir hizmet, platformlarından, teknolojilerinden, satıcılarından veya dil uygulamalarından bağımsız olarak diğer hizmetlere erişebilir.

  • Varlıkların ve hizmetlerin yeniden kullanılabilirliği, bir hizmetin müşterilerinin yalnızca genel arayüzlerini ve hizmet bileşimini bilmeleri gerektiğinden.

  • SOA tabanlı iş uygulaması geliştirme, zaman ve maliyet açısından çok daha verimlidir.

  • Ölçeklenebilirliği artırır ve sistemler arasında standart bağlantı sağlar.

  • 'Ticari Hizmetlerin' verimli ve etkili kullanımı.

  • Entegrasyon çok daha kolay hale gelir ve içsel birlikte çalışabilirliği iyileştirir.

  • Geliştiriciler için karmaşıklığı soyutlayın ve iş süreçlerini son kullanıcılara daha yakın hale getirin.

Bileşen tabanlı mimari, tasarımın yöntemleri, olayları ve özellikleri içeren iyi tanımlanmış iletişim arayüzlerini temsil eden bireysel işlevsel veya mantıksal bileşenlere ayrıştırılmasına odaklanır. Daha yüksek düzeyde bir soyutlama sağlar ve sorunu, her biri bileşen bölümleriyle ilişkili alt problemlere böler.

Bileşen tabanlı mimarinin temel amacı, component reusability. Bir bileşen, bir yazılım öğesinin işlevselliğini ve davranışlarını yeniden kullanılabilir ve kendi kendine konuşlandırılabilen bir ikili birim halinde kapsüller. COM / DCOM, JavaBean, EJB, CORBA, .NET, web servisleri ve grid servisleri gibi birçok standart bileşen çerçevesi vardır. Bu teknolojiler, grafik JavaBean bileşenleri, MS ActiveX bileşenleri ve basitçe sürükle ve bırak işlemiyle yeniden kullanılabilen COM bileşenleri gibi yerel masaüstü GUI uygulama tasarımında yaygın olarak kullanılmaktadır.

Bileşen odaklı yazılım tasarımının, geleneksel nesne odaklı yaklaşımlara göre birçok avantajı vardır:

  • Mevcut bileşenleri yeniden kullanarak pazarda daha az zaman ve geliştirme maliyeti.

  • Mevcut bileşenlerin yeniden kullanımıyla artan güvenilirlik.

Bileşen nedir?

Bir bileşen modüler, taşınabilir, değiştirilebilir ve yeniden kullanılabilir bir dizi iyi tanımlanmış işlevselliktir ve uygulamasını kapsayarak daha üst düzey bir arayüz olarak dışa aktarır.

Bir bileşen, diğer bileşenlerle etkileşime girmesi amaçlanan, belirli işlevleri veya bir dizi işlevi kapsayan bir yazılım nesnesidir. Açıkça tanımlanmış bir arayüze sahiptir ve bir mimari içindeki tüm bileşenlerde ortak olan önerilen davranışa uyar.

Bir yazılım bileşeni, yalnızca sözleşmeyle belirlenmiş bir arayüze ve açık bağlam bağımlılıklarına sahip bir bileşim birimi olarak tanımlanabilir. Diğer bir deyişle, bir yazılım bileşeni bağımsız olarak konuşlandırılabilir ve üçüncü şahısların oluşturmasına tabidir.

Bir Bileşenin Görünümleri

Bir bileşenin üç farklı görünümü olabilir - nesne yönelimli görünüm, geleneksel görünüm ve süreçle ilgili görünüm.

Object-oriented view

Bir bileşen, bir veya daha fazla işbirliği yapan sınıflar kümesi olarak görülür. Her problem etki alanı sınıfı (analiz) ve altyapı sınıfı (tasarım), uygulanması için geçerli olan tüm öznitelikleri ve işlemleri tanımlamak için açıklanır. Ayrıca, sınıfların iletişim kurmasını ve işbirliği yapmasını sağlayan arayüzlerin tanımlanmasını da içerir.

Conventional view

İşlem mantığını, işleme mantığını uygulamak için gerekli olan dahili veri yapılarını ve bileşenin çağrılmasını ve verinin ona iletilmesini sağlayan bir arabirimi entegre eden bir programın işlevsel öğesi veya modülü olarak görülür.

Process-related view

Bu görünümde, her bileşeni sıfırdan oluşturmak yerine, sistem bir kitaplıkta tutulan mevcut bileşenlerden inşa ediyor. Yazılım mimarisi formüle edilirken, bileşenler kütüphaneden seçilir ve mimariyi doldurmak için kullanılır.

  • Bir kullanıcı arabirimi (UI) bileşeni ızgaraları, kontroller olarak adlandırılan düğmeleri içerir ve yardımcı program bileşenleri, diğer bileşenlerde kullanılan belirli bir işlev alt kümesini ortaya çıkarır.

  • Diğer yaygın bileşen türleri, kaynak yoğun olan, sık erişilmeyen ve tam zamanında (JIT) yaklaşımı kullanılarak etkinleştirilmesi gereken bileşenlerdir.

  • Kurumsal iş uygulamaları ve Enterprise JavaBean (EJB), .NET bileşenleri ve CORBA bileşenleri gibi internet web uygulamalarında dağıtılan birçok bileşen görünmezdir.

Bileşenlerin Özellikleri

  • Reusability- Bileşenler genellikle farklı uygulamalarda farklı durumlarda yeniden kullanılmak üzere tasarlanmıştır. Bununla birlikte, bazı bileşenler belirli bir görev için tasarlanabilir.

  • Replaceable - Bileşenler, diğer benzer bileşenlerle serbestçe değiştirilebilir.

  • Not context specific - Bileşenler, farklı ortamlarda ve bağlamlarda çalışmak üzere tasarlanmıştır.

  • Extensible - Bir bileşen, yeni davranış sağlamak için mevcut bileşenlerden genişletilebilir.

  • Encapsulated - AA bileşeni, arayanın işlevselliğini kullanmasına izin veren ve dahili işlemlerin ayrıntılarını veya herhangi bir dahili değişken veya durumu açığa çıkarmayan arayüzleri gösterir.

  • Independent - Bileşenler, diğer bileşenlere minimum bağımlılık sağlayacak şekilde tasarlanmıştır.

Bileşen Bazlı Tasarım İlkeleri

Bileşen düzeyinde bir tasarım, kaynak koduna çevrilebilen bazı ara temsiller (örneğin grafik, tablo veya metin tabanlı) kullanılarak temsil edilebilir. Veri yapılarının, arayüzlerin ve algoritmaların tasarımı, hataların ortaya çıkmasını önlememize yardımcı olmak için iyi belirlenmiş yönergelere uygun olmalıdır.

  • Yazılım sistemi yeniden kullanılabilir, birleşik ve kapsüllenmiş bileşen birimlerine ayrıştırılır.

  • Her bileşenin, gerekli bağlantı noktalarını ve sağlanan bağlantı noktalarını belirten kendi arabirimi vardır; her bileşen ayrıntılı uygulamasını gizler.

  • Bileşenin mevcut parçalarına dahili kod veya tasarım değişiklikleri yapmaya gerek kalmadan bir bileşen genişletilmelidir.

  • Soyutlamalara bağlı bileşen, harcanabilirlikte zorluğu artıran diğer somut bileşenlere bağlı değildir.

  • Bağlayıcılar, bileşenler arasındaki etkileşimi belirleyerek ve yöneterek bileşenleri bağladı. Etkileşim türü, bileşenlerin arayüzleri tarafından belirlenir.

  • Bileşenler etkileşimi, yöntem çağrıları, asenkron çağrılar, yayınlama, mesajla yönlendirilen etkileşimler, veri akışı iletişimleri ve diğer protokole özgü etkileşimler biçimini alabilir.

  • Bir sunucu sınıfı için, ana istemci kategorilerine hizmet etmek için özel arayüzler oluşturulmalıdır. Arayüzde yalnızca belirli bir müşteri kategorisiyle ilgili olan işlemler belirtilmelidir.

  • Bir bileşen diğer bileşenlere uzanabilir ve yine de kendi uzantı noktalarını sunabilir. Eklenti tabanlı mimari kavramıdır. Bu, bir eklentinin başka bir eklenti API'si sunmasına izin verir.

Bileşen Düzeyinde Tasarım Yönergeleri

Mimari modelin bir parçası olarak belirtilen bileşenler için bir adlandırma kuralları oluşturur ve ardından bileşen seviyesi modelinin bir parçası olarak iyileştirir veya detaylandırır.

  • Mimari bileşen adlarını problem alanından alır ve mimari modeli gören tüm paydaşlar için anlam ifade etmelerini sağlar.

  • Diğer varlıklara herhangi bir ilişkili bağımlılık olmadan bağımsız olarak var olabilen iş süreci varlıklarını çıkarır.

  • Bu bağımsız varlıkları yeni bileşenler olarak tanır ve keşfeder.

  • Uygulamaya özel anlamlarını yansıtan altyapı bileşeni adlarını kullanır.

  • Soldan sağa tüm bağımlılıkları ve üstten (temel sınıf) alta (türetilmiş sınıflar) kalıtımı modeller.

  • Herhangi bir bileşen bağımlılığını, doğrudan bileşenden bileşene bağımlılık olarak temsil etmek yerine arabirimler olarak modelleyin.

Bileşen Düzeyinde Tasarım Yapmak

Analiz modeli ve mimari modelde tanımlanan problem alanına karşılık gelen tüm tasarım sınıflarını tanır.

  • Altyapı alanına karşılık gelen tüm tasarım sınıflarını tanır.

  • Yeniden kullanılabilir bileşenler olarak edinilmeyen tüm tasarım sınıflarını açıklar ve mesaj ayrıntılarını belirtir.

  • Her bileşen için uygun arabirimleri tanımlar ve öznitelikleri detaylandırır ve bunları uygulamak için gereken veri türlerini ve veri yapılarını tanımlar.

  • Sözde kod veya UML etkinlik diyagramları aracılığıyla her işlemdeki işlem akışını ayrıntılı olarak açıklar.

  • Kalıcı veri kaynaklarını (veritabanları ve dosyalar) açıklar ve bunları yönetmek için gereken sınıfları tanımlar.

  • Bir sınıf veya bileşen için davranışsal temsiller geliştirir ve detaylandırır. Bu, analiz modeli için oluşturulan UML durum diyagramlarını detaylandırarak ve tasarım sınıfıyla ilgili tüm kullanım durumlarını inceleyerek yapılabilir.

  • Ek uygulama ayrıntısı sağlamak için dağıtım şemalarını detaylandırır.

  • Sınıf örneklerini kullanarak ve belirli donanım ve işletim sistemi ortamını belirleyerek bir sistemdeki anahtar paketlerin veya bileşen sınıflarının konumunu gösterir.

  • Nihai karar, yerleşik tasarım ilkeleri ve yönergeleri kullanılarak alınabilir. Deneyimli tasarımcılar, nihai tasarım modeline karar vermeden önce alternatif tasarım çözümlerinin tamamını (veya çoğunu) dikkate alır.

Avantajlar

  • Ease of deployment - Yeni uyumlu versiyonlar ortaya çıktıkça, diğer bileşenlere veya bir bütün olarak sisteme herhangi bir etki yapmadan mevcut versiyonları değiştirmek daha kolaydır.

  • Reduced cost - Üçüncü taraf bileşenlerin kullanılması, geliştirme ve bakım maliyetlerini yaymanıza olanak tanır.

  • Ease of development - Bileşenler, tanımlanmış işlevsellik sağlamak için iyi bilinen arayüzler uygular ve sistemin diğer bölümlerini etkilemeden geliştirmeye izin verir.

  • Reusable - Yeniden kullanılabilir bileşenlerin kullanımı, geliştirme ve bakım maliyetini çeşitli uygulamalara veya sistemlere yaymak için kullanılabilecekleri anlamına gelir.

  • Modification of technical complexity - Bir bileşen, bir bileşen kapsayıcısı ve hizmetlerini kullanarak karmaşıklığı değiştirir.

  • Reliability - Her bir bileşenin güvenilirliği, yeniden kullanım yoluyla tüm sistemin güvenilirliğini artırdığından, genel sistem güvenilirliği artar.

  • System maintenance and evolution - Sistemin geri kalanını etkilemeden uygulamayı değiştirmek ve güncellemek kolaydır.

  • Independent- Bileşenlerin bağımsızlığı ve esnek bağlanabilirliği. Paralel olarak farklı gruplara göre bileşenlerin bağımsız gelişimi. Yazılım geliştirme ve gelecekteki yazılım geliştirme için verimlilik.

Kullanıcı arayüzü, kullanıcının bakış açısından bir yazılım sisteminin ilk izlenimidir. Bu nedenle, herhangi bir yazılım sistemi kullanıcının gereksinimlerini karşılamalıdır. UI esas olarak iki işlevi yerine getirir -

  • Kullanıcının girişini kabul etme

  • Çıkışın görüntülenmesi

Kullanıcı arayüzü, herhangi bir yazılım sisteminde çok önemli bir rol oynar. Muhtemelen bir yazılım sisteminin görünen tek yönü -

  • Kullanıcılar, başlangıçta, iç mimarisini dikkate almadan, yazılım sisteminin harici kullanıcı arayüzünün mimarisini göreceklerdir.

  • İyi bir kullanıcı arayüzü, kullanıcıyı yazılım sistemini hatasız kullanmaya çekmelidir. Kullanıcının yanıltıcı bilgi vermeden yazılım sistemini kolayca anlamasına yardımcı olmalıdır. Kötü bir kullanıcı arayüzü, yazılım sisteminin rekabetine karşı piyasa başarısızlığına neden olabilir.

  • UI'nin sözdizimi ve semantiği vardır. Sözdizimi, metinsel, ikon, düğme vb. Gibi bileşen türlerini içerir ve kullanılabilirlik, kullanıcı arayüzünün anlamını özetler. Kullanıcı arayüzünün kalitesi, görünümü ve hissi (sözdizimi) ve kullanılabilirliği (anlambilim) ile karakterize edilir.

  • Temel olarak iki ana kullanıcı arabirimi türü vardır - a) Metinsel b) Grafik.

  • Farklı alanlardaki yazılımlar, kullanıcı arayüzünün farklı stilini gerektirebilir, örneğin hesap makinesi sayısal sayıları görüntülemek için yalnızca küçük bir alana ihtiyaç duyar, ancak komutlar için büyük bir alana ihtiyaç duyar, Bir web sayfasının formlara, bağlantılara, sekmelere vb.

Grafiksel kullanıcı arayüzü

Grafik kullanıcı arayüzü, günümüzde mevcut olan en yaygın kullanıcı arayüzü türüdür. Resimlerden, grafiklerden ve ikonlardan yararlandığı için oldukça kullanıcı dostudur - bu nedenle 'grafik' olarak adlandırılır.

Aynı zamanda bir WIMP interface çünkü -

  • Windows - Yaygın olarak kullanılan uygulamaların çalıştığı ekranda dikdörtgen bir alan.

  • Icons - Bir yazılım uygulamasını veya donanım cihazını temsil etmek için kullanılan bir resim veya sembol.

  • Menus - Kullanıcının ihtiyaç duyduklarını seçebileceği seçeneklerin listesi.

  • Pointers- Kullanıcı fareyi hareket ettirdikçe ekranda hareket eden ok gibi bir sembol. Kullanıcının nesneleri seçmesine yardımcı olur.

Kullanıcı Arayüzü Tasarımı

Kullanıcının birincil görevlerini ve sorun alanını anlayan görev analizi ile başlar. Programcıya göre değil, Kullanıcının terminolojisine ve kullanıcının işinin başlangıcına göre tasarlanmalıdır.

  • Kullanıcı arayüzü analizi gerçekleştirmek için, uygulayıcının dört unsuru incelemesi ve anlaması gerekir -

    • users arayüz aracılığıyla sistemle kim etkileşim kuracak

    • tasks son kullanıcıların işlerini yapmak için gerçekleştirmesi gereken

    • content arayüzün bir parçası olarak sunulan

    • work environment bu görevlerin yürütüleceği

  • Doğru veya iyi UI tasarımı, makinelerin değil, kullanıcının yeteneklerine ve sınırlamalarına göre çalışır. Kullanıcı arayüzünü tasarlarken, kullanıcının çalışma ve ortamının doğası hakkında bilgi de önemlidir.

  • Gerçekleştirilecek görev daha sonra, her birinin yeteneklerinin ve sınırlamalarının bilgisine dayalı olarak kullanıcıya veya makineye atanan bölümlere ayrılabilir. Bir kullanıcı arayüzünün tasarımı genellikle dört farklı seviyeye ayrılır -

    • The conceptual level - Kullanıcının sisteme bakışını ve bunlarla ilgili olası eylemleri dikkate alan temel varlıkları açıklar.

    • The semantic level - Sistem tarafından gerçekleştirilen işlevleri, yani sistemin işlevsel gereksinimlerinin açıklamasını açıklar, ancak kullanıcının işlevleri nasıl başlatacağını ele almaz.

    • The syntactic level - Açıklanan işlevleri çağırmak için gerekli giriş ve çıkış sıralarını açıklar.

    • The lexical level - Girdi ve çıktıların gerçekte nasıl oluştuğunu ilkel donanım işlemlerinden belirler.

  • Kullanıcı arayüzü tasarımı, tüm yinelemelerin önceki adımlarda geliştirilen bilgileri açıkladığı ve geliştirdiği yinelemeli bir süreçtir. Kullanıcı arayüzü tasarımı için genel adımlar

    • Kullanıcı arabirimi nesnelerini ve eylemlerini (işlemleri) tanımlar.

    • Kullanıcı arayüzünün durumunun değişmesine neden olacak olayları (kullanıcı eylemleri) tanımlar.

    • Arayüz aracılığıyla sağlanan bilgilerden kullanıcının sistemin durumunu nasıl yorumladığını gösterir.

    • Her arayüz durumunu, aslında son kullanıcıya görüneceği şekilde tanımlayın.

    Kullanıcı Arayüzü Geliştirme Süreci

    Aşağıdaki diyagramda gösterildiği gibi spiral bir süreci izler -

    Interface analysis

    Sistemle etkileşime girecek kullanıcılara, görevlere, içeriğe ve çalışma ortamına odaklanır veya bunlara odaklanır. Sistem işlevini gerçekleştirmek için gereken insan ve bilgisayar odaklı görevleri tanımlar.

    Interface design

    Bir kullanıcının sistem için tanımlanan her kullanılabilirlik hedefini karşılayan bir şekilde tüm tanımlanmış görevleri gerçekleştirmesini sağlayan bir dizi arayüz nesnesini, eylemi ve bunların ekran temsillerini tanımlar.

    Interface construction

    Kullanım senaryolarının değerlendirilmesini sağlayan bir prototip ile başlar ve inşaatı tamamlamak için geliştirme araçlarıyla devam eder.

    Interface validation

    Arayüzün her kullanıcı görevini doğru bir şekilde uygulama, tüm görev varyasyonlarını barındırma, tüm genel kullanıcı gereksinimlerini karşılama ve arayüzün kullanımı kolay ve öğrenmesi kolay olma derecesine odaklanır.

    User Interface Models

    Aşağıdaki dört model kullanıldığında bir kullanıcı arayüzü analiz edildiğinde ve tasarlandığında -

    User profile model

    • Sistemin son kullanıcılarının profilini yaş, cinsiyet, fiziksel yetenekler, eğitim, motivasyon, hedefler ve kişiliğe göre oluşturan bir kullanıcı veya yazılım mühendisi tarafından oluşturulmuştur.

    • Kullanıcının sözdizimsel ve anlamsal bilgisini göz önünde bulundurur ve kullanıcıları acemi, bilgili, aralıklı ve bilgili sık kullanıcılar olarak sınıflandırır.

    Design model

    • Yazılımın verilerini, mimarisini, arayüzünü ve prosedürel temsillerini içeren bir yazılım mühendisi tarafından oluşturulmuştur.

    • Gereksinimlerin analiz modelinden türetilmiştir ve sistem kullanıcısının tanımlanmasına yardımcı olan gereksinim şartnamesindeki bilgiler tarafından kontrol edilir.

    Implementation model

    • Arayüzün görünümü ve hissi üzerinde çalışan yazılım uygulayıcıları tarafından, sistem sözdizimini ve anlambilimini açıklayan tüm destekleyici bilgiler (kitaplar, videolar, yardım dosyaları) ile birlikte oluşturulmuştur.

    • Tasarım modelinin bir çevirisi olarak hizmet eder ve kullanıcının zihinsel modeliyle aynı fikirde olmaya çalışır, böylece kullanıcılar daha sonra yazılımla rahat hisseder ve onu etkili bir şekilde kullanır.

    User's mental model

    • Uygulamayla etkileşimde bulunurken kullanıcı tarafından oluşturulur. Kullanıcıların kafalarında taşıdıkları sistemin görüntüsünü içerir.

    • Genellikle, kullanıcının sistem algısı ve açıklamanın doğruluğu, kullanıcının profiline ve uygulama alanındaki yazılıma genel olarak aşinalığına bağlıdır.

    Kullanıcı Arayüzünün Tasarımıyla İlgili Hususlar

    Kullanıcı merkezli

    Bir kullanıcı arayüzü, bir ürünün geliştirme yaşam döngüsü boyunca kullanıcıları içeren, kullanıcı merkezli bir ürün olmalıdır. Bir kullanıcı arayüzünün prototipi, kullanıcılara açık olmalı ve kullanıcılardan gelen geri bildirimler nihai ürüne dahil edilmelidir.

    Basit ve Sezgisel

    UI, talimatlar olmadan hızlı ve etkili bir şekilde kullanılabilmesi için basitlik ve sezgisellik sağlar. GUI, menülerden, pencerelerden ve düğmelerden oluştuğu ve sadece fare kullanılarak çalıştırıldığı için, metinsel kullanıcı arayüzünden daha iyidir.

    Kullanıcıları Kontrol Altına Alın

    Kullanıcıları önceden tanımlanmış dizileri tamamlamaya zorlamayın. Onlara seçenekler verin - iptal etmek veya kaydetmek ve kaldıkları yere dönmek için. Arayüzün tamamında, sistem veya geliştirici terimleri yerine kullanıcıların anlayabileceği terimler kullanın.

    Kullanıcılara, eylemin sonuçlarını göstererek veya eylemin başarıyla gerçekleştirildiğini kabul ederek bir eylemin gerçekleştirildiğine dair bazı göstergeler sağlayın.

    Şeffaflık

    Kullanıcı arayüzünün şeffaf olması, kullanıcıların bilgisayar aracılığıyla doğrudan ulaştıklarını ve birlikte çalıştıkları nesneleri doğrudan manipüle ettiklerini hissetmelerine yardımcı olmalıdır. Arayüz, kullanıcılara sistem nesneleri yerine çalışma nesneleri verilerek şeffaf hale getirilebilir. Örneğin, kullanıcılar bir parolanın kaç bayt depolama alanı olması gerektiğini değil, sistem parolalarının en az 6 karakter olması gerektiğini anlamalıdır.

    Aşamalı açıklama kullanın

    Ortak özelliklere ve sık kullanılan eylemlere her zaman kolay erişim sağlayın. Daha az yaygın olan özellikleri ve eylemleri gizleyin ve kullanıcıların bunlarda gezinmesine izin verin. Her bilgiyi tek bir ana pencereye koymaya çalışmayın. Anahtar bilgi olmayan bilgiler için ikincil pencereyi kullanın.

    Tutarlılık

    UI, ürün içinde ve arasında tutarlılığı korur, etkileşim sonuçlarını aynı tutar, UI komutları ve menüler aynı formatta olmalı, komut noktalamaları benzer olmalı ve parametreler tüm komutlara aynı şekilde aktarılmalıdır. UI, kullanıcıları şaşırtabilecek davranışlara sahip olmamalı ve kullanıcıların hatalarından kurtulmalarına olanak tanıyan mekanizmaları içermelidir.

    Entegrasyon

    Yazılım sistemi, MS not defteri ve MS-Office gibi diğer uygulamalarla sorunsuz bir şekilde entegre olmalıdır. Veri alışverişini gerçekleştirmek için doğrudan Pano komutlarını kullanabilir.

    Bileşen Odaklı

    UI tasarımı modüler olmalı ve bileşen odaklı mimari içermelidir, böylece UI tasarımı, yazılım sisteminin ana gövdesinin tasarımıyla aynı gereksinimlere sahip olacaktır. Modüller, sistemin diğer kısımlarını etkilemeden kolayca değiştirilebilir ve değiştirilebilir.

    Özelleştirilebilir

    Tüm yazılım sisteminin mimarisi, birçok farklı kişinin yazılımı bağımsız olarak genişletmesine olanak tanıyan eklenti modülleri içerir. Bireysel kullanıcıların kişisel tercihlere ve ihtiyaçlara uyması için çeşitli mevcut formlar arasından seçim yapmasına olanak tanır.

    Kullanıcıların Bellek Yükünü Azaltın

    Kullanıcıları, bilgisayarın onlar için ne yapması gerektiğini hatırlamaları ve tekrarlamaları için zorlamayın. Örneğin, çevrimiçi formları doldururken, müşteri adları, adresleri ve telefon numaraları, bir kullanıcı girdikten sonra veya bir müşteri kaydı açıldığında sistem tarafından hatırlanmalıdır.

    Kullanıcı arayüzleri, kullanıcılara bilgileri geri çağırmak zorunda kalmadan tanımaları için öğeler sağlayarak uzun vadeli bellek alımını destekler.

    Ayrılık

    Yeniden kullanılabilirliği ve sürdürülebilirliği artırmak için kullanıcı arabirimi, uygulaması yoluyla sistemin mantığından ayrılmalıdır.

    Yinelemeli ve Artımlı Yaklaşım

    Aday çözümler üretmeye yardımcı olan beş ana adımdan oluşan yinelemeli ve artımlı bir yaklaşımdır. Bu aday çözüm, bu adımlar tekrarlanarak daha da geliştirilebilir ve sonunda uygulamamıza en uygun mimari tasarımı yaratabilir. Sürecin sonunda mimarimizi inceleyip ilgili tüm taraflara iletebiliriz.

    Bu sadece olası bir yaklaşımdır. Mimarinizi tanımlayan, gözden geçiren ve ileten daha birçok resmi yaklaşım vardır.

    Mimari Hedefi Belirleyin

    Mimari ve tasarım sürecini oluşturan mimari hedefi belirleyin. Kusursuz ve tanımlanmış hedefler mimariyi vurgular, tasarımdaki doğru problemleri çözer ve mevcut aşamanın ne zaman tamamlandığını ve bir sonraki aşamaya geçmeye hazır olduğunu belirlemeye yardımcı olur.

    Bu adım aşağıdaki etkinlikleri içerir -

    • Başlangıçta mimari hedeflerinizi belirleyin.
    • Mimarimizin tüketicisini tanımlayın.
    • Kısıtlamaları belirleyin.

    Mimari faaliyet örnekleri arasında, bir Web uygulaması için sipariş işleme kullanıcı arayüzünde geri bildirim almak için bir prototip oluşturmak, bir müşteri sipariş izleme uygulaması oluşturmak ve bir güvenlik incelemesi gerçekleştirmek için bir uygulama için kimlik doğrulama ve yetkilendirme mimarisi tasarlamak yer alır.

    Başlıca Senaryolar

    Bu adım, en önemli olan tasarıma vurgu yapar. Bir senaryo, bir kullanıcının sistemle etkileşiminin kapsamlı ve kapsayıcı bir açıklamasıdır.

    Temel senaryolar, uygulamanızın başarısı için en önemli senaryolar olarak kabul edilen senaryolardır. Mimari hakkında karar vermeye yardımcı olur. Amaç, kullanıcı, işletme ve sistem hedefleri arasında bir denge sağlamaktır. Örneğin, kullanıcı kimlik doğrulaması önemli bir senaryodur çünkü bunlar, bir kalite özniteliğinin (güvenlik) önemli işlevsellikle (bir kullanıcının sisteminize nasıl giriş yaptığı) kesişimidir.

    Uygulamaya Genel Bakış

    Mimariyi gerçek dünyadaki kısıtlamalara ve kararlara bağlayarak daha dokunulabilir hale getiren bir uygulamaya genel bakış oluşturun. Aşağıdaki faaliyetlerden oluşur -

    Uygulama Türünü Tanımlayın

    Uygulama türünün bir mobil uygulama, zengin bir istemci, zengin bir internet uygulaması, bir hizmet, bir web uygulaması veya bu türlerin bir kombinasyonu olup olmadığını belirleyin.

    Dağıtım Kısıtlamalarını Belirleyin

    Uygun bir dağıtım topolojisi seçin ve uygulama ile hedef altyapı arasındaki çakışmaları çözün.

    Önemli Mimari Tasarım Stillerini Belirleyin

    Bölümlemeyi iyileştirmek için istemci / sunucu, katmanlı, ileti yolu, etki alanına dayalı tasarım vb. Gibi önemli mimari tasarım stillerini belirleyin ve sık sık tekrar eden sorunlara çözümler sunarak tasarımın yeniden kullanımını teşvik edin. Uygulamalar genellikle bir stil kombinasyonu kullanır.

    İlgili Teknolojileri Belirleyin

    Geliştirmekte olduğumuz uygulama türünü, uygulama dağıtım topolojisi için tercih ettiğimiz seçenekleri ve mimari stilleri dikkate alarak ilgili teknolojileri belirleyin. Teknolojilerin seçimi ayrıca organizasyon politikaları, altyapı sınırlamaları, kaynak becerileri vb. Tarafından yönlendirilecektir.

    Önemli Sorunlar veya Önemli Sıcak Noktalar

    Bir uygulama tasarlanırken hataların en çok yapıldığı bölgeler sıcak noktalar. Kalite özelliklerine ve kesişen endişelere dayalı olarak temel sorunları belirleyin. Olası sorunlar arasında yeni teknolojilerin ortaya çıkışı ve kritik iş gereksinimleri yer alır.

    Kalite öznitelikleri, mimarinizin çalışma zamanı davranışını, sistem tasarımını ve kullanıcı deneyimini etkileyen genel özellikleridir. Kesişen endişeler, tasarımımızın tüm katmanlar, bileşenler ve katmanlar için geçerli olabilecek özellikleridir.

    Bunlar aynı zamanda yüksek etkili tasarım hatalarının en sık yapıldığı alanlardır. Kesişen endişelere örnek olarak kimlik doğrulama ve yetkilendirme, iletişim, yapılandırma yönetimi, istisna yönetimi ve doğrulama vb. Verilebilir.

    Aday Çözümler

    Temel etkin noktaları tanımladıktan sonra, ilk temel mimariyi veya ilk üst düzey tasarımı oluşturun ve ardından aday mimari oluşturmak için ayrıntıları doldurmaya başlayın.

    Aday mimari, uygulama türünü, dağıtım mimarisini, mimari stili, teknoloji seçeneklerini, kalite özelliklerini ve kesişen konuları içerir. Aday mimari bir gelişme ise, yeni aday mimarilerin yaratılabileceği ve test edilebileceği temel olabilir.

    Döngüyü yinelemeli olarak takip etmeden ve tasarımı geliştirmeden önce, aday çözüm tasarımını önceden tanımlanmış olan temel senaryolara ve gereksinimlere göre doğrulayın.

    Tasarımın belirli alanlarını keşfetmek veya yeni konseptleri doğrulamak için mimari sivri uçları kullanabiliriz. Mimari sivri uçlar, belirli bir tasarım yolunun fizibilitesini belirleyen, riski azaltan ve farklı yaklaşımların uygulanabilirliğini hızla belirleyen bir tasarım prototipidir. Mimari artışları önemli senaryolara ve sıcak noktalara karşı test edin.

    Mimari İnceleme

    Hataların maliyetini düşürmek ve mimari sorunları olabildiğince erken bulmak ve düzeltmek için mimari inceleme en önemli görevdir. Proje maliyetlerini ve proje başarısızlık olasılığını azaltmanın sağlam ve uygun maliyetli bir yoludur.

    • Mimariyi sık sık büyük proje kilometre taşlarında ve diğer önemli mimari değişikliklere yanıt olarak gözden geçirin.

    • Bir mimari incelemenin temel amacı, mimariyi doğru bir şekilde doğrulayan temel ve aday mimarilerin fizibilitesini belirlemektir.

    • Fonksiyonel gereksinimleri ve kalite özelliklerini önerilen teknik çözüme bağlar. Ayrıca sorunları belirlemeye ve iyileştirme alanlarını tanımaya yardımcı olur

    Senaryo temelli değerlendirmeler, iş açısından en önemli senaryolara odaklanan ve mimari üzerinde en büyük etkiye sahip olan bir mimari tasarımın gözden geçirilmesi için baskın bir yöntemdir.

    Yazılım Mimarisi Analiz Yöntemi (SAAM)

    Başlangıçta değiştirilebilirliği değerlendirmek için tasarlanmıştır, ancak daha sonra kalite niteliklerine göre mimariyi gözden geçirmek için genişletilmiştir.

    Mimari Ödünleşim Analiz Yöntemi (ATAM)

    Mimari kararları kalite nitelikleri gerekliliklerine ve belirli kalite hedeflerini ne kadar iyi karşıladıklarına göre gözden geçiren SAAM'ın parlak ve geliştirilmiş bir versiyonudur.

    Aktif Tasarım İncelemesi (ADR)

    Genel bir gözden geçirme yapmak yerine, bir seferde mimarinin bir dizi sorununa veya bağımsız bölümlerine daha fazla odaklanan tamamlanmamış veya devam eden mimariler için uygundur.

    Ara Tasarımların Aktif İncelemeleri (ARID)

    Devam eden mimariyi incelemenin ADR yönünü, bir dizi soruna odaklanarak ve kalite özelliklerine odaklanan senaryo tabanlı incelemenin ATAM ve SAAM yaklaşımını birleştirir.

    Maliyet Fayda Analizi Yöntemi (CBAM)

    Mimari kararların maliyetlerini, faydalarını ve zamanlama sonuçlarını analiz etmeye odaklanır.

    Mimari Seviye Değiştirilebilirlik Analizi (ALMA)

    İş bilgi sistemleri (BIS) için mimarinin değiştirilebilirliğini tahmin eder.

    Aile Mimarisi Değerlendirme Yöntemi (FAAM)

    Birlikte çalışabilirlik ve genişletilebilirlik için bilgi sistemi aile mimarilerini tahmin eder.

    Mimari Tasarımın İletişimi

    Mimari tasarımı tamamladıktan sonra, tasarımı geliştirme ekibi, sistem yöneticileri, operatörler, işletme sahipleri ve diğer ilgili tarafları içeren diğer paydaşlara iletmeliyiz.

    Mimariyi başkalarına tanımlamak için aşağıdaki iyi bilinen birkaç yöntem vardır: -

    4 + 1 Model

    Bu yaklaşım, tüm mimarinin beş görünümünü kullanır. Bunların arasında dört görüş (logical view, process view, physical view, ve development view) mimariyi farklı yaklaşımlardan tanımlar. Beşinci görünüm, yazılım için senaryoları ve kullanım durumlarını gösterir. Paydaşların, özellikle kendilerini ilgilendiren mimarinin özelliklerini görmelerini sağlar.

    Mimari Açıklama Dili (ADL)

    Bu yaklaşım, sistem uygulamasından önce yazılım mimarisini tanımlamak için kullanılır. Aşağıdaki endişeleri giderir - davranış, protokol ve bağlayıcı.

    ADL'nin temel avantajı, tasarımı resmi olarak kullanmaya başlamadan önce mimariyi bütünlük, tutarlılık, belirsizlik ve performans açısından analiz edebilmemizdir.

    Çevik Modelleme

    Bu yaklaşım, "içerik temsilden daha önemlidir" kavramını izler. Oluşturulan modellerin basit ve anlaşılması kolay, yeterince doğru, ayrıntılı ve tutarlı olmasını sağlar.

    Çevik model, belirli müşterileri hedefler ve bu müşterinin çalışma çabalarını yerine getirir. Belgenin basitliği, yapının modellenmesine paydaşların aktif katılımını sağlar.

    IEEE 1471

    IEEE 1471, resmi olarak ANSI / IEEE 1471-2000, "Yazılım Yoğun Sistemlerin Mimari Tanımlaması için Önerilen Uygulama" olarak bilinen bir standardın kısa adıdır. IEEE 1471, özellikle bağlama, görüşlere ve bakış açılarına özel bir anlam vererek bir mimari tanımlamanın içeriğini geliştirir.

    Birleşik Modelleme Dili (UML)

    Bu yaklaşım, bir sistem modelinin üç görünümünü temsil eder. functional requirements view (kullanım durumları dahil, kullanıcının bakış açısından sistemin işlevsel gereksinimleri); the static structural view(sınıf diyagramları dahil nesneler, nitelikler, ilişkiler ve işlemler); vedynamic behavior view (nesneler arasında işbirliği ve sıra, etkinlik ve durum diyagramları dahil olmak üzere nesnelerin iç durumundaki değişiklikler).

ja/tutorial
es/tutorial
de/tutorial
fr/tutorial
th/tutorial
pt/tutorial
ru/tutorial
vi/tutorial
it/tutorial
ko/tutorial
tr/tutorial
id/tutorial
pl/tutorial
hi/tutorial
japost
espost
depost
frpost
thpost
ptpost
rupost
vipost
itpost
kopost
trpost
idpost
plpost
hipost

© Copyright 2021 - 2024 | All Rights Reserved