003 Uml Semalari [94 Slides]
•Télécharger en tant que PPT, PDF•
3 j'aime•7,369 vues
Unified Process ve UML ile Yazılım Geliştirme - 3 - UML Şemaları
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 003 Uml Semalari [94 Slides]
Similaire à 003 Uml Semalari [94 Slides] (20)
003 Uml Semalari [94 Slides]
- 1. UML/UP ile Yazılım Geliştirme Bölüm 3 / 7
- 2. İçerik • UML’in Sizin için Anlamı • UML Şemaları, Semboller ve Semantik İlişkileri • Şema ve Model Bazlı UML Çalışmaları Arasındaki Farklar • Alternatif Yazılım Geliştirme Süreçlerinde UML'in Yeri • UML ile Gereksinim Yönetimi • UML ile Nesne Yönelimli Tasarım
- 3. İçerik • UML Modeli Kavramları • UML Tanımını Genişletme Mekanizmaları • Davranış Şemaları • Yapısal Şemalar
- 4. UML 2.0 Şema Türleri * * * * *
- 5. Kısaca UML UML sembolik bir dildir: Yazılım sistemlerinin oluşturulması esnasında ortaya çıkan iş ürünlerinin – Tasavvur edilebilmesine, – İfade edilebilmesine, – Oluşturabilmesine ve – Dokümante edilebilmelerine yarar.
- 6. UML Modeli Oluşturma Nedenleri • Oluşturulacak sistemin yapısı ve davranışı hakkındaki bilgiyi paylaşmak • Sistem mimarisini tasavvur ve kontrol edebilmek • Sistemi daha iyi anlayıp çözümü basitleştirmek ve tekrar kullanılabilirliği artırmak • Riskleri yönetebilmek
- 7. 4 Model Kuralı • Oluşturduğunuz model problemi nasıl çözeceğinizi belirler. • Her model farklı detay seviyelerinde bilgi verebilir. • En iyi modeller gerçekle bağlarını koparmayanlardır. • Tek bir model kesinlikle kafi değildir.
- 8. İçerik • UML Modeli Kavramları • UML Tanımını Genişletme Mekanizmaları • Davranış Şemaları • Yapısal Şemalar
- 9. UML Genişletme Mekanizmaları • UML tanımı çok geniş de olsa bazen özel durumlara uyabilmesi için ‘genişletilmesi’ (extend) gerekebilir. • UML tanım genişletme mekanizmaları - Yeni model sembolleri oluşturmak, - Yeni özellikler (property) tanımlayabilmek, - Yeni semantik yapılar oluşturabilmek için kullanılır. • Genişletme mekanizmaları dörde ayrılır: - stereotype, tagged values, kısıtlar ve notlar
- 10. Stereotype • Stereotype genellikle UML sembollerini yeni ortamlarda tanımlamak amacıyla kullanılır: Örneğin Asansör Kontrol Sisteminin bir modelini oluştururken, bazı class’ları ve durumlarını (state) vurgulamak isteyebiliriz • «hardware» • «software» • Stereotype mutlaka tanımlandığı özel durum için ve hep aynı şekilde (mantıkla) kullanılmalıdır.
- 11. Stereotype • Stereotype kullanım şekli: - Stereotype’ı UML sembolünün adının üstüne yerleştiriniz • Stereotype adını «» işaretleri arasına koyunuz: (Örneğin, «node») - Yeni ikonu (resmini) tanımlayınız Stereotype Stereotype ikon gösterimi etiket gösterimi «button» u CancelButton CancelButton state
- 12. Stereotype “UML Tanımıyla Gelenler” Tanımlı Stereotype’lar: UML tanımı içinde mevcut, anlamı kesin olarak belirlenmiş ve işarete karşılık gelen bir ikonu olan işaretlerdir. cd Design Model <<Stereotype Adı>> Class1 ud Use ... Tanımla Gelenler: • Boundary, Entity, Control • Aktör, vs. Actor1
- 13. Size Ait İşaretler “UML in Color” Peter Coad (TogetherSoft) entity class’larının da kendi aralarında gruplara ayrılması gerektiğini söyler: vi. <<Thing>> vii. <<Description>> viii. <<Role>> ix. <<Moment-Interval>>
- 14. Tagged Values • Tagged values – UML sembollerine ek özellikler atarken kullanılır – Mevcut UML sembol ve stereotype’larına eklenebilir – Bir isim-değer (özellik-değer, tag-value) ikilisi olarak kullanılır. • Genellikle aşağıdaki konularda kullanılır - Kod üretimi - Versiyon kontrolü - Konfigürasyon yönetimi - Sahiplik (telif hakkı kanıtı) - vs. vs.
- 15. Tagged Values • Tagged value {} parantezi içine yazılan çok kısa bir nottur: - {tag adı, ayraç (=), bir değer}’den oluşur. tagged value {yazan = “Ali”, Versiyon = 2.5} Eleman isim adres
- 16. Kısıtlamalar • UML’in semantik yapısına yeni kurallar ekleyerek veya mevcut kuralları değiştirerek onu genişletirler • Her zaman uyulması gereken kuralları tanımlarlar • Kısıtlamalar tıpkı birer not gibi yazılabildiği, kullanılan UML ürününün api’ı ve/veya özel menü sistemleri aracılığıyla da yazılabilirler
- 17. Tagged Values ve Kısıtlamalar Gösterimleri aynıdır. UML ürünleri kullanıldığında NOT sembolünün içine yazılırlar. Pek çok farklı yerde belirtilebildiklerinden yaygın bir kullanımı yoktur. {Tagged Value / Constraint} {Vermek istediğiniz ek bilgi} {Vurgulamak istediğiniz kısıtlama}
- 18. Notlar • Oluşturulan modellere eklenen daha detaylı açıklamalardır - Örneğin, verilen bir tasarım kararının gerekçesini vurgulamak amacıyla kullanılabilir. • Not ikonu içine yazılan yazılardır Abstraction-occurrence pattern 1..* Title Copy
- 19. UML Metamodel • Metamodel olası modellerin kullanacağı yapısal ve semantik özelliklerin tanımlandığı bir modeldir • UML modeli, ait olduğu metamodelin bir uygulanış şeklidir • UML metamodeli – UML sembollerini tanımlar – Tanımlamalar için UML sembollerinin bir alt kümesini kullanır – Aralarında ilişkiler kurulan paketlerle düzenlenir
- 20. UML Metamodel • UML metamodeli aşağıdaki konulara yanıtlar bulunarak oluşturulur: - Syntax Yapısı (Abstract Syntax): Class Şemaları kullanılarak tanımlanır - Net olarak tanımlanmış kurallar: Model öğelerinin uyması gereken kurallar (sınırlamalar) tanımlanır -Örneğin, bir class’ın birden fazla adı olamaz - Semantik Yapı: Model öğelerinin ilşkilendirilme biçimleri gündelik dille tanımlanır
- 21. UML Profilleri • UML Profilleri özel konulara yönelik UML modelleri geliştirebilmemizi sağlarla - Örneğin, süreç mühendisliği, gerçek zamanlı sistemler, web uygulamaları vs. vs. • Bir profil ‘paketinde’ bir veya daha çok genişletme mekanizması ürünleri bulunur (stereotype, tagged value, kısıtlamalar) • Bunlar UML model öğelerine uygulanarak kullanılırlar
- 22. UML Profilleri • Bir UML profilinde aşağıdaki çalışmalardan gerekenler yapılır: - UML metamodelinin ilgili bir bölümü seçilir - Stereotype’lar ve/veya tagged value çiftleri tanımlanır - Mevcut kurallara yeni ekler tanımlanır - Yeni bir semantik yapı tanımlanır
- 23. Profil Örneği • Temel GUI bileşenlerine yönelik bir profil tanımlarsak, • GUI yapımız aşağıdaki öğelere sahip olacaktır: - Formlar - Butonlar • Kısıtlamalar: – Bir form bir ‘dialog box’ı çalıştırabilir – Formlar ve Dialog Box’ların butonları olabilir
- 24. GUI Profili Class ve Association UML metamodelinden gelmektedir GUI Profili Class Association <<stereotype>> <<stereotype>> <<stereotype>> <<stereotype>> Form Button Contains Invokes <<stereotype>> DialogBox
- 25. GUI Profili Uygulaması <<Form>> 1 <<Invokes>> 1 <<DialogBox>> MainView OpenDialogBox 1 1 <<Contains>> <<Contains>> 1 1 <<Button>> <<Button>> OkButton CancelButton
- 26. İçerik • UML Modeli Kavramları • UML Tanımını Genişletme Mekanizmaları • Davranış Şemaları • Yapısal Şemalar
- 27. UML 2.0 Şemaları
- 28. Davranış Şemaları – use case şeması* – activity şeması* – Etkileşim Şemaları • sequence şeması • collaboration / communication şeması • interaction overview • timing şeması – statechart / state machine şeması*
- 29. Use Case Şeması • Temel Kavramlar • Şema İçeriği • Şemayla Aktarılan Bilgiler • Tasarım Teknikleri • Forward ve Reverse Engineering
- 30. Temel Kavramlar • Her tasarlanan sistem bir insanla veya başka bir sistemle etkileşir • Sistemin kullanıcıları onun tahmin edilebilir bir şekilde çalışmasını beklerler • Use Case sistemin kullanıcılarına sunacağı bir hizmetin senaryo şeklindeki anlatımıdır. Bu yüzden bir fiil ismine sahiptir: Yap, Et gibi adlandırılır. Örneğin, “Para Çek”, “Havale Yap”. • Aktör sistemin sunduğu hizmetleri kullanan bir kişi veya başka bir sistemdir. • Aktörler mutlaka tasarlanan sistemin dışında olmalıdırlar.
- 31. Use Case’lerin 3 Temel İşlevi – Sistemin Sınırlarını Çizmek: Tasarlanan sistemin dışarıdan nasıl görüleceğini programcılara da yol gösterebilecek şekilde belirlemek – Sistemin Bütünlüğünü Görebilmek: Sunulan hizmetlerin sistem içinde nasıl gerçekleştirileceğini görebilmek – Test için Referans Oluşturmak: Sistem oluştukça eklenen yeni unsurları kaldırıp kaldıramayacağını anlamak
- 32. ‘Sihirli’ Use Case Sayısı Nedir?
- 33. İlgili Roller • Şemayı Hazırlayanlar: – İş Analisti – Sistem Analisti • Şemayı Kullananlar: – Müşteri – Proje Yöneticisi – Tasarımcı – Veri Tabanı Analisti – Kullanıcı Arayüzü Tasarımcısı – Testçi – Kullanım Kılavuzu Hazırlayanlar
- 34. Use Case Şeması Sembolleri - 1 Sembol Tanımı Syntax use case Belli bir hedefe ulaşmak için kullanılabilecek tüm alternatif U seC aseN am e senaryolar. aktör Sistemle etkileşen kişilerin canlandırdıkları roller ve dış sistemler. A c to rN a m e sistem Oluşturulan sistemle aktörleri sınırı birbirinden ayıran sınır.
- 35. Use Case Şeması Sembolleri - 2 Sembol Tanımı Syntax association Aktörlerin veya Use Case’lerin birbirlerini kullanmaları. generalization Aktörlerin çeşitlerini ve Use Case’lerin özel durumlarını vurgular. extend Bir Use Case’in kullanıcısının <<extend>> seçimine bağlı olarak çalıştırdığı diğer bir Use Case’i vurgular.
- 36. Use Case Şeması Sembolleri - 3 Sembol Tanımı Syntax include Bir Use Case’in her zaman çalıştırdığı diğer bir Use Case’i <<include>> vurgular. Note Her şemaya dilenen bilgilerin yazılması için ve hyperlink note oluşturmak amacıyla kullanılır. Anchor note to Notu şemadaki sembollere item bağlamaya yarar.
- 37. Şema Örneği 1
- 38. Use Case Bulma Teknikleri 1 ud Use Case Model Use Case 6, Use Case 5'in ozel bir durumudur. Use Case 5'in bazi Use Case1 alternatif akislari buradadir. Use Case 2 her zaman Use Case 1 ile birlikte calisir. Use Case6 «include» Actor1 Use Case2 Use Case4 Use Case 3 istege bagli olarak Use Case 4 ile birlikte calisir. Use Case5 «extend» Actor2 Use Case 3'den Actor 2'ye bir mesaj gitmektedir. Use Case3
- 39. Use Case Bulma Teknikleri 2 Event Table Çalışması: Özne Nesne Fiil Oluşturulanlar Sistemin Cevabı Aday Use Case Aday Aktör Öğrenci derse kayıt olur Ders listesine eklenme Dersi alabilirmi bakar Kayıt Ol Öğrenci Haftalık Ders Programı Çakışan derslere bakar Eğitmen derse kayıt olur Ders listesine eklenme Dersi alabilirmi bakar Kayıt Ol Öğrenci Haftalık Ders Programı Çakışan derslere bakar
- 41. Use Case Bulma Teknikleri 3 1. Aktörler Adaylarını Bulun 2. Event Table Çalışmasını Yapın 3. Aktör ve Use Case’leri Belirleyin 4. Aktörleri Çizin ve İlişkilerini Düşünün 5. Use Case’leri Çizin ve Aktörlere Bağlayın 6. Use Case’ler Arasındaki İlişkileri Belirleyin
- 42. Aktör Bulma Soruları • Sistemin gereksinimleri kimleri ilgilendiriyor? • Sistem organizasyonun hangi biriminde kullanılacak? • Sistemden kimler faydalanacak? • Sisteme veri sağlayacak, sistemden bilgi alacak ve sistem kayıtlarını değiştirecek olanlar kim? • Sistemin bakımını kim yapacak? • Sistemin hizmetlerinden yararlanacağı başka sistemler var mı? • Sistemin hizmetlerini sunacağı başka sistemler var mı? • Sistemin kullanımında birden fazla rolü oynayan kişiler var mı? • Sistemin kullanımında aynı rolü oynayan birden çok kişi var mı?
- 43. Use Case Bulma Soruları • Aktörlerin yerine getirecekleri görevler nelerdir? • Aktörlerden herhangi birisi sistem kayıtlarını oluşturma, kaydetme, değiştirme, silme ve okuma amaçlı olarak kullanacak mı? • Hangi use case’ler yukarıdaki kaydetme, değiştirme, silme ve okuma işlemlerine yol açacak? • Herhangi bir aktörün sistemi sistem dışındaki ani değişikliklerden haberdar etmesi gerekli mi? • Herhangi bir aktörün sistem içinde olanlardan haberdar edilmesi gerekiyor mu? • Hangi use case’ler sistemin bakımı için kullanılacak? • Sistemin vereceği tüm hizmetler (fonksiyonel gereksinimler) bulunan use case’ler ile yansıtılabiliyor mu?
- 44. Use Case Şeması Egzersiz # 1 Lütfen şemadan anladıklarınızı bir paragrafta özetleyiniz (10 dk.) uc Use Case Modeli II Satın Al Kataloğa Bak «extend» Müşteri (from Aktörler) (from Use Case'ler) (from Use Case'ler) Banka «include» (from Aktörler) Sisteme Bağlan (from Use Case'ler) «include» Kataloğu Hazırla Sistem Yöneticisi (from Aktörler) (from Use Case'ler)
- 45. Use Case Şeması Egzersiz # 2 Aşağıdaki tanıma uygun use case şemasını çiziniz (15 dk.). “Sadece üyelerin bir satın alma yapabileceği bir cd satış portali oluşturmanız gerekmektedir. Bu portali ziyaret edenler üye olmadıkları takdirde portal kataloğuna erişemeyeceklerdir. Üye olma işlemi sırasında başvuru yapanların: • isim ve soyadları, • e-mail adresleri • favori müzisyenleri (3 isim) • favori cd’leri (3 isim) • arayıp bulamadıkları cd’ler (3 isim) • bilgileri toplanacaktır. Üyelerden ayrıca bir şifre tanımlamaları istenecek ve e-mail adresleri kullanıcı adları olarak kullanılacaktır. Web sitesinde şirket kataloğuna bakarak cd satın alabilmenin dışında, üyeler birbirleri arasında cd değiş tokuşu yapabileceklerdir. Sistem üyelerin hangi cd’leri alıp sattıklarına, hangi cd’leri arayıp bulamadıklarına bakarak, cd önerilerinde bulunacaktır.“
- 46. Activity Şeması • Temel Kavramlar • Şema İçeriği • Şemayla Aktarılan Bilgiler • Tasarım Teknikleri • Forward ve Reverse Engineering
- 47. Temel Kavramlar • Sistem akışı içinde önce ne sonra ne olduğunu koşullarını işaret ederek gösterebiliriz. • Use Case akışını çizebiliriz. • Sistem genelinin işleyişini çizebiliriz. • Bir hizmete yönelik işlemleri toplu halde inceleyebiliriz (UC Map). • Tek bir işlemin nasıl gerçekleştirildiğini inceleyebiliriz.
- 48. İlgili Roller • Şemayı Hazırlayanlar: – İş Analisti – Sistem Analisti – Tasarımcı – Programcı • Şemayı Kullananlar: – Müşteri – Proje Yöneticisi – Tasarımcı – Programcı – Veri Tabanı Analisti – Kullanıcı Arayüzü Tasarımcısı
- 49. Activity Şeması Sembolleri 1 Sembol Tanımı Syntax Start State Activity Şemasındaki akışın başladığı nokta. End State Activity Şemasındaki akışın bittiği nokta. Activity Akış esnasında gerçekleşen bir faaliyet veya bir komut.
- 50. Activity Şeması Sembolleri 2 Sembol Tanımı Syntax State Activity sembollerini önce hangisinin Transition geldiğini belirterek birbirine bağlar veya bir döngüyü ifade eder.. Decision Akışın koşullara göre dallandığı noktalarda kullanılır. Swimlane Faaliyet ve komutları sorumluluklarına göre gruplamaya yarar.
- 51. Activity Şeması Sembolleri 3 Sembol Tanımı Syntax Synchronization Eş zamanlılık içeren faaliyetleri bars ‘ayrılma’ veya ‘birleşme’ noktaları oluşturarak birbirine bağlamaya yarar. Note Her şemaya dilenen bilgilerin yazılması için ve hyperlink note oluşturmak amacıyla kullanılır. Anchor note to Notu şemadaki sembollere item bağlamaya yarar.
- 52. Activity Şeması Sembolleri 4 Sembol Tanımı Syntax Object ‘Elle tutulabilir’ nesnelerdir. OrderItem ObjectFlow Object’i girdi ve çıktı olarak faaliyet ve komutlara bağlamaya yarar.
- 53. Şema Örnekleri 1 act Pizza Siparişi Ahçıbaşı Garson Müşteri ActivityInitial Siparişi Ver Menüyü v er Pizza hamurunu hazırla Afiyetle ye Siparişi mutfağa ilet Pizza malzemelerini hazırla Serv is yap Hesabı iste Pizzayı fırına v er Hesabı sun Hesabı öde Garsona haber v er v s. v s.
- 54. Activity Şeması Örnekleri 2 act Telefon Satış Birimi Müşteri Telefonla Satış Depo Muhasebe Vazgeçirmeye çalış ActivityInitial «satışa sunuldu» İade isteğini ilet Ürün Vazgeçti mi? Ürünü tekrar satışa sun Elemana Bonus yaz Müşteriye ödeme yap Kargoya v er ActivityFinal İade numarası v er ActivityFinal «iade edildi» Ürün Ürünü kabul et
- 57. Activity Şeması Egzersiz Aşağıdaki bilgileri alternatifleri ve beklenmeyen durumları da ekleyerek activity şemasıyla anlatınız (15 dk.) • Yemek Tarifi: Arap Usulü Ispanak – Soğanları kızgın yağda 5 dk. kavurunuz, – İsterseniz, sarmısak ve kimyon ekleyerek 1 dk. daha kızartınız. – Ispanakları tavaya yavaş yavaş ekleyiniz. Eklenen ıspanakların yapraklarını iyi yumuşayıncaya kadar karıştırınız. Taze ıspanak büyük ölçüde pişirilirken ufalacağından, ıspakların hepsi tavaya sığacaktır. – Daha önce yumuşamaları için gece boyunca suda beklettiğiniz nohutların suyunu süzünüz ve tavaya ekleyiniz. – Karışıma tereyağı ve baharat (tuz, biber ve kırmızı biber) ekleyiniz. – Karışım köpürmeye başlayana dek ısıtmaya devam ediniz. – Karışımı kendi suyu içinde hafif nemli olarak sununuz.
- 58. Statechart Şeması • Temel Kavramlar • Şema İçeriği • Şemayla Aktarılan Bilgiler • Tasarım Teknikleri • Forward ve Reverse Engineering
- 61. Temel Kavramlar 3 Action ve Output:
- 62. Temel Kavramlar 4 Event ve State Machine örtüşmesi:
- 63. Temel Kavramlar 5 Bir faaliyet sona erene ve state geçerliliğini yitirene dek eş zamanlı olarak sürekli çalışır:
- 64. Temel Kavramlar 6 Hiyerarşik State Machine’ler:
- 65. İlgili Roller • Şemayı Hazırlayanlar: – Sistem Analisti – Tasarımcı – Programcı • Şemayı Kullananlar: – Sistem Analisti – Tasarımcı – Programcı
- 66. State Machine Şeması Egzersizi Kredi Kartı borcunu zamanında ödemeyenlere tutarın % 5.5’i oranında ceza verilmektedir. Borcunu son ödeme tarihinden bir ay sonra hala ödemeyenlerin kartlarına el konulmaktadır. Diğer durumlarda kart kullanımı normal şekliyle sürmektedir. Kredi Kartı aylık ödeme tutarı 1,000 YTL ve üzerinde olanların kart limitleri iki katına çıkarılmaktadır. 1000 YTL ve üzeri ödeme yapanlara toplam harcamalarının % 2’si oranında hediye çeki gönderilmektedir.
- 67. İçerik • UML Modeli Kavramları • UML Tanımını Genişletme Mekanizmaları • Davranış Şemaları • Yapısal Şemalar
- 68. UML 2.0 Şemaları
- 69. Yapısal Şemalar – class şeması* – package şeması* – composite structure şeması – object şeması – component şeması – deployment şeması
- 70. Class Şeması • Temel Kavramlar • Şema İçeriği • Şemayla Aktarılan Bilgiler • Tasarım Teknikleri • Forward ve Reverse Engineering
- 71. Temel Kavramlar • Class kendisinden üretilecek nesneler için ortak değişken ve metodları içeren bir şablondur. • Bu şablondan üretilecek her nesne sadece şablonunda belirtilen değişken tipine uygun veri yapılarını taşıyabilir. • Her nesne şablonunda tanımlanmış metodlar aracılığıyla kullanılabilir.
- 72. Temel Kavramlar Değişkinler: Bir tip – değer ikilisidir. Class’lar değişken tipini belirler. Nesneler değişken değerini belirler. Değişkenler bir ilkel veri veya bir class tipinde olabilirler. İlkel veri tipi kullanılan yazılım ortamına bağlı olarak değişen integer veya string gibi mevcut veri tipleridir.
- 73. Temel Kavramlar Metodlar: Class’ın tüm nesnelerinin canlandırabileceği davranışlardır. Metodlar önce birer sorumluluk olarak ortaya çıkıp daha sonra fonksiyonlara dönüşürler. Fonksiyona dönüştüklerinde parametreleri ve return tipleri tanımlanmış olmalıdır.
- 74. Temel Kavramlar • Değişkinler ‘private’ Course • Metodlar ‘public’ - number : Integer - name : String - classSize : Integer Hepsi küçük harfle başlar - active : Boolean ve kelimeler bitişik + openForEnrollment ( ) yazılır. + closeEnrollment ( ) + isOpenForEnrollment ( )
- 75. Temel Kavramlar • Her eleman bulunduğu yere erişim haklarını ifade eden bir görünürlüğe sahiptir (visibility). – ‘public’ elemanlar Class dışından görülebilir ve erişilebilirler. Sembolleri: ‘+’ – ‘protected’ elemanlar sadece Class’la generalization ilişkisine sahip Class’larca görülebilir ve erişilebilirler. Sembolleri: ‘#’ – ‘private’ elemanlar ait olduğu Class dışında görülemez ve erişilemezler. Sembolleri: ‘-’
- 76. Temel Kavramlar Encapsulation: Değişkenlerin ‘private’ olma nedenidir. Course - number : Integer - name : String - classSize : Integer - active : Boolean + openForEnrollment ( ) + closeEnrollment ( ) + isOpenForEnrollment ( ) + register ( )
- 77. Temel Kavramlar Generalization: + courses Course - number : Integer * - Farklı ‘abstraction’ - - name : String classSize : Integer active : Boolean seviyeleri arasında + openForEnrollment ( ) + closeEnrollment ( ) ırsiyet ilişkileri kurmak + isOpenForEnrollment ( ) + register ( ) için kullanılır. GraduateCourse PostGraduateCourse - thesisTopic - Sponsor + register ( ) + publishWork ( ) + closeEnrollment ( ) + register ( )
- 78. Temel Kavramlar Polymorphism: + courses - Course number : Integer implementasyonun * - - name : String classSize : Integer detaylarını gizleyerek kolay - active : Boolean + openForEnrollment ( ) kullanımı sağlar. + closeEnrollment ( ) + isOpenForEnrollment ( ) + register ( ) Aynı isme sahip fakat farklı çalışan fonksiyonları ifade GraduateCourse PostGraduateCourse eder. - thesisTopic - Sponsor + register ( ) + publishWork ( ) + closeEnrollment ( ) + register ( )
- 79. Temel Kavramlar Inheritance: oluşmuş class’ların özelliklerinin kademeli olarak zenginleştirilebilmesine olanak verir. Class’ları özel durumlara istinaden ayırarak farklı ‘abstraction’ seviyeleri oluşturulmasını sağlar. Böylece katmanlı bir sistem mimarisine imkan vererek tekrar kullanımı kolaylaştırır.
- 80. Temel Kavramlar Abstract Class: Kendisinden nesne üretilmeyen, hiyerarşik yapının en üstünde yer alan ve kendinden özelleştirilmiş class’lar vasıtasıyla değişkenlerini sistemin kullanımına sunan class’lardır. cd Design Hayvanlar Omniv orlar Eteburlar Otoburlar
- 81. Class Şeması Sembolleri 1 Sembol Tanımı Syntax association Nesneleri etkileşen Class’lar arasında çizilir. aggregation Parça bütün ilişkisi ifade eden bir association türüdür. generalization Aralarında tür / ırsiyet ilişkisi olan Class’ları birbirlerine bağlar. dependency Bağımlılık ilişkisini ifade eder.
- 82. Class Şeması Sembolleri 2 Sembol Tanımı Syntax class Aynı veri yapısı ve davranışı sergileyen nesnelerin kaynaklandığı kalıptır. interface Bir öğenin davranışlarını temsil eden bir fonksiyon grubudur. « in te r fa c e »
- 83. İlgili Roller • Şemayı Hazırlayanlar: – Tasarımcı – Programcı • Şemayı Kullananlar: – Tasarımcı – Programcı
- 84. Class Şeması Örneği cd Design Hayvanlar Bitkiler FotosentezYapanlar Otoburlar Eteburlar Omniv orlar Tur Ucanlar Surunenler
- 85. Class Şeması Egzersiz # 1
- 86. Class Şeması Egzersiz # 2 • “Dinozorlar Paleozoik, Mesozoik ve Senozoik zaman dilimlerinde görülmüşlerdir. Paleozoik’in sonlarına doğru memelileri andıran ilginç bir örnek Dimetrodon’dur. Dimetrodon’un sırtında yelken gibi büyük bir çıkıntı vardı. Dimetrodon yürürken dört ayağını birden kullanıyordu ve etçildi. • Uçan dinozorlara (Pterosor) örnek olarak Pteranodon’u verebiliriz. Diğerlerinin aksine Pteranodon’un kuyruğu yoktu ve çok geniş kanatları vardı (8 m.). Yine ilginç bir özelliği diğerlerinin aksine dişlerinin olmamasıydı. Uçan dinozorlar etçillerdi. • Etçil dinozorların en ünlüsü Tiranosorus’dur. Etçil dinazorların en önemli özelliklerinden birisi genellikle ön ayaklarının çok küçük ve kullanışsız olmasıdır. Bu tür etçil dinozorlar arka ayakları üzerinde yürür ve ön ayaklarını hareket amacıyla kullanmazlar. • Otçul dinozorların en uzunları Diplodokus ve Brontosorus etçil dinazorların aksine dört dev ayağa sahiptiler ve hepsini kullanarak gayet hızlı yürüyebildikleri düşünülmektedir. ”
- 87. Package (Paket) Şeması • Temel Kavramlar • Şema İçeriği • Şemayla Aktarılan Bilgiler • Tasarım Teknikleri • Forward ve Reverse Engineering
- 88. Temel Kavramlar • Paket, Subsystem ve Model – Model içindeki elemanları belli bir referansa göre gruplamaya yararlar. – Her grubun elemanları arasında farklı bir semantik ilişki vardır. Farklı bir nedenden dolayı bir araya gelmişlerdir. • Subsystem (Modül) ve Model aslında birer pakettir.
- 89. Temel Kavramlar Paket UML modeli elemanlarından oluşan bir gruptur.
- 91. İlgili Roller • Şemayı Hazırlayanlar: – Herkes • Şemayı Kullananlar: – Herkes
- 92. Paket Şeması Örnekleri Satış Müşteri Sipariş Depo Yer CD Stok Sipariş
- 93. Şema Eksiksizliği Kontrolleri 1 • UML Şeması hazırlamak serbest resim çalışmasına dönüşmemelidir. • Şemanın hazırlanma amacı asla mevcudiyeti olmamalıdır. • Şemayı hazırlayan ya düşünüyordur, ya sistemi geliştiriyordur, ya birisine doküman hazırlıyordur ya da bir sistemin yapısını inceliyordur. • Şemaların belli hazırlayıcıları ve kullanıcıları vardır.
- 94. Şema Eksiksizliği Kontrolleri 2 • Bir UML şeması çizmeye karar verdiğimizde belli bir amacımız ve açıkça ifade edilebilen sorularımız olmalıdır. • Sorularımız yanıt bulduğunda eğer şirketimiz içinde gereken dokümantasyon seviyesine de uyuyorsak çizim çalışması biter. • Her şemanın aynı konuda olsalar bile farklı yararlılık dereceleri vardır. Bazı şemalar zamana karşı koyar bazılarıysa giderek gözden düşer.
Notes de l'éditeur
- Unified Modeling Language (UML) iş akışlarından tasarım öğelerine dek yazılım projeleri sürecinde ortaya çıkan bilgi türlerini bir bütünlük içerinde üretip tüketme imkanı veren bir sembolik dildir. Yazılım geliştirme faaliyetleri esnasında ortaya çıkan iş ürünlerinin, Tasavvur edilebilmesini: İncelediğiniz problem düzleminin veya geliştirdiğiniz çözümün karmaşıklığının kontrol altına alınmasını, İfade edilebilmesini: Verdiğiniz kararların / Saptadığınız özelliklerin gerçeğe en yakın ve anlamı yoruma açık olmayan bir şekilde modele eklenebilmesini, Oluşturulabilmesini: Yaptığınız model çalışmalarının birer iş yapma faaliyeti olmasını; modelin oluşturulurken aynı zamanda iş yapılmasını sağlamasını, Dokümante edilebilmesini: Model çalışmalarının proje çalışmaları sona erdikten sonra kullanılabilecek birer doküman olarak da kullanılabilmelerini sağlar.
- UML modeli oluşturma nedenlerinden başlıcaları, Geliştirilen sistemin yapısal ve davranış özelliklerini belirleyebilmek ve paylaşmak. Alternatif çözümleri karşılaştırabilmek ve en etkili yaklaşımları seçebilmek. Seçilen yaklaşımların dokümantasyonunu ve tekrar kullanımını sağlamak. Yazılım geliştirme faaliyetlerini sistem mimarisi oluşturma odaklı bir hale getirerek, değişikliğin etkisini azaltmak ve manevra kabiliyetini artırmak. Sisteme farklı çıkarlara göre bakabilmek ve çözümü daha basitleştirmek. Böylelikle, problem çözümünün anlaşılabilirliğini ve tekrar kullanabilirliğini artırmak. Risklere proje başında odaklanabilmek ve risk azaltma bazlı olarak yazılımı geliştirebilmek. İteratif yazılım geliştirme UML sürecinin merkezinde yer alır ve yazılımı kademe kademe çalışır parçalar halinde oluşturarak riskleri önem sırasına göre ortadan kaldırmayı hedefler.
- Dört Model Kuralı: Model Yapınız Çözüm Yönteminizdir: Oluşturduğumuz modelin parçaları ve bu parçaların içerikleri probleme nasıl müdahale edebileceğimizi belirlediğinden, çözümün sınırlarını da dikte eder. Örneğin, gereksinimler aşamasında ifade edilen bir karmaşıklığı hangi analiz ve tasarım kararlarıyla bertaraf edeceğiniz, yapılacak analiz ve tasarım çalışmalarının birbirlerine göre önemleri gibi konular çözüm enstrümanlarımız olarak ortaya çıkar. Her Modelin Belli Muhatapları Vardır: Her modeli oluşturacak ve bu modelden yararlanarak başka çalışmalar yapacak model sahibi roller vardır. Dolayısıyla, modeller bu muhataplara göre farklı amaçlara hizmet ederler ve farklı detay seviyelerine sahiptirler.
- UML 2.0 Şemalarını özetlersek, Şemalar Yapısal ve Davranış şemaları olarak ikiye ayrılırlar. Davranış Şemaları sırasıyla: Use Case Şeması: Sistemin kullanım senaryolarının, aktörlerin ve aralarındaki ilişkilerin gösterildiği bir şemadır. Activity Şeması: İş akışları, veri akışı ve karmaşık program algoritmalarının gösterildiği bir şemadır. State Machine Şeması: Davranışı duruma göre değişen nesnelerin davranış analizlerinin, ömür döngülerinde yaşadıkları durumların ve bu durumlar arasındaki geçiş mantıklarının gösterildiği bir şemadır. UML sürümleri boyunca adı en çok değişen şemadır: State Şeması, Statechart Şeması, State Transition Şeması ve şimdiki adıyla State Machine şeması. Etkileşim Şemaları: Sequence Şeması: Nesneler arasındaki etkileşimlerin zaman ekseninde gösterildiği bir şemadır. Communication Şeması: Nesnelerin, ilişkilerinin ve aralarındaki mesaj akışının gösterildiği bir şemadır. Semantik olarak sequence şemasına denktir. Ancak, nesneler ve aralarındaki mesajların ortaya çıkardığı yapısal özellikleri incelemeye daha faydalıdır. Eski adı Collaboration Şemasıdır. Interaction Overview Şeması: Activity şemasının bir türevidir. Bu şemada kullanılan ‘activity’ sembolleri birer etkileşim şemasını ifade etmektedir. Böylelikle, zaman içerisinde birbirinden kopuk olarak gerçekleşen etkileşimlerin alakalarını gösterme imkanı verir. Timing Şeması: İncelenen öğenin maruz kaldığı durumların zaman içerisindeki analizine imkan verir. Dış olaylar bir nesnenin zaman içinde verdiği cevapların gösterildiği bir şemadır.
- Senaryo bazlı yaklaşımdaki temel varsayımlar, Her tasarlanan sistemin bir insan grubuyla ve /veya başka sistemlerle etkileşim halinde olduğu ve bu etkileşimleri göz önüne serecek bir şekilde çözüm geliştirilmesi gerektiği ve Sistemin kullanıcılarının onun tahmin edilebilir bir şekilde çalışmasını bekledikleridir. Bu varsayımlar çerçevesinde baktığımızda, bir Use Case (Kullanım Senaryosu) sistemin kullanıcılarına sağladığı hizmetlerin senaryolar şeklinde bir anlatımıdır. Anlatılan senaryolara konu olan hizmet sistemin kullanıcısı için anlamlı, gözlenebilir ve zamanla bölünmeyen bir fayda olmak zorundadır. Bu yaklaşım altında sistemin gelişimi kullanıcılarına sağladığı faydaları gölgelemeden, o faydaların sağlanmasını garantileyecek şekilde devam eder. Bir Aktör ise, sistemin sunduğu hizmetleri tetikleyen ve bu hizmetlerden yararlanan bir rol (Bir kullanıcı rolü, örneğin, banka şubesindeki bireysel bankacılık görevlisi veya müzik aletleri satan bir dükkandaki kasiyer gibi) veya bir başka sistemdir. Burada dikkat edilmesi gereken nokta aktörlerin tasarlanan sistemin mutlaka dışında olmaları gerektiğidir. Bunun bazı istisnaları mevcuttur. Eğer, sistem içinde belli bir duruma istinaden otomatik olarak bazı akışları çalıştıran bir tetik mekanizması varsa (Örneğin, sayaç gibi) bu aktörsüz bir use case veya daha yaygın olarak bir aktör olarak gösterilir. Özellikle gerçek zamanlı yazılımlarda bu durum çok yaygındır. Öyleki, tasarım büyük ölçüde bu sistem içi tetik mekanizmalarının etkileşimlerini belirleme faaliyetleridir. Bu durum gerçek zamanlı sistemlerde kodun büyük oranda otomatik olarak üretilmesine imkan vermektedir.
- Kullanıcı Senaryolarının en temel üç işlevini özetleyecek olursak, Sistemin Sınırlarını Tanımlamak: Sistemin sağlayacağı temel işlevleri ve bunların birbirleriyle olan ilişkilerini belirterek, geliştirilecek sistemi diğerlerinden ayırmak. Sistem içerisinde ise kullanım senaryoları vasıtasıyla sistemin sağlayacağı temel işlevlerin sınırlarını ve bunların birbirlerine olan bağımlılıklarını tanımlamak. Sistemin Bütünlüğünü Görebilmek: Sistemin taahhüt ettiği hizmetleri birbirinden kopuk fonksiyonlar veya sadece sistem seviyesindeki modül tanımlarıyla ifade edilmelerinden ziyade direkt olarak müşteriye sağlanan faydalara bağlamak. Dilendiğinde seviye seviye ve farklı rollerin ihtiyaçlarına göre bu hizmetlerin nasıl gerçekleştirildiğini görebilmek. Test için Referans Oluşturmak: Kullanım Senaryosu şemaları her use case’in detaylı alternatifleriyle birlikte akış, veri kullanımı ve iş mantığı bilgilerine sahip olduğundan uygun veri setleri tanımlandığında aynı doküman bir fonksiyonel tesk akış dokümanı olarak kullanılabilmektedir. Bunun da ötesinde, yazılım süreci içerisinde gerçekleştirilen tüm çalışmalar en alt birim olarak use case’ler altında gruplandıklarından, tüm yönetsel ve test faaliyetlerinin planlamasında en önemli Öğe use case’dir.
- Use Case yaklaşımıyla yeni tanışan pek çok kişiye use case’lerin bulunmaları mistik ve doğruluğu çok zor test edilebilir gelebilir. Bunun nedeni geleneksel düşünce şekillerinin referanslarını değişmek zorunda olmalarıdır. Ancak yeni referansa alıştıkça aslında use case bulmanın pek güç olmadığını ve kişinin use case modelinin eksiksizliğinin çok net olarak ölçülebileceğini görürler. Yapılması gereken kişinin kensini Aktör yerine koyması ve kendisi için Gözlenebilen ve Açık bir şekilde bir fayda ifade eden fiillerle sistemin temel bir özelliğini ifade etmesidir. Yukarıdaki örneğe bakacak olursak, Solda use case şemasını çizin hatalı olarak kendisini fonksiyonel düşünmenin etkisine bırakmış ve Functional Decomposition’a (Birbiriyle yakın alakası olan fonksiyonların dağınıklaşması) yol açmıştır. Use Case isimlerine bakacak olursak bunların ufak işlemleri ifade ettiklerini görürüz. Add, Delete ve Update gibi fayda bazlı bilgi vermeyen hemen her use case’in parçası olabilecek işlem adlarını görüyoruz. Burada bahsi geçen pek çok use case yanyana konunca aslında gerçek fayda görülebiliyor, gerçek use case açığa çıkıyor. Sağdaki örnekte use case mantığına uyularak aynı konunun yeni bir modeli çizilmiş. Burada Müşteri Web sayfası kataloğuna bakıp, bir siparişi geçiyor. Bakar bakmaz kime ne faydası olduğunu, use case’in çalıştıılmasının sonucunu görebiliyoruz. Buradaki çözümün daha güzel bir ifadesi olabilir mi? Evet, olabilir. Sağdaki use case’i ikiye ayırabiliriz: Browse Website ve Place Order. Daha sonra da Place Order’dan Browse Website’a bir extends çizgisi çekebiliriz. Bunu okuyacak olursak: Müşteri web sitesini gezebilir ve bu esnada eğer isterse bir sipariş verebilir.
- Use Case Şeması yazılım proje süreci açısından, Gereksinim Yönetimi disiplini içerisinde yer alır. Şemanın iki türü mevcuttur: İş Use Case Şeması (Business Use Case Model): Geliştirilecek yazılımın kapsamının ötesinde, söz konusu işin nasıl yürüdüğünü göstermeye yönelik bir çalışmadır. Kullandığınız iş süreçlerinin, iş mantığının, dolayısıyla iş modenilizin tahlil edildiği bir çalışmadır. Bu değerlendirmeyi takiben, söz konusu işin sağladığı hizmetlerden hangilerinin yazılımla simüle edileceğine karar verilerek, kademe kademe otomasyona geçmek için kullanılır. Örneğin, Müzik CD’leri satan bir dükkanı düşünürseniz, içeride bir görevliye aklınıza takılan bir melodiden bahsedebilirsiniz. Görevli size o melodinin yer aldığı eseri bulabilir. Eğer, satın almaya karar verirseniz, kasada da satın alma işlemini tamamlayabilirsiniz. Bu iş modelini bir Business Use Case şemasıyla resmettiğinizde, ileride hangi hizmetlerin otomasyona yöneleceğine karar verebilirsiniz. Bunun da ötesinde, iş mantığınızı değerlendirme ve geliştirme imkanına sahip olabilirsiniz. Sistem Use Case Şeması (Use Case Model): Yukarıda çalışmayı takiben veya iş modeliniz üzerinde hakimseniz ilk çalışma olarak yapılabilir. Az önce verdiğimiz örnekte, melodinin hangi esere ait olduğunun tespit edilmesini, bir yazılım projesi haline getirerek, çalışmalara başlayabiliriz. Özet olarak, bu tür farklı ihtiyaçlara cevap verdiğinden use case şeması pek çok rolü birbirine bağlar. Şema analistler tarafından hazırlanır. Eğer Business Use Case şeması çizilecekse, bunlar İş Analistleri; yoksa Sistem Analistleri olurlar. Hazırlanan Use Case Şeması, Müşteri: ile sistemin sağlayacağı hizmetler ve bunların nasıl sağlanacağı üzerinde bir anlaşmaya varmak, sistemin sınırlarını belirlemek, Proje yöneticisi: tarafından geliştirilecek sistemin sağlayacağı hizmetlerin önceliklendirilmesi ve kademelendirilmesi, Tasarımcı, Veri Tabanı Analisti ve Kullanıcı Arayüzü Tasarımcısı: tarafından kendi görevlerini yerine getirebilmek için girdi, Testçiler: için ürünün yerine getirmesi gereken fonksiyonların ve başarı kriterleri için bir referans, Kullanım Kılavuzunu Hazırlayanlar: için geliştirelen ürünün kullanım adımlarını tanımlamak için bir referans olarak kullanılır.
- Use Case Şeması Sembolleri: Use Case: tanımı için sık verilen örneklerden bir tanesi ‘To Do List’dir (Yapılacaklar Listesi). Bir örnek verecek olursak, use case adı ile ifade edilen fiil, kullanıcısı tarafından gözlenebilir, anlamlı ve sonu olan bir faydadır: “Para Çek” gibi. Para Çekme işlemiyle ilgili başarılı, başarısız ve olağan dışı senaryolar hep bu tanım altında detaylandırılacaklardır. Aktör: Sistemin sağladığı faydaları (use case’leri) tetikleyen ve onlardan faydalanan sistemler veya insan gruplarıdır. Eğer bir kişi bir sistemden iki ayrı şekilde fayda elde ediyorsa, o kişi iki ayrı role sahiptir. Yine aynı şekilde, iki ayrı kişi sistemden aynı şekilde faydalanıyorlarsa, o iki kişi de geliştirdiğimiz sistem açısından bir aktördür. Aktör ve Use Case aynı cümlenin parçalarıdır. Dolayısıyla, sistemi kullanan rolleri (aktörleri) iyi tanımlayabilmek, sistemin sağladığı faydalara odaklanarak mümkündür. Sistem Sınırı: çok popüler olmayan, sistemin işlevleri (use case’ler) ile sistemin kullanıcılarını (aktörler) birbirlerinden ayırmaya yarayan bir semboldür. Kullanımı yaygın değildir, çünkü sistemin işlevleri ile kullanıcıları use case şemalarında son derece açık bir şekilde ayrılmışlardır.
- Use Case Şeması Sembolleri: Association İlişki Çizgisi: UML şemalarında en çok kullanılan ilişki çizgisi sembolüdür. Okunma şekli ‘kullanma’ veya ‘haberleşme’ şeklindedir. Örneğin, “Müşteri ATM’den Para Çeker” = Müşteri’den Para Çek Use Case’ine bir Association çizilir. Generalization İlişki Çizgisi: Bir ırsiyet (inheritance), tür ilişkisi belirtmeye yarar. Aktörlerin kaç çeşit olduklarını göstermeye yarar. Use Case’ler arasında da tür belirtmeye yarasa da bu çok yaygın bir kullanım değildir. Çünkü, ileride göreceğimiz gibi, use case türü demek use case içindeki bir grup alternatif akış demektir ki bunlar zaten use case içinde barınabilirler. Extend İlişki Çizgisi: UML tanımında popülerlik önemlidir. Bu yüzden sempati duyduğumuz ve faydalı bulduğumuz semboller artık UML tanımının bir parçası olmaktan çıkabilirler. Tabii bunun tersi de mümkündür. Extend ilişki çizgisi Bu duruma iyi bir örnektir. UML tanımının eski sürümlerinde, iki use case’in birbirlerini etkilemesi (birlikte çalışması) yine association çizgisi yardımıyla olmaktaydı. Bunun artık kabul görmüş yolu bir bağımlılık çizgisi (dependency) çizmek ve üzerine “extend” işaretini (stereotype) koymaktır. Extend ilişkisinin tam olarak ifade ettiği ilişki ise bir seçenek ilişkisidir. Eğer bir use case’den faydalanırken, bu use case’in sağladığı faydayla alakalı ve keyfi olarak bir başka use case’i çalıştırabiliyorsanız, ikinci (keyfi olarak çalıştırdığınız) use case’den birinci (önce çalıştırdığınız) use case’e doğru bir extend ilişkisi çizmelisiniz. Sembolün referansı İngilizce dili olduğundan, şöyle okuyacağız: İkinci Use Case ‘extends’ Birinci Use Case. Örneğin, www.amazon.com web sitesini gezebilirim ama ancak canım isterse alış veriş yaparım. Dolayısıyla, ‘Browse Web Site’ (Web Sitesini Gez) use case’i ile ‘Purchase Item’ (Satın Al) use case’i arasında bir seçenek ilişkisi mevcut. Purchase Item ‘extends’ Browse Web Site.
- Use Case Şeması Sembolleri: İnclude İlişki Çizgisi: Bu ilşki çizgisi de tıpkı extend ilişki çizgisi gibi use case’lerin birlikte çalışma nedenlerini daha detaylı bir şekilde göstermek amacıyla ortaya çıkmıştır. Extend’in aksine include use case’ler arasındaki zaruriyet ilişkilerini göstermek amacıyla kullanılır. Örneğin, eğer bir use case’den faydalanırken, bu use case’in sağladığı faydayla alakalı bir başka use case’i çalıştırmak zorundaysanız, birinci (önce çalıştırdığınız) use case’den ikinci (çalıştırmak zorunda kaldığınız) use case’e doğru bir include ilişkisi çizmelisiniz. Sembolün referansı İngilizce dili olduğundan, şöyle okuyacağız: Birinci Use Case ‘includes’ İkinci Use Case. Örneğin, www.amazon.com web sitesini gezerken, alış veriş yapmak istersem önce sisteme kendimi tanıtmam gerekir. Dolayısıyla, ‘Purchase Item’ (Satın Al) use case’i ile ‘Login’ (Sisteme Bağlan) use case’i arasında bir zaruriyet ilişkisi mevcut. Purchase Item ‘includes’ Login. Note: Her UML şeması için aynı şekilde kullanılan bir semboldür. Şemalarınıza gerekli notlarınızı yazmak için kullanabilirsiniz. Anchor Note to Item İlişki Çizgisi: Notlarınızı diğer şema sembollerine bağlamak için kullanabileceğiniz bir ilişki çizgisidir.
- Buradaki örnekte, Kullanıcı Aktörünün Alıcı ve Satıcı türlerine sahip olduğunu, Kullanıcı’nın Sisteme Bağlan UC’ini çalıştırdığında bu iki Aktör’den birine dönüştüğünü görüyoruz. Kullanıcı sisteme bağlanmadan bir teklif vermek isterse (Varsayım: O anda olan bir müzayedeye kayıtsız bir izleyici olarak katılım mümkün), sistem onu Sisteme Bağlanmaya zorlayacaktır: Teklif Ver extends Kataloga Bak VE Teklif Ver includes Sisteme Baglan. Kullanıcı bir Alıcı dönüştüğünde dilediği zaman Teklif Ver UC’ini çalıştırarak, bir teklif verebilir. Satıcı Aktörleri ise Sisteme Bağlan UC’ini çalıştırdıktan sonra Açık Artırma Kur’abilir ve Açık Artırma Seansı Başlat’abilirler. Eğer Açık Artırma Seansı Başlat’ırlarsa Sayaç belli bir süre saymaya başlar. Bu süre sonunda Sayaç Açık Artırmayı Kapat’ır ve Alıcı ile Satıcıları müzayedenin bittiğinden haberdar eder. Sizin de dikkat edeceğiniz gibi Use Case Şemalarında sıkı bir zaman ilişkisi yoktur. neyin önce neyin sonra olduğu çok kesin ve şemanın tamamına yönelik olarak vurgulanmaz. Eğer bu tür bir bakış açısına ihtiyaç duyarsanız, Activity Şemalarını kullanmalısınız.
- Use Case İlişkileri Aktör ile Aktör arasında : Generalization : Tür, Daha fazla veya az yetki Aktör ile Use Case arasında: Use Case yönünde : Association (Çalıştırma, Kullanma) Aktör ile Use Case arasında: Aktör yönünde : Association (Mesaj Verme, Veri Aktarma, Erişme, Kullanma) Use Case ile Use Case arasında: Generalization : Tür, Bir grup alternatif akış Use Case ile Use Case arasında: Parçadan Bütüne doğru : Extend : Seçeneğe bağlı olarak Zenginleştirme, eklenme Use Case ile Use Case arasında: Bütünden Parçaya doğru : Include : Zaruri olarak bir parçası olma, daima birlikte çalışma
- Use Case’leri bulmak için kullanılan en denenmiş ve başarılı olmuş yöntem Event Table Çalışmasıdır. Bu çalışmada aktör olup olmadıkları göz ardı edilerek tüm kişi ve sistemlerin geliştirdiğimiz sistemle etkileşimleri Özne, Nesne ve Fiil’ini belirterek yazılır. Daha detaylı çalışmalarda bu listeye Sistemin Cevabı, Oluşturulan Kayıtlar vs. gibi bilgiler de eklenir. Daha sonra bu listeye yukarıdan aşağıya bakılarak benzer nesne-fiil grupları bulunur. Bulunan grupların aslında aynı Aktör’e ait olup olmadığı incelenir. Diğer bir çalışma şekli de aynı listeye bu kez soldan sağa bakarak, alakalı cümlelerin bir Use Case tanımı altında gruplandırılmasıdır. Bu iki çalışma şekli birbirlerini tamamlarlar.
- Buradaki (Jackson Reed’in ‘Developing Applications with Java and UML’ kitabından alınan) örnekte, geliştirilecek sistemin sağlayacağı işlevlerin aktör bazında gruplandığını görüyoruz. Event Table çalışmasında, oluşturulan tabloya Özne-Fiil-Nesne ilişkisinin ötesinde, istenen diğer bilgi türleri de eklenebilir. Buradaki örnekte işlevin kullanım sıklığı (Frequency) gözümüze çarpıyor. Eğer, değerleri hakkında kabaca bir fikre sahipseniz, bu bilgi ileride use case gruplamaları yaptığınızda, use case’lerin göreceli önemlerini belirlerken işinize yarayabilir.
- Use Case Şeması Çizme Aşamaları [1] Aktör Adaylarını Bulun: Bu adayların geçerlilikleri hakkında fazla düşünmeyin. Sistemi kullanan herkes ve her diğer sistem bir aktör adayıdır. [2] Event Table Çalışmasını Yapın: En azından Özne-Fiil-Nesne ilişkisini belli edecek şekilde, bulduğunuz tüm adayları altalta yazarak (Bir excel dosyası çok pratik bir çözüm olabilir), bir liste oluşturunuz. [3] Aktör ve Use Case’leri Belirleyiniz: Daha sonra “Aynı Nihai Hedefe Yöneliklik” ve “Eşdeğer Rol Tanımı” açısından aktör adayları ve sistemden faydalanma şekillerini inceleyiniz. Bu çalışma sonucunda sistem genelindeki use case’lerin % 80’ini bulmanız mümkündür. Bu da proje planlama ve yönetimi açısından kafi bir kontrol seviyesidir. [4] – [6] Use Case Şemasının Detaylarını Belirleyiniz: Önce bulduğunuz aktörlerden başlayarak, derlediğiniz bilgileri resmediniz. Aktörler arasındaki “tür” ilişkilerini Generalization sembolünü kullanarak belirtiniz. Daha sonra tek yolu tarih edeceğimiz olmamakla birlikte, en önemli aktörden başlayarak aktörleri sırasıyla Use Case Şemasına yerleştiriniz. Yerleştirdiğiniz aktörü onunla ilgili use case’leri şemaya ekleyerek, use case’lere bağlayınız (Association). Çizdiğiniz use case’ler arasındaki “seçenek” (extend) ve “zaruriyet” (include) ilişkilerine dikkat ediniz ve gerektiğinde bu sembolleri kullanarak, use case’leri diğer use case’lere bağlayınız. Bu işlemleri tüm aktörler için tekrarlayınız. Oluşturduğunuz kaba use case şemasını toplantıya katılanlarla birlikte değerlendirip, aranızda bir fikir birliği sağlayınız. Aynı düşüncelerin şemada farklı gösterimleri mümkündür. Bu ve benzeri detayları daha sonra değerlendirmek üzere, şema genel yapısı üzerinde anlaşmaya bakınız. Hem bu çalışmanın hem de öncekilerin başarısı, bu çalışmalara proje sorumluluğunu paylaşan her gruptan en az bir temsilcinin katılımıyla mümkündür. Eğer toplantılara gelmesi gereken gruplardan biri (Analistler, Tasarımcılar, Konu Uzmanları, Müşteriler, Yöneticiler gibi) gelmemişse toplantıyı erteleyiniz. Bu toplantılara (ortalama katılımcı sayısı genellikle onu aşmaz) en fazla ardışık üç gün veriniz. Toplantı sonunda mutlaka bir çıktı (Use Case Şeması) ve karar birliğinizi ifade eden bir toplantı tutanağını basıp aranızda dağıtınız.
- Aktör Bulma Soruları Bu sorular bir eksiksizlik iddiasında değildir. Birbiriyle aynı bilgiyi bulmaya çalışan sorular varsa bunlar farklı soruluş biçimleriyle unuttuklarınızı tespite yöneliktir. Soruların amacı aktör adaylarını ortaya çıkarmak olup, zaten bulmuş olabileceğiniz bir cevapla vakit kaybetmeniz gerekmemektedir. [1] Geliştireceğiniz sistemin gereksinimleri (isterleri, requirements) kimlere fayda sağlamaya yönelik? [2] Geliştirilen sistemin kullanıcıları bir şirketin veya kurumun özel bir biriminde mi görev yapmaktadırlar. Örneğin, şube bankacılığı, bir gıda fabrikasının ambar yönetim birimi, F-16 pilot adaylarını yetiştirmek için kullanılan simülasyon merkezi, vs. [3] Sistemle etkileşecek belli roller kimlerdir? Kim sistem vasıtasıyla veri girişi yapacak, eski verileri inceleyecek ve gerekli değişiklikleri yapacaktır? [4] Sistemin bakımı için düşünülen prosedürler nelerdir ve kimler bu işlerle ilgileneceklerdir. Örneğin, yeni müşterilere uyarlama için parametrik bir yapı mı kullanılacaktır, yeni sürümlerin müşterilere aktarılmaları için düşünülen yollar nelerdir? [5] – [6] Sistemin bağımlı olduğu veya bizim sistemimize bağımlı olan diğer sistemler nelerdir? [7] – [8] Sistemi faklı rolleri canlandırarak birden fazla şekilde kullanan kişiler var mıdır? Örneğin, bir kişi hem yöneticilik yetkilerini kullanarak, ambar giriş çıkışlarını denetleyebiliyor, aynı zamanda da aslında alt kadroların yapmaları gereken ambara giren ve ambardan çıkan malları veri tabanına ekleyebiliyor mu? Aynı zamanda, bunun aksi durum mevcut mudur? Müşteri kadroları söz konusu olduğunda, iş tanımı olarak farklı olsalar da sistemi kullanım şekilleriyle aynı rol (aynı aktör = tek aktör) olan kişiler var mıdır?
- Use Case Bulma Soruları [1] Aktörlerin sistemi kullanarak yerine getirecekleri işler, görev tanımları nedir? [2] Aktörlerden herhangi birisi sistemi bazı kayıtları oluşturmak, kaydetmek, değiştirmek, silmek ve okumak amacıyla kullanacak mı? [3] Yukarıda saptadığınız fonksiyonlar / işlemler hangi kapsamda bir grup oluşturmaktadır? Hangi nihai hedefe (faydaya) yöneliklerdir? Hangi bütünün parçalarıdır? [4] Bulduğunuz aktörlerden herhangi birisinin geliştirdiğiniz sistemi sınırları dışındaki değişikliklerden (sensörlerin ilettiği değerler, kredi kartları sistemi gibi bağlı olduğu sistemlerin durumu vs.) haberdar etmesi gerekiyor mu? [5] Herhangi bir aktörün sistem içindeki (kendi çalıştırmadığı use case’lerin etkilerinden) değişikliklerden haberdar edilmesi gerekiyor mu? [6] Hangi use case’ler sistemin bakımı için kullanılacak? Yazılım ekibi gözüyle bakınca tespit edilen faydalar (shadow use cases) nelerdir? [7] Sistemin sağlayacağı tüm hizmetler (tüm fonksiyonel gereksinimler) use case’ler ile ifade ediliyor mu? Bu aşamada gereksinimlerin tanımladığınız faydaların altına (use case’lerin kapsamına, akışlarına eklenerek) yazılarak kapsandığından emin olunuz. Örneğin, “ Bakiyeye Bakaılabilmesi”, aslında “Para Çek” use case’nin bir akışının parçası olduğundan kapsanmaktadır ve adının use case seviyesinde (Ayrı bir use case olarak) tanımlanması gerekmez.
- Lütfen şemadan anladıklarınız aşağıda bir paragrafı aşmayacak şekilde özetleyiniz. Bu egzersiz için verilen süre 10 dakikadır.
- Lütfen yukarıdaki açıklamalardan anladıklarınızı aşağıda bir use case şeması çizerek özetleyiniz. Bu egzersiz için verilen süre 15 dakikadır.
- Activity Şeması zaman içerisinde birbirini takip eden faaliyetlerin ilişkilerini göstermek amacıyla kullanılır. Bu faaliyetler ardışık olabilirler, birbirlerini izlemeleri veya birbirlerine alternatif oluşturmaları belli koşullara bağlı olabilir. Bütün bu bilgileri belli bir detay seviyesinde ve tanımlı muhataplar tarafından tüketilmek üzere activity şemalarını kullanarak ifade edebiliriz. Dolayısıyla tipik activity şeması çizme nedenleri arasında şunları sıralayabiliriz, Use Case (Kullanım Senaryosu) akışlarını göstermek, Use Case seviyesinin de üstünde, tüm sistemi kapsayacak şekilde, bir “workflow” (İş Akışı) şeması yerine, Use Case Map oluşturarak uzun bir zaman diliminde tek başlarına gözlenebilir ve anlamlı faydaların (use case’lerin) nasıl bir ilişkiye sahip olduklarını göstermek amacıyla, Çok daha detay seviyede karmaşık bir algoritmanın hangi komutlar ve mantık dahilinde gerçekleştiğini göstermek amacıyla kullanabiliriz.
- Şema aşağıdaki roller tarafından kullanılabilir: İş Analisti: tarafından Workflow (İş Akışı) ve İş Use Case Modelini (Business Use Case Model) detaylandırmak amacıyla, Sistem Analisti: tarafından Use Case Modelini detaylandırmak, dokümantasyon yerine kullanmak veya dokümantasyonları daha kolay anlaşılır kılmak amacıyla, Tasarımcı: tarafından programcıları kullanılacak algoritmalarla ilgili olarak yönlendirmek için, Programcı: tarafından kullanacağı algoritmaları öğrenmek ve değerlendirmek için üretilebilir. Şema bilgilerini tüketecekleri sıralayacak olursak, Müşteri: İş Akışları, Yazılım kapsayacağı iş kapsamı, İşlevlerin (Faydaların, Use Case’lerin) üzerinde anlaşmaya varmak için, Proje Yöneticisi: Gereksinimlerin ve Proje Kapsamının eksiksizliğini kontrol için, Tasarımcılar: arasında fikir alış verişi ve tasarım yöntemlerinin saptanması için, Programcılar: arasında algoritmik yaklaşımlarının karşılaştırılması ve uygun yöntemin saptanması için, Veritabanı Analisti: tarafından veritabanı modelini oluştururken ihtiyaç duyacağı tüketilen veri bilgilerini öğreneceği akış bilgileri olarak, Kullanıcı Arayüzü Tasarımcısı: tarafından arayüz / ekran akışlarını ve arayüz / ekran yapılarını belirlemek için ihtiyaç duyacağı akış bilgileri olarak kullanılabilir.
- Activity Şeması Sembolleri Start State Noktası: Her şemada olması gereken başlangıç noktası. Şema başına bir tane olabilir. End State Noktası: Şemada bulunması zaruri olmayan ve şema başına dilediğiniz sayıda bulundurabileceğiniz incelenen akışın bitiş noktalarını gösteren bir semboldür. Activity: Şemanın hazırlandığı detay seviyesine / muhatabına göre değişmekle birlikte, çizilen akışın adımlarını ifade eder. Örneğin, iş süreçlerinizin temel adımları, kullanım senaryolarının (use case) akış adımları veya bir fonksiyonun birbirini izleyen komutları.
- Activity Şeması Sembolleri State Transition Çizgileri: Şemaya eklediğiniz activity sembollerini (akış adımlarını) gerçekleşme sıralarına göre birbirlerine bağlar (önce hangisi, sonra hangisi geliyor). Decision sembolünün de yardımıyla Activity sembolleri arasındaki koşulları (if, else if, switch, vs.) ve döngüleri (loop) belirtmeye yarar. Decision: Akışın koşullara göre dallandığı durumlarda kullanılarak, alternatif durumların Acticity Şemasına eklenmesine imkan verir. Swimlane (Yetki Alanları): Activity şemasındaki adımların belli referanslara göre gruplanmasını sağlar. Örneğin, eğer bir use case akış detayını çiziyorsanız, akış bilgilerini bir dialog yapısında gösterebilmek için akış adımlarını “Akışı çalıştıran aktörün adı” ve etkileştiği “sistemin adı” olmak üzere, ikiye bölebilirsiniz.
- Activity Şeması Sembolleri Synchronization Bar: Eş zamanlılık içeren, birlikte yapılan faaliyetleri ilgili oldukları akış adımıyla daha sıkı bir şekilde alakalandırabilmek için kullanılır. İki kullanım şekli vardır. Ya bir akış adımını pek çok olası / paralel akışa bağlar. Akış adımı ve alternatif akışlar arasında bir “decision” sembolü olur. Ya da herhangi bir koşula bağlı olmaksızın bir akış adımının doğal sonucu olan birden çok adımının zaman içindeki ilişkisini gösterir. Tersi bir durumda ise, pek çok alternatif adım tek bir akış adımına bağlanarak, girdi sağlar. Note: Her UML şeması için aynı şekilde kullanılan bir semboldür. Şemalarınıza gerekli notlarınızı yazmak için kullanabilirsiniz. Anchor Note to Item İlişki Çizgisi: Notlarınızı diğer şema sembollerine bağlamak için kullanabileceğiniz bir ilişki çizgisidir.
- Activity Şeması Sembolleri Object: sembolünü class’lardan türetilen object’lerle (nesne) karıştırmamak gerekir. Burada object’den kasdedilen elle tutulur metalar veya akış adımlarının gerçekleşmeleri için gereken girdi ve çıktılardır. Object Flow: Object sembollerini alakalı oldukları akış adımlarına (activity) girdi ve çıktı ilişkisini belirtecek bir şekilde (girdiyse ok ucu activity’e doğru, çıktıysa ok ucu activity’den dışarıya doğru) bağlamaya yarar.
- Buradaki şemada, Activity Şeması’nın üç parçaya ayrılarak zaman ilişkisinin (Önce ne oldu, Sonra ne oldu) ona göre ifade edildiğini görüyoruz. Ahçıbaşı Pizza Hamurunu Hazırla’dıktan sonra, belki de ertesi gün, Garson Müşteri’den Sipariş’i alır. Sipariş alınmasının bir bölümünün Müşteri’nin işi olduğunu görüyoruz. Müşteri hangi pizzayı istediğini belirtir. Bunun üzerine Garson, isteği Mutfağa İletir. Ahçıbaşı dün mayalanmaya bıraktığı hamurlarından bir topak alarak, onu açar ve istenen Türe Uygun Malzemeleri Hazırla’r. Daha sonra Pizzayı Hazırlar (onu fırına verir vs.). Pizza hazır olunca, Garson onu Servis Yap’ar. Müşteri pizzasını Afiyetle Ye’dikten sonra Hesabı İster ve Garson da Ücreti Tahsil Ed’er.
- Buradaki şemada Swimlane (Yetki Alanı) kullanımı görüyoruz. Activity Şemalarında Yetki Alanları herşey olabilir: Aktörler, Use Case’ler, Class’lar, Modüller vs. Önce Müşteri bir Ürünü Geri Gönderme İsteğini İlet’iyor. Telefondaki satış görevlisi ona bir İade Numarası Al’ıyor. Müşteri bu numarayı göndereceği kargonun görünen bir tarafına yazarak Ürünü Gönderiyor. Eve keyfi yerinde dönüyor çünkü ona göre Ürün İade Edildi statüsünde. Kargo ürünü bir kaç gün sonra satın alındığı şirkete teslim ediyor. Şirketin iade deposu Ürünü Al’ıyor. Bir tetkikten sonra, Ürünü Tekrar Satışa Sunuyor. Ürünün Satisa Sunuldu statüsünü Öğrenen muhasebe bölümü Müşteriye Ödeme Yapıyor (Kredi kartına Geri yükleme vs.). Bu şema da bir önceki gibi bir “Workflow Şeması.” Yani yazılımın geliştirileceği ortamda işlerin nasıl yürüdüğünün ifade edildiği genel bir şema. Bu şemadaki her faaliyet belki de pek çok Use Case’e ve modüle dönüşecek. Bu durumda şemayı hazırlayanların İş Analistleri ve şemayı kullanacak kişilerin Sistem Analistleri olduklarını söyleyebiliriz.
- Buradaki şemada Activity Şemalarının özel bir kullanım şeklini görüyoruz: Bir algoritmanın detaylarının ifade edilmesi. Bu durumda şemanın tasarımcı veya programcıdan programcıya yönelik olarak hazırlandığını söyleyebiliriz.
- Burada ise Activity Şemalarında Object’lerin kullanımına değinilmiş. Bir müşteri mağazada bir CD’yi seçerek kasaya götürdüğünde, kasiyer bu CD’yi alarak fiyatına bakar. Fiyatına baktığı CD’nin ücretini tahsil eder ve onu depodan düşer. Müşteriye CD’sini paketleyerek verir. Aynı zamanda müşteriye alışveriş fişini de verir.
- Lütfen verilen bilgileri aşağıda bir activity şeması ile ifade ediniz. Egzersiz için verilen süre 15 dakikadır.
- Bu şemada iki tane State (Durum) görüyoruz: Lamp On : Lamba Yanıyor Lamp Off : Lamba Sönük Bu durumlar arasında geçiş LampOff -> LampOn’a ‘on’, LampOn -> LampOff’a ‘off’ komutlarıyla olmaktadır. Bu iki durumdan hangisi aktif olursa o durumun aktifliğini kendi komutunu çalıştırarak ‘on’ veya ‘off’ sağlamaktadır. Buradan anlamamız gereken bu durumların sahip oldukları durum bilgilerinin sadece dış tetik mekanızmalarınca değiştirilebileceğidir.
- State Machine veya Statechart Şemalarında kullanılan semboller kısaca, Initial Psedostate : Akış başlangıçı Top State : İçinde diğer durumları içeren bir durum, superstate Transition : Bir durumdan diğerine geçiş çizgisi Final State : Akış sonu Trigger : Bir durumdan diğerine geçerken aktif hale gelen işlem Action : Trigger’a göre çalıştırılan komut
- Aynı işlemler Action ve Output gibi yapılabilirler. Örneğin, soldaki resimde Lamba off’dan on konumuna geçerken, On Trigger’ına istinaden print(“on”) Action’ı çalıştırılmaktadır. Sağdaki örnekte ise, Lamba önce off konumundan on konumuna geçmektedir. Sonra on konumunu korurken print(“on”) Action’ı çalıştırılmaktadır.
- State Machine modeliyle ifade edilen olay akışı nedir diye merak edersek, yukarıdaki gibi bir karşılaştırma yapabiliriz. Olay Akışı: Nesnelerin oluşturulması ve ilk değerlerin verilmesi Tetiklenme için bekleme Tetik mekanızmasına karşılık gelen işlemlerin yapılmaları Nesnenin hafızadan silinmesi State Machine Akışı: Lamba yakılır Lamba söndürme tetik mekanızması beklenir (Lambanın yanıklığı korunur) Lamba söndürme ikazı alındığında Lamba söndürülür Lamba yakma tetik mekanızması beklenir (Lambanın sönüklüğü korunur) Lamba yakma ikazı alındığında önce Lamba Yanıyor (on) yazısı basılır sonra da Lamba yakılır
- Sürekli çalışan işlemler : do Bir durum aktifliğini koruduğu müddetçe çalıştırılırlar.
- State Machine Modeli Soyutlamaları (Abstraction) Lamba “on” ve “off” konumları dışında “flash” konumuna da sahiptir. Flash konumu LambFlashing durumu altında açıklanmış / gizlenmiştir.
- State Machine Şemasını hazırlayanlar, Sistem Analisti: Tasarımcıların hazırladıkları versiyonlara göre daha az detaya sahip olan, sistemin akışını kritik olarak etkileyebilecek öğelerin, sistemin koşullara göre nasıl davranış değiştirdiğini gösterdiği bir çalışma türüdür. Yazılım türlerine göre, gereksinim çalışmalarının önemli bir kısmı olabilir (Örneğin, gerçek zamanlı yazılımlar: simülasyon, vs.). Tasarımcı ve Programcı: tarafından davranışı değişkenlerinin alacağı özel öneme sahip değerlere (state, durum) göre değişen nesnelerin davranışlarını incelemeye yarayan bir çalışma türüdür. Yazılım türlerine göre, analiz ve tasarım çalışmalarının önemli bir kısmı olabilir (Örneğin, gerçek zamanlı yazılımlar: simülasyon, vs.). Şemayı kullananlar ise aralarındaki fikir alışverişlerini sağlamak için, yine yukarıda belirtilen rollerdir.
- Lütfen yukarıdaki anlatılanları bir State Machine şeması ile özetleyiniz. Egzersiz süresi 10 dakikadır.
- UML 2.0 Şemalarını özetlersek, Şemalar Yapısal ve Davranış şemaları olarak ikiye ayrılırlar. Yapısal Şemalar sırasıyla: Class Şeması: Class’lar başta olmak üzere, statik model sembollerini ve türlerini, içeriklerini ve bu sembollerin birbirleriyle olan ilişkileri gösterir. Object Şeması: Nesneleri ve ilişkilerini belli zamandaki durumlarına göre göstermek için kullanılır. Genellikle bir class şeması veya etkileşim (collaboration / communication) şemasıdır. Component Şeması: Geliştirilen sistemin bileşenlerinin, birbirleriyle olan etkileşim ve bağımlılıklarının, kullanıma açık interface’lerinin gösterildiği bir şemadır. Composite Structure Şeması: Seçilen öğenin (Bir class, bileşen veya use case) iç yapısının ve öğenin sistemin diğer parçalarıyla olan etkileşiminin gösterildiği bir şemadır. Deployment Şeması: Sistem mimarisinin çalışma ortamının, kullanılan donanım ve yazılım altyapılarının özelliklerinin ve birbirleriyle olan ilişkilerinin ifade edilerek gösterildiği bir şemadır. Package Şeması: Model öğelerinin çeşitli referanslara göre gruplanmalarına ve model yapısının proje ihtiyaçlarınıza göre yapılandırılmasına imkan veren bir şemadır.
- Class nesne tabanlı yaklaşım içerisindeki en temel öğedir. Veri yapısı ve bu veriler üzerinde yapılabilecek işlemlerin benzeştiği durumlarda onların gruplanarak, bir soyutlama oluşturması işleminin sonucudur. Bu soyutlamadan (şablondan) üretilecek her nesne bu tanımlı değişken türlerinden başkalarını içeremez ve bu veriler üzerinde daha önce tanımlanmış işlemlerden başkalarının yapılmasına izin veremez.
- Class’ların içerebileceği iki temel bilgi türünden ilki değişkenlerdir (attributes, variables, fields). Değişkenlerin bir tipi ve program akışı içinde alabilecekleri değerleri vardır. Nesneler değişkenlerin çeşitli değerler taşıyarak, program akışı esnasında ihtiyaç duyulan veri alışverişini sağlarlar. Değişkenler birer ilkel veri tipinde (integer, boolean, character, vs.) olabilecekleri gibi birer class tipinde de olabilirler. Dolayısıyla kendi tanımladığımız class’ları da birer değişken olarak program akışı içerisinde kullanabiliriz.
- Class’ların içerebileceği diğer bilgi tipi metotlardır (method, responsibility, function). Bu metotlar temel soyutlamaların tanımlandığı analiz aşamalarında birer sorumluluk olarak ortaya çıkıp, daha sonra tasarım çalışmaları esnasında detayları artık belirlenmiş (return type, parameter, precondition, postcondition, vs.) fonksiyonlara dönüşürler.
- Class UML’de en yaygın olarak üç parçalı bir dikdörtgen sembolüyle gösterilir. En üstteki parçasına, Her kelimesi büyük harfle başlamak üzere, class’ın adı yazılır. Üstten ikinci parçasına class’ın değişkenleri, üçüncü parçasına da class’ın metotları yazılır. Değişken ve metot isimleri ilk kelimeleri küçük daha sonrakilerse büyük harfle ve birbirine bitişik olarak yazılır. Değişken üzerlerinde yapılabilecek hataları engellemek için doğrudan erişilemezler ve bu yüzden ‘private’ olarak ifade edilirler. Metotlarsa class’ın kolay kullanımını sağlamak için diğer nesnelerin kullanımlarına açıktırlar ve ‘public’ olarak işaretlenmişlerdir.
- Class’ların değişkenlerinin ve bazı özel durumda metotlarından bazılarının direkt erişime açılmamaları (‘private’ olmaları) nesne tabanlı yaklaşımın dört önemli özelliğinden, Encapsulation’ı sağlamaktadır. Kullanıcısı bir class’ın değişkenlerine direkt olarak erişmez ve bilmesi gerekmeyen karmaşıklıklar ondan gizlenir. Böylece hata yapması engellenir ve işini görmesi için gerekenden fazla bilgi derlemesi gerekmez.
- Tasarımımızda soyutlama seviyelerini belirleyebilmek için nesne tabanlı yaklaşımın dört önemli özelliğinden, Abstraction’ı kullanıyoruz. Çok sayıda class’dan oluşan nesne modellerini daha kolay oluşturmak ve daha sonra da kolay anlayabilmek için aralarında tür ilişkileri kuruyoruz.
- Nesne Tabanlı programlama dillerinde önemli bir yeri olan Polymorphism, encapsulation ilkesine hizmet eden bir programlama tekniğidir. Aynı isme sahip fonksiyonlar kullanılırken sağlanan veri türü ve sayılarına göre farklı algoritmalar dahilinde çalışırlar. Aslında birbirlerinden türetilmiş class’lara yayılmış, aynı isme sahip fakat farklı amaçlar için kullanılan fonksiyonlar kullanma tekniğidir. Örneğin, “GeometrikSekiller” adinda bir ana class’ımız olsun. Onun altında, Daire, Üçgen, Kare gibi class’lar, onlarında altında onların türleri olduğunu düşünün. Bu durumda çeşitli class’larda mevcut olan bir ‘çiz()’ fonksiyonu, ekrana girilen verilere bağlı olarak bir kare, bir üçgen veya daire çizebilecektir.
- Generalization ilişkisini kullanarak oluşturduğumuz class tür ilişkileri (Parent-Child), her seviyede farklı bir soyutlama oluşturur. Bu mekanizmanın en büyük faydası sistemin daha sonra kolaylıkla yeni durumlara adapte olabilmesinin sağlanmasıdır. Yeni class’lar yeni class türleri olarak eklenir ve mevcut tasarımın özelliklerinden yararlanırlar. Bu katmanlı yazılım mimarisi tekrar kullanımı sağlayan en önemli etkendir.
- Abstract Class’lar soyutlama katmanlarının hiyerarşik yapılarının en üstünde yer alırlar. onlardan nesne üretilmez. Tüm ‘child’ seviyesindeki class’larında ortak olan özellikleri içerirler ve bu özellikler bu ‘child’ seviyesindeki class’lar aracılığıyla kullanılırlar. Yukarıda verdiğimiz örnekte olduğu gibi, Hayvanlar class’ından bir nesne üretmek anlamlı değildir. Çünkü buradaki sınıflandırmayı beslenme yöntemlerine göre yapmaktayız ve hangi hayvanı sembolize eden bir nesne üretirsek üretelim aslında hayvanlar class’ının türleri olan Omnivorlar, Eteburlar ve Otoburlar türlerinden birisine ait olmak zorundadır.
- Class Şeması Sembolleri: Association İlişki Çizgisi: Birbirlerinin metotlarını çalıştıran nesneleri olan class’lar arasına çizilir. Çift yönlü veya tek yönlü olarak çizilir. Koddaki karşılığı bir class tipindeki değişkendir: Class1 x, y, z; Aggregation İlişki Çizgisi: Aggregation aslında bir çeşit association’dır. Tek farkı haberleşmeye ek olarak aynı zamanda bir parça bütün ilişkisini de ifade etmesidir. İki tür gösterim şekli vardır. Eğer parça bütünden bağımsız olarak da program akışı içerisinde (iş mantığı açısından) kullanılıyorsa, bütüne bitişik içi boş bir baklava sembolü ile parçaya doğru çizilen bir çizgi ile ifade edilir. Bu durumda parçadan -bütünden üretilen nesneler olmasa da- direkt olarak nesneler üretilebilir. Koddaki karşılığı, association gibi, bir class tipindeki değişkendir: Class1 x, y, z; Eğer parçanın bütünden bağımsız mevcut olması mantıklı değilse, bu sefer daha sıkı bir parça bütün ilişkisi kurularak, bütüne bitişik içi dolu bir baklava sembolü ile parçaya doğru çizilen bir çizgi ile ifade edilir. Bu durumda parçadan nesne üretebilmek için mutlaka bütünün de nesnesinin üretilmesi gerekir. Koddaki karşılığı bir class tanımı içinde tanımlanmış ve dolayısıyla o class’dan bağımsız varolamayacak bir değişkendir. Generalization İlişki Çizgisi: Aralarında tür ilişkisi olan (Parent-Child) class’ları birbirlerine bağlamak için kullanılır. Geliştirilen problem çözümünün nesne yapısını berraklaştırmak için yapılan en önemli çalışmalardandır. Dependency İlişki Çizgisi: Eğer class’ın yerine getirmeyi tahhüt ettiği bir hizmetin bağımlı olduğu başka bir veri varsa, bu class’dan bağımlı olduğu class’a doğru bir “dependency” (bağımlılık) çizgisi çizeriz. Kodda bir karşılığı olmayan bu ilişki sadece şemalarda gözden kaçabilecek önemli bir noktayı hatırlatmak amacıyla kullanılmaktadır.
- Class Şeması Sembolleri: Class: Nesne tabanlı yaklaşımın en temel öğesi olan, nesnelerin üretildiği ortak veri yapısı ve davranışları bir soyutlama altında toplayan, semboldür. Interface: adıyla işaretlenmiş (stereotype) bir class’dır. Class’ların, sistemlerin ve modüllerin implementasyon detaylarını gizleyerek, kolay kullanımını sağlayan bir semboldür. İçerdiği fonksiyonlar bu interface’e bağlı bir implementasyon class’ı aracılığıyla görevlerini yerine getirirler. Implementasyon class’I aynı isimli fonksiyonlara sahiptir.
- Class Şemalarını hazırlayanlar ve kullananlar temelde iki role sahiplerdir: Bunlar, Tasarımcı ve Programcı rolleridir. Tasarımcılar analiz ve tasarım class’larını bulurken ve bu class’lardan üretilen nesnelerin yapılarını incelerken class şemalarına başvururlar. Diğer bir kullanım nedenleri, kendi deneyimleri doğrultusunda programcıları yönlendirirken, yoruma açık olmayan bir şekilde bilgilerini bu ortamda aktarabilmeleridir. Buna ek olarak, tasarımcılar kendi aralarında fikir alışverişi nedeniyle de class şemalarını kullanırlar. Bunun en büyük nedeni problemlerin olası çözümlerinin birden fazla olabilmesidir. Bu tür mutlak doğru olmayan durumlarda bir yaklaşım neden ve düşünce sürecini vurgulayarak, en iyi çözümü seçmeye çalışırlar. Programcılar ise tasarım kararlarını aldıktan sonra bu çözümü geliştirirken ihtiyaç duydukları class’ları tanımlamak ve bu çözüme entegre etmek amacıyla class şemasını kullanırlar.
- Bu örnekte Nesne Modeli’nin 4 seviyesi olduğunu görüyoruz: En üstte Canlı Türleri: Bitkiler, Hayvanlar … yer almakta. Bir alt seviyede canlılar beslenme şekillerine göre gruplandırılmışlar: Fotosentez Yapan Bitkiler, Otobur Hayvanlar, Etebur Hayvanlar ve Omnivor Hayvanlar 3. Bu seviyede 4. seviyedeki gruplanmaları daha kolay zenginleştirebilmek için bir üst katman oluşturulmuş: Etebur Türleri 4. Son seviyede Eteburların bir Tür değerine göre Uçanlarını ve Sürünenlerini buluyoruz. Örneğin Tür = Dinazorlar, Surunenler. Allosaurus veya Tür = Memeliler, Uçanlar, Yarasa olabilir.
- Lütfen yukarıdaki class şeması içeriğini bir paragrafta özetleyiniz. Egzersiz süresi 10 dakikadır.
- Lütfen yukarıdaki açıklamalara dayanarak bir class grubu oluşturunuz. Egzersiz süresi 20 dakikadır.
- Paket Şeması aslında herhangi bir şema türünde yapılan çalışmalar esnasında bu şemalara yerleştirilen sembollerin belli referanslar doğrultusunda gruplanmaları nedeniyle ortaya çıkmaktadır. Dolayısıyla aslında Paket Şeması adı altında bir şema türü yoktur. Her paket altında gruplanan sembol topluluğunun ilişkilerinin farklı bir nedeni vardır. Bu neden paket altındaki öğelerin yazılım süreci disiplinlerinden birine ait olmaları, belli bir çalışmanın girdisi veya çıktısı olmaları veya geliştirilen sistemin aynı modülünde ya da aynı katmanında yer almaları olabilir.
- Paketler arasında hiyerarşik ilişkiler kurularak, altalta giderek alakalı çalışmaları daha detaylı hale gelen veya yazılım süreci içerisinde farklı bakış açılarına göre modeli yapılandıran yaklaşımlar mümkündür. Paketlerin tek başlarına belli bakış açılarını temsil edebilmeleri, bizlerin farklı referanslara göre sisteme bakmayı sağlayan karmaşık sistemleri etkili bir biçimde ifade edebileceğimiz modelleri oluşturabilmemizi sağlar. Bu yaklaşıma pararlel olarak UML modeli bir role, roller arasındaki ilişkilere, kullandığımız teknolojinin katmanlarına, belli yazılım süreçleri disiplinlerine ve keyfi olarak tanımlayabileceğimiz herhangi bir referansa göre içinde ilerleyebileceğimiz 3 Boyutlu bir yapıya bürünür. Ayrıca, modelin tekrar kullanılabilirliği, versiyonlanması ve hedeflemiş olabileceğiniz kalite standartlarına uygunluğu hep bu model yapısının (paket içeriklerinin ve ilişkilerinin) özenle belirlenmesi ve uygulanmasına bağlıdır.
- Paket Şeması Sembolleri Package: Tüm model sembollerini gruplamak için kullanılabilecek paket sembolüdür. Dependency: Paketler arasında kurulabilecek yegane ilişki “dependency” ilişkisidir: “--------- ” Bu ilişki temelde birbirine bağımlılık ve bu ilişkiye sahip öğelerinde geliştirilmelerinde zaman açısından öncelik ve sonralık bilgisi vermeye yöneliktir. Sık kullanılmamakla birlikte, çeşitli stereotype’larla işaretlenen bu sembolün en yaygın kullanım şekli: <<trace>>: Yazılım süreci içerinde öncelik, sonralık ilişkisi. PaketA --- <<trace>> --- PaketB: “PaketA PaketB’ye bağlı olarak, daha sonra oluşturulur.” Subystem: Tasarım çalışmaları esnasında geliştirilen yazılımı aralarında mantık ilişkisi bulduğunuz, modüllere bölmeye yarar.
- Paket Şemasını yazılım ekibinizdeki herkes hazırlayıp, kullanabilir. Model yapısı içerisinde çalışmalarınızı nerede yürütürseniz yürütün, oluşturduğunuz sembolleri belli gruplara ayırmak ve aralarında ilişkiler kurmak istediğinizde bu şemaya başvurmak isteyeceksiniz.