Müteahhitlik Firması Sistemi

Bu UML yazılım modelleme örneğimizde bir müteahhitlik firması için arsa alımı,malzeme temini,bina yapım ve satış işlemleri için gerekli adımları gösteren modellemeyi yapacağız.


Müteahhitlik Firması Sistemi gerekli kayıtları tutarak ve aşamaları uygun şekilde gerçekleştirerek projelerin daha düzenli olmasını sağlıyor.Arsa ve malzemelerin kontrolünü sağlayarak projelere uygun arsa ve malzemelerin teminini kolaylaştırıyor.


.

Arsa Kontrolü aktivite şeması veri tabanında var olan kayıtlardaki uygun arsaya ulaştırıyor.Arsa alımı durumunda veri tabanına yeni kayıt girilmesini sağlıyor.Arsanın inşaata hazırlanması için gerekli işlemleri başlatıyor.


Başvuru aktivite şemasında başvuru belgelerinin toparlanıp onay için gerekli makamlara gönderilmesi gösteriliyor.Eğer başvuru kabul edilmezse kabul edilmeme gerekçeleri hakkında düzenlemeler yapılarak yeniden başvuruluyor.Onay alındığında ise projeyi başlatıyor.


Malzeme Kontrolü aktivite şemasında veri tabanındaki envanter kaydını tutarak projenin gerçekleşmesi için gerekli malzemeleri kontrol ediyor.Malzeme eksikliği durumunda yeni malzemelerin stoklanmasını sağlıyor ve gerekli malzemelerin ilgili projelere nakil edilmesine yarıyor.

Grup Üyeleri:

13-701-005  Rasim GÜLER

15-701-055  Zekeriya ŞEKER

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.