Bu yazımda sizlere, UML içindeki aktivite
diyagramlarını açıklayacağım. Aktivite diyagramlarının ne tür durumlarda
kullanıldığını, içerdiği özel sembolleri ve avantajlarını göstererek, nasıl oluşturabileceğimizi
bir örnek üzerinde göreceğiz.
"Aktivite" Diyagramları
Aktivite diyagramları, UML ile ilgili kaynaklarda en az açıklanan diyagramlardandır. Birçok kaynakta; algoritma tasarlarken kullandığımız akış diyagramlarının (flowchart) UML uyumlu hali olarak ifade edilmektedir. Ancak; aktivite diyagramlarını bu şekilde kısıtlı bir kullanım alanı ile açıklamak sahip olduğu zenginlikten yararlanmamızı engellemektedir. Bu yazıda UML diyagramlarını kullanmak için Rational Rose tasarım aracı kullanılacaktır.
UML için bu diyagramların spesifikasyonları oluşturulurken; birçok teknikten yararlanılmıştır. Bu teknikler; Petri ağları (Yazılım Mühendisliği konusu ile ilgilenenlerin birçok kaynakta rastlayabileceği), durum (state) modelleme teknikleri, Jim Odell in olay (event) diyagramları, iş akışı (workflow) modelleme teknikleri ve akış diyagramları olarak sıralanabilir. Bu kadar fazla tekniği kendi içinde barındıran bu diyagramları tüm detayları ile açıklamak ve örneklendirmek için tek başına bir kitap yazılabilir ancak bu yazıda, uygulamalarınızda kullanabileceğiniz önemli özellikleri açıklamaya çalışacağım.
Nerelerde kullanılabilir?
Aktivite diyagramlarını ilk kez gören bir tasarımcı, bu diyagramların akış diyagramlarından sadece gösterim olarak farkının bulunduğunu söyleyebilir. İki diyagram arasındaki belki de en temel fark; aktivite diyagramlarının "paralel" davranışları desteklemesi olarak açıklanabilir. Çok parçacıklı (multithreaded) uygulamalar geliştiriyor ve bu uygulamaların algoritmik mantığını UML ile göstermek istiyorsanız bu diyagramlar sizin işinize yarayacaktır. İş akışını, bir süreci veya karmaşık bir algoritmayı UML ile modellemek istiyorsanız yine bu diyagramları kullanabilirsiniz. Aktivite diyagramları sayesinde iş süreçlerini gözden geçirerek, gereksiz şekilde
ardışık yapılan işlemleri paralel olarak yapabileceğinizi belirleyebilirsiniz. Ayrıca; bir veya daha fazla kullanım senaryosunun (use case) ayrıntılarını bu diyagramlar sayesinde ortaya koyabilirsiniz.
Algoritmalarınızda çok fazla mantıksal işlem varsa; bu diyagramların görünümünü bozabilirsiniz. Bu nedenle; bu tür durumlarda doğruluk tablosu (truth table) oluşturmanın da yararını düşünmelisiniz.
Aktivite diyagramlarında bazı aktivitelerin paralel olarak gösterilmesi, bu aktivitelerin paralel yapılmak zorunda olduğunu göstermez. Sadece, aktivitelerin sıra ilişkisi içermediğini belirtir. Örneğin; kendinize kahve hazırlarken fincanınıza önce kahve, sonra şeker, daha sonra da sıcak su ilave etmek yerine önce sıcak su, sonra kahve ve en sonunda şeker koyabilirsiniz. Geliştirme ortamınız o an için paralel aktiviteleri desteklemese bile, bu aktiviteleri diyagramlarınızda paralel olarak göstermek sizlere ilerisi için yarar sağlayacaktır. UML 1x içinde bu diyagramlar, durum diyagramları ile çok fazla ilişkilendirilmişti. UML 2 ile birlikte bu bağlılık ortadan kaldırılmış ve bu diyagramlar, tasarımlarda daha fazla tercih edilmeye başlanmıştır. Aynı zamanda; bu diyagramları, UML 2 ile birlikte en fazla değişikliğe uğramış diyagramlar olarak ifade etmek mümkündür.
Ne zaman aktivite diyagramı, ne zaman durum diyagramı?
Sistemin yaşamı boyunca alabileceği tüm durumlar "durum diyagramı" ile belirtilirken, ilgili durumda yapılması gereken aktiviteler "aktivite diyagramı" sayesinde ortaya konur. Aktivite diyagramları; bir davranışın giriş ve çıkışlarını göstermektedir. Oluşturacağınız modelde; giriş ve çıkışlar önemliyse "aktivite diyagramlarını" tercih etmek durumundasınız. "Durum diyagramları" ise; olaylara verilen tepkileri daha etkin biçimde göstermektedir. Giriş/çıkışın önemli olmadığı, durumların daha önemli olduğu senaryolarda "durum diyagramlarını" tercih edebilirsiniz.
Detaylara geçmeden önce bir örnek üzerinde aktivite diyagramlarını görelim. Rational Rose tasarım aracı ile aktivite diyagramı çizebilmek için; öncelikle bir kullanım senaryosu oluşturulur. Kullanım senaryosuna farenin sağ tuşu ile tıklayarak, alt diyagramlar menüsünden (sub diagrams) yeni aktivite diyagramı (new activity diagram) seçilir. Bu örnekte; bir müşterinin kahve istediğini varsayalım. Bu aşamada gerekli olan "kahvehazirla" kullanım senaryosunu detaylandırmak için basit bir aktivite diyagramı çizeceğiz. Şekil 1de kullanım senaryosu, Şekil 2de ise aktivite diyagramı gösterilmektedir.
Şekil 1: Kullanım Senaryosu
Şekil 2: Aktivite Diyagramı
Şekil 2de aktivite diyagramlarını basit olarak açıklamak için, "kahve hazırlama" kullanım senaryosu aktiviteler ile detaylandırılmıştır. Şeklin en üstündeki içi dolu siyah daire, aktivite diyagramının başlangıcını göstermektedir. Tüm aktivite diyagramlarında böyle bir başlangıç noktası bulunmak zorundadır. Şeklin en altında bulunan, içi dolu siyah daireyi kapsayan daire ise bitiş noktası olarak ifade edilir. Fowler ve Scott; bitiş noktalarını zorunlu kılmamıştır ancak diyagramların okunurluğunu kolaylaştırmaktadır.
Başlangıç noktasından "suyu kaynat" aktivitesine doğru çizilen oka UML içinde geçiş (transition) adı verilmektedir. "Suyu kaynat", "fincana suyu dök", "kahveyi fincana ekle", "şekeri fincana ekle", "içeriği karıştır", "şeker ekle", "servis yap" ile gösterilen işlemler ise aktivite olarak tanımlanmaktadır. "içeriği karıştır" aktivitesinden sonra; akış diyagramlarında kullandığımız karar noktasının (decision point) yer aldığını görmektesiniz. İçeriğin tadına göre bir kontrolün yapıldığı bu baklava diliminin solunda ve sağında, köşeli parantezler içerisinde açıklamalar yazmaktadır. Akış diyagramlarından farkı, baklava içerisine herhangi bir açıklamanın yazılmamasıdır. Baklava diliminden çıkan geçişler üzerindeki ( [ifade] ) bu açıklamalara, koruma (guard) adı verilmektedir. Bir geçiş üzerinden geçebilmek için üzerindeki koruma ifadesi doğru değerde olmalıdır. Çıkıştaki koruma değerleri birbiri ile çelişmemeli, aynı durumları kapsamamalıdır. Koruma (guard) kullanmak; şekillerinize katkı sağlıyorsa tercih edilmelidir. Bir süreci modellerken işinize yaramayabilirken bir algoritmanın açıklanmasında faydalı olabilmektedir. Ayrıca; şeklinizi karmaşıklaştırmamak için, karar noktalarının sayısını azaltmakta fayda vardır. Örneğin; 2 tane karar noktası koymak yerine, çıkışta 3 geçiş oluşturarak 1 tane karar noktası ile şekli basitleştirebilirsiniz.
Önceden de açıkladığımız gibi; fincana suyun, şekerin, kahvenin eklenmesi işlemleri arasında bir ardışıllık olmadığı için bu aktiviteleri paralel olarak gösterebiliriz. Bu paralel aktiviteler, birbirine paralel 2 çizgi arasında gösterilmiştir. İlk çizgiye çatal (fork), ikinci çizgiye ise birleşme (join) adı verilmektedir. Genel olarak; her çatala ilişkin bir birleşme noktası bulunmalıdır. Çatalın girişindeki bir süreç (proses), birden fazla parçacığı (thread) başlatabilir. Çatalların girişinde sadece 1 tane geçiş bulunurken çıkışında 2 veya daha fazla geçiş bulunabilir. Birleşme çizgisinin girişinde ise, 2 veya daha fazla geçiş yer alırken; çıkışında tek bir geçiş bulunmalıdır. Aynı çatalın girişinde birden fazla geçişin (transition) olmasını istiyorsanız, bu geçişleri bir baklava dilimi ile birleştirilmesiniz.
Aktivite diyagramının sağ tarafında; diyagramın adı, kim tarafından oluşturulduğu, oluşturulma tarihi not (note) adı verilen sembol içerisinde gösterilmektedir.
Aktivite diyagramlarında dikkatinizi bir noktaya çekmek istiyorum. Bu diyagramlar size neler olup bittiğini gösterirken, bu işlemleri kimin gerçekleştirdiği bilgisini sunmamaktadır. Bu durumda; bu diyagramları koda dönüştürmeye çalıştığınız zaman; ilgili aktivite için hangi sınıfı kullanmanız gerektiği bilgisini elde edemeyeceksiniz. Farklı bölümlerin ortaklaşa çalışarak ortaya koyduğu bir süreci, bu diyagramlar ile modellediğiniz durumda; hangi aktiviteyi hangi bölümün gerçekleştireceğini modelinize tanıtamayabilirsiniz. Basit bir çözüm olarak her aktiviteyi bir sınıfla (class) ya da bir bölümle etiketleyebilirsiniz. Bu çözüm sonuç verecektir ancak şeklinizin karışmasına yol açabilir.
UML içindeki kulvar (swimlane) bu kapsamda kullanılmaktadır. Aktivite diyagramları bu amaçla dikey bölgelere ayrılmaktadır. Her alan belirli bir sınıfın ya da bölümün sorumluluğunu göstermektedir. Ancak; bu şekilde bir çözüm de etkileşim (interaction) diyagramları kadar basit bir sonuç vermemektedir. UML 1.xde kulvar (swimlane) kavramı kullanılırken UML 2de bu kavram yerini bölmeleme (partition) kavramına bırakmıştır. Ancak; amaç ve gösterimde bir değişiklik olmamıştır. Örneğin; yönetimin bir çalışana prim vermeye karar vermesiyle birlikte, basit olarak etkileşimde bulunan bölümleri Şekil 3deki gibi gösterebiliriz.
Şekil 3: UML içinde bölmeleme
Bölmeleme için kullandığımız çizgileri dikey olarak gösterebileceğimiz gibi, yatay olarak da gösterebiliriz. Paralel aktiviteleri göstermek için kullandığımız çizgileri de yatay olarak göstermek mümkündür. Kulvarlar (swimlane), doğrusal süreçlere kolaylıkla uygulanmaktadır. Uygulamalarınızda çok fazla sayıda dikey çizgi kullanmak şeklinizi büyütebilir, uygulamada 5i geçmemelidir.
Rational Rose for c++ tasarım aracının 2002 yılındaki versiyonunda buraya kadar açıklanan kavramlar desteklenmektedir. Ancak; UML içerisinde aktivite diyagramlarında kullanılabilecek daha fazla sayıda kavram mevcuttur. Bu aşamadan sonra; açıklanan kavramlar Rational Rose - 2002 versiyonunda yer almamaktadır. Yukarıda açıklanan kavramları kullanarak; kolaylıkla aktivite diyagramlarınızı oluşturabilirsiniz.
Bir aktiviteyi alt aktivitelere ayırmak da mümkündür. Aktivitenin iç yapısını aktivite içinde gösterebilir veya kompozit aktivite olarak kullanabilirsiniz. Alt aktivite içeren aktivitenin yanına, bu özel durumu belirtmek için özel bir sembol konulmalıdır. Aktivite diyagramları içerisinde, sinyalleri göstermek de mümkündür. Sinyal; bir aktivitenin dış süreçten bir olay aldığını gösterir. Şekil 4de UML içindeki sinyal ve pin sembolleri gösterilmiştir. Üst kısımdaki şekiller sinyallere ilişkin sembolleri gösterirken, alttaki iki aktivite arasındaki gösterim pin kavramını ortaya koymaktadır. İlk sembol "zaman sinyalini" (örneğin; mikrodenetleyicide her milisaniyede bir denetimin yapılması), 2.sembol sinyal girişini, 3. sembolde sinyal oluşumunu göstermektedir.
Aktivite diyagramlarında geçişleri takip etmekte zorlanıyorsanız, bağlanıcı (connector) kavramını kullanabilirsiniz. Bu sayede tüm mesafe boyunca, çizgi çizmeniz gerekmez. Aktiviteden bir geçiş çıkararak bu geçişi küçük bir daireye bağlar ve bu daireye bir isim verirsiniz. Aynı şekilde; karşıdaki aktiviteye aynı isimdeki küçük bir daireden bir giriş yaparak aradaki bağlantıyı temsil etmiş olursunuz.
Şekil 4: Sinyal ve pin sembolleri
Aktiviteler de, yöntemler gibi parametreye ihtiyaç duyabilir. Genelde bu
parametreler diyagramda gösterilmez ancak istenirse pin kavramı ile bu parametreleri gösterebilirsiniz. UML 1.x içinde pin kavramı yer almazken UML 2 ile birlikte ortaya çıkmıştır.
Aktivite diyagramları içerisinde; nesne akışını da göstermek mümkündür. Bu amaçla; iş akışından etkilenen sınıflar dikdörtgen içerisinde gösterilir. Bu dikdörtgenden kesikli çizgiler çıkarılarak ilgili aktiviteye bağlantı kurulur.
UML içinde bir akışı sonlandırmak istiyorsanız; içine çarpı işaretinin konulduğu küçük bir daire kullanılabilir. Akış sonunu gösterecek olan bu sembol; tüm aktiviteyi sonlandırmaz.
Döngü oluşturmadan özyinelemeleri (iteration) göstermek istiyorsanız; dinamik eşzamanlılık (concurrency) kavramı kullanılabilir. * işareti ilgili aktivitenin üzerine konularak, birden fazla yapıldığını ortaya koyabilirsiniz.
Bir aktivitenin çıkışında oluşan koleksiyonların her biri için (collection); devamında gelen aktivitelerin gerçekleştirileceği durumda yayılma bölgesi (expansion region) kavramı kullanılabilir.
Aktivite diyagramları için aslında daha fazla açıklama yapmak mümkündür. Ancak; çoğu kavram şu an için birçok tasarım aracı tarafından desteklenmemektedir veya UMLin yeni versiyonlarında değiştirilmektedir. Bu yazıda belirtilen temel kavramları kullanarak; projelerinizdeki iş akışlarını, karmaşık algoritmaları, kullanım senaryolarını kolaylıkla modellemeniz mümkün olacaktır.
Bir sonraki yazıda görüşmek üzere.
Çağatay Çatal
[email protected]
Kaynaklar
1-) UML Disteilled, Martin Fowler, Addison Wesley, 2002.
2-) UML Bible, Tom Pender, John Wiley, 2003.
3-) Learning UML, Sinan Si Alhir, OReilly, 2003.
4-) UML Weekend Crash Course, Thomas A. Pender, Wiley, 2002.
5-) UML Reference Manual, James Rumbaugh, Ivar Jacobsan, Grady Booch, Addison Wesley, 1999.
Makale:
UML ile Aktivite (Activity) Diyagramları UML ve Sistem Analizi Çağatay Çatal
|