Anahtar İlkeler
Yazılım mimarisi, sistemin tanımlanan işlevleri yerine getiren 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 bağlayıcıları (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 rutin ç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 sisteminin kullanımını açıklar. |
Servis Odaklı Mimari (SOA) | Sözleşmeleri ve mesajları kullanarak 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ı | Etki 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 ortaya çı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 kuruluştaki 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, bunların etkileşimleri ve kuruluşun iş süreçleriyle olan ilişkileri için bir şablon 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 - Organizasyonun 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.
Sorunu net bir şekilde anlamadan, 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 çözmedikleri 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 işlevsel 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 oluşturulmalı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, stilleri veya desenleri 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şleçlerini 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:
Son Yapmak 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şen işlevselliği arasında örtüşme olmaz. Bu, yüksek kohezyon ve düşük birleşme 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
Tekrar etmeyin işlevi, bileşenlerin işlevselliğinin tekrarlanmaması gerektiğini ve dolayısıyla bir kod parçasının yalnızca bir bileşende uygulanması gerektiğini belirtir. Bir uygulama içindeki işlevselliğin tekrarlanması, 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 Katmanlar halinde 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ı olacaktır. Aynı katmanda farklı türden sorunları karıştırmaktan kaçının.
Katmanlar Arası İletişim Protokolünü Tanımlayın
Bileşenlerin birbirleriyle nasıl iletişim kuracağını anlayın, bu da dağıtım senaryoları ve üretim ortamı hakkında eksiksiz bir bilgi gerektirir.
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.