Uml etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Uml etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

14 Şubat 2016 Pazar

UML ile "Sequence" Diyagramları

Sequence" Diyagramları

Bu makalemizde UML’in en önemli diyagramlarından biri olan "Sequence" diyagramlarını inceleyeceğiz. "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 :NesneIsmiformatı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. 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ğiaktivitedir(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. 


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


Ş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ı 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. 

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

Yukarıdaki örnekte dikkat ederseniz kolaylık olması açısından aynı nesne birden fazla zaman çizgisine sahip olabilmektedir. (Bkz : Nesne 1 zaman çizgisi)
Share:

12 Şubat 2016 Cuma

UML İLE ÖRNEK ÇALIŞMA

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

UML TEMELLERi



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.
İş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.

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ş yada 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.

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

UML DE DİYAGRAM ÇEŞİTLERİ


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.

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

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

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 

Ö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 


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.
Share:

UML ANALİZ NEDİR?

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 imkansız hale gelmiştir. Bu yüzden standart bir modelleme ve analiz diline ihtiyaç duyarız. Programımızın analiz ve dizayn 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 makinasına 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



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

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. 




Share: