UML

Yazılım teknolojisi geliştikçe yazılan programların karmaşıklığı ve zorluğu giderek

artmaktadır. Donanım ve yazlımın iç içe girdiği, büyük ağ sistemlerinin giderek arttığı bir
dönemde doğaldır ki biz programcıların yazacağı programlarda büyüyecektir. Yazacağımız
programlar çok karmaşık olacağı için kod organizasyonu yapmamız zor olacaktır. Hele birçok
programcının çalışacağı projelerde bu nerdeyse imkânsız hale gelmiştir. Bu yüzden standart
bir modelleme ve analiz diline ihtiyaç duyarız. Programımızın analiz ve tasarım aşamasında
modellemeyi güzel yaparsak ileride doğabilecek birçok problemin çıkmasına engel olmuş
oluruz. UML daha çok nesneye dayalı programlama dilleri için uygundur. Problemlerimizi
parçalara ayırabiliyorsak ve parçalar arasında belirli ilişkiler sağlayabiliyorsak UML bizim için
biçilmiş kaftan gibidir. Mesela bir ATM siteminde müşteriyi, banka memurunu ve ATM
makinasını ayrı parçalar halinde düşünebiliriz. Müşteri ATM makinasından para çeker, banka
memuru ATM makinesine para yükler. Ama banka memuru ile müşteri arasında doğrudan bir
ilişki yoktur. Bu tür ilişkiler UML 'de çeşitli diyagramlarla gösterilir. Bu diyagramlar hakkında
geniş ve detaylı bilgiyi daha sonraki yazılarımızda ele alacağız.

Bu kısa girişten sonra UML 'in tarihine bakalım. UML 'in doğuşu son yıllarda yazılım
endüstrisindeki en büyük gelişmelerden biri olarak kabul edilebilir. UML 1997 yılında
yazılımın, diyagram şeklinde ifade edilmesi için bir standartlar komitesi tarafından
oluşturuldu. Daha önce hemen hemen her daldaki mühendislerin standart bir diyagram
çizme aracı vardı. Ve şimdi de programcıların UML 'si var.

UML ile hazırlanmış bir yazılım hem daha az maliyetli hem daha etkili ve daha uzun ömürlü
olur. UML ile dokümantasyonu yapılmış bir programın sonradan düzenlenmesi daha kolay
olur. Bütün bunlar UML kullanmamız için yeterli sebeplerdir diye düşünüyorum. Kısaca,
UML'nin faydalarını maddeler halinde sıralarsak;

1-) Öncelikle programımız kodlanmaya başlamadan önce geniş bir analizi ve tasarımı
yapılmış olacğından kodlama işlemi daha kolay olur. Çünkü programdan ne beklediğimizi ve
programlama ile neler yapacağımızı profesyonel bir şekilde belirleriz UML ile.

2-) Programımızda beklenmedik bir takım mantıksal hataları (bug) minimuma indirgemiş
oluruz.

1
3-) Tasarım aşaması düzgün yapıldıysa tekrar kullanılabilen kodların sayısı artacaktır. Buda
program geliştirme maliyetini büyük ölçüde düşürecektir.

4-) UML diagramları programımızın tamamını kapsayacağı için bellek kullanımını daha etkili
hale getirebiliriz.

5-) Programımızın kararlılığı artacaktır. UML ile dokümanlandırılmış kodları düzenlemek daha
az zaman alacaktır.

6-) Ortak çalışılan projelerde programcıların iletişimi daha kolay hale gelir.Çünkü UML ile
programımızı parçalara ayırdık ve parçalar arasında bir ilişki kurduk.

Bir sistemin geliştirilmesi kabaca aşağıdaki aşamalardan geçmektedir. İlk iki aşamada UML
büyük ölçüde rol oynar.

Unutmayın: UML bir programlama dili değildir. Bir diyagram çizme ve ilişkisel modelleme
dilidir.

Şimdi kısa ve öz bir şekilde UML komponentlerinden (diagramlar) bahsedelim: Nesneler

arasında ilişki kurmak için UML bir takım grafiksel elemanlara sahiptir. Bu elemanları
kullanarak diyagramlar oluşturacağız. UML temel olarak 9 diyagram türünden oluşur.

CLASS DIAGRAM

Gerçek dünyada eşyaları nasıl araba, masa, bilgisayar şeklinde sınıflandırıyorsak yazılımda
da birtakım benzer özelliklere ve fiillere sahip gruplar oluştururuz. Bunlara "Class"(sınıf)
denir. Geliştirici açısından önemli olan "Class Diagramları" hakkında daha sonra detaylı bir
makalemiz olacak.

OBJECT DIAGRAM

Bir nesne(object) sınıfın (class) bir örneğidir. Bu tür diyagramlarda sınıfın yerine gerçek
nesneler kullanılır.

2
 Edited by Foxit Reader
Copyright(C) by Foxit Software Company,2005-2008
For Evaluation Only.

STATE DIAGRAM

Gerçek nesnelerin herhangi bir zaman içindeki durumunu gösteren diyagramlardır. Mesela,
Ali nesnesi insan sınıfının gerçek bir örneği olsun. Ali 'nin doğması, büyümesi, gençliği ve
ölmesi State Diagram 'larıyla gösterilir.

SEQUENCE DIAGRAM

Class ve Object diyagramları statik bilgiyi modeller. Hâlbuki gerçek zamanlı sistemlerde
zaman içinde değişen interaktiviteler bu diyagramlarla gösterilemez. Bu tür zamanla değişen
durumları belirtmek için sequence diyagramları kullanılır.

ACTIVITY DIAGRAM

Bir nesnesinin durumu zamanla kullanıcı tarafından ya da nesnenin kendi içsel işlevleri
tarafından değişebilir.Bu değişim sırasını activity diyagramlarıyla gösteririz.

USE CASE DIAGRAM asdasd

Programımızın davranışının bir kullanıcı gözüyle incelenmesi Use Case diyagramlarıyla

yapılır. Gerçek dünyada insanların kullanacağı bir sistemde bu diyagramlar büyük önem
esadasd
taşırlar.

dddddmnvhvjhvbjhcvjhdfvjhdf
COLLABORATION DIAGRAM

Bir sistemin amacının yerine gelmesi için sistemin bütün parçaları işlerini yerine getirmesi
gerekir. Bu işler genellikle birkaç parçanın beraber çalışmasıyla mümkün olabilir. Bu tür
ilişkileri göstermek için Collaboration Diyagramları gösterilir.

COMPONENT DIAGRAM
asdasd
Özellikle birden çok geliştiricinin yürüttüğü projelerde sistemi component dediğimiz parçalara
ayırmak, geliştirmeyi kolaylaştırır. Sistemi öyle modellememiz gerekir ki her geliştirici
ötekinden bağımsız olarak çalışabilsin. Bu tür modellemeler Component Diyagramlarıyla
yapılır.

3
DEPLOYMENT DIAGRAM

Bu tür diyagramlarla sistemin fiziksel incelenmesi yapılır. Mesela bilgisayarlar arasındaki

baglantılar, programın kurulacağı makinalar ve sistemimizdeki bütün aletler Deployment
Diyagramında gösterilir.

Class Diagramları ve UML Temelleri

UML ile sınıf diyagramları oluşturmak nesne temelli programlamanın getirdiği bir gerekliliktir,
biz bu makalede UML ile sınıf gösterimi ve sınıf ilişkileri gibi kavramları inceleyeceğiz. Sınıf
diyagramları oluşturmak için temel bilgileri teker teker inceleyeceğiz.

UML ile oluşturulan "Sınıf Diagramları", aralarında bizim belirlediğimiz ilişkileri içeren sınıflar
topluluğudur. UML' de bir sınıf aşağıdaki gibi dikdörtgen ile gösterilir. Dikdörtgenin en
üstünde sınıfın adı vardır.

Sınıflara isim verirken, her kelimenin baş harfinin büyük olması

diyagramlarımızın başkaları tarafından incelenmesi sırasında kolaylık
sağlayacaktır.

Bir sınıfın çeşitli özellikleri olabilir. Mesela, bir insan nesnesi olan 'ali' nesnesinin yaşı bir
özellik (attribute) bildirir. Bir sınıfın özellikleri SınıfAdı'nın hemen altına yazılır. Bir sınıfın
hiç özelliği olmayabileceği gibi birden fazla özelliği de olabilir. Aşağıda bir sınıfın özelliklerinin
grafik olarak gösterimi vardır.

Bir özelliğin değerini sonradan değiştirebileceğimiz gibi yandaki "yaş"

özelliği gibi varsayılan bir değer de verebiliriz. Bu değerler number,
string, boolean,float,double veya kullanıcı tanımlı bir tür olabilir.

Sınıfların bir diğer önemli elemanı da işlevlerdir (operations). İşlevler bir sınıfta iş yapabilen
elemanlardır. Bu iş başka bir sınıfa yönelik olabileceği gibi kendi içindeki bir iş de olabilir.
Class diyagramında işlevler aşağıdaki gibi özelliklerin hemen altında gösterilir.

4
 İşlevler özelliklerden farklı olarak birtakım bilgilere ihtiyaç
duyabilir veya birtakım bilgileri dışarıya verebilir, ya da
bunların hiçbirini yapmaz. Yandaki işlev1, birtakım işler
yapar bunun için dışardan bir bilgiye ihtiyaç duymaz ve
dışarıya bir bilgi vermez, işlev2, işini yapabilmek için
birtakım bilgilere ihtiyaç duyar. Mesela, işlev2, eğer bir
toplama işlemi yapıyorsa toplanacak elemanları ister. işlev3
ise iş yaptıktan sonra işinin sonucunu dış dünyaya verir.

Bir sınıf diyagramında kullanılabilecek temel yapılar bunlar olmasına rağmen "constraints"
ve "notes" dediğimiz elemanları da ekleyebiliriz. Notes(Notlar) genellikle işlevlerin ve
özelliklerin hakkında bilgi veren opsiyonel kutucuklardır. Constraints (koşullar) 'ler ise sınıfa
ilişkin birtakım koşulların belirtildiği ve parentez içinde yazılan bilgilerdir.

Şimdi de sınıflar arasındaki ilişkiye(Assocation) değinelim.

ASSOCATION (Sınıflar arası ilişki)

Sınıflar arasındaki ilişkiyi göstermek için iki sınıf arasına düz bir çizgi çekilir. İlişkiyi gösteren
çizginin üzerine ilişkinin türü yazılır. Mesela Kitap ve İnsan sınıfları olsun. Kitap ile insan sınıfı
arasında "okuma" ilişkisi vardır. Bunu sınıf diyagramında aşağıdaki gibi gösteririz.

Bir İnsan sınıfı gerçek nesnesi olan "Ali" ile

kitap sınıfı gerçek nesnesi olan "UML kitabı"
arasında "okuma" ilşkisi vardı. Kısaca şöyle
deriz. Ali, UML kitabı okur. Tabi gerçek bir
sistemde ilşkiler bu kadar basit olmayabilir.
Bazı durumlarda ikiden fazla sınıf arasında
ilişki olabilir, o zaman da her sınıf arasındaki
ilşkiyi tanımlamamız gerekir. Bazı
durumlarda ise belirtilen ilişkinin bir kurala
uyması gerekebilir. Bu durumda ilişki
çizgisinin yanına "constraints"(ilişki kuralı)
yazılır.

5
Bazı durumlarda sınıflar arasındaki ilişki, bir çizgiyle belirtebileceğimiz şekilde basit
olmayabilir. Bu durumda ilişki sınıfları kullanılır. İlişki sınıfları bildigimiz sınıflarla aynıdır.
Özellik ve işlev elemanları olabilir. Sınıflar arasındaki ilişki eğer bir sınıf türüyle belirleniyorsa
UML ile gösterimi aşağıdaki şekildeki gibi yapılır.

Görüldüğü gibi Müşteri ile Kitapçı sınıfı arasında

"satın alma" ilişkisi vardır. Fakat müşteri satın
alırken Ücret ödemek zorundadır. Bu ilişkiyi
göstermek için Ücret sınıfı ilişki ile kesikli çizgi ile
birleştirilir.

Şu ana kadar gördüğümüz ilişkiler bire-bir ilişkilerdi. İlişkiler bire-bir olmak zorunda değildir.
Bir sınıf, n tane başka bir sınıf ile ilişkiliyse buna bire-çok ilişiki denir. Mesela Yüzbaşı ile Er
arasında bire-yüz bir ilişki vardır. Diyagramda bunu gösterirken Yüzbaşı sınıfına 1 Er sınıfına
ise 100 yazacağız. Gösterimi aşağıdaki gibidir.

Burda 1 yüzbaşı 100 Er'e komut(emir)

verebilir anlamı vardır.

En temel ilişkiler aşağıdaki gibi listelenebilir:

-> Bire-bir
-> Bire-çok
-> Bire-bir veya daha fazla
-> Bire-sıfır veya bir
-> Bire-sınırlı aralık (mesela:bire-[0,20] aralığı)
-> Bire-n (UML de birden çok ifadesini kullanmak için '*' simgesi kullanılır.)
-> Bire-Beş ya da Bire-sekiz

Diğer bir ilişki türü ise bir sınıfın kendisiyle kurduğu ilişkidir.Bu tür ilişkiler genellikle bir
sınıfın sistemde birden fazla rolü varsa ortaya çıkar.Bu tür ilişkilere "reflexive associations"
denir.Bu tür bir ilişki UML ile aşağıdaki gibi gösterilir.

6
 Patron bir eleman olmasına rağmen kendisi gibi eleman olan birden
çok çalışan 'dan sorumludur.

UML ile Use Case Diagram'ları Oluşturma

Bir sistemin, class diyagramlarıyla ancak durağan bir analizini yapabiliyorduk. Use Case
diyagramları ise sistemin ve sınıfların zamanla değişimini de içerecek biçimdeki
diyagramlardır. Bir Use Case modeli Use Case diyagramları ve Use case açıklamaları
dediğimiz senaryolardan oluşmaktadır. Use Case diyagramları ise Actors, Use Case ve Use
Case 'ler arasındaki ilişkilerden oluşmaktaır. Kısaca Use Case modelini tanımlarsak şöyle
diyebiliriz. Sistemin kullanıcısının bakış açısıyla sistemin davranışlarının diyagramlarla
modellenmesidir. Use Case 'ler sistemin kabaca ne yaptığı ile ilgilenir, kesinlikle nasıl ve
neden yapıldığını incelemez.

Use Case modelini oluşturan diğer önemli bir yapı ise senaryolardır. Senaryolar kullanıcı
tarafından başlatılan çeşitli olaylar dizisidir. Her ne kadar bazı sistemlerde bir olay ya da
senaryo kullanıcı tarafından değil de donanım veya belirli bir zaman geçmesi sonucu
başlatılsa da, sistemi tasarlamamız için Use Case 'lerden faydalanamayacağımız anlamına
gelmez.

Şimdi bir Use Case modellemeye örnek vererek Use Case 'ler arasındaki ilişkinin nasıl
yapıldığını görelim.Tabi öncesinde bazı kavramları açıklamak gerekir.

Use Case ifadeleri UML diyagramlarıyla aşağıdaki gibi gösterilir.

7
Yukarıda da görüldüğü gibi Aktör yani kullanıcı Use Case modelinde bir Use Case 'i başlatır
ve sonuç olarak bir değeri başka bir kullanıcıya verir. Use Case 'ler yukarıda da görüldüğü
gibi elips şeklinde gösterilir. Kullanıcıların altında kullanıcıların adı bulunur. Kullanıcı ve Use
Case arasındaki ilişkiyi belirtmek için ise düz bir çizgi çizilir.

Daha önce de dediğimiz gibi herbir Use Case, senaryalordan oluşur, senaryolar ise bir çeşit
olaylar serisidir. Her Use Case 'e ait senaryolar aşağıdaki ifadelerden bir sonuç bekler.

-> Use Case 'i başlatan kullanıcıdan

-> Use Case 'in başlaması için gereken ön bilgilerden
-> Senaryodaki adımlardan
-> Senaryo bittikten sonraki durumlardan
-> Use Case 'den faydalanacak aktör durumundaki nesnelerden.

Use Case'ler Arasındaki İlişki

Yukarıda da belirttiğimiz gibi use case 'ler tekrar kullanılabilen birimlerdir. Tekrar
kullanmanın iki yöntemi vardır.Bunlar : inclusion ve extension 'dır. Bu iki metodun dışında
use case 'ler arasındaki ilişkiyi gösteren iki kavram daha vardır. Bunlar ise; Generalization
(Genelleme) ve Grouping(gruplama) 'dır. Bu kavramlar hakkında detaylı bilgiyi aşağıda
bulabilirsiniz.

Inclusion(içerme)

Bu metodla bir use case içindeki adımlardan birini başka bir use case içinde kullanabiliriz.
Inclusion yöntemini kullanmak için <<include>> şeklindeki bir ifade kullanılır. Bu ifade daha
önce gördüğümüz sınıf diyagramlarındaki sınıfları birbirine bağlayan noktalı çizgilerin üzerine
yazılır. Kullanmak istediğimiz use case 'ler arasına çektiğimiz noktalı çizginin üzerine
<<include>> yazısını yazarız.

Extension(eklenti)

Bu metodla varolan bir Use Case 'e yeni yeni adımlar ekleyerek yani use case 'ler yaratlır.
Inclusion'da olduğu gibi extension 'ları göstermek için yine use case 'ler arasına noktalı
çizgiler konur ve üzerine <<extension>> ibaresi yazılır.

8
Generalization(genelleme)

Bildiğiniz gibi sınıflar için türetme kavramı vardır. Türetme ile oluşturulan sınıf ana sınıfın
tüm özelliklerini alır ve istenirse yeni sınıfa yeni özellikler eklenir. Use Case 'ler arasındaki bu
ilişki de sınıflarda türetme(inheritance) kavramına benzemektedir. Gösterim biçimi sınıf
diyagramlarındaki türetmenin gösteriliş şekliyle aynıdır. Yani use case 'ler arasında düz bir
çizgi çizilir ve çizginin taban(base) sınıfı gösteren ucuna içi boş bir üçgen çizilir.

Aşağıdaki şekilde, bir siteye ait kullanıcıların genellemesinin nasıl yapıldığını görebilirsiniz. Bir
sitedeki online kullanıcılar ziyaretçilerden ve üyelerden oluşur, ayrıca sitenin üye kullanıcıları
ve ziyaretçiler için sunduğu hizmetler farklı olabileceği için aktörler arasında genelleme
yapılmıştır.

Grouping(gruplama)

Gruplama metodu tamamen fiziksel olarak bazı use case 'leri bir arada toplamak için
kullanılır. Gruplama tekniği genellikle birkaç alt sistemden oluşan büyük sistemlerde
kullanılır.

9
Use Case diyagramları hakkında temel bilgileri verdikten sonra Use Case diyagramlarına
örnek olabilecek bir uygulama yapalım.

Örnek:

C#nedir?com web sayfasına gelen bir kullanıcının neler yapabileceğini use case
diyagramlarıyla göstermeye çalışalım. Siteye gelen bir kullanıcı kayıtsız şartsız makale
başlıklarını görebilmektedir. Online olan kullanıcı Siteyi tavsiye edebilir, siteye üye olabilir,
C# ile ilgili olan kitapları inceleyebilir. Ancak makale okuması ve kaynak kod indirebilmesi
için siteye üye girişi yapmalıdır. Makale okuması ve kaynak kod indirebilmesi için gereken
şart siteye üye olmaktır. C#nedir?com sitesine bağlanan bir kullanıcının site üzerindeki
hareketlerini belirtir diyagram aşağıdaki gibidir.

10
UML ile State (Durum) Diyagramları

"State" kelimesinin Türkçe karşılığı "Durum" dur. O halde state diyagramlarını, bir nesnenin
ömrü buyonca sahip olacağı durumları modelleyen diyagramlar şeklinde tanımlayabiliriz.
Peki, ne demek bu? Öyle bir nesne düşününki belirli olaylar karşısında değişik durumlarda
bulunsun. Ve bu durumlar arasında çeşitli yöntemlerle geçişler mümkün olsun. Mesela bir
lambayı düşünün, lambanın yaşam süresince 3 farklı durumda olabileceğini söyleyebiliriz.
Birinci durum lambanın kapalı olması, ikinci durum lambanın açık olması son durum da
lambanın düşük enerji harcayarak yanması olsun. Bu 3 durum arasında geçişler mümkündür.
Bu geçişleri sağlayan ise çeşitli olaylardır. Örneğin lambayı kapalı durumdan açık duruma
getirmek için lambanın anahtarını çevirmek gerekir. Aynı şekilde lambayı düşük enerjili halde
yanan durumundan açık durumuna getirmek için lamba anahtarını yarım çevirmek gerekir.
Lamba nesnesi durum değiştirirken yaptığı işlere "action", lambanın durum değiştirmesini
sağlayan mekanizmaya ise event(olay) denilmektedir.

Nesnelerin bu şekilde durumlarını modellemek için UML'deki standart State Diyagramları

kullanılır. State diyagramları bir nesneye ait dinamik modellemeyi içermektedir. Dinamik
modellemeden kastım nesnenin ömrü boyunca gireceği durumları belirtmesidir. Daha önce
gördüğümüz sınıf diagramları ise statik modelleme olarak anılmaktadır. Şimdi bu kısa
girişten sonra State Diyagramları ilgili temel bilgileri aktarayım.

State Machine (Durum Makinesi)

"State Manchine", bir nesnenin bütün durumlarını bir şema halinde gösteren yapıdır. Temel
kavramları anlattıktan sonra bir "state machine" örneği vereceğim.

State (Durum)

Tek bir nesnenin herhangi bir durumunu ifade etmek için "State" sözcüğü kullanılır.

Event (Olay)

Nesnenin "state" ler arasındaki geçişini sağlayacak yordama event(olay) denir.

11
Action (Aksiyon)

Nesnenin bir durumdan diğer bir duruma geçtiğinde yaptığı işlere "action" denilmektedir.
Action, çalıştırılabilir herhangi bir durum olabilir.

Transition (Geçiş)

Nesnelerin durumları arasındaki geçişi sembol etmeye "Transition" denir. Bir nesnenin her
durumu arasında bir ilişki olmayabilir. Örneğin lamba açıkken lamba kapatılamıyorsa bu iki
durum arasında bir geçiş yoktur denir. Bir transiton(geçiş)'da 4 yapı vardır. Bu yapılardan
ikisi doğal olarak "hedef(target)" ve "kaynak(source)" durumudur. Geçişler kaynak
durumdan hedef duruma doğru yapılır. Üçüncü yapı Kaynak durumdan hedef duruma geçişi
sağlayan "event trigger(olay ateşleyicisi)" dır. Son yapı ise nesnenin durum geçişi sonrasında
ne şekilde davranacağını belirleyen "action" dır.

Self Transition (Öz-Geçiş)

Bazen bir nesnenin durum geçişleri farklı iki durum arasında olmayabilir. Mesela lamba açık
durumda olduğu halde lambayı tekrar açmaya çalışmak "self transition" kavramına bir
örnektir. Kısaca hedef durum ve kaynak durumun aynı olduğu durumlar "Self Transition"
olarak adlandırılır.

Initial State (İlk durum)

Programatik bir anlam ifade etmiyor gibi görünsede Initial State kavramı nesnenin gerçek bir
duruma geçmeden önceki durumunu belirtir. Kısaca, nesne ilk yaratıldığında alacağı duruma
bir geçiş sağlamak için gerçek anlamda bir "state" olmayan şekil(içi dolu küre) kullanılır.

Final State (Son Durum)

Nesnenin ömrü bittiğinde aldığı durumu ifade etmek için kullanılan semboldür. Bir nesne
birden fazla "Final State" durumuna sahip olabilir.

Yukarıda anlatılan kavramların kafanızda daha belirgin bir hale gelmesi için aşağıdaki şemayı
inceleyebilirsiniz. Bu şemaya kabaca "State Macihine" de denilebilir. (Not: Aşağıdaki şema
sadece kavramların kafanızda daha net olarak canlanabilmesi için verilmiştir. Gerçek yaşama
yönelik bir durum makinesi değildir.)

12
Bu aşamada önemle vurgulamamız gereken nokta State Diyagramlarının tek bir
nesne ile ilişkili olmasıdır.

Nesnelerin durumlarının UML ile nasıl gösterildiğine bakalım. Bir State yukarıdaki şemada
olduğu gibi köşeleri yuvarlatılmış dörtgen şeklinde gösterilir. Bir State'in yukarıdaki şemada
görülmeyen 3 ana bileşeni vardır. Birinci bileşeni State'in adıdır. İkinci bileşen State
değişkenleri üçüncü bileşen ise State ile ilgili çeşitli aktiviteleri belirtmek için kullanılan
yapıdır. Bu aktivitilerin bazıları UML'de standart olarak belirtilmiş olmasına rağmen istersek
kendimizde aktivite tanımlayabiliriz. Standart olan aktivitelerin sayısı 3'tür. Bunlar entry,
exit ve do isimli aktivitelerdir. entry aktivitesi, nesnenin ilgili duruma geçtiği andaki
davranışın adını belirtir. exit aktivitesi, nesne ilgili durumdan diğer bir duruma geçişi
sırasındaki davranışını belirler. Örneğin bir lambanın açık durumdan kapalı duruma
geçtiğinde lambadaki elektrik devresinden akımın kesilmesi yada lambanın kapalı durumdan
açık duruma geçişi sırasında devreye akımın verilmesi bu tür aktivitelere örnek verilebilir.
Diğer bir standart aktivite olan do ise nesnenin belirtilen durumda olduğu sürece nasıl bir
davranış sergileyeceğini belirtir. Lambanın yanması sırasında devreden geçen akımın
sabitliğinin korunması do aktivitesine örnek olarak verilebilir. Bir "State" 'in bütün standart
aktivitelerini tanımlamak zorunda değiliz. Söz gelimi bir "State" ' in yalnızca do aktivitesi
olabilir.

Yukarıdaki "State" tanımlamalarını göz önünde bulundurursak UML'de en temel durum

modeli aşağıdaki gibi yapılabilir.

13
Yukarıdaki şekil teknik makale içeriği sunan bir siteye ait kullanıcının ONLINE olma
durumunu modellemektedir. Şekildeki en üstteki kısım "State Name" yani durum adını
belirtir. İkinci kısım ilgili duruma ait çeşitli parametreleri gösterir. Bu örnekte ONLINE
durumunda olan kullanıcının sisteme ne zaman giriş yaptığı belirtilmektedir. Parametreler
bölümüne ihtiyaç olduğunda çeşitli ifadelerde(ToplamSüre = EskiSüre + YeniSüre gibi)
yazılabilir. Son ve en alttaki bölüm ise "State" ile ilgili aktiviteleri göstermektedir. entry
aktivitesinde kullanıcının "Hoş geldin" mesajı ile karşılanması, exit aktivitesinde "Güle güle"
mesajı ile uğurlanması, do aktivitesinde ise kullanıcıya makale okuma iznin verileceği
belirtilmektedir. Bu standart aktivitelerin dışında olan tavsiye isimli diğer bir aktivitede ise
kullanıcıya diğer teknik makale içeren sitelerin tavsiye edileceği belirtilmektedir.

Durumlar Arası Koşullu Geçişler (Guard Condition)

Bir nesnenin bir durumdan diğerine geçişi için sadece olay tetiklenmesi yetmeyebilir. Mesela
gün ışığına göre yanıp sönen aynı zamanda açma kapama düğmeside olan bir lambayı
düşünün. Gündüz saatlerinde lamba kapalı durumdayken anahtar çevrilerek lambanın
açılması istenmeyebilir. Yani lambanın açılması ortamın karanlık olmasınada bağlıdır. Sadece
lambanın anahtarını çevirerek lambanın açılamayacağı koşullu geçişlere örnek olabilir.
Lambanın açılması için "anahtar açma" olayının meydana gelmesi ve ortamın aydınlık
seviyesinin lambanın açılması için yeterli olması gerekmektedir. Bu durumu geçişler üzerine
açılan ve kapanan köşeli parantezler içine koşulu yazarak belirtebiliriz. Örneğin KAPALI ve
AÇIK durumları arasındaki geçişe aşağıdaki gibi bir koşul yazılabilir.

14
 [Aydınlık == Gunduz Seviyesi]
KAPALI --------------------------------------> AÇIK
Anahtarı Çevirme

Eğer geçişler arasında sadece koşul ifadesi yazılırsa, koşul ifadesi gerçekleştiği anda geçişin
sağlanması beklenir. Yani olayın ateşlenmesine gerek yoktur. Yukurıdaki gösterimde ise
lambanın AÇIK duruma geçebilmesi için hem koşulun sağlanması hemde olayın(anahtarı
çevirme) gerçekleşmesi gerekir.

Alt Durumlar (Substates)

Gerçek hayattaki sistemler burada anlattığım sistemlerden çoğu zaman daha karmaşık
olacaktır. Hatta birçok sistemin durum modeli çıkarıldığında bazı durumların içinde farklı
durumların olduğu görülmektedir. Bu tür "alt durumları" içeren modellemeler UML ile
yapılabilmektedir. Alt durumlara bir örnek verelim: Bir CD çalar programını düşünün. CD
çalar programı belirli bir anda ya çalışıyor durumdadır ya da çalışmıyor durumundadır. Eğer
CD çalar programı çalışır durumda ise yine iki durum olabilir. CD çalar programı ya bir kayıt
yapıyordur, ya da seçilen şarkıyı çalıyordur. Çalışma durumu içindeki bu iki durumu
aşağıdaki gibi modelleyebiliriz.

Alt-durumlar ile ilgili önemli durumlar :

1-a ) Bir alt-durum, varolan başka bir durum içinde olmalıdır.

1-b ) Alt-durumu olan bir duruma "Composite State" denir.

1-c ) Bir durum içinde birden fazla seviyede durum olabilir. Örneğin yukarıdaki örnekte Kayıt
durumu içinde de alt durumlar olabilir.

1-d ) Herhangi bir alt-durum içermeyen durumlara "Simple State" yani basit durum denir.

15
Kompozite(Composite) Durumlar ilgili Önemli Özellikler

2-a ) Bir composite duruma geçiş(transition) olabileceği gibi, composite durumdan başka
durumlarada geçiş olabilir. Eğer bir geçiş composite duruma doğru ise bu composite
durumun "Başlangıç Durumu(Initial State)" içermesi zorunludur. Eğer böyle olmasaydı
tanımsız durumlar ortaya çıkardı. Bu durumu aşağıdaki composite durum diyagramından
rahatlıkla görebilirsiniz.

2-b ) Eğer geçiş(transition) bir alt-duruma doğru ise ve dıştaki duruma ilişkin her hangi bir
entry aktivitesi varsa çalıştırılır ve ardından alt-duruma ilişkin aktiviteler çalıştırılır.

2-c ) Eğer geçiş(transition), composite durum içindeki bir alt-durumdan, composite durumun
dışındaki bir duruma doğru ise, önce composite durumun exit aktivitesi ardından alt-
durumun exit aktivitesi çalıştırılır.

2-d ) Eğer geçiş(transition) composite durumdan, dışarıdaki farklı bir duruma doğru ise
öncelik sırası diğer alt-durumlara göre bu geçiştedir.

Aşağıda karmaşık bir durum modeli verilmiştir. Bu modelde 2-a, 2-b, 2-c ve 2-d
maddelerinde verilen geçişler işaretlenmiştir.

16
UML ile "Sequence" Diyagramları

"Sequence" kelime anlamı olarak "birbirini takip eden, ardışıl olan, peşi sıra" anlamlarına
gelmektedir. UML diyagramı olarak ise nesnelerin peşi sıra etkileşimde bulunmalarını ve
nesnelerin zaman boyutunda birbirleri ile ilişkiye girmeleri anlamında kullanılmaktadır. Bu
yazı boyunca bu diyagramlardan kelime kargaşası yaratmama adına "Sequence"
diyagramları şeklinde bahsedeceğim. Bir önceki UML makalesinde incelemiş olduğumuz
Durum diyagramlarının aksine "sequence" diyagramları nesnelerin birbirleriyle
haberleşmesini zaman boyutunda ele almaktadır. Dikkat ederseniz şu ana kadar
incelemiş olduğumuz, nesne, durum ve use case diyagramlarında nesnelerin ilişkileri
zamandan bağımsız olarak ele alınmıştı. İlk olarak zaman kavramını "sequence"
diyagramlarında ele almış olacağız.

Hatırlarsanız Durum Diyagramları yazısında nesnelerin ömürleri boyunca alabilecekleri

durumları incelemiştik. Ancak nesnelerin birbirleri ile haberleşmesini ve durumlarını bu
haberleşme mantığına göre değiştirebilmelerini incelememiştik. İşte bu yazıda göreceğimiz
"sequence" diyagramları vasıtası ile nesnelerin birbirleri ile haberleşmesini zamana bağlı
olarak ele alacağız. Bir diyagramın zaman bağlı olmasından kastımız, nesnelerin
gerçekleştirdikleri aktivitelerin peşisıra gerçekleşmesi ve bu peşisıralığın belirlenen zaman
dilimleri içerisinde maydana gelmesidir. İlerleyen kısımlarda daha detaylı olarak
inceleyeceğimiz için isterseniz bir "sequence" diyagramında olabilecek nesneleri tek tek ele
alalım :

Bir "sequence" diyagramı temel olarak nesnelerden(objects), mesajlardan (messages) ve

zaman eksenlerinden(timeline) oluşmaktadır. Aşağıda bu üç UML bileşenide ayrıntılı bir
şekilde açıklanmıştır.

Nesneler (Objects)

Nesneler diğer UML diyagramlarında da belirttiğimiz gibi belirli görevleri gerçekleştirmek için
tanımlanan yapı bloklarıdır. Nesneler, tasarım ve modellemenin en küçük yapı taşı olduğu
için hemen hemen her tür diyagramda nesneleri görmekteyiz. "sequence" diyagramında
nesneler aşağıdaki şekilde görüleceği üzere diktörtgen ve bu diktörtgen içinde nesne ismi
olacak şekilde temsil edilir. Önemli noktalardan birisi ise nesne isminin :NesneIsmi
formatında olmasıdır. "sequence" diyagramlarında nesneler genellikle diyagramın fiziksel
olarak en üstünden ve soldan sağa olacak biçimde sıralanır. Yani nesnelerin "sequence"

17
diyagramlarındaki orjini sol üst köşedir. Ve yayılım biçimi soldan sağadır. Bu bir kural
olmamakla beraber kullanılan en yaygın biçimi bu şekildedir. Bizde bu yazının sonunda
vereceğimiz örnektte bu şekilde kullanacağız.

Şekil 1 : Nesne

Her bir nesnenin altından çıkan ve kesik kesik olan çizgi nesnenin zaman
çizgisini(timeline) belirtmektedir. "Sequence" diyagramlarındaki zaman olgusu bu
çizgilerle belirtilmektedir. Kesik çizginin en altı teorik olarak sonraki zamanı göstermektedir.
Zaman çizgisi üzerinde bulunan ince ve uzun diktörgenler ise o nesnenin o zaman içerisinde
meydana getirdiği aktivitedir(activation). Yine teorik olarak diktörgenin uzunluğu
aktivitenin ne kadar zaman aldığı ile doğru orantılıdır. Yani uzun süren bir aktivite daha uzun
dikdörtgenle gösterilir. (Çoğu zaman bu kurala uyulmamaktadır.)

Mesajlar (Messages)

Mesajlar bir nesnenin zaman çizgisinden diğer bir nesnenin zaman çizgisine doğru çizilen
simgelerden oluşmaktadır. Nesnelerin birbirleri ile haberleşmesi, birbirlerine komut
göndermesi kalın çizilmiş oklarla gösterilmektedir. Bir nesne kendisine mesaj gönderebileceği
(recursion - öz yineleme) gibi başka nesneyede mesaj gönderebilir. Dahası nesne
olmayan farklı bir UML bileşenide nesnelere mesaj gönderebilir. Örneğin use case
diyagramlarında kullandığımız aktör bileşeni aşağıdaki gibi "sequence" diyagramındaki bir
nesneye mesaj gönderebilir.

18
Şekil 2: Mesaj Örneği

"Sequence" diyagramlarında 3 çeşit mesaj tipi kullanılmaktadır. Aşağıda bu 3 mesaj tipi

grafiksel gösterimleriyle birlikte açıklanmıştır.

Mesaj Tipleri :

1 - Basit(Simple) Mesaj Tipi: Bu mesaj tipi basit anlamda bir nesnenin, akış kontrolünü
diğer bir nesneye verdiği durumlarda kullanılır. Sık kullanılan bir mesaj tipi değildir.
Gösterimi aşağıdaki gibidir:

Şekil 3: Basit Mesaj

2 - Senkron (Synchronous) Mesaj Tipi: Bir nesnenin mesajı gönderdikten sonra, zaman
çizgisinde devam edebilmesi için karşı nesneden cevap beklenmesi gereken durumlarda
kullanılır. Varsayılan mesaj tipi olduğundan sıklıkla bu mesaj tipi kullanılmaktadır. Gösterimi
UML diyagramlarında aşağıdaki gibidir.

Şekil 4: Senkron Mesaj

3 - Asenkron (Asynchronous) Mesaj Tipi: Senkron mesajların aksine bir nesnenin mesajı
gönderdikten sonra, zaman çizgisinde devam edebilmesi için karşı nesneden cevap
beklenmesi gerekmiyorsa kullanılır. Sıklıkla asenkron işlemesi gereken komut zincirlerinde
kullanılmaktadır.

19
Şekil 5: Asenkron Mesaj

Zaman (Time)

"Sequence" diyagramlarının son ve en önemli bileşeni zaman olgusunun sembolize edildiği

zaman çizgisidir. (time line) Daha önce de denildiği gibi zaman çizgisi nesneden dikey olarak
aşağı doğru kesik bir çizgi şeklinde ilerler. Nesneye en yakın olan aktiviteler daha erken
gerçekleşir anlamındadır. Aşağıdaki örnekte iki nesnenin zaman çizgileri aynı diyagram
üzerinde gösterilmiş ve farklı zamanlarda gerçekleşen aktivitelere örnek verilmiştir.

Şekil 6: Basit bir "sequence" Diyagramı

Yukarıdaki basit diyagramda senkron mesajlar 1-2-3-4 sırasında gerçekleşmektedir. Her

mesaj gönderiminden sonra dikkat ederseniz aktivite kutuları çizilmiştir. Ayrıca 3. mesajda
ise öz yinelemeli (recursion - kendi kendine mesaj) mesajlara örnek verilmiştir.

Gerçek "Sequence" Diyagramları Nasıl Çizilir?

Gerçek projelerde "sequence" diyagramlarını çıkarmak sanıldığı kadar zor bir işlem değildir.
Yeterki karşılaştığımız sorunun ve tasarım probleminin farkında olalım. Proje modülleri için
çıkaracağımız "sequence" diyagramları, bakış açımıza, proje ekibinin iletişim biçimine veya
modülün herkes tarafından bilinirliğine göre değişebilmektedir. Söz gelimi akış biçimi kolayca
anlaşabilecek sistemler de basit bir "sequence" diyagramı yeterli olabilecekken henüz yeni
geliştirilen bir sistem için her ayrıntıyı "sequence" diyagramları üzerinde göstermek
gerekebilecektir. "Sequence" diyagramları bu ayrım gözetilerek genellikle iki biçimde
incelenmektedir: Instance (örnek) ve generic (genel) "sequence" diyagramları.
Instance olarak adlandırılan diyagramlarda genellikle basit bir şema çizlir, ayrıntılar gözardı

20
edilir ve "best case" denilen en iyi olasılıklar ele alınır. Örneğin bir ATM makinasının akışını
modelleyen diyagramda sadece kullanıcı aktivitelerinin, paranın kullanıcıya verilmesinin ele
alınması aynı zamanda hesapta paranın olmaması, ATM makinasında paranın olmaması gibi
durumları ele alınmaması bu tarz diyagramlara örnek olabilir. Generic diyagramlarda ise
model daha karışık ve her yönüyle ele alınır. Öyleki döngü ve koşul yapıları dahi "sequence"
diyagramında gösterilir. Koşul ve döngü ifadeleri aynı nesne üzerinde farklı aktivite kutuları
ile gösterilmektedir. Aşağıda her iki yaklaşımla çizilmiş iki "sequence" diyagramını
bulabilirsiniz.

Instance "Sequence" Diyagramına Örnek :

Üç nesneli bir ATM makinasının çalışmasını modelleyen "sequence" diyagramını örnek

verelim. Sistemimizde ilgilendiğimiz üç nesne bulunmaktadır.

Tuş Takımı ve Para Alma Modülü: Kullanıcnın ATM makinası ile haberleştiği arayüzler
(Nesne 1)

Hesap Kontrol Modülü: Kullanıcı doğrulama ve bakiye kontrol gibi mantıkların işletildiği
birim (Nesne 2)

Para İletme Bölümü: Kullanıcının yani talebinin arayüz yani Nesne1 yardımıyla kullanıcıya
sunulması. (Nesne 3)

Diyagramımızı çizmeden önce iş kurallarımızı maddeler halinde yazalım :

1 - Kullanıcı şifresini yazar.

2 - Ardından çekmek istediği tutarı nesne 1 yardımıyla yazar. (tuş takımı)

3 - Çekmek istenilen tutar nesne 2 tarafından kontrol edilir.

4 - Eğer bakiye uygun ise Nesne 3 e mesaj gönderilerek bu modüle para aktarımı sağlanır.
Not: Bu örnekte bakiyenin uygun olacağı varsayılacaktır. (yukarıda anlatılan best case
durumu)

5 - Nesne 3, Nesne 1 i yani arayüzü uyararak paranın alınması sağlanır.

21
Örneğe ilişkin "sequence" diyagramı ise aşağıdaki gibi çizilebilir. Diakkat ederseniz sadece
kullanıcının girdiği tutar’ın bakiyeden küçük olduğu "best case" dediğimiz en ideal durum
modellenmiştir. Diğer durumlar bu modelde bulunmamaktadır.

Şekil 7 : Örneğe ilişkin instance "sequence" diyagramı

Generic "Sequence" Diyagramına Örnek:

Generic "sequence" diyagramında birden fazla senaryo aynı anda ele alınmaktadır. Söz
gelimi aşağıdaki örnekte kullanıcının girdiği tutar bakiyeden büyük ise iki senaryo daha
eklenmektedir. Bu durumda ya ödenebilen maksimum miktar ödenmekte ya da işlem iptal
edilmektedir. Bunun gibi birçok senaryo diyagrama eklenebilir. Tabi eklenen her senaryo
diyagramı iyice karıştıracaktır. Bu yüzden diyagramlarımızı oluştururken bütün senaryoları
içerebilecek durumları çıkarmaya çalışma ile birlikte maksimum okunabirliği de gözönünde
bulundurmak gerekir. Zira çıkaracağımız diyagramlar geliştiricilerin işini zorlaştırma yerine
kolaylaştırmalıdır. Zaten temel amacımız da bu olmalı.

22
Şekil 8: Örneğe ilişkin generic "sequence" diyagramı

Yukarıdaki örnekte dikkat ederseniz kolaylık olması açısından aynı nesne birden fazla zaman
çizgisine sahip olabilmektedir.

UML ile Aktivite (Activity) 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

23
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

24
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 1’de
kullanım senaryosu, Şekil 2’de ise aktivite diyagramı gösterilmektedir.

Şekil 1: Kullanım Senaryosu

25
Şekil 2: Aktivite Diyagramı

Şekil 2’de 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",

26
"ş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ç (process), 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.

27
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.x’de kulvar (swimlane) kavramı
kullanılırken UML 2’de 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 3’deki 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 5’i 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

28
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 4’de 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.

29
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 UML’in 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.

Türetme, Genelleme ve Arayüz Kavramları

Türetme (Inheritance)

Eğer eşyalar arasında genellemeler yapabiliyorsak genellemeyi yaptığımız eşyalarda ortak

özelliklerin olduğunu biliriz. Mesela, "Hayvan" diye bir sınıfımız olsun.Memeliler, Sürüngenler,
Kuşlar da diğer sınıflarımız olsun.Memeliler, Sürüngenler ve Kuşlar sınıfının farklı özellikleri
olduğu gibi hepsinin Hayvan olmasından dolayı birtakım ortak özellikleri vardır. Bu yüzden
Memeliler, Sürüngenler ve Kuşlar birer hayvandır deriz. Yani kısacası Memeliler, Sürüngenler
ve Kuşlar, Hayvan sınıfından türemiş ve herbirinin kendine özgü özellikleri vardır deriz.
Nesne yönelimli programlamada buna türetme (Inheritance) denir. UML 'de türetme
aşağıdaki şekilde olduğu gibi gösterilir.

30
 Yanda gördüğünüz türetme
ağacında Sürüngenler, Kuşlar
ve Memeliler hayvandır.
İnsan, Kedi ve Köpek ise
memelidir anlamı çıkmaktadır.
Sınıflar arasındaki türetme
işlemi yandaki gibi ucu açık
üçgen ve düz bir çizgiyle
gösterilir. Bu durumda
"HAYVAN" sınıfı ana
sınıf(parent class), Memeliler,
Kuşlar ve Sürüngenler ise
yavru (sub class) sınıflardır.

Türetmeye sınıflar arası ilişki

açısından baktığımızda
türetmenin "is kind of" (bir
çeşit) ilişkisinin olduğu
görülür.Yani Kuş bir çeşit
Hayvan'dır deriz. (Bird is kind
of Animal)

Kısaca toplarlarsak, türetmenin ve genellemenin programcı açısından önemi

büyüktür.Nesneler arasında ortak özellikler varsa bunu her sınıfta belirtmenin yerine ortak
özellikleri bir sınıfta toplayıp diğer sınıfları ondan türetip yeni özellikler ekleyerek
organizasyonu daha etkin hale getirebiliriz.Tabi istersek ortak özelliklerin toplandığı sınıf ile
gerçek nesneler oluşturmayı engelleyebiliriz.Bu tür sınıflara "abstract class" denir.Bir sınıfın
"Abstract" olması için Sınıf ismini italik yazmamız gerekir.

İçerme (Aggregations)

Bazı sınıflar birden fazla parçadan oluşur.Bu tür özel ilişkiye "Aggregation" denir.Mesela ,bir
TV 'yi ele alalım.Bir televizyon çeşitli parçalardan oluşmuştur. Ekran,Uzaktan
Kumanda,Devreler vs.. Bütün bu parçaları birer sınıf ile temsil edersek TV bir bütün olarak
oluşturulduğunda parçalarını istediğimiz gibi ekleyebiliriz. Aggregation ilişkisini 'bütün parça'

31
yukarıda olacak şekilde ve 'bütün parça'nın ucuna içi boş elmas yerleştirecek şekilde
gösteririz. Örnek bir şekil aşağıdaki gibidir.

Yandaki şekilden de görüldüğü

üzere bir TV sistemi 1
EKRAN,1 KUMANDA, birden
çok DEVRE 'den oluşmaktadır.
TV' nin bir parçası olan
KUMANDA ise 2 PİL, 1 TUŞ
TAKIMI ve 1 IŞIK LAMBASI
'ndan oluşmaktadır. İçi boş
elma ile gösterilen ilşkilerde
herbir parça ayrı bir sınıftır ve
tek başlarına anlam ifade
ederler. Parça bütün arasında
çok sıkı bir ilişki yoktur. TV
nesnesi yaratıldığında bir
ekran veya bir kumanda
nesnesi daha sonradan
oluşturularak TV ye takılır.
Ama bazı durumlarda bütün
nesneyi yarattığımızda
parçalarının da yaratılmasını
isteriz. Mesela bir insan
bedenini analizini yapalım. Bir
insan vücudu baş, gövde, el
ve ayaklardan oluşur. Bir
insan vücudunu
düşündüğümüzde tümüyle
düşünürüz.
Sadece "Beden" nesnesini oluşturup sonradan bedene el, ayak, baş takmak çok mantıksız
olurdu. Bu tür ilişkilerin gösterilmesine ise "COMPOSITE ASSOCATION" denir. Bu ilişki
diğerine göre daha sıkıdır. Bu tür ilişkilerde bütün nesne yaratıldığında parçalar da anında
yaratılır. Bazı durumlarda, takılacak parçalar duruma göre değişebilir.Belirli koşullarda
Kumanda, bazı durumlarda da Ekran olmayacaksa bu tür durumlar koşul ifadeleri ile birlikte
noktalı çizgilerle belirtilir.Bu konuyu daha sonraki makalelerimizde detaylı bir şekilde ele

32
alacağız. Bu durumda takılacak parçalar "constraint(koşul)" ile belirtilir.

Bir "COMPOSITE" ilişkisi aşağıdaki şekilde gösterilir.

Gerçek bir BEDEN nesnesi
oluştuğunda mutlaka ve
mutlaka 1 KAFA, 1 GÖVDE
ve 4 EL_AYAK nesnesi
yaratılacaktır. Gördüğünüz
gibi sıkı bir parça-bütün
ilişkisi mevcuttur.

Arayüz (Interface)

Bazı durumlarda bir sınıf sadece belirli işlemleri yapmak için kullanılır. Herhangi bir sınıfla
ilişkisi olmayan ve standart bazı işlemleri yerine getiren sınıfa benzer yapılara
arayüz(interface) denir.Arayüzlerin özellikleri yoktur. Yalnızca bir takım işleri yerine getirmek
için başka sınıflar tarafından kullanılırlar. Mesela, bir "TuşaBasma" arayüzü yaparak ister onu
"KUMANDA" sınıfında istersek de aşağıdaki şekilde görüldüğü gibi "KLAVYE" sınıfında
kullanabiliriz. Sınıf ile arayüz arasındaki ilişkiyi kesik çizgilerle ve çizginin ucunda boş üçgen
olacak şekilde gösteririz. Sınıf ile arayüz arasındaki bu ilişkiye gerçekleme(realization) denir.
Sınıfla, arayüz arasında UML gösterimi açısından fazla bir fark yoktur.Tek fark arayüzde
özellik(attribute) yoktur.Diğer bir fark ise arayüz adlarını yazarken adın üstüne <interface>
yazısını eklemektir.Aşağıda bir arayüz-sınıf ilişkisi mevcuttur.

KLAVYE sınıfı YAZICI arayüzündeki

TusBasma() işlevini kullanır. Bu ilişkiye
gerçekleme(realization) denildiğini unutmayın.

33
Görünürlük (Visibility)

Görünürlük işlemi bir sınıfın işlevlerine ve özelliklerine ilişkin kullanım alanını belirler.
Görünürlük belirtmek için işlevin ya da özelliğin başına görünürlük seviyesi ile ilgili simge
yazılır. 3 çeşit görünürlük seviyesi vardır.

Public Seviyesi: Bütün sınıflara açık seviye. İşareti : +

Protected Seviyesi: Sadece ilgili sınıfa ve kendisinden türeyen sınıfların kullanımına açık
seviye. İşareti : #

Private Seviyesi: Sadece ilgili sınıfın (orjinal sınıf) erişebileceği seviye. İşareti : -

Mesela bir bilgisayar dosyası ilgili sınıfın özellikleri ve işlevleri ile ilgili görünülürlük özelliği
aşağıdaki gibi gösterilebilir.

34