Ana içeriğe atla

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz.
UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir.
image
Şekil 1. Class Diyagram
Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Amaç, diyagramın sadece belirli kısımlarının (sınıf özelliklerinin ve işlevlerinin) gösterimini sağlamaktır. Bir sınıf diyagramında kullanılabilecek temel yapılar bunlar olmasına rağmen "constraints" ve "notes" dediğimiz elemanlar da mevcuttur. 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.

image
Şekil 2. Örnek daire sınıfı
Şekil2’deki sınıf diyagramını incelerken +, - işaretleri görülmektedir. Sınıf diyagramında yer alan nitelik ve method isimlerinin önünde aşağıda sıralanan bezelemer (adornments) kullanılabilir.
  • Private (-); Nitelik yada metota sınıf dışında erişim engellenmiştir.
  • Protected (#); Nitelik yada metota erişim sınırlandırılmıştır.
  • Public (+); Nitelik yada metot genel kullanıma açıktır.
Sınıf diyagramları kendi başlarına bir şey ifade etmez ancak aralarındaki ilişkilerle birlikte incelendiklerinde anlamlıdır. UML içerisinde sınıflar arasında 4 farklı ilişki tanımlanabilir;
  1. Bağlantı İlişkisi (Association)
  2. Genelleme/Kalıtım İlişkisi (Generalization/Inheritance)
  3. Bağımlılık İlişkisi (Dependency) (Aggregation, Composition)
  4. Gerçekleştirim İlişkisi (Realization)
1. Bağıntı İlişkisi (Association Class)
Bağıntı ilişkisi, sınıf diyagramlarında en çok kullanılan ve en basit ilişki türüdür. Çoğu zaman referans tutma biçimindedir. İki nesne arasında varolan bağıntının çokluları (n:m), ilişki bağıntı sınıfı ile ifade edilebilir. Bağıntı ilişkisi iki nesne arasına çizilen düz çizgi ile belirtilir.  Bağıntı  ilişkileri için tanımlanmış bilgiler aşağıdaki gibidir;
  • Bağıntının Adı
  • Sınıfın bağıntıdaki rolü
  • Bağıntının çokluğu
Bağıntı adı, iki sınıf arasındaki ilişkinin küçük bir açıklamasıdır. Bu açıklama ile birlikte yön bilgisi de belirtilebilir.

image
Şekil 3. Bağıntı ilişkisinde bağıntı adı ve yönü
Sınıf diyagramlarında sınıflar arasında bire n ilişki kurulabilir. Bir sınıf, n tane başka bir sınıf ile ilişkiliyse buna bire-çok (1-n) ilişki denir.
image
Şekil 4. Bağıntı ilişkisinde çokluk gösterimi
Şekil4’de işçi-işveren ilişkisinde bir şirketin en az bir işçisi olduğu (1..*), bir işçinin ise 0 ya da herhangi bir sayıda(*) şirkette işçi olarak çalışmış olabileceği ifade edilmektedir. İki sınıf arasında yanlızca tek bir bağıntı çizilmesi gibi bir kısıt yoktur. En temel bağıntı ilişki tipleri 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 (Manidar bir örnek:));
image
Şekil 5. Reflexive ilişki örneği
Şekil5’i inceleyecek olursak , patron bir eleman olmasına rağmen kendisi gibi eleman olan birden çok çalışandan sorumludur diyebiliriz.
2. Sınıflar Arasında Türetme (Inheritance) ve Genelleme (Generalization) İlişkisi
Nesne tabanlı programlama tekniğinin en önemli parçası türetme (inheritance) dir. Türetme yoluyla bir sınıf başka bir sınıfın var olan özelliklerini alarak, o sınıf türünden başka bir nesneymiş gibi kullanılabilir. Bir sınıfın işlevleri türetme yoluyla genişletilecekse, türetmenin yapılacağı sınıfa taban sınıf (base class), türetilmiş olan sınıfa da türemiş sınıf (derived class) denir. Şekilsel olarak türemiş sınıftan taban sınıfa bir ok olarak belirtilir.
image
Şekil 6. UML’de türetme örneği
UML 'de türetme Şekil 6’da gösterilmiştir. Türetme ağacında daire ve kare birer şekildir. Sınıflar arasındaki türetme işlemi ucu açık üçgen ve düz bir çizgiyle gösterilir. Bu durumda "Şekil" sınıfı ana sınıf (parent class), daire ve kare 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.
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 gerekmektedir.
3. Bağımlılık İlişkisi (Dependency) (Aggregation, Composition)
3.1. İçerme (Aggregations) Bağıntı İlişkisi
Birden fazla parçadan oluşan sınıflar arasındaki ilişkiye "Aggregation" denir. 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. İçi boş elmas ile gösterilen ilişkilerde herbir parça ayrı bir sınıftır ve tek başlarına anlam ifade ederler.
image
Şekil 7. İçerim ilişki örneği
3.2. Oluşum (Composition) Bağıntı İlişkisi
Parça bütün arasında çok güçlü bir ilişki yoktur. Ama bazı durumlarda bütün nesneyi yarattığımızda parçalarının da yaratılmasını isteriz. Bu tür ilişkilerin gösterilmesine ise "COMPOSITE ASSOCATION" denir. Bu ilişki diğerine göre daha güçlü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.Bu durumda takılacak parçalar "constraint(koşul)" ile belirtilir.
image
Şekil 8. Oluşum ilişki örneği
Uygulamada oluşum ve içerim bağıntılarının kimi durumlarda birbirine karıştığı görülmektedir. Bunun nedeni, oluşum bağıntısınınaslında içerim nağıntısının daha güçlü bir biçimi olmasıdır. Her oluşum bağıntısı aslında aynı zamanda bir içerim bağıntısıdır. Belirleyici fark ise iki bağıntı türünün nesneleri birbirine bağlama gücü arasındaki farktır. İki bağıntı türü arasındaki farkları inceleyelim;
  • Oluşum bağıntısında her parça aynı anda sadece tek bir bütüne ait olabilir. Bu nedenle oluşum bağıntısında bütün tarafı çokluk değeri daima 1 olmak zorundadır. İçerim bağıntısında ise bir parçanın birden fazla bütün tarafından paylaşımı söz konusu olabilir.
  • Oluşum ilişkisinde parçanın yaşam süresi doğrudan bütünün yaşam süresine bağlıdırç Bütün nesnesi yaratılmadan parça nesnesi yaratılamaz ve bütün tarafındaki nesne silindiğinde parça nesnelerde onunla birlikte silinmelidir.
Aşağıda çeşitli bağıntı türlerinin bir arada kullanıldığı örnek bulunmaktadır.
image
Şekil 9. Genel bağıntı örneği
Yukarıdaki bağıntıda aşağıdaki ilişkiler yer almaktadır;
  • Her okulun sıfır ya da daha fazla öğrencisi yeralmaktadır.
  • Her okulda bir ya da daha fazla bölüm vardır.
  • Her bölüm tek bir okula bağlıdır.
  • Her bölüm bir ya da daha fazla sayıda ders açmaktadır.
  • Her bölüm bir ya da daha fazla öğretim üyesine sahiptir.
  • Her bölümün öğretim üyelerinden seçilmiş bir başkanı vardır.
  • Her öğretim üyesi bir ya da daha fazla bir bölümde görev yapmaktadır.
  • Her öğretim üyesi sıfır ya da daha fazla sayıda ders vermektedir.
  • Her ders bir ya da daha çok bölüm tarafından açılır.
  • Her dersi sıfır ya da daha fazla sayıda öğrenci almaktadır.
  • Her derse en az bir tane öğretim üyesi atanmıştır.
  • Her öğrenci bir ya da daha fazla sayıda okula kayıtlıdır.
  • Her öğrenci sıfır ya da daha fazla sayıda ders alabilir.
  • Her öğretim üyesi ya tekbir bölümün başkanıdır ya da hiçbir bölümün başkanı değildir.
4. Gerçekleştirim (Realization) İlişkisi
Gerçekleştirim lişkisi en çok kullanıcı arayüzlerinin (user interface) modellenmesinde kullanılır. Arayüz yanlızca method adlarını ve bunların parametrelerini içermektedir. Program yazarken, yanlızca arayüzlerin kullanılması ve arayüzü gerçekleştiren sınıfın diğer sınıflardan ayrı tutulması, yazılımın geliştirilmesi ve bakımında önemli kolaylık sağlar. Gerçekleştirim ilişkisi kesikli bir çizginin ucuna yerleştirilen içi boş bir üçgen ile gösterilir.
image
Şekil 10. Gerçekleştirim ilişkisi
Yukarıdaki örneği inceliyecek olursak; IHesapla adı verilen ve diğer sınıfların kullanımına açılmış arayüz sınıfı tanımlanmıştır. Bu sınıfta yer alan metotların gerçekleştirimi ise Hesapla sınıfı tarafından üstlenilmiş durumdadır. İyi yapılan bir tasarımda tüm sınıflar yanlızca arayüzde yer alan metotları kullanmalı, doğrudan Hesapla sınıfının metotları çağırılmamalıdır. Böylece Hesapla sınıfının gerçekleştirimi, uygulamamnın kalanını etkilemeksizin istendiği gibi değişebilir. Arayüzlerin diğer bir yararı arayüzün gerçekleştirimini yapan sınıfın kaynak kodunu, sınıfı kullanan diğer programcılar tarafından erişilmesi gereğini ortadan kaldırmasıdır. Bu nedenle arayüz sınıfları, kod gizliliğini sağlamak isteyen yazılım firmaları tarafından yaygın biçimde kullanılmaktadır.
Sınıf İlişkileri Özet Tablosu
No
İlişki
Örnek Gösterim
Açıklama
1 Bağıntı(Association) image İki sınıfın herhangi bir şekilde birbirleriyle iletişim kurmasıdır. Örneğin : Öğrenci ve Okul arasındaki ilişki
1.a Çokluk (Multiplicity) image İki sınıf arasındaki 1:n ilişkidir. Birden fazla öğrencinin okul ile olan ilişkisi olarak çıklanabilir. Şekildeki * işareti 1:n ilişkiyi göstermektedir.
1.b Yönlü Bağıntı (Directed Association) image Sınıflar arasındaki tek yönlü ilişkiyi gösterir. Ok işareti ile gösterilir.
1.c Dönüşlü Bağıntı(Reflexive Association) Belirgin bir çizimi yoktur. 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
2 Kalıtım/Genelleme(Inheritance/Generalization) image Bu ilişki, bir nesnenin bir diğerinin özel bir türü olduğu gerçeğini modellemek için kullanılır.
3 İçerme(Aggregation) image İki sınıf arasındaki “sahiptir” veya içerir türünden bağıntıları modellemekte kullanılır.Bütün parça içi boş elmas ile gösterilir.
3.a Oluşum(Composition) image İçerme ilişkisinin farklı bir çeşitidir. Tüm bağıntılar içinde en güçlü olanıdır. Parça-bütün ilişkilerini modellemekte kullanılır.
4 Gerçekleştirim(Realization) image Kullanıcı arayüzlerinin modellemesinde kullanılır. Arayüz yanlızca method adlarını ve bunların parametrelerini içermektedir.
Bir sonraki makalemizde UML diyagramlarından State (Durum) diyagramlarını ayrıntılı inceleyeceğiz.
Referanslar
Neslihan ÇALIŞKANEL

Yorumlar

  1. Neslihan Hanım,
    Klavyeniz sağlık çok güzel bir makale olmuş.
    Hoşcakalın.

    YanıtlaSil
    Yanıtlar
    1. Bu yorum bir blog yöneticisi tarafından silindi.

      Sil
    2. Bu yorum bir blog yöneticisi tarafından silindi.

      Sil
  2. Serdar Bey, yorumunuz için teşekkür ederim. En kısa zamanda yeni makalemizde buluşmak dileğiyle.

    YanıtlaSil
  3. Bu konuda internette rastladığım en güzel Türkçe makaleydi.

    YanıtlaSil
  4. Yorumunuz için teşekkürler.

    YanıtlaSil
  5. Güzel makale olmuş, elinize sağlık.

    YanıtlaSil
  6. web sitenizi çok beğendim iyi paylaşımlar dilerim.

    site satın al

    YanıtlaSil
  7. teşekkürler, gayet yararlı olmuş

    YanıtlaSil
  8. Bulup bulabileceğimiz en yararlı türkçe kaynak olmuş. Çok teşekkürler..

    YanıtlaSil
  9. Tek kelime ile harika bir makale. Bu kadar bilgiyi toplayip ogrenmem birkac gunumu alacakti. Sayenizde cok degerli bir zamani kazandirdiniz. Cok tesekkur ederim.

    YanıtlaSil
  10. Cok iyi yahu, türkce metin bulmak zor bu konularda, ingilizce ve diger yabanci dillerdekiler de gereksiz ayrinti da bogulmuslar. Iyi bir calisma olmus. Ellerinize saglik.

    YanıtlaSil
  11. Güzel yorumlarınız için teşekkürler.

    YanıtlaSil
  12. Çok teşekkürler. ellerinize saglik

    YanıtlaSil
  13. elinize sağlık. umarım yazmaya devam edersiniz...

    YanıtlaSil
  14. Çok güzel anlatılmış, teşekkürler

    YanıtlaSil
  15. Elinize sağlik gayet açik ve güzel bir şekilde konulara değinilmiş,sinav öncesi baya bi faydali oldu ..

    YanıtlaSil
  16. Neslihan hanim cok güzel anlatmissiniz tesekkürler

    YanıtlaSil
  17. Neslihan Hanım çok güzel hazırlanmışınız. Diğer UML ile ilgili yazılarınızı da okuyorum. Çok teşekkür ederim size.

    YanıtlaSil

Yorum Gönder

Bu blogdaki popüler yayınlar

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara