4 + 1 mimari görünüm modeli ve UML arasında haritalama

4 + 1 mimari görünüm modelinin UML ile nasıl eşleştiği konusunda biraz kafam karıştı.

Wikipedia aşağıdaki eşlemeyi verir:

• Mantıksal görünüm: Sınıf diyagramı, İletişim diyagramı, Sıra diyagramı.
• Geliştirme görünümü: Bileşen şeması, Paket şeması
• İşlem görünümü: Faaliyet diyagramı
• Fiziksel görünüm: Dağıtım şeması
• Senaryolar: Kullanım senaryosu diyagramı

Nesne Yaşam Döngüsü Kavramında UML Sekans Diyagramı Yapılarının kağıt rolü aşağıdaki eşlemeyi verir:

• Mantıksal görünüm (sınıf diyagramı (CD), nesne diyagramı (OD), dizi diyagramı (SD), işbirliği diyagramı (COD), durum grafiği diyagramı (SCD), aktivite diyagramı (AD))
• Geliştirme görünümü (paket diyagramı, bileşen diyagramı),
• Proses görünümü (kullanım senaryosu, CD, OD, SD, COD, SCD, AD),
• Fiziksel görünüm (dağıtım şeması) ve
• Yukarıda belirtilen dördü birleştiren vaka görünümünü kullanın (vaka diyagramı, OD, SD, COD, SCD, AD).

UML 4 + 1 Malzeme Görüntüle web sayfası aşağıdaki eşlemeyi sunar:

Son olarak, UML 2 ile 4 + 1 View Architecture uygulayan teknik inceleme başka bir harita daha verir:

• Mantıksal görünüm sınıf diyagramları, nesne diyagramları, durum grafikleri ve kompozit yapılar
• Süreç görünümü dizi diyagramları, iletişim diyagramları, aktivite diyagramları, zamanlama diyagramları, etkileşime genel bakış diyagramları
• Geliştirme görünümü bileşen diyagramları
• Fiziksel görünüm dağıtım diyagramı
• Kullanım örneği görünümü kullanım örneği diyagramı, etkinlik diyagramları

Daha fazla aramanın diğer eşlemeleri de göstereceğinden eminim.

Çeşitli insanlar genellikle farklı bakış açılarına sahip olsa da, bunun neden böyle olduğunu anlamıyorum. Özellikle, her UML diyagramı sistemi belirli bir açıdan açıklar. Öyleyse, örneğin, "dizi diyagramı" neden bir yazar tarafından sistemin "mantıksal görünümünü" açıklarken, bir başka yazar "süreç görünümünü" tanımladığını düşünüyor?

Karışıklığı netleştirmeme yardım eder misiniz?

Her ne kadar Bart van Ingen Schenau'nun cevabına genel olarak katılıyorum , ancak birkaç noktanın ek ayrıntıya ihtiyacı olduğunu düşünüyorum.

4 + 1 Görünüm Modelinin avantajı, belirli modelleme gösterimlerinin kullanılmasına gerek kalmadan paydaşları ihtiyaç duydukları bilgi türüyle eşleştirmesidir. Vurgu, tüm grupların sistemi anlama ve işlerini yapmaya devam etme bilgisine sahip olmasını sağlamaktır.

Yazılım Mimarisinin 4 + 1 Görünüm Modeli, Philippe Kruchten'in IEPE Yazılımında (Kasım 1995) yayınlanan Yazılım Mimarisinin "4 + 1" Yazılım Modelini Görüntüle Modelinde tanımlanmıştır . Bu yayın UML'ye özel referanslar yapmıyor. Aslında, kağıt kullanan Booch notasyonu mantıksal görünümü için, süreç görünümü ve geliştirme görünümü için Booch gösterimde uzantıları, fiziksel görünüm geliştirme "birkaç şekilleri" ve senaryoları için yeni bir gösterimde kullanılmasını sesleniyor.

Her bir görünümü belirli diyagram türleriyle eşlemeye çalışmak yerine, her bir görünümün hedef kitlesinin kim olduğunu ve hangi bilgilere ihtiyaç duyduklarını düşünün. Bunu bilerek, çeşitli model türlerine ve hangilerinin gerekli bilgileri sağladığına bakın.

Mantıksal görünüm, son kullanıcının istediği tüm işlevlerinin sistem tarafından yakalanmasını sağlama konusundaki endişelerini gidermek üzere tasarlanmıştır. Nesneye yönelik bir sistemde bu genellikle sınıf düzeyindedir. Karmaşık sistemlerde, bir paket görünümüne ihtiyacınız olabilir ve paketleri birden çok sınıf diyagramına ayırabilirsiniz. Diğer paradigmalarda, modülleri ve sağladıkları işlevleri temsil etmek ilginizi çekebilir. Sonuç, gerekli işlevselliğin bu işlevselliği sağlayan bileşenlerle eşleştirilmesi olmalıdır.

Süreç görünümü, tüm sistemi tasarlayan ve daha sonra alt sistemleri veya sistemi bir sistem sistemine entegre eden kişiler için tasarlanmıştır. Bu görünüm, sistemin sahip olduğu görevleri ve işlemleri, dış dünyaya ve / veya sistem içindeki bileşenler arasında arabirimlere, gönderilen ve alınan iletilere ve performans, kullanılabilirlik, hataya dayanıklılık ve bütünlüğün nasıl ele alındığını gösterir.

Geliştirme görünümü öncelikle modülleri ve alt sistemleri inşa edecek geliştiriciler içindir. Modüller arasındaki bağımlılıkları ve ilişkileri, modüllerin nasıl düzenlendiğini, yeniden kullanıldığını ve taşınabilirliğini göstermelidir.

Fiziksel görünüm, öncelikle yazılımın fiziksel konumlarını, düğümler arasındaki fiziksel bağlantıları, dağıtım ve kurulum ve ölçeklenebilirliği anlaması gereken sistem tasarımcıları ve yöneticileri içindir.

Son olarak, senaryolar gereklilikleri yakalamaya yardımcı olur, böylece tüm paydaşlar sistemin nasıl kullanıldığını anlarlar.

Her bir görünümün ne sağlaması gerektiğini anladıktan sonra, hangi modelleme notasyonlarının kullanılacağını ve hangi ayrıntı düzeyinde gerekli olacağını seçebilirsiniz. Bart'ın son paragrafı özellikle doğrudur - UML modellerinizde belirli tasarım öğelerine odaklanarak veya çeşitli diyagram türlerini bir kümede birleştirerek çeşitli düzeylerde ayrıntılar gösterebilirsiniz. Ayrıca, sistem mimarinizi ( SysML , Varlık İlişkisi modelleme veya IDEF) daha iyi tanımlamak için UML'nin ötesine geçerek diğer modelleme gösterimlerine geçmeyi düşünebilirsiniz .

4 + 1 Mimari Modelin görünümleri ile çeşitli UML diyagramları arasında bire bir eşleme bulamamanızın nedeni, böyle bir eşlemenin mevcut olmamasıdır.

Tüm bu yazarların 'eşlemeleri' ile anlatmaya çalıştıkları, her görünüm için, o görünümde anlatmak istediğiniz bilgileri iletmek için yararlı olabilecek farklı bir UML diyagramları setinin olmasıdır.

Ek olarak, bazı UML diyagramları, diyagramdaki farklı öğeleri vurgulayarak farklı şekillerde kullanılabilir, bu da onları birden çok görünüm için yararlı kılar. Ancak bir UML diyagram türü birden çok görünümde kullanılabilse bile, her görünüm için farklı bir diyagram (veya diyagram kümesi) çizersiniz.

Her ne kadar Thomas Owens'ın son kullanıcılarınızın ihtiyaçlarını karşılamaya yönelik yaklaşım yaklaşımını kabul etsem de , belirtilemeyen bir şey, Kruchten'in "4 + 1 Görünüm Modeli Mimarisi" nin orijinal tanımının herhangi bir şey yapmamasının nedeni UML'ye özel referanslar, makalenin 1995'te (cevap durumları olarak) yazıldığı, ancak UML'nin 1997'ye kadar gerçekten bir standart olarak kabul edilmemesidir .

Makalede Booch Notasyonunun sürekli kullanımı, model görünümlerinin her birinin belirli bir UML diyagramına bağlanmasının uygun olabileceğini düşündürmektedir, çünkü Grady Booch UML'nin geliştirilmesinde yer alan kişilerden biriydi.

Bu nedenle, birçok farklı yazar, her bir görünüm için farklı UML diyagramlarının uygulanabilir olduğunu düşünmektedir, çünkü 4 + 1 modelinin orijinal tanımının dayandığı Booch Notasyonunun bir miktar "soyutlaması" olarak birden fazla UML diyagramı düşünülebilir. her bir görünümü temsil eder.

Umarım bu, bunu yapan herkes için işleri biraz daha temizler.

1995'te satın aldığınız VCR'yi hala kullanıyor musunuz? 4 + 1 yazılım bebeklik dönemindeyken uygulanabilirdi. Ama o zaman bile, hiç kimse 2 veya 3'ten fazla "görüş" kullanmamıştır. Son 20 yılda yazılım mühendisliği değişti. Günümüzde kapsam / bağlam ve kavramsal ve mantıksal ve fiziksel ve ... hepsi farklıdır. Bir çok COTS çözümü entegre edilmeli vb. Bugün, peyzaj haritaları, hizmet gerçekleştirmeleri ve düzinelerce başka görüş ve görüşten bahsediyoruz. Buna bakmanın en iyi yolu Zachman gibi basit bir sınıflandırma çerçevesinden geçmektir: 6 görünüm ve 6 bakış açısı. Bırakın başlangıç ​​noktanız olsun. 6 görüşler şunlardır: içeriksel kavramsal veya iş mantığı veya sistem fiziksel veya teknoloji teslimi veya işletmeyi işleyen eserler

6 bakış açısı: veri veya ne işlevi veya nasıl ağ veya nerede insanlar veya kim zaman veya ne zaman motivasyon veya neden

Bir örnek verelim. Yalnızca verilerle ilgileniyorsak, kapsam görünümü ile başlayıp "Kapsamımız CRM'dir" diyoruz. Veri bakış açısı için kavramsal görünümde CRM için bazı semantik bir model geliştireceğiz. Model kavramsal, veri nesneleri yerine iş bilgisi kavramları olacaktır. Daha sonra, mantıksal görünümde kavramsal CRM modelimizden mantıksal veri modeli üreteceğiz. ER metodolojisini mantıksal veri modeli üretmek için kullanabiliriz. Ardından, fiziksel görünümde, fiziksel veri modeli üreteceğiz. Burada, bizim seçim, dizinler vb db platformu için somut veri türleri tanımlayacağız. Son olarak, teslimat görünümünde DDL betiğimiz olacak, işleyen kurumsal görünümünde bazı veritabanı sunucusunda konuşlanmış bir ikili dosya olacak ve DBM satıcısının dahili veri yapılarına eşlendi. Bunu her bakış açısı veya sütun için tekrarlıyoruz. Ayrıca, birden fazla paydaş varsa, her bir bakış açısı / görünüm kombinasyonu için birden fazla model oluşturacağız. Artık bu sınıflandırmaya sahip olduğunuza göre, kendi bakış açılarınızı ve görüşlerinizi tanımlayabilir ve bunları bu sınıflandırma ile hizalayabilirsiniz. Örneğin, kurumsal düzey girişimler için aşağıdaki bakış açılarının hepsi önemlidir: aktör işbirliği uygulama davranışı uygulama işbirliği uygulama yapısı uygulama kullanımı iş fonksiyonu iş süreci işbirliği süreci ve dağıtım bilgi yapısı altyapı altyapı kullanımı peyzaj haritası genel bakış katmanlı organizasyonel hizmet gerçekleştirme vb. Artık bu sınıflandırmaya sahip olduğunuza göre, kendi bakış açılarınızı ve görüşlerinizi tanımlayabilir ve bunları bu sınıflandırma ile hizalayabilirsiniz. Örneğin, kurumsal düzey girişimler için aşağıdaki bakış açılarının hepsi önemlidir: aktör işbirliği uygulama davranışı uygulama işbirliği uygulama yapısı uygulama kullanımı iş fonksiyonu iş süreci işbirliği süreci ve dağıtım bilgi yapısı altyapı altyapı kullanımı peyzaj haritası genel bakış katmanlı organizasyonel hizmet gerçekleştirme vb. Artık bu sınıflandırmaya sahip olduğunuza göre, kendi bakış açılarınızı ve görüşlerinizi tanımlayabilir ve bunları bu sınıflandırma ile hizalayabilirsiniz. Örneğin, kurumsal düzey girişimler için aşağıdaki bakış açılarının hepsi önemlidir: aktör işbirliği uygulama davranışı uygulama işbirliği uygulama yapısı uygulama kullanımı iş fonksiyonu iş süreci işbirliği süreci ve dağıtım bilgi yapısı altyapı altyapı kullanımı peyzaj haritası genel bakış katmanlı organizasyonel hizmet gerçekleştirme vb.

Krutchen'in 4 + 1'i tüm bu ihtiyaçları karşılayamadı