Sınıflar arasında birleşim ve gruplama ilişkileri

Bennet, McRıbb and Farmer "gruplama" (aggregation) ilişkisini bütün-parça ilişkisine benzetiyor.

Birleşim (composition) ilişkisini de daha kuvvetli bir gruplama ilişkisi olarak tanımlıyorlar.

Bir nesne başka nesnelerin grubunu içeriyorsa, üst nesneyi temsil eden sınıf ile alt nesneleri temsil edilen sınıflar arasında bir gruplama ilişkisi vardır. Üst nesne bütünüyle alt nesnelerin birleşiminden oluşuyorsa, üst nesne sınıfı ve alt nesne sınıfları arasında birleşim ilişkisi vardır.

Bir gruplama ilişkisi aşağıdaki gibi çizilir. Önce üst sınıftan başlayan bir "aggregation" bağlantı türü seçersiniz:

"New Class" seçeneğiyle eklettiğiniz bağlantılı sınıfa bir ad verdikten soınra gruplama ilişkisini çizdirmiş olursunuz:

İlişki bağlanan sınıf tarafındaki bir boş baklava sembolüyle gösterilir. Arzu edenler baklava bağlantısını çokluk gösterimleri vb. Ekleyerek tatlandırabilirler.

Gruplama ilişkisinde, üst sınıf türü bir nesne alt sınıf türlerinden nesneleirn bir grubunu içerir, ama tümüyle o gruptan ibaret değildir.

Buna karşın, birleşim ilişkisi de bağlanan sınıf tarafındaki bir dolu baklava sembolüyle gösterilir:

Birleşim ilişkisinde üst sınıf türü bir nesne tümüyle alt sınıf türlerinden nesnelerin bir birleşimidir

Özelliklerin Tanımlanması ve Sınıflarla Eşleştirilmesi

Bir kullanım şemasına göre üzerinde işlem yapılacak her tür bilgi bir sınıf şemasında bir sınıfa ait bir özellik olarak gözükecektir. Sorun özelliğin ait olacağı sınıfı bulmaktır.

Bennet, McRobb and Farmer kitabı bu konuda bir mülakatı örnek veriyorlar.

Örnek mülakatta Agate Reklamcılık şirketinin bir yöneticisi  idarecilerin kendi maaşlarını performans göre yaptıkları pazarlıklarla belirlediklerini, ama alt düzey çalışanların maaşlarının kadro derecelerine göre belirlendiğini söylüyor. Kadro derecesi de çalışanın amirinin performans değerlendirmesi sonucu değişebiliyor.

Bu bilgilerden anlıyoruz ki "Çalışan" adlı bir sınıf bir çalışanı temsil edecekse, ona ait maaş bilgisi de "Çalışan" sınıfındaki bir "Kadro Derecesi" bilgisinden elde edilecek. Belki de kadro derecesi ayrı bir sınıf olmalı ve "Çalışan" ve "Kadro Derecesi" sınıfları arasında bir kullanım ilişkisi olmalı ki birinin diğeri türünden özelliği olduğu anlaşılsın.

Mülakatın devamında Agate yöneticisi kadro derecelerine göre hakedilen maaşların her yıl sonunda ekonomik parametrelere göre yeniden belirlendiğini açıklıyor.

Demek ki "Kadro Derecesi" sınıfına ait bir "Maaş Katsayısı" gibi bir bilgi var ve o da zaman zaman değişebiliyor. Yani kadro derecesinin o anki değeri o anki maaşın para cinsinden değerini veriyor. Belki maaş katsayısı bile kendi başına bir sınıf olabilir.

Sonra öğreniyoruz ki şirketin genel performansına göre maaş katsayıları enflasyon gibi ekonomik parametrelerin de ötesinde arttırılabiliyormuş. Bunların belirlediği maaşlardan ayrıca çalışanın kişisel performansına bağlı primler de varmış.

Bu bilgileri toparlarsak, "Çalışan" sınıfında yalnızca çalışanın kimlik ve iletişim bilgileri yer alsın diyebiliriz. Bu sınıfın kullanım ilişkisi içinde olduğu bir "Kadro derecesi" sınıfı olur, o sınıfta da kadro derecesinin sayısal veya kodlanmış değeri, başlangıç ve bitiş tarihleri olur. "Maaş Katsayısı" sınıfı da "Kadro derecesi" sınıfıyla bağlantılı olur ve bir kadro derecesine karşılık gelen maaş katsayısı değerinin geçerlilik tarihleri olur. Şu küçük şema parçasında bunları göstermeye çalıştık:

Bu şemadan şunu anlamalıyız: "Çalışan" sınıfında "KadroDerecesi" türünden bir bilgi, bir özellik tanımı var. "KadroDerecesi" sınıfını sırf o özellik tanımındaki ek bilgilerin bir grubu olarak oluşturduk. Bu nedenle "KadroDerecesi" sınıfı aslında bir "ilişki sınıfı" (associational class) sayılır. Aynı projenin başka kısımlarında da gerekecek bir sınıf değil. Sırf "Çalışan" sınıfında tanımlanması gereken bilginin ayrıntılarını göstermek için şemaya eklenmiş bir sınıf. "KadroDerecesi" türünden bir nesnede de bir maaş katsayısı bilgisi var ki o bilgiyi oluşturan ayrıntıları da "MaaşKatsayısı" adlı bir ilişki sınıfında grupladık.

Çokluk derecelerini de açıklayalım: Her çalışan için geçmiş ve şimdiki olmak üzere bir veya daha fazla "KadroDerecesi" türünden bilgi var. Bunu kullanım ilişkisinin bitimindeki 1..* çokluk derecesinden anlıyoruz. Öte yandan bir kadro derecesine sahip mutlaka bir eleman olacak diye bir kural yok. Bazı kadro derecelerine sahip eleman belli bir anda olmayabilir. O nedenle ilişkinin o ucunda çokluk derecesi 0..*, yani olmayabilir de, birden fazla olabilir de. Buna karşın, her bir "KadroDerecesi" örneği için geçerlilik tarihlerini de belirten bir veya daha fazla "MaaşKatsayısı" bilgisi olabilir (o kadronun geçmiş ve şimdiki katsayı karşılıkları). Bu ilişkinin çoklukları da bir tarafta ", diğer tarafta 1..*

Sınıflar Arasında Kullanım İlişkileri

"UML Distilled" kitabında sınıf ilişkilerini gösteren ilk örnek daha önceki bir paylaşımda uyarladığımız "Sipariş" sınıf tanımıyla, onun özelliklerinin türleri arasındaki ilişkileri gösteriyor:

Bu şema parçasında, "Sipariş" adlı sınıfın "Date" (Tarih bilgilerini saklayacak tür) sınıfı araşında bir kullanım ilişkisi olduğunu gösteriyor. "Sipariş" sınıfının "Date" türünden bir özelliği var.

Yeri gelmişken bu tür bir ilişkinin Visual Paradigm ile çizilmesini gösterelim:


Bu kez başlangıç sınıfı kullanan sınıf olacaktır, yani diğer sınıf türünden bir özelliği olan "Sipariş" sınıfı. Bu sınıfı temsil eden kutuyu seçip kuracağınız ilişki türlerinden "Association" seçin.

İlişkinin hedef sınıfı kullanılan türü temsil eden sınıf olacaktır. Bu sınıf için henüz bir kutu koymamışsanız, "New Class" seçenğini kabul edip adı konmamış yeni bir sınıf ekletin.

Yeni sınıf belki düz bir çizgiyle, belki bazı etiketlerle, ve belki de buradaki gibi iki yönlü oklarıyla gözükecektir:

Bu ilişki göstermindeki oklar erişlebilirliği, daha doğrusu kullanım ilişkisinin yönünü göstermek içindir. "Sipariş" sınıfından "Ürün" sınıfa giden ok başına bakarak,  "Sipariş" türünden bir nesnenin "Ürün" türü özelliği veya özellikleri olduğunu anlıyoruz.  Her "Sipariş" sınıfı örneği "Ürün" sınıfından bir veya daha fazla örnek kullanıyor demektir bu. "Ürün" sınıfından "Sipariş" sınıfına giden ok ise "Ürün" örneğinin "Sipariş" türünden bir özelliği olması demektir. Yani "Ürün" türü bir örneğin hangi "Sipariş" örneğine ait olduğunu biliyor demektir. Bu da tabi ki mantıklı değildir.

Belki sizin yarattığınız ilişkide hiç ok başı yoktu. Bunun nedeni Visual Paradigm'ın varsayılan tercihleri nedeniyle kullanım ilişkisinin her özelliğini göstermemesi olabilir. Oklar ya da diğer özellikler var ya da yok, onların ilişki çizgisi üzerinde gösterilmesi için ayarlaı şöyle yaparsınız:

Şemanın kısayol menüsünden "Presentation Options" (Sunum Ayarları) --> "Association Didplsy Options" (İlişki Görünüm Ayarları) --> "Configure Association Presentation Option" (İlişki Sunumu Ayarlarını Belirle) seçeneklerini tercih edin.

Karşınıza gelecek formda şemadaki tüm ilişki gösterimlerinde hangi özelliklerin görüneceğini belirleyebilirsiniz:

Hangi onay kutusunu tıklamışsanız, onun neyin gözükmesini sağlayacağını sağdaki küçük şema örneğinde göreceksiniz.

Yaptığınız tercihler soınrasında bile bir şey gözükmeyebilir; belki de yeni yarattığınız ilişkinin görüntülenecek özellikleri belirlenmemiştir. Bunları belirlemek için de ilişki çizgisi üzerinde kısayol menüsü açın. "Association End To" kısmı ilişkinin hedefi olan kullanılan tür (bu örnekte "Ürün" sınıfı) ile ilgilidir.

Bu form üzerinde "Role;" etiketli kutuya "Ürün" türü nesnelerin "Sipariş" sınıfının hangi özelliğinde gözüktüğünü yazacaksınız. Bunun için "Ürünler" adını seçtik. Sipariş kapsamında birden fazla ürün alınacağına göre ürün çokluğu da (Multiplicity) * ile, birdehn fazla, gösterilecektir.

Sınıf Kategorileri

Bennet, McRobb and Farmer kaynağımız sınıfların ne amaçla tanımlandıklarına göre kategorilere ayırmış. Bunlara "analiz sınıf stereotipleri" demişler. "Stereotip" (Stereotype) terimini açıklamak için de ünlü film aktörlerinin filmden filme değişen karakterlerinin ortak özelliklerini örnek olarak göstermişler.

Sınıfar tanımladıkları özellik ve davranışlara göre ayrılırlar, ama bazılarının kullanıcı ile sistem arasında veya sistemin bölümleri arasında iletişim kurmak, sistemdeki nesneleri temsil etmek, ve sistemdeki süreçleri kontrol etmek gibi ortak amaçları vardır.

Sistem sınırları üzerinden gerçekleşen iletişimden sorumlu sınıflara "sınır sınıfları" (boundary classes) denir. Belki "uçbirim sınıfları" da diyebiliriz, çünkü genelde "arayüz" de denen uçbirimlerde rol alırlar. Bu tür sınıf tanımlarını oluştururken gerçek program uygulamasında seçilen programlama dili veya görsel platform, vb. gibi uyarlama şeklinin belirleyecek ayrıntılara girmemeye dikkat etmek gerekir.

Gerçek veya soyut nesnelerin özellik ve davranışlarını paketleme amaçlı sınıfları ise "nesne sınıfları" (entity classes) kategorisine sokabiliriz. Kaynak kitabımız bu tür sınıfların genellikle asıl sistemin dışında kalan nesnelerin sisteme gerekli olacak bilgilerini saklamak veya o dış nesnelerin sistemle iletişimini sağlayacak davranışlarını uyarlamak için tanımlandığını belirtiyor.

Son olarak, kaynak kitabımız sistem süreçlerini ve etkileşimlerini kontrol amacıyla tanımlanan "kontrol sınıfları" (control classes) kategorisinden söz ediyor. Genellikle her kullanım durumunun gerçekleşmesi için bir kontrol sınıfı olacağını npt ediyorlar.

Bu sınıf kategorileri ayrımı sistemi yöneten programda sınıf örneklerinin varoluş sürelerini belirler. Bir nesne sınıfı örneği genellikle daha uzun ömürlüdür. Temsil ettiği nesne sistemde varolduğu veya sistemle ilişkisi sürdüğü sürece, onu temsil eden sınıf örneği de var olmaya devam eder. Buna karşın bir sınır sınıfı örneği sınır üzerinden iletişim varken vardır, sonra yok edilir. Bir kontrol sınıfı örneği de kontrol edeceği süreçten daha uzun ömürlü olmaz.

Sınıflar Arasında Genelleme ve Türetme İlişkileri

Aslında kaynak kitabımız "genelleme" (generalization) terimini kullanıyor, ama bu derlemede söz edeceğimiz konu sınıf türetmeyle ilgili olacak.

Genelleme sınıflar arasındaki benzerlikleri keşfetmek demektir. Bir grup nesnenin en genel ortak özellik ve davranışları tanımlayan bir sınıf tanımı oluşturdunuz diyelim. Bu sınıf tanımı tanımladığı ortak özellik ve davranışlara sahip her nesneyi temsil edecektir, ama bazı nesnelerin kendilerine özgü özellik ve davranışları bu sınıf tanımının dışında kalmış olabilir. Dışarıda kalmış bu özellik ve davranışların da ortak olanlarını yeni bir sınıf tanımında toplarsınız. Bu yeni sınıf tanımında en genel tanımları yeniden koymaya gerek olmasın derseniz, yeni sınıfı genel sınıftan "türetmeniz" gerekir. Yeni sınıf genel sınıftaki tanımları "miras almış" olacaktır  Bu açıdan bakılınca, yeni sınıfı en genel üst sınıfın soyundan gelen bir alt sınıf gibi düşünebilirsiniz. Genel sınıfla ayrıntıları tanımlayan yeni sınıf arasında bir soyağacındaki veya bir organizasyondaki gibi bir hiyerarşik ilişki vardır.

Gerçek programlama uygulamalarında ortak özellik ve davranışları uyarlayan kodların en genel sınıf tanımlarında paketlendikten sonra bir daha yazılmalarını gerektirmez. Bu nedenle sınıf türetme nesneye yönelik programlamanın yeniden kod kullanımı (code reuse) prensibinin en iyi uygulama şeklidir.

En ortak özellik ve davranışları tanımlayan sınıf genelleme hiyerarşisinin en üstünde gözükecektir. Bunu yine kaynak kitaptan uyarladığımız aşağıdaki örnekte göstermeye çalıştık:

"Çalışan" adlı üst-sınıf tüm çalışanların ortak özelliklerini tanımıyor. Ücret alma şekillerine göre farklılaşan çalışan gruplarının ortak özellikleri ise "AylıklıÇalışan" ve "SaatliÇalışan" alt sınıflarında tanımlanıyor.

Yeri gelmişken sınıf kutuları arasında genelleme ilişkisinin Visual Paradigm ile nasıl çizlldiğini gösterelim. Üst ve bir alt sınıf önceden şemaya koymuşsanız, üst sınıf kutusunun seçip onun sağ üst köesinde beliren ilişki kurma düğmeciğini tıklatabilirsiniz:

Kurabileceğiniz ilişki türleri arasından ilkini, yani genelleme ilişkisini seçersiniz. Bu ilişkiyi en genelleşmiş sınıf olan "Çalışan" sınıfını seçerek kurmanız önemlidir.

Kuracağınız ilişkinin hedef sınıf adını yazmanız için bir metin kutusu gelecektir karşınıza. Bu kutuya "A" harfini yazdığınızda önceden koymuş olduğunuz "AylıklıÇalışan" sınıf adı önerilecektir.

Kabul edip ilişkiyi kurun. Bunun için önerilen ad üzerinde çift tıklayın. Kurulan ilişki bir düz çizgi şekilknde gözükecek ve özel sınıftan genel sınıfı gösteren bir ok başı olacaktır. İlişkiye ad ve özellik yazmanız için bekleyen metin kutusunu şimdilik boş verin.

İlişkiyi temsil eden çizgi üzerinde bir kez tıklarsanız bir büküm noktası eklemiş olursunuz. Bu nokta üzer4inde basıp sürükleme yaparsanızi çizgiyi bu noktadan bükmüş olursunuz:

Çizgiyi bir yerinde daha bükerseniz, şemanın son halinde gösterdiğimiz köşeli s şeklini elde edersiniz.

Genelleme ilişkisini şemaya önceden koyduğunuz sınıf kutuları arasında çizdirmek zorunda değilsiniz. Yine genel sınıfı seçip genelleme ilişkisi seçeneğini tercih edin, bu kez yeni sınıf oluşturmayı öneren kutuya bir sınıf adı yazmadan Enter tuşuna basın.

Ad verip özellik tanımları ekleyeceğiniz yeni sınıf kutunuz genelleme ilişkisi de hazır olarak görünecektir:

Sınıf ve Nesne Kavramları Hakkında

Bennet, McRobb ve Farmer'ın kitabı nesneye yönelik yazılım projelerine yeni giriş yapacak olanlar için sınıf ve nesne kavramlarını temelden inceleyip karşılaştırıyor. Bu kısımda o incelemelerden derlemeler sunacağız.

UML tanımına göre sınıf aynı türden nesnelerin sahip olduğu bilgi ve davranışları belirleyen bir yönergedir. Programlama dilleri açısından bakarsak da, sınıf bu nesneleri temsil edecek bir kod paketinde olması gereken değişken (bilgileri saklamak için) ve fonksiyon (davranışları uyarlamak için) tanımlarının bir kod paketidir. Yazarlar başka kaynaklara da referans yaparak, nesnelerin ne bildiklerini ve ne iş yaptıklarını bilmesi gereken insanlar gibi görülebileceğini de hatırlatıyorlar. Bu açıdan bakıldığında, nesne bir meslek sahibi kişidir, sınıf ise meslek sahibi kişinin bilgi ve iş yöntemlerini belirleyen bir yönergedir.

Nesne "Ben kimim?" (Bir pişirici), "Ne yapabilirim?" (Pişiririm), ve "Ne biliyorum?" (Hiçbir şey) sorularına cevap verebilmelidir. Sorunun cevaplarını da bir yönerge görevi yapan sınıf tanımına bakarak verebilir, ama vereceği tam cevaplar kendi bilgilerine ve o anki durumuna bağlıdır.

Bir sistemi yönetecek proje oluştururken, sistemde yer alacak nesneleri bu tür sorulara verecekleri cevaplara göre ayırmak ve ortak cevapları olan nesneleri temsil edecek sınıf tanımları oluşturmak gerekecektir. Hem çalışanlar, hem müşterilerin adları, adresleri ve başka iletişim bilgileri vardır, ama sırf bu cevapları ortak diye bu türlerden nesneleri, "Kişi" diye bir sınıf çatısı altında toplayamayız. İş sistemde ne yaptıkları sorusuna gelince, çalışanların ve müşterilerin cevapları farklı olacaktır.

Ayrıca, sınıf tanımlarını nesnelerin sistemde gereken bilgi ve davranışlarıyla sınırlı tutmak gerekecektir. Sistemde aynı rolü oynayan nesnelerin o rolle ilgili ortak özellik ve davranışları o nesneleri temsil eden bir sınıf tanımı oluşturmakta kullanılabilir.

Unutmayın, ne gerç.ek hayattaki, ne de sistemi yönetecek yazılımdaki nesnelerin her özelliği aynı olacaktır. Ortak özellik deyince özelliklerin adlarını ve türlerini kastediyoruz. Yani bir müşteriyi temsil edecek olan nesne o müşterinin adını, o müşterinin şirketinin adını ve iletişim bilgilerini, belki müşteri için yürülen kampanyalarla ilgili bilgileri içerecek ve bu bilgi paketi başka bir müşteriyi temsil eden nesnedekinden farklı olacaktır. Ama tüm müşteri nesnelerinde bu ad, şirket, iletişim ve kampanya bilgileri olması için sınıf tanımında bu türden bilgileri saklayacak  özellik tanımları ve bu bilgileri işleyecek davranışları uyarlayan fonksiyon tanımları olmalıdır. Bu açıdan bakılınca, bir sınıf tanımı bir kalıptır, ve bir nesne o kalıpla kesilmiş bir kurabiyedir. Aynı kalıptan çıkmış her kurabiye aynı şekle sahiptir.

Bu arada, şunu da belirtmeden geçmeyelim. Kaynak kitabımız "nesne" (object) kavramının artık UML'de bir standart tanımı olmadığına değiniyor. Yukarıda tarif ettiğimiz şekliyle, aynı sınıf tanımının kalıbından çıkmış nesnelere o sınıfın "örnek"leri (instances) demek teknik açıdan daha doğru bir kullanım olacaktır.

Visual Paradigm ile Sınıf Kutusu Çizimi

Şimdi bir önceki örnekte bir sınıf temsil edecek kutunun Visual Paradigm programı ile nasıl çizildiğini gösterelim.

İlk adım "UML Modeling" kategorisinden "Class Diagram" (Sınıf şeması) seçeneğini tıklayıp boş bir sınıf şeması yaratın.

 Boş sınıf şeması karşınıza geldiğinde sol üst köşede şema adını yazmanız gereken bir kutu olacaktır. Buraya kendi belirlediğiniz bir adı yazın.

Şemaya bir sınıf kutusu yerleştirmek için soldaki sembol paletinin en üstündeki "Class" etiketli sembolü tıklatıp bir de boş şema sayfasını tıklatırsınız. Ya da bu sembolü paletten çekip sayfa üzerine bırakır gibi yaparsınız.

Eklediğiniz sınıf kutusu başlık bölmesinde adını yazmanız gerekecektir.

Kutunun geri plan rengi farklı olsun isterseniz, kutu yukarıdaki gibi seçiliyken (kenarlıklar üzerindeki küçük karecikler sembolün seçili olduğu anlamına geliyor) kontrol şeridindeki "Diagram" (Şema) sekmesindeki "Format" (Biçimlendir) etiketli düğmeyi tıklayın. Karşınıza gelecek formda geri plan rengini "Background" sekmesinden seçebilirsiniz. Adlandırılmış renklerden birini seçmek yerine, sağdaki renk kartelasından seçim yapabilir, veya kırmızı, yeşil ve mavi bileşen oranlarını belirleyerek kendiniz bir renk oluşturabilirsiniz.

Bu formda yaptığınız renk ve diğer biçimlendirme tercihleriniz hep geçerli olsun isterseniz, biçimlendirme diyalog formunun sağ alt köşesindeki "Set As Default" (Varsayılan Olarak Belirle) düğmesini tıklayın. Göreceğiniz kısayol menüsündeki üst seçenek tercihlerinizi başka sınıf kutuları için varsayılan tercihler olarak uygulatır, alt seçenek ise tercihlerinizi tüm şema sembolleri için varsayılan olarak uygulatır. Son bir aşamada varsayılan tercihlerinizin üzerinde çalıştığınız şemaya mı (current diagram) yoksa tüm projeye mi (whole project; oluşturduğunuz projeye birden fazla şema ekleyerek onu bir sunum dosyası haline getirebilirsiniz) uygulanacağınız seçersiniz.

Bu kutu üzerinde özellik ya da fonksiyon adı vb. başka bir şey yazamadığınızı göreceksiniz. Sınıfa ait bu bilgileri eklemek için sembol üzerinde açacağınız kısayol menüsünü kullanmalısınız. Kısayol menüsünün "Add" (Ekle) seçeneğinden erişeceğiniz alt menüden "Attribute" seçeneğini tıklayarak bir özellik tanımı ekletebilirsiniz:

Eklediğiniz özellik "attribute" metni seçili olarak gelecektir. Bunun yerine kendi belirlediğiniz özellik adını yazabilirsiniz:

Şu an için daha fazlasını yapamazsınız. Özellik adını düzenlemeyi bitirmek için şemada bir başka yeri tıklayın, özellik adı (belki de bu örnekteki gibi {unique} gibi bir niteleyici etiketle) son halini alacaktır. Bundan sonraki düzenlemeleri yapmak için bu özelliği seçip üzereinde kısayol menüsünü açın:

"Open Specification" (Ayarları Aç) seçeneğinden açacağınız özellik ayarları formu üzerinde özellik tanımının çokluğu (Multiplicity),

dışarıdan görünürlüğü/erişilebilirliği (Visibility),

ve türü (Type) gibi seçimlerinizi yapabilirsiniz:

Özellik türü için göreceğiniz seçenekler (en azından bizim için böyleydi) C++ programlama diline ait türler olacaktır, ama "Type" etiketli noş kutuya kendi belirlediğiniz tür adını yazabilirsiniz. "..." etkietli düğmeyi tıklayarak da projenizdeki sınıf şemasına eklemiş olduğunuz türlerden birini seçebilirsiniz.

Aslında bu kadarı yeter, ama oluşturduğunuz bu özellik tanımın bazı kısımları (örneğin çokluk değeri) gözükmeyebilir. Özellik tanımında hangi öğelerin gözükeceğini belirlemek için sınıf şeması sunum seçeneklerini düzenlemeniz gerekecektir.

Şemanın bir boş yerine kısayol menüsünü açın ve "Configure Class Presentation Options" seçeneğini tıklayın:

Karşınıza gelecek olan formda sınıf kutusunda hangi öğelerin gösterileceğini belirleyecek bir çok onay kutusu göreceksiniz. Arzu ettiğiniz tercihleri bu form üzerinde yapabilirsiniz:

Sınıf Gösteriminde Özellikler

"UML Distilled" kitabından bir sınıfı temsil eden kutuda özelliklerin gösterilişi konusunu inceliyoruz.

Bir sınıf kutusunda bir özellik tanımı tam şekliyle aşağıdaki gibidir:

- ad : tür [1] = "Adsız" {yalnızca okunur}

• Tanımın en başında özellik tanımının dışarıdan erişilebilirliğini belirten bir eksi (gizli, özel) veya artı (dışarı açık) sembolü bulunur.
• Özelliğin bir adı vardır.
• Adını izleyen : sembolünden sonra özelliğin türü gelir. String (karakter dizgisi), Boolean (mantıksal belirteç), Integer (tamsayı) gibi programlama dillerinde tanıdığınız değişken türlerinden birini koyarsınız buraya.
• Özelliğin çokluğunu köşeli parantezler içinde yazarsınız. Burada sınıf türünden bir nesnenin bu özellikten kaç tanesine sahip olacağı konusunda bilgi verirsiniz. Burada basitçe bir tamsayı değeryerine, özel anlamlara gelen semboller kullanabilirsiniz. Kitaptaki gibi, bu konuya sonra değineceğiz.
• = sembolünden sonra özelliğin varsayılan (ilk) değerini koyarsınız.
• Kıvırcık parantezler {} içinde de özellik hakkında ek bilgiler koyarsınız. Bu örnekteki gibi dışarıdan değiştirilemeyecek olan bir özellik {yalnızca okunur) yani {readonly}) olarak nitelenir.

Bu prensiplere göre çizilmiş bir sınıf şemasındaki kutu aşağıdaki gibi gözükür:

"AlınanTarih" Date (Tarih) türünden, "ÖnÖdemeli" Boolean (mantıksal belirteç) türünden bilgilerdir. "AlınanTarih" bilgisi ya hiç yoktur (o zaman çokluğu 0 olur) ya da vardır (o zaman çokluğu 1 olur). "ÖnÖdemeli" bilgisi ise mutlaka vardır (varsayılan değer, projenin gereksinimlerine göre True, doğru, ya da False, yanlış olabilir).

"Ürünler" ise "SiparişÜrünü" diye ayrı bir sınıf türünden birden fazla belirsiz sayıda çokluğu olan (bunu * ile gösteriyoruz) bir dizidir. {ordered} (sıralı) etiketinden bu dizinin sıralı saklandığını anlıyoruz.

Kitap bu aşamada aynı gösterimin sınıflar ve türler arasındaki ilişkiler (associations) ile gösterimi konusunu da gösteriyor, ama biz daha basit olan bu şekli göstermekle yetineceğiz. Zaten sınıf şemalarını geniş açıdan incelerken sınıf ilişkilerinin görselleştirmesini de tarif edeceğiz.

Kullanım Durumlarından Hareketle Sınıfların Tanımlanması

Bennet, McRobb ve Farmer kitabı bir yazılım projesine hazırlanırken sistemi oluşturacak sınıfların belirlenmesi konusunda oldukça aydınlatıcı ipuçları veriyor. Sınıf şemalarının çizimi ve kullandığı görselleştirme yöntemlerinden önce sınıfların tanımlanması konusunda bu kaynaktan derlemeler sunacağız.

Kaynağımıza göre sını8f şemaları nesneye yönelik analiz açısından büyük önem taşırlar. Hem üst seviyeden planlanan sistemin mimarisini (sistemi oluşturan nesnelerin yapısal ilişkilerini), hem de alt seviyeden bu nesneleri temsil edecek sınıf kod paketlerinde olması gtereken özellik ve davranışları görselleştirirler. Sınıf şemalarının bu amaçları karşılayabilmesi için sınıflar doğru tanımlanmalıdır, ama modelleme aşamasının ilk adımlarında sınıf tanımları tam doğru olmayabilir.

Şemalarda yer alacak sınıfların tanımlanmasında birinci kaynak kullanım durumu şemalarıdır. Aktörler ve onların sistemi kulanımları için gerekli bilgiler, kullanım sonrası ortaya çıkan bilgiler, vb. Birer sınıf tanımıyla temsil edelebilecek nesne türlerini oluşturmak için ilk ipuçlarını sağlarlar.

Örneğin, Agate reklamcılık şirketi için planlanan sistem için oluşturulan kullanım durumu şemasındaki "Kampanya için eleman ata" kullanım durumunu göz önüne alın. Bu kullanım durumunun baş aktörü "Kampsanya Yöneticisi"dir. Bu kullanım durumunun senaryosuna bakarsanız, sistem müşterilerin bir listesini sunacak, yönetici bir müşteriyi seçecek, sistem bu müşteri için planlanmışp kampanyaları listeleyecek, yönetici bir kampanya seçecek, sistem zaten o kampanyada yer almayan elemanları listeleyecek, yönetici de kampanyada görev alacak yeni elemanları o listede işaretleyecek, son olarak sistem seçilen elemanların görevlendirildiğini doğrulayacaktır.

Kaynağımıza göre, bu örnekte sözü geçen kampanya yöneticisi, müşteri adı, kampanya, müşteri, eleman vb. her tür bilgi bir sınıf tanımı için bir başlangıçmış gibi gözükebilir. Yazarların önerisi bu kullanım durumunun amacını gerçekleştirmek için sistemin saklaması gereken bilgilerle oluşturulacak sınıf tanımlarına odaklanmak. Kampanya yöneticisi tabi ki baş aktör olarak bir sınıf tanımıyla temsil edilmelidir. Müşteri adı da saklanması gereken bir bilgidir, ama müşteriyle ilgili bir bilgi olduğuna göre, belki de müşterinin kendisini temsil edecek bir sınıf tanımında müşteri adı bilgisini bir özellik olarak saklamak yeterli olacaktır.

Bu kullanım durumunda gereken bilgilere bakarak, kampanya yöneticisi, müşteri, kampanya ve eleman sınıf tanımları adayları olarak çıkıyor ortaya. Kaynak kitap bu aşamada bir "işbirliği şeması" (collaboration diagram) oluşturmayı gösteriyor ama biz şimdilik o ayrıtılara girmeyelim. "Müşteri", "Kampanya" ve "Eleman" sınıf adaylarının "Ekampanyaya eleman ata" kullanım durumuyla ilgili bilgileri içeren olası sınıf tanımları olduğunu bilmeniz yeter. Hatırlarsanız, bu kullanım durumunda kampanya yöneticisi sistemin sunduğu bir müşteriler listesinden birini seçince, sistem o müşteriyle ilgili kampanyaları listeleyecekti. Demek ki müşteriler listesinden bir seçim yapılınca sçeilen müşteriyi temsil eden bir "Müşteri" nesnesi yaraılmalı, ve o müşteri nesnesiyle ilgili kampanyaların bir listesi de oluşturulmalı. Yani "Müşteri" sınıf tanımında "Kampanya" nesnelerinin bir listesi olmalı veya "Kampanya" nesnelerine referans yapan bağlantılar olmalı. Bu tür çıkarımlarla sınıf şemasında yer alacak sınıf tanımlarında yer alması gereken bilgileri tanımlayacaksınız.

Pansiyon Müşteri Takip

Bu UML yazılım modelleme örneğimizde Pansiyon Müşteri Takip Sistemi yapacağız. Pansiyona gelen müşterilerin bilgilerini alıp kayıt eden, odaların müsaitlik durumuna göre tercihlerine en uygun odaya yerleştiren bir modelleme yapacağız.Ve sonrasında her geçen gece ardından müşteri hesabına günlük ücreti ekleyen ve alınan ek hizmetlerinde bu ücrete eklendiği bir hesap oluşturan pansiyon müşteri takip sistemi oluşturacağız.

Potansiyel Müşteri Bilgilerini Al

Pansiyona gelen müşterileri ilk olarak veritabanına daha önceden kayıt edilmiş olan etkinlikler, fiyat ve odalar hakkında bilgiler sunulur. Daha sonra müşterinin kimlik bilgileri; sistem tarafından belediye, zabıta ve turizm bakanlığına gönderilir.İlgili kurumlardan gelen geri dönüşlerde, müşterinin konaklamasında herhangi bir sakınca yoksa rezervasyon işlemine geçilir.

Avantaj;

Müşterinin daha güvenli bir pansiyonda kalmasını sağlamak.

Müşteri Rezervasyon

Müşteri bilgileri veritabanında sorgulanır sistemde daha önce kaydı yoksa yeni kayıt oluşturulur. Kaydı varsa rezervasyon kaydı açılır.

Avantaj;

Bu bilgiler online bir veritabanına kayıt edilir. Böylece müşteri dilediği zaman pansiyonun mobil uygulamasını kullanarak hesap takibi kolaylıkla yapabilir

Odaya Yerleştir

Veritabanından boş odalar sorgulatılarak müşteriye oda ve oda konum bilgileri sunulur. Eğer boş odalardan müşterinin istediği herhangi bir oda varsa o odaya yerleştirilir.Eğer istediği bir oda yoksa rastgele bir odaya yerleştirilir.

Avantaj;

Müşterinin oda seçim hakkı olur.

Etkinlik Planlama ve Müşterinin Özel İsteklerini Alma

Veritabanında kayıtlı olan etkinlik bilgileri müşteriye sunulur. Müşteri etkinliğe katılmak isterse ilgili etkinliğe kaydı yapılır ve hesabına etkinlik ücreti eklenir, katılmak istemez ise yapılmasını istediği herhangi bir etkinlik var mı? Diye sorulur, var ise etkinlik planlayıcısına özel isteği bildirilir.
Müşteriye konaklamayla ilgili özel istekleri var mı? Diye sorulur, var ise gerekli çalışanlara iletilir.

Avantaj;

Müşteri dilediği zaman otel mobil uygulamasından veya web sitesinden etkinliklerin takibini yapabilir. Etkinlik isteklerini, konaklama isteklerini, pansiyon hakkında görüş öneri ve şikayetlerini kolaylıkla ilgili personele iletebilir.

13-701-009 Emre Nazlı
13-701-038 Yusuf Akbaş
13-701-021 Coşkun Aslan

Sınıf Şemalarına Giriş

Martin Fowler "UML Distiled" kitabında en çok görülen UML şemalarının sınıf şemaları olduğunu yazıyor. Bu tür şemalar sistemi oluşturan nesneleri ve aralarındaki sürekli yan, durağan ilişkileri görselleştirmek içindirler. Sınıf şemaları ayrıca nesnelerin özellik ve davranışlarını da nesneleri temsil eden kutularda listelerler.

Sınıfı temsil eden kuru başlığında sınıf adı, kutu içeriğinde ise sınıfta tanımlı özelliklerin (attributes, properties) adları yer alır. Özellik adlarının önünde dışarıdan erişilebilirlik derecesini belirleyen sembol veya etiketler yer alır. Bu küçük örnekteki eksi işaretleri bu özelliklerin nesneye ait özel, yani dışarıdan gizlenmiş özellikler olduğu anlamına geliyor.

Böyle bir örnekte gösterilen şekliyle, sınıf şeması bu adla tanımladığınız türden her nesnenin sahip olacağı özellikleri listeliyor. Bu sınıf türünden bir nesne yarattığınızda, bu tanımın bir örneğini (instance) yaratmış olursunuz. Bu nesne de sınıfı temsil eden kutudaki özelliklere sahip olur.

"Özellik" deyince aklınıza .NET programlama dillerindeki dışarıdan öğrenilip değiştirilebilen bilgileri temsil eden property tanımları gelmiş olabilir. Aslında nesneye yönelik programlamanın teorisine bakacak olursanız, nesneye ait her tür bilgi bir "özellik"tir. Genellikle gizli üye değişkenlerde saklanan özel bilgiler nesneye ait karakteristik bilgilerdir; onlar için "attributes" terimi kullanılır. "property" terimi de bu bilgilerden dışarı açık olanları için kullanılır. Bu ayrıntıya takılmayın. Burada işin programlama kısmıyla ilgilenmeyeceksiniz. Siz bir sınıf şemasında sistemi oluşturan nesnelerin sahip oldukları bilgileri listeleyeceksiniz, o kadar. Nesneye ait bilgilerin de olur olmaz hepsini değil, yalnızca sistemin çalışmasını ilgilendiren bilgileri listeleyeceksiniz.

Sınıf şemasında bir nesnenin (sistemle ilgili) davranışları da nesne türünü temsilş eden kutunun üçüncü bölmesinde listelenir:

Kutunun bu alt bölümünde listelenen davranışlara UML terminolojisinde "eylemler" (operations) denir. Bu küçük örnekte bir elemanın reklamcılık şirketinde bir kampanyaya atanmasını sağlayan ve ücretini belirleyecek yeni bir kadro verilmesini sağlayan iki eylemin adını listeledik. Adlandırma şekline kafayı takmayın; bu küçük resmi Bennet, McRobb ve Farmer kitabındaki bir örnekten uyarlamıştık. Oradaki adlandırma şeklinde sadık kaldık.


Nesnenin "eylemleri" deyince genellikle başka nesnelerin o nesneden talep edeceği davranışların adları gelsin. Bu açıdan bakılınca, nesne eylemlerini bir profesyonel kişinin sipariş üzerine yapacağı işler gibi düşünebilirsiniz. Bu nedenle nesne eylemleri genellikle dışarıdan erişilebilir olmalıdır. Dışarıya açık derken, eylemin nasıl yapıldığını herkes biliyor sanmayın. Profesyonel bir kişi iş yapma şeklini gizli tutar, ama yapacağı işe bir ad koymuştur, başka birisi de işi o adla talep eder. Yukarıdaki küçük kutuda + semboplüyle dışarı açık olarak gösterilen eylemler nesnenin sipariş üzerine gerçeklşeştirebileceği eylemlerin adlarıdır. Gerçek bir programlama dilinde bunları dışarı açık, yani sınıf tanımı dışındaki kodlardan çağrılabilen fonksiyonlarla uyarlarsınız.

Futbol Kulübü Sporcu Takip Sistemi

Bu UML Yazılım Modelleme örneğimizde bir futbol kulübü için sporcuların yetenek,sağlık ve gelişme durumlarını takip eden modelleme yapacağız.

Bu örnekte amacımız sporcunun(futbolcunun) yeteneklerine göre mülakatta başarılı olanları sağlık kontrolünden sonra Futbol kulübüne kayıt işlemini gerçekleştirmek, kişisel antrenman ve beslenme programını hazırlamak, gelişimini izlemek olacaktır.

----------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------------

Aday kaydı yap kullanım durumunda sekreter , mülakata katılmaya hak kazanan sporcu adaylarının kimlik bilgilerini bilgisayar programı aracılığı ile sunucudaki veritabanına kayıt yapar.

Aday değerlendirme kullanım durumunda;

Antrenör, sporcu adayını koşma,mekik, şınav, barfiks vb. testlere tabii tutarak kondisyon seviyesini belirler ve top sürme , pas atma vb. testlere sokarak yeteneklerini belirler.

Elde edilen sonuçlara göre antrenör, sporcu adayının kulüp için uygun olup olmadığını değerlendirir.

Bu kullanım durumunda bilgisayar ve veritabanına gereksinim duyulmaz.

                Diyetisyen  bu kullanım durumunda  sporcunun  antrenman programından verileri çekerek  sporcunun program yardımı ile antrenman günü ve normal gününde ne kadar kaloride  beslenmesi  gerektiğinin hesaplamasını yapar.

                Diyetisyen, sporcunun hesaplanan kalori miktarına göre ve veri tabanımızda bulanan besinlerin besin değerlerine göre beslenme listesi oluşturur.Program besin değerlerini her besin eklemesinde denetleyerek gerekli proteinin alınmadığı durumda takviye besin ekleme uyarısı yapar.

Grup Üyeleri:

►Mustafa Yorgun 13-701-030

►Semih Topçu 13-701-020

►Yasin Börek 13-701-002

Organizasyon Şirketi

Bu örnekte bir organizasyon şirketinin düğün, mezuniyet, açılış törenlerini organize eden bir sistem modellemeye çalışacağız.
Amacımız şirketimize gelen kişilerin isteklerine uygun yer, ikram çeşitleri, masa düzeni organize etmeye çalışacağız.

Üyeler;
Rahime SİMAV
Gizem METİN
Mekkiye TEKİN

                               

                                              

vpp

---------------------------------------------------------------------------------------------------                         

      ----------------------------------------------------------------------------------------------------------

Bu şemada Organizasyon Kaydı Yap,Organizasyon Planı Hazırla,Ödeme Yap,Mekan Temini,Araç Temini kullanım durumları bilgisayardan gerçekleştirilir. Organizasyon kayıtlarını bilgisayarda tutarak kayıtların daha güvenilir saklama avantajı sağlar. Organizasyon kayıtlarına bilgisayardan hızlı ve kolay bir şekilde ulaşabiliriz.

Dekor, mekan, araç seçimlerinde müşteriye bilgisayar üzerinden görsel sunum sağlayarak zaman kazanırız.Organizasyon planı içinde yer alan organizasyon tarihi,organizasyon için özel istekler ve bu organizasyon için temin edilmiş mekan,araç ve dekor bilgilerini veri tabanına kaydettiğimiz için veri kaybı olma olasılığı en aza indirgenir.Bu bilgileri bilgisayar ortamında sakladığımız için ayrıca not tutulmasına gerek yoktur.

Veri tabanında kayıtlı tutulan organizasyon tarihinin dolu olup olmadığını kontrol edip duruma göre organizasyonu farklı tarihe alırız.Gerçekleştirilen organizasyonun ödemesini bilgisayar ortamına kaydettiğimiz için bilgi kaybı olmaz.Bu sistemi tasarlarken bilgisayar,veritabanı ve internetin bize sağladığı avantajlar, verilerin güvenli bir ortama kaydedilmesini sağlamak, organizasyonda kullanılarak dekor seçeneklerinin arttırılması ve verilerin güvenilirliği sağlanır.