UML’de Class Diyagramları (Temeller)

Nesne yönelimli programlamada her bir nesnenin konseptini belirten yapılara sınıf (class) adı verilmektedir. Sınıflar çok farklı yapılarda ve işlevlerde olabilirler. Bununla birlikte, genellikle programlamada bütün iş tek bir sınıfın üzerine yüklenmez. Kuracağınız sistem ile ilgili önce temel sınıflar belirlenip daha sonra bunlar arasındaki bağlantıların açıklanması gerekir. Bunu bir yazılım geliştirme sürecinin tasarım aşamasında yaparız. Bunu yaparken de muhtemelen UML’in nimetlerinden faydalanıyor oluruz.

İnternette UML diyagramlarını aratsanız veya biri size bir UML diyagramı gösterse, muhtemelen göreceğiniz şey bir Class (Sınıf) Diyagramı olacaktır. Çünkü bu diyagram UML’de en sık kullanılan diyagramdır. Class diyagramı, sistemde var olan nesnelerin türünü ve onlar arasındaki statik ilişkiyi açıklayan bir diyagram türüdür. Burada diyagramların isimlerini ve bazı kavramları Türkçe’ye çevirmeden kullanacağım. Bu gibi diyagramlarda Türkçe çeviri anlamlı olsa da ileride göreceğimiz diyagramlarda anlaşılmayı zorlaştıracak çeviriler ile karşılaşabilirsiniz. Bu yüzden diyagram isimlerini ve bazı kavramları İngilizce olarak bırakacağım.

Class diyagramları UML’de Yapı Diyagramları (Structure Diagrams) kısmında yer alır ve az önce söylediğim gibi, nesne türlerinin statik ilişkilerini gösterir. Burada nesne türünden kasıt programlamada kullanılan sınıflardır. Elbette diyagramda sınıflar arasındaki ilişkiyi göstermeden önce sınıfın özelliklerini göstermek gerekir. Bir sınıfın UML diyagramında 2 özelliği (feature) bulunur: Öznitelikler (Attributes) ve İşlemler (Operations). Bir sınıfın UML diyagramındaki özniteliği, aslında programlamada o sınıfın üye değişkenlerine (member variables) karşılık gelir. Bir sınıfın UML diyagramındaki işlemi ise aslında programlamada o sınıfın üye fonksiyonu (member function) veya metodu (method) anlamına gelir.

Sınıfın özniteliklerinin bir yazım biçimi vardır. Her bir öznitelik kutucuğun ortasındaki alanda bir satırlık yer kaplar. Bir özniteliğin genel formu şu şekildedir:

<Görünürlük> <İsim>: <Tür> <Multiplicity> = <Varsayılan Değer> {<Property String>}

Bir özniteliğin sadece isminin yazılması zorunludur. Diğer kısımlarının belirtilmesi zorunlu değildir. Özniteliğin kısımları ile ilgili temel açıklamar şöyledir:

• Görünürlük (Visibility): Bu özniteliğin dışarıdan erişim ilkesinin ne olduğunu belirtir. Örneğin C++’ta kullanılan Access Modifier‘lar bu durumu birebir karşılar. Eğer bir sınıfın üye değişkeni public ise buraya “+“, private ise buraya “–“, protected ise buraya “#” işareti konulur.
• İsim (Name): Genellikle buraya o özniteliğe programlamada karşılık gelen değişkenin ismi yazılır.
• Tür (Type): Bir özniteliğin türü, programlamada ona karşılık gelen değişkenin türünü belirtir. Bu da öznitelik ile ilgili kısıtlamaları (alabileceği minimum ve maksimum değerler gibi) daha iyi anlamamıza yardımcı olur.
• Multiplicity (Çokluk): Bir özniteliğin Multiplicity’si, o özniteliğe kaç adet nesnenin karşılık geleceğinin göstergesidir. Bu konuyu daha sonra inceleyeceğiz.
• Varsayılan Değer (Default Value): Özniteliğin, yani değişkenin ilk değerini belirtir.
• Property String (Nitelik String’i): Bu kısımda ise öznitelik ile ilgili çeşitli özellikler yer alır. Örneğin “read-only” ile bu özniteliğin sadece okunabilir olduğu anlaşılabilir. Eğer bu kısım boş bırakılırsa, varsayılan olarak özniteliğin düzenlenebilir bir yapıda olduğu anlaşılmalıdır.

Şimdi hemen konu ile ilgili bir örnek verelim. Burada C++’ta bildirimi yapılan bir sınıfı UML diyagramı ile göstereceğiz. Sınıfımızın ismi Employee olacak ve bir çalışan ile ilgili temel değişkenlere sahip olacaktır:

class Employee{
private:
    string name;
protected:
    string address;
    string phone;
public:
    int salary = 3000;
    bool isActive;
};

Gördüğünüz gibi görünürlük kısmında değişkenin private, protected ve public olmasına göre değişik semboller kullanılmaktadır. İsim ve tür kısımlarını ise değişkenin tür ve isimleri ile aynı yaptık. İlk değer almış olan değişkenlerin değerlerini varsayılan değer kısmında gösterdik. Burada Multiplicity ve Property String kısımlarını kullanmadık. Bu kısımları ileride daha ayrıntılı bir biçimde göreceğiz.

Şimdi bir sınıfın sahip olduğu metotları UML diyagramında nasıl göstereceğimize bakalım. UML’de bir sınıfın sahip olduğu metotlar işlem (operation) olarak adlandırılır ve işlemler sınıf kutucuğunda en alt kısma yazılır. Sınıfın her metodunu işlem olarak yazmamıza gerek yoktur. Bu konudan birazdan bahsedeceğim. İşlemlerin tıpkı öznitelikler gibi belli bir yazım formatı bulunmaktadır ve her bir işlem bir diyagramda bir satırı kaplamaktadır. Bu yazım biçimini şöyle özetleyebiliriz:

<Görünürlük> <İsim>(<Parametre Listesi>): <Geri Dönüş Türü> {<Property String>}

Yine bu kısımları tek tek açıklayalım:

• Görünürlük (Visibility): Bu işlemin dışarıdan erişim ilkesinin ne olduğunu belirtir. Alabileceği değerler ve anlamları özniteliklerdeki gibidir.
• İsim (Name): Genellikle buraya o işleme programlamada karşılık gelen metodun ismi yazılır.
• Parametre Listesi (Parameter List): Programlamada metodun aldığı parametreler tür bilgileri ile birlikte buraya yazılır. Bu kısmın formatını birazdan açıklayacağım.
• Geri Dönüş Türü (Return Type): Basitçe metodun geri dönüş türünü belirtir.
• Property String (Nitelik String’i): Özniteliklerde olanla aynı anlama gelir.

Bir işlemde parantezler isimle beraber zorunlu olarak yazılmak zorundadır. Diğer kısımlar ise seçenekseldir. Parantezlerin içinde yer alan parametre listesi ise tıpkı öznitelikler gibi şu formatta yazılabilir:

<Parametre Yönü> <İsim>: <Tür> = <Varsayılan Değer>

Bu kısımların anlamları ise şöyledir:

• Parametre Yönü (Parameter Direction): Bu parametrenin bir girdi parametresi, çıktı parametresi veya her iki işi de yapan bir parametre olduğunu belirtir. Eğer parametre metoda sadece değer gönderen bir girdi parametresi ise in, metottan sadece değer alan bir çıktı parametresi ise out, her iki işi de yapabilen bir parametre ise bu kısma inout kelimesi yazılır.
• İsim (Name): Metodun parametre tanımındaki isim ile buradaki isim genellikle aynı şeyi ifade eder.
• Tür (Type): Metodun parametre tanımındaki tür ile buradaki tür genellikle aynı şeyi ifade eder.
• Varsayılan Değer (Default Value): Bazı programlama dillerinde parametrelere varsayılan değer verme mekanizması bulunur. İşte bu mekanizmada verilen değerler bu kısma yazılabilir.

Parametre listesine yazılan parametreler, tıpkı metot tanımlamalarında olduğu gibi virgül (,) ile ayrılırlar. Şimdi az önce verdiğimiz Employee sınıfını biraz değiştirelim. Bu sınıfın tüm üye değişkenlerini private hale getirip bu değişkenlerin bazılarına erişim sağlayan (okuma ve yazma yapan) çeşitli metotlar tanımlayalım:

class Employee{
private:
    string name;
    int salary;
    bool isActive;
public:
    Employee(string name, int salary, bool isActive);
    string getName();
    void setSalary(int newSalary);
    int getSalary();
    void setActive(bool status);
    bool getActive();
};

Gördüğünüz gibi sınıfın Constructor (Yapıcı) metodu için herhangi bir geri dönüş değeri belirtmedik. Ayrıca kullanımını göstermek adına setSalary ve setActive fonksiyonlarında parametrelerin yönünü de belirttim. Nesne yönelimli programlama yaklaşımından bildiğiniz gibi "get" ve "set" ile başlayan metotlar, bir sınıfın private değişkenlerine erişim sağlayan metotlardı. Bu metotları UML diyagramlarında göstermeye gerek yoktur. Çünkü zaten bir özniteliğin Property String’ine onun okunabilir veya yazılabilir olduğu durumunu (istersek) belirtebiliriz. Bu metotları UML diyagramlarında kullanmak gereksiz bir uzamaya yol açabilir.

Bir sınıfın, onun üye değişkenlerinin ve fonksiyonlarının UML diyagramında nasıl gösterileceğini gördük. Daha önce de belirttiğimiz gibi, tasarımda bir sınıf bütün işleri üstüne yüklenmez. O zaman zaten UML diyagramıyla sınıfları göstermenin bir anlamı kalmazdı. Fakat çoğu zaman birden fazla sınıfı diyagrama yerleştirmek de bir çözüm sağlamaz. Sınıflar birbirleriyle ilişki içerisinde olan yapılardır. Bu ilişkileri UML diyagramlarında da göstermek gerekir. Elebete ilişkinin türüne göre gösterim de değişiklik gösterecektir.

UML diyagramlarında sınıflar arasındaki ilişkiler çizgiler ve oklar ile temsil edilir. Elbette çizginin ve okun tipi, onun ne tür bir ilişki olduğu ile ilgili bize ipucu verir. UML’de temel olarak 6 tür ilişki (relationship) bulunur. Bazı kaynaklarda bu türleri birbirinin altına yerleştirerek, daha az sayıda ilişkiden bahsedilebilir. Bu ilişkiler şunlardır:

• Association (Ortaklık)
• Dependency (Bağımlılık)
• Aggregation (Birleşme)
• Composition (Kompozisyon)
• Generalization (Genelleme) veya Inheritance (Kalıtım)
• Realization (Gerçekleme)

Bu ilişkilerin UML diyagramlarındaki gösterimleri şöyle özetlenebilir:

Bu kavramları doğrudan İngilizce olarak kullanacağım. Öncelikle Association (Ortaklık) kavramından başlayalım. Association’lar iki sınıf arasında düz çizgi olarak gösterilir. İki sınıfın birbiri ile ilişkili olduğunu göstermenin en temel yoludur. Association’ların uç kısımlarında herhangi bir ok işareti yer almayabilir. Bu durumda Association ile birbirine bağlanan sınıfların, birbiri ile çift yönlü (bidirectional) bir ilişkiye sahip olduğu anlaşılır. Ancak Association’larda tek yönlü bir ilişki de mevcuttur. İlişki türüne göre Association’lar 3 tiptir:

• Unidirectional Association (Tek Yönlü Ortaklık)
• Bidirectional Association (Çift Yönlü Ortaklık)
• Self/Reflexive Association (Öz/Dönüşümlü Ortaklık)

Association ilişkileri ile programlamada sınıf içerisinde başka bir sınıf türünden değişken barındırılan durumlarda karşılaşılır. Unidirectional Association (Tek Yönlü Ortaklık) sadece bir sınıfın diğer sınıf türünden bir değişkeni barındırdığı durumu anlatır. Bidirectional Association (Çift Yönlü Ortaklık) ise her iki sınıfın da birbirleri türünden değişkenleri barındırdığı durumu anlatır. Self/Reflexive Association (Öz/Dönüşümlü Ortaklık) ise bir sınıfın yine kendi türünden bir değişkeni içerisinde barındırdığı durumu anlatır. Association türlerinin UML’de gösterimi şu şekilde özetlenebilir:

UML diyagramlarında sınıflar yukarıdaki gibi sadece bir dikdörtgenin içine sınıf adı yazılarak da gösterilebilir. Bu basitleştirilmiş bir gösterimdir ve sınıfın ayrıntılarına girmeden, sınıflar arası ilişkileri daha düzgün bir şekilde göstermek için kullanılır. Bu konudan yola çıkarak Association’ların en önemli kullanım yerlerinden birini açıklamakta fayda var. Diyelim ki sınıfın işlemlerini (metotlarını) önemsemiyoruz. Sınıfın bütün özniteliklerini sadece Association’lar ve bu sınıf kurucukları ile göstermemiz mümkündür. Örneğin aşağıdaki Car sınıfını göz önüne alalım:

Bu sınıfın 3 adet public değişkeni bulunmaktadır ve hepsi de ayrı bir sınıf türünden değişkenlerdir. Nesne yönelimli programlamada her şeyi birer nesne olarak ele almamız ideal bir yaklaşımdır. Bu nedenle aslında bu değişkenler de birer nesnedirler ve Car sınıfı bunları kullanır. Bu durumda burada bir Unidirectional Association durumu vardır. Yani kısaca, sadece üye değişkenlerini dikkate aldğımız bir sınıfın gösterimini öznitelikler yerine Association kullanarak da yapabiliriz. Örneğin Car sınıfını Association’lar ile şu şekilde gösterebiliriz:

Bu gösterimde öznitelikler ile belirttiğimiz her şeyi burada da belirtebiliriz. Öncelikle okun yönü kaynaktan hedefe doğrudur. Burada kaynak diğer sınıfları kullanan sınıf olan Car sınıfıdır. Hedef sınıflar ise String, Date ve Color sınıflarıdır. Hedef sınıfların yanında, o sınıfa ait tanımlanmış olan değişkenlerin isimlerini ve görünürlük bilgilerini yazabiliriz. Genel olarak bir Class diyagramının sadece Association’lar kullanılarak gösterilmesi, yukarıdaki gibi belirli türlerin yoğunluklu olduğu ve ilişkilerin gösterimine önem verildiği durumlarda kullanılır. Bu gösterimin bir avantajı da birazdan açıklayacağım Multiplicity kavramını daha detaylı kullanabilmesidir.

Şimdi yazının başından beri karşımıza çıkan Multiplicity kavramına bakalım. Bir özniteliğin Multiplicity (Çokluk) değeri, ona en az ve en çok kaç tane nesne atanabileceğinin veya referans gösterilebileceğinin bir göstergesidir. Bir Multiplicity şu şekilde ifade edilir:

<Alt Sınır Değeri>..<Üst Sınır Değeri>

Eğer alt sınır ve üst sınır değerleri birbirine eşitse, tek bir sayı ile de Multiplicity’leri göstermek mümkündür. Eğer bir Multiplicity’nin üst sınırı belli değilse, üst sınır değeri yerine "*" işareti koyarak bunu belirtebilirsiniz. Sık kullanılan Multiplicity örnekelri şöyledir:

Bir öznitelikte Multiplicity kullanırken, özniteliğin tanımında (yukarıda gösterdiğim) uygun yere "[]" parantezleri içine Multiplicity yazılır. Hemen bir örnek verelim:

Yukarıda bir futbol takımını temsil eden SoccerTeam isimli bir sınıf verilmiştir. Bildiğiniz gibi bir futbol takımında sahada 11 adet oyuncu bulunmaktadır. Bu oyunculardan 1 tanesi kalecidir ve diğer 10 kişi çeşitli pozsiyonlarda konumlandırılabilir. Yukarıda da kaleciyi belirten goal_keeper özniteliğinin Multiplicity değeri 1’dir. Bunun anlamı takımda bir kaleci mutlaka olmalıdır. Diğer özniteliklerden ise forvet sayısının 2 ile 3 arasında, ortasaha ve defans sayılarının ise 3 ile 4 arasında olması gerektiği anlaşılmaktadır. İşte Multiplicity bir nesneye böyle bir anlam katar. Ancak onun en doğru kullanım alanı Association gösterimindedir. Hemen bir örnek verelim:

Yukarıdaki UML diyagramında müşteriyi belirten Customer sınıfı ve siparişi belirten Order sınıfı verilmiştir. Association ilişkisinden anlayacağınız gibi buradaki ilişki iki yönlüdür. Taraflarda yer alan Multiplicity değerlerinden kimin kime ne kadar sayıda ihtiyaç duyduğunu görebilirsiniz. Buradaki örnekten "bir müşterinin birden fazla siparişi olabilir veya hiç olmayabilir" ve "bir sipariş sadece bir müşteriye ait olabilir" gibi çıkarımlar yapılabilir. Multiplicity’lerin Association ile kullanımının en büyük farkı, her iki taraf için de Multiplicity değerlerini kolaylıkla belirtebiliyor oluşumuzdur. Multiplicity’lerin Association’lar ile kullanımında çeşitli kavramlar ortaya çıkar. Bu kavramlar:

• Optional (Seçeneksel): Alt sınırın 0 olduğunu belirtir.
• Mandatory (Zorunlu): Alt sınırın 1 veya daha fazla olduğunu belirtir.
• Single-valued (Tek Değerli): Üst sınırın 1 olduğunu belirtir.
• Multivalued (Çok Değerli): Üst sınırın 1’den büyük (genellikle “*”) olduğunu belirtir.

Şimdi hem öznitelikleri, hem Association’ları hem de Multiplicity kavramını kullanan bir UML diyagramını C++ koduna dökelim:

class CreditCard{
public:
    string cardNumber;
    Customer cardOwner;
};

class Order{
    Customer orderOwner;
};

class Customer{
private:
    string name;
public:
    vector orders;
    vector cards;
};

Çokluk belirten değişkenlerde çoğul isimler kullanmanız tavsiye edilir. Ayrıca çokluk belirten değişkenlerde vector gibi yapıların kullanıldığına dikkat edin. Normalde bu tür her şeyin birbiri ile ilişkili olduğu sistemler pek uygun bir tasarım örneği değildir. Ancak burada gördüklerimizi pekiştirmek adına bir örnek verdiğimden şimdilik bu konuyu es geçebiliriz. Association’lar ile ilgili çok daha fazla özellik bulunsa da şimdilik bu konuyu burada bitireceğim. Çünkü onları da açıklamak yazıyı fazlaca uzatacağından, bu bilgileri daha sonra vereceğim.

Nesne yönelimli programlamada kalıtım (inheritance) kavramını bildiğinizi varsayıyorum. Kısaca kalıtım, bir nesnenin çeşitli özelliklerini başka bir nesneden devralmasına denir. Bu da aslında sınıflar arasında bir tür ilişkidir. Bu ilişkiyi UML diyagramında göstermek için Generalization (Genelleştirme) denilen bir ilişki türü kullanılır. Bu ilişki normal bir çizginin ucuna içi boş üçgen yerleştirilerek gösterilir.

Generalization’a bir örnek verecek olursak, öncelikle bir şirketteki müşterileri temsil eden Customer sınıfını ele alalım. Müşterileri bir sınıfla göstermek güzel olsa da büyük bir şirkette (örneğin bir bankada) müşteriler bireysel ve kurumsal olmak üzere iki çeşittir. Bu müşterilerin ortak özellikleri olduğu gibi, birbirinden farklı özellikleri de bulunabilir. Bu durumda bireysel müşterileri PersonalCustomer sınıfı ile, kurumsal müşterileri de CorporateCustomer sınıfı ile ayrı ayrı temsil edebiliriz. Ancak bu sefer de aynı özellikleri iki ayrı sınıfta 2 kez tanımlamış oluruz.

Bu sorunu en iyi kalıtım ile çözeriz. Ortak özellikleri Customer sınıfında toplayıp PersonalCustomer ve CorporateCustomer sınıflarını bu sınıftan türetebiliriz. Böylelikle sadece farklı özellikleri bu sınıflarda barındırmış oluruz. Burada Customer sınıfını Supertype (Üst Tür), PersonalCustomer ve CorporateCustomer sınıflarını ise Subtype (Alt Tür) olarak adlandırabiriz. Bu isimlendirmeler bazı kaynaklarda Superclass (Üst Sınıf) ve Subclass (Alt Sınıf) olarak geçse de aslında ikisi farklı anlamlara gelir (buna daha sonra değineceğiz). Şimdi bu kalıtım ilişkisini UML diyagramında gösterelim:

Kalıtımın programlamaya sağladığı en önemli katkı Substitutability (Yer Değiştirebilirlik) prensibini sağlayabilmesidir. Bu prensibe göre programlamada Supertype türünden tanımlı bir yere onun Subtype’ını koyduğunuzda mükemmel bir şekilde çalışabilmelidir. Örneğin Customer sınıfı için bildirimi yapılmış bir yere onun Subtype’ı olan PersonalCustomer sınıfı türünden bir nesne atarsak, bu prensibe göre yazılmış kodda her şey düzgünce çalışacaktır. Elbette PersonalCustomer sınıfı Customer sınıfına göre farklı özelliklere sahip olabilir (Polymorphism). Ancak bu sınıfın kullanıcısı bundan haberdar olmaz.

Burada Subtype ile Subclass arasındaki farkı anlamak gerekir. Eğer bir sınıf her koşulda onun Supertype’ı ile yer değiştirebiliyorsa, kalıtımın kullanılıp kullanılmadığına bakılmaksızın bu sınıf yer değiştirilen sınıfın Subtype’ı olarak adlandırılır. Eğer burada iki sınıf arasında bir kalıtım ilişkisi varsa bu sınıf o zaman Subclass olarak adlandırılabilir. Subclass ve Subtype oluşturmanın pek çok yöntemi vardır. Kalıtım bu yöntemlerden sadece biridir. Şimdi aşağıdaki C++ kodunu UML diyagramında gösterelim:

class Vehicle{
    int numberOfWheels;
    Color color;
};

class Motorcycle : public Vehicle {
    string type;
};

class Tractor : public Vehicle {
    double backWheelRadius;
    double frontWheelRadius;
};

class Truck : public Vehicle {
    int payloadCapacity;
};

Son olarak UML diyagramlarında çeşitli kısıtlamaları ve yorumları yazabileceğimiz bir gösterimden bahsedip yazıyı sonlandıracağım. UML’de herhangi bir eleman ile ilişkili olan veya herhangi bir eleman ile ilişkili olmayıp UML’in tamamını kapsayan bir yorum veya kısıtlama yazmak istediğimizde, sağ-üst köşesi kıvrılmış olan bir dikdörtgen şekli kullanırız. Bu şeklin içine yorumu veya kısıtlamayı yazarız. Örneğin Figür 8’de SoccerTeam ile ilgili bir kısıtlama böyle bir şekle yazılmıştır. Bir yorumu veya kısıtlamayı bir elemanla ilişkilendirmek için, onunla eleman arasına kesikli çizgi çekilmektedir. Bu kesikli çizgiyi anlamak bazen okunabilirlik açısından sıkıntı oluşturabileceğinden, çizginin sonuna keyfi olarak açık bir çember yerleştirilebilir. Örnek bir yorumu şu şekilde verebiliriz:

Bu yazıda Class diyagramlarının en temel özelliklerinden bahsettik. Öznitelik ve işlem kavramını açıkladık ve bunların programlamadaki yerini göstermeye çalıştık. Ayrıca sınıflar arasındaki çeşitli ilişkilerden bahsettik. Bu bölümde sadece Association ve Generalization (Inheritance) ilişkilerinden bahsettik. Özellikle Association kullanan diyagramlarda oldukça önemli bir yere sahip olan Multiplicity kavramını da açıklamaya çalıştık. Bu yazıda gördüklerimizin yanında, Class diyagramlarının daha gelişmiş özelliklerini göstereceğim bir yazı daha yazmayı planlıyorum.

REFERANSLAR

1. https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
2. https://www.uml-diagrams.org/multiplicity.html