UML Class Diyagramları
Bu yazımızda UML Class Diyagramlarını öğreneceğiz. Ancak bundan önce UML kavramına bakalım.
UML(Unified Modeling Language) nedir?
UML, bir sistemin tasarımını görselleştirmek için yazılım mühendisliği alanında genel amaçlı modelleme dilidir. Yazılı bir dil değildir. Farklı amaçlar için kategorilere ayrılmış olsa da, genel itibariyle modelleme için kullanılır. 1995 yılında, yazılımlarda bir standart yaklaşım oluşturmak için geliştirilmiştir. Yani UML diyagramları ile önceden modellediğiniz bir yazılım projesini, modele uygun olacak şekilde herhangi bir dil ile geliştirebiliyorsunuz. Bu da yazılım mühendisleri arasında ortak bir dil oluşturuyor. İlk çıktığı zamandan beri sürekli geliştirme göstererek, birçok farklı dala ayrılmıştır. Aşağıda UML diyagramlarının kategorilerini görebiliyoruz. Bizim bu yazımızda bahsedeceğimiz Class Diagram, Structure Diagram altında bulunmakta. Structure Diagrams(Yapısal Diyagramlar), modellenmekte olan sistemde bulunması gerekenler için kullanılır.
UML Class Diyagramları
Class diyagramları, OOP(Nesne Tabanlı Programlama) temel alınarak tasarlanmıştır. Amaç yazılımımız içindeki sınıflar ve aralarındaki ilişkileri tanımlamaktır. Gelin daha detaya inelim. Aşağıdaki gibi Animal adında bir sınıfımız olduğunu düşünelim.
class Animal {
private String name;
private int id;
private int age; public void setName(String name){
this.name=name;
}
public void eat() {
System.out.println("Eating");
}
}
Not: Yazının daha fazla uzamaması için tüm getter-setter metodlar yazılmamıştır.
Animal sınıfını Java’da bu şekilde yazdık. Peki biz bu sınıfı tüm diğer nesne tabanlı dillerde yazabilecek şekilde ifade etmek isteseydik? Yani diğer yazılımcıların da anlayacağı bir dilde yazsaydık. İşte o zaman sınıf diyagramında ifade etmemiz gerekirdi.
Üstte Animal sınıfının class diyagramdaki gösteriminizi görüyoruz. Class diyagramlarında sınıflar bu şekilde ifade ediliyor. Üstte “Attributes” yani sınıfa ait nitelikler(örneğin isim, yaz, id bilgisi), alt kısımda sınıfa ait metodlar bulunuyor. İfadelerin solunda bulunan “-” işareti ise access modifier(erişim niteleyicisi). Yani o niteliğin default, public, private ya da protected olduğunu gösteriyor. Sınıf abstract olsaydı Animal yerine Animal şeklinde italik yazarak ifade edebilirdik ya da <<abstract>> şeklinde altına yazabilirdik. Aynı şekilde bir interface içinse <<interface>> şeklinde belirtiriz. Access modifierlar için gösterimler aşağıdaki listedeki gibi.
Sınıf gösterimini gördük. Ancak sınıfın tek başına gösterimi bir şey ifade etmiyor. Bu sınıflar arasındaki bağlantıların gösterimi de önemli. UML’de ilişkilerin listesi şu şekilde:
1- Generalization/Inheritance
2- Realization/Implementation
3- Association
4- Dependency (Aggregation & Composition)
1- Generalization/Inheritance
Peki nesne tabanlı programlamanın olmazsa olmazı inheritance(kalıtım) nasıl gösterilir onu görelim.
Üstte kalıtımın nasıl ifade edildiğinin gösterimi bulunmakta. Bu gösterim abstract sınıftan kalıtım alırken de aynı. Bu tür kalıtım ilişkisinde nesneler arasında “IS-A” ilişkisi bulunmaktadır.
“Tortoise IS AN Animal”
“Kaplumbağa bir hayvandır.”
2- Realization/Implementation
Bu ilişki arayüzler ile sınıflar arasındaki ilişkiyi modellemek için kullanılır. Dashed(kesikli) çizgi ile ifade edilir. Kalıtımdaki çizginin kesik kesik olan halidir.
Örnek: --------------▻
3- Association
Association, class diyagramlarında en çok karşımıza çıkan ilişki çeşitlerindendir. Design patterns ile ilgili yazılarımda UML örneklerinde associationlarla bol bol karşılaştığımız için bu kısmı iyi anlamak önemli. Inheritance’da sınıflar arasında IS-A ilişkisi var demiştik. Burda da sınıflar arasında HAS-A ilişkisi bulunuyor. Birazdan örneklerle göreceğiz.
Associationlar 4 çeşide ayrılmaktadır. Bunlar bi-directional(tek yönlü), uni-directional(çift yönlü), reflexive ve aggregation&composition. Aggregation ve composition ilişkisinde bağımlılık söz konusu olduğu için onu ayrı başlıkta ele alacağız. Çeşitlerine bakmadan önce Multiplicity kavramına bakalım. Çünkü Associatinlarda sınıflar arasındaki bağlılık ilişkisinde bu kavram önemli.
Sınıflar arasında HAS-A ilişkisi kurarken çeşitlilik sayısını belirtmek isteğe bağlı bir durum. Üstte görülebileceği gibi sayı belirtebiliyorsunuz. Bunun dışında doğrudan bir sayı ya da 4..10 gibi sayı aralığı da verebiliyorsunuz.
Bi-directional Association
Bu iki sınıf arasında tek taraflı bir ilişki olduğunda kullanılmakta.
Üstteki ilişkinin okunuşu şu şekildedir.
“Person HAS AN Address”
“İnsan bir adrese sahiptir”
Burada 1 yerine 0..n şeklinde bir ifade de kullanılabilirdi. Üstteki ilişkide 1 yazdığı için, Person sınıfı içerisinde Address sınıfı tipinde bir attribute bulunacağını belirtiyor. Ancak Address sınıfında Person ile ilgili bir bilgi yer almıyor. Çünkü ilişki türü bi-directional(tek yönlü). Ayrıca ilişki ile ilgili aradaki bağlantıya isim verebilmemiz mümkün. Bu tercihe bağlı bırakılmıştır.
Uni-directional Association
Bu iki sınıf arasında çift taraflı bir ilişki olduğunda kullanılmakta.
Üstte bunun çok güzel bir örneği bulunmakta. Bu ifadenin Türkçe’si şu şekilde. Student sıfır ya da sonsuz tane kursa kayıt olmuş olabilir, aynı şekilde kursa hiç öğrenci kayıt olmamış olabilir ya da sonsuz tane öğrenci kayıt olabilir. Burada sol tarafta bulunan sınıfı karşı ilişkili olduğu sınıf tarafındaki sayı ilgilendiriyor. Sağdakini de tam tersi. Yani bir kursa en az 1 öğrenci kayıt olmalı ifadesi için Student sınıfı tarafını 1..* şeklinde değiştirecektik. Student sınıfında Course sınıfından yaratılmış nesnelerin listesi, Course sınıfında da Student sınıfından yaratılmış nesnelerin listesi tutulmakta.
Reflexive
Anlaması en zor ilişki bu diyebiliriz. Reflexive(dönüşlü) yani sınıfın kendisi ile yaptığı ilişkidir.
Üstte reflexive ilişki için güzel bir örnek yer alıyor. Directory(Dosya dizini) hiç ya da sonsuz sayıda alt dosya dizinine sahip olabilir. Aynı şekilde hiç ya da 1 tane üst dizine sahip olabilir. Directory sınıfı kendi sınıfından türettiği 2 tane directory nesnesi ile üstteki modeli gerçekleştirebilir.
4- Dependency (Aggregation & Composition)
Bu ilişki türünü çift yönlü association olarak düşünebiliriz. Ancak ekstra sınıflar arasında bağlılıktan söz edeceğiz.
Aggregation ve Composition’da sınıflar arasında parçası olma anlamı vardır. Bir sınıf diğer sınıfın bir parçasıdır. Bu ilişki Aggregation’da biraz daha zayıfken, Composition’da daha güçlüdür. Çünkü Composition ilişkisinde parçası olduğu sınıf yok olursa diğer sınıfta yok olmaktadır. Bu tür ilişkilerde HAS-A ya da IS-PART-OF şeklinde okuyabiliriz.
Aggregation
Üstte sınıflar arasında Aggregation ilişkisini görebilirsiniz. Tekerlek araba sınıfının bir parçasıdır. Ancak araba sınıfı yok olduğunda tekerlek yok olmak zorunda değildir. Aralarında zayıf bir parça ilişkisi vardır.
Composition
Üstte sınıflar arasında Composition ilişkisini görebilirsiniz. Kalp, insan sınıfının bir parçasıdır. İnsan sınıfı yok olduğunda kalpte yok olacaktır. İki sınıf arasında güçlü bir parça ilişkisi vardır. Composition ile agreegation arasındaki fark budur. Umarım açıklayıcı olmuştur.
Üstteki sınıflar arasındaki ilişkiler gerçek projelerde hepsi bir arada kullanılabilmektedir. Yazıda sınıflar arasındaki ilişkileri anlamak için nesne tabanlı programlama hakkında en azından temel düzey bilgi gerekmektedir. Yazının sonuna geldik. Beklediğimden biraz daha uzun oldu. Ancak bu konu yazılım mühendisliği için çok önemli olduğundan detaylı anlatmaya çalıştım. Bana yazının yorum bölümünden ya da tgrlbyrk@icloud.com mail adresinden ulaşabilirsiniz. Lütfen yazıyı kâr amacıyla izinsiz kopyalamayınız.
