Mimari Modelleri
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.