Çok Dişli Uygulamaların UML Diyagramları


25

Tek iş parçacıklı uygulamalar için, bu uygulamanın mimarisine genel bir bakış için sınıf diyagramları kullanmayı seviyorum. Bununla birlikte, bu tür bir şema çok fazla iş parçacıklı / eşzamanlı uygulamaları anlamaya çalışırken çok yardımcı olmamıştır, örneğin farklı iş parçacıklarında "canlı" bir sınıfın farklı örnekleri (bir örneğe erişim yalnızca bir örnekten tasarruf edilir) yaşadığı iplik). Sonuç olarak, sınıflar arasındaki ilişkilerin mutlaka bu nesnelere yöntem çağırabileceğim anlamına gelmez, bunun yerine hedef nesnenin iş parçacığında bu çağrıyı yapmam gerekir.

Eşzamanlı, Dağıtılmış ve UML ile Gerçek Zamanlı Uygulamaları Tasarlamak gibi konularda Hassan Gomaa tarafından tasarlanan çoğu literatür, konu sınırlarını nesne diyagramlarına çizme gibi bazı güzel fikirlere sahipti, ancak genel olarak biraz akademik ve endişe verici görünüyordu. gerçekten faydalı ol.

Bu şemaları problem alanının üst düzey bir görüntüsü olarak kullanmak istemiyorum, bunun yerine sınıflarım / nesnelerimin, etkileşimlerinin ve yukarıda bahsettiğim iplik sınırlarından kaynaklanan sınırlamaların ayrıntılı bir açıklaması olarak kullanmak istemiyorum.

Bu nedenle bilmek istiyorum:

  1. Çok iş parçacıklı uygulamaları anlamada en çok ne tür diyagramlar buldunuz?
  2. Çok iş parçacıklı uygulamaların özelliklerini göz önünde bulunduran klasik UML uzantıları var mı, örneğin bunu gösteren ek açıklamalar
    • bazı nesneler belirli bir iş parçacığında yaşayabilirken, diğerlerinde iş parçacığı yakınlığı yoktur;
    • bir nesnenin bazı alanları herhangi bir diziden okunabilir, ancak yalnızca bir kişiden yazılabilir;
    • Bazı yöntemler senkronizedir ve bir sonuç verirken, diğerleri sıraya alınır ve sonuçları farklı bir iş parçacığında geri çağırma yoluyla döndürürken eşzamansız olur.

2
Kişisel olarak eşzamanlı kullanım durumlarını / süreçlerini modellemek için (potansiyel olarak) etkinlik diyagramları buldum, ancak sınıf / nesne seviyesine inmek istiyorsanız gerçekten uygun değiller.
Péter Török

Yanıtlar:


12

İplik işlemlerinin nasıl gerçekleştiğine dair en önemli içgörü, sıralama diyagramı olarak bilinen şeyle gösterilebilir . İşte wikipedia'dan bir örnek

görüntü tanımını buraya girin

Bu şema temel olarak, genellikle yaşam çizgisi adı verilen dikey bir tek çizginin üzerindeki bir yön ile birlikte olayların listesini çizer . Bu durumda, her iş parçacığı kendi yaşam çizgisinin sahibidir. Diyagram, senkron, asenkron vb. Gibi her türlü olayın temsilini sağlar.

Bu tür sistemlerdeki diğer en önemli şey durum çizelgeleri veya durum çizelgeleridir. Genellikle, bu model yalnızca bir durum makinesi olarak temsil edilirse uygulanır. Bununla birlikte, çok dişli sistemlerin çoğunda (dişlerin önemsiz olmadığı yerlerde), farklı durumlar için izole edilmiş algoritmalarla çalışmak üzere tasarlanması en iyisidir.

Etkileşim şeması ve iletişim şeması gibi başka şema türleri de var, ancak sıra şeması çizmeye çalışmak ve durum şemaları azami netlik sağlayacak.


6

Cevabım Dipan'ın UML dizilim diyagramlarını içerdiği için tamamlayıcı . % 100 saf UML olmayan bir stilin de iyi olduğunu buldum. Eşzamanlılık Modellerinde kullanılan diyagramlara bir göz atın . Bazıları neredeyse UML benzeridir (ancak bu kesinlikle standart değildir):

görüntü tanımını buraya girin

Java iş parçacığı senkronizasyonunda bekle / bildir ile ilgili bilginiz varsa, bahsettiğim belgeden aşağıdaki sıra şemasını beğeneceksiniz:

görüntü tanımını buraya girin


Bu, .NET / C # için de geçerlidir ve Visual Studio, çok iş parçacıklı davranışları tanımlamak için kontrol akışı parçası türlerini içeren yerleşik takım oluşturma UML dizisi diyagramına sahiptir. Bkz. Msdn.microsoft.com/en-us/library/dd465153.aspx#Anchor_1
David Burg

0

Aynı sınıfı kullanan çoklu iş parçacıklı uygulamalar için püf noktası, aynı sınıfı bir ipliği temsil eden her modele sürükleyip bırakmak olabilir. Sınıf, diyagram veya kodu tıklatarak aynı sınıfa farklı görünümlerde sahip olabilir ve model ve kodda gezinebilirsiniz. Model birleşmenin iyi bilinen bir kavram olmadığını biliyorum ama Omondo ile Eclipse içinde gerçekten iyi çalışıyor.

Demek istediğim, birden fazla projeden oluşan büyük bir uygulamayı modellerken. Her proje için bir model yaratıyorum ve sonra daha büyük bir projenin içinde birleştiriyorum. Tüm modelleme, tüm projeyi java kodundan UML'ye çevirirken aldığım model olan sınıf diyagramları kullanılarak yapılır. Benim örneğimde mevcut kodu kullanıyorum ve onu tek bir UML modeline tersine çeviriyorum ve daha sonra UML modellerini oluşturan tek bir büyük modele dönüştüren tüm bu ters kodu birleştiriyorum. Ayrıca mevcut kodu tersine çevirmek yerine birden fazla model oluşturabilirsiniz. Her iki şekilde de çalışır - kodsuz yaratmada veya mevcut kodla ters mühendislik aşamasında.

Mantıklı olup olmadığını bilmiyorum ama belki çok projeli modelleme ile yaptığım gibi her iş parçacığı için alt modelleri yeniden toplayarak büyük bir model yaratabilirsiniz. Umarım bu yardım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.