UML

Unified Modeling Language

Nedir?
 UML 'nin faydaları
1-) Öncelikle programımız kodlanmaya başlamadan önce geniş bir analizi ve tasarımı yapılmış olacağı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.

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.
 UML komponentleri(diagramlar)
Nesneler arasında ilişki kurmak için UML bir takım grafiksel elemanlara sahiptir. Bu
elemanları kullanarak diyagramlar oluşturacaktır.
UML temel olarak 9 diyagram türünden oluşur.

CLASS DIAGRAM (Sınıf)

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.

OBJECT DIAGRAM (Nesne)

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.

STATE DIAGRAM (Durum)

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.
 UML komponentleri(diagramlar)
SEQUENCE DIAGRAM (Sıralama)
Class ve Object diyagramları statik bilgiyi modeller. Halbuki 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 (Aktivite)

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 (kullanım şekli)

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 taşırlar.

COLLABORATION DIAGRAM (İşbirliği)

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.
 UML komponentleri(diagramlar)
COMPONENT DIAGRAM (Bileşen)

Ö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.

DEPLOYMENT DIAGRAM (Dağılım)

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.
 Sınıf Diagramı
UML ile sınıf diyagramları oluşturmak nesne temelli programlamanın getirdiği bir
gerekliliktir.
• 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ıf Diagramı
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.
İş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.
 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.
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.
 ASSOCATION (Sınıflar arası ilişki)
Ş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ş yada Bire-sekiz
 ASSOCATION (Sınıflar arası ilişki)
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 (Kendine Dönen )" denir.Bu tür bir ilişki UML ile aşağıdaki gibi gösterilir.

Patron bir eleman olmasına rağmen kendisi gibi eleman

olan birden çok çalışan 'dan sorumludur
 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.
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)

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' 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.
 İÇERME (AGGREGATIONS)
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 durumda takılacak parçalar "constraint(koşul)" ile belirtilir.

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.
 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.
 USE CASE Diagram
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.
Use Case ifadeleri UML diyagramlarıyla aşağıdaki gibi gösterilir.

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.

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 Diagram
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.
 USE CASE Diagram
Generalization(genelleme)

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.
 USE CASE Diagram
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.

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.
 State (Durum)Diagram
"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
 State Machine (Durum Makinesi)
"State Manchine", bir nesnenin bütün durumlarını bir şema halinde gösteren yapıdır.

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.

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.
 State Machine (Durum Makinesi)
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. )
 State Machine (Durum Makinesi)

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.
 State Machine (Durum Makinesi)
Yukarıdaki "State" tanımlamalarını göz önünde bulundurursak UML'de en temel durum modeli aşağıdaki gibi
yapılabilir.

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.
 State Machine (Durum Makinesi)
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.

[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.
 State Machine (Durum Makinesi)
Alt Durumlar (Substates)

Gerçek hayattaki sistemler burada anlattığım sistemlerden çoğu zaman daha kompleks
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 yada ç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, yada 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.
 State Machine (Durum Makinesi)
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 kompleks bir durum modeli verilmiştir. Bu modelde 2-a, 2-b, 2-c ve 2-d maddelerinde verilen geçişler
işaretlenmiştir.
 "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ı.

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.
 "Sequence" Diyagramları
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" 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.

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 dikdö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.)
 "Sequence" Diyagramları
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.

Ş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.
 "Sequence" Diyagramları
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.

Şekil 5 : Asenkron Mesaj

 "Sequence" Diyagramları
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.
 "Sequence" Diyagramları
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ı 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.
 "Sequence" Diyagramları
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.
 "Sequence" Diyagramları
Örneğe ilişkin "sequence" diyagramı ise aşağıdaki gibi çizilebilir. Dikkat 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ı

 "Sequence" Diyagramları
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 yada 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ı.

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

 «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

Durum ve aktivite diyagramları 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.

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.
 «Aktivite" Diyagramları
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.

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

Şekil 1: Kullanım Senaryosu

 «Aktivite" Diyagramları
Ş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.

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.

Şekil 2: Aktivite Diyagramı

 «Aktivite" Diyagramları
 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.
Ö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.
 «Aktivite" Diyagramları

Ş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.
 UML diagramlarına
 4+1 bakış, bu diyagramları sınıflandırmak ve yazılım yaşam çevrimindeki kullanım yerlerini
ortaya koymak için kullanılan bir kavramdır. Bu bakışlar;
 1-) Kullanıcı Bakışı (User View): Müşteri gereksinimlerini ortaya koymak ve müşteriye,
sistemi tanıtmak amacı ile kullanılan bakış açısıdır. Bazı kaynaklarda; kullanım senaryosu
(use case) bakışı olarak da açıklanmaktadır. Bu amaçla; önceki yazılarımızda
açıkladığımız "kullanım senaryosu" (use case) diyagramları kullanılmaktadır.
 2-) Yapısal Bakış (Structural View): Sistemin nelerden meydana geldiğini gösteren bakış
açısıdır. Bazı kaynaklarda bu bakış, tasarım (design) veya mantıksal (logical) bakış olarak
da açıklanmaktadır. Bu amaçla; önceki yazılarımızda açıkladığımız "sınıf" (class)
diyagramları ve "nesne" (object) diyagramları kullanılmaktadır.
 3-) Davranış Bakışı (Behavioral View): Sistemin dinamik yapısını ortaya koyan bakış
açısıdır. Bazı kaynaklarda; süreç (process) bakışı olarak da açıklanmaktadır. Bu amaçla;
önceki yazılarımızda açıkladığımız "sıralama" (sequence), "işbirliği" (collaboration),
"durum" (statechart), "aktivite" (activity) diyagramları kullanılmaktadır.
 4-) Gerçekleme Bakışı (Implementation View): Sistemin alt modüllerini ortaya koyan bakış
açısıdır. Bazı kaynaklarda; bileşen (component) bakışı olarak da açıklanmaktadır. Bu
amaçla; bu yazımızın asıl konusu olan "bileşen" (component) diyagramları
kullanılmaktadır.
 5-) Ortam Bakışı (Environment View): Donanımın (üzerinde yazılımın çalışacağı), fiziksel
mimarisinin ortaya konduğu bakış açısıdır. Bazı kaynaklarda; dağıtım (deployment) bakışı
olarak da açıklanmaktadır. Bu amaçla; ileriki yazılarımızda açıklanacak olan "dağıtım"
(deployment) diyagramları kullanılmaktadır.
 Bileşen diagramları
 Gerçekleme bakışı, geliştirilen yazılım sisteminin alt modüllerini ortaya koymayı hedefler.
Bu amaçla kullanılan modelleme elemanları, bileşenler ve paketlerdir (package). Paketler;
yazılımın üst seviyedeki fiziksel parçaları olup katmanlar halinde oluşturulur. Her katmanın
bir arayüzü bulunmaktadır. Örneğin; istemci-sunucu uygulaması geliştirdiğimizi düşünelim.
Bu sistem için paketler; istemci, istemciye erişimi sağlayacak olan sürücü (bir kütüphane
olarak oluşturulabilir veya hazır bir sürücü kullanılabilir), sunucu tarafında bağlantıyı
sağlayacak olan sunucu kayıt yöneticisi, istemcinin isteklerini karşılayacak olan sunucu
hizmet yöneticisi olabilir. Geliştirilecek sistemin gereksinimlerine bağlı olarak, bu paketlerin
sayısını arttırabilir veya azaltabilirsiniz.
 "Temel bileşen diyagramı" (main component diagram) ile, yazılım sistemi içindeki tüm
paketleri bir diyagram üzerinde göstermek mümkündür. Şekil 1’ de yukarıda açıklanan
örneğe ilişkin, temel bileşen diyagramı verilmektedir. Bu sayede, sisteme dışarıdan bakan
birisi (müşteri, testçi, programcı, tasarımcı veya analist) sistemi basit bir yapıda
görebilmektedir.

Şekil 1: Temel bileşen diyagramı örneği

 Bileşen diagramları
 Genel olarak; tek başına çalışabilen alt modülleri bileşen olarak düşünebilirsiniz. Bu bileşenler; yer
değiştirilebilir olmalı ve birini çıkarıp diğerini yerleştirmek, sistem üzerinde fazla değişikliğe yol
açmamalıdır. Bu amaçla; bileşenlerin arayüzlerinin gerçekleniyor olması yeterlidir. Bileşenler sayesinde,
sisteminiz daha esnek bir yapıya kavuşurken bakım yapılabilirliği de artmaktadır. Aynı arayüzü sağlayan
başka bir bileşeni sisteme entegre ettiğiniz durumda sistem, mevcut yapıda herhangi bir değişiklik
olmadan çalışmaya devam edecektir.
 Bileşenler oluşturulurken, aşağıdaki noktaları göz önünde bulundurmak gerekmektedir:
 * Steryotipleri bu diyagramlardaki bileşenler üzerinde kullanabilirsiniz. Örneğin; <<library>> veya <<web
service>> gibi.
 * Bileşenler yer değiştirilebilir olduğu için, gerekli arayüzler sağlanıyor olmalıdır.
 * Bileşenlere ayırıcı isimler verilmelidir. Bu sayede, dışarıdan sistemi inceleyenlerin sistemi anlaması
kolaylaşmaktadır.
 * Detaylı tasarımda bileşen diyagramlarını kullanırken, ortama özel uzantıları kullanmanız yarar
sağlayacaktır. Örneğin; dispatcher.cpp veya handler.cs gibi.
 * Bileşenlerin gerçekleştirdiği arayüzler, lolipop sembolü ile gösterilmelidir. Aslında bu arayüzler,
gerçekleme ilişkisi (realization association) ile kesikli çizgilerle de gösterilebilmektedir. Ancak; diyagram
üzerinde lolipop diyagramları algılamayı daha kolay sağlamaktadır. Lolipop sembolleri, genelde bileşen
diyagramlarının solunda gösterilir. Birçok tasarım aracında bu sembol bulunmamaktadır.
 * Diyagramların okunurluğunu bozmamak için, sadece gerekli arayüzler diyagram üzerinde
gösterilmelidir.
 * Bileşenleri, sadece arayüz üzerinden diğer bileşenlere bağımlı yapmalısınız. Bağımlılıkları; soldan
sağa veya yukarıdan aşağıya göstermek genelde tercih edilir.
 * Kullanıcı arayüz bileşenleri ve veritabanı modelleme için, bileşen diyagramlarını tercih etmeyin.
 Bileşen diagramları
 Bileşen diyagramları, sadece kaynak kod dosyalarını göstermek için kullanılmaz. Örneğin; istemci-
sunucu örneğinde, istemci tarafındaki dll’leri ve .exe’yi aynı bileşen diyagramında göstermek
mümkündür. Bazı kaynaklarda bu bileşenler; dağıtım (deployment) diyagramları olarak da ifade
edilmektedir.

Rational Rose (2002 versiyonu)

tasarım aracında, bileşen diyagramı
oluşturabilmek için Şekil 3’de verilen
semboller kullanılabilmektedir.
Şekil 2: Bileşen diyagramları içindeki dağıtım diyagramları

Şekil 3: Rational Rose içindeki bileşen diyagramına ilişkin özel semboller

 Bileşen diagramları
 Şekil 4’ de, 2 tane .dll kullanan (algo.dll ve network.dll) bir "client.exe" uygulamasının
bileşen diyagramı gösterilmektedir. Bağlantıyı sağlamak için "connector.cpp" içindeki
arayüzler, istekleri yapmak için "handler.cpp" içindeki arayüzler kullanılmaktadır. Şekilde,
.obj dosyaları ve bu dosyaları oluşturan .cpp dosyaları gösterilmektedir. "main.cpp"
dosyasının içinde, "connector.cpp" ve "handler.cpp" içindeki bazı metotlar kullanıldığı için
bağımlılık oku gösterilmiştir.

Şekil 4:Örnek bir bileşen diyagramı

Kaynaklar
 www.Csharpnedir.com
 Sefer Algan(algans@itu.edu.tr)
 www.uml.org