004 Uml Modeli Yapisi [64 Slides]
•Download as PPT, PDF•
1 like•1,203 views
Unified Process ve UML ile Yazılım Geliştirme - 4 - UML Modeli Yapısı
Recommended
More Related Content
What's hot
What's hot (15)
Similar to 004 Uml Modeli Yapisi [64 Slides]
Similar to 004 Uml Modeli Yapisi [64 Slides] (20)
004 Uml Modeli Yapisi [64 Slides]
- 1. UML/UP ile Yazılım Geliştirme Bölüm 4/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 • Modüllerin Yapısı • Modül Tanımlama Teknikleri • Modül Gerçekleştirme Teknikleri • Modellerin Yapısı • Modellerin İlişkileri
- 4. Modül (Subsystem) Özellikleri • Bir modülün iki özelliği vardır: – Dış görünümü: modülün sağladığı hizmetleri gösterir. – İç görünümü: modülün verdiği hizmetleri destekleyen altyapıyı gösterir. • Bu iki görünüm arasında bire bir bir ilişki vardır.
- 5. Modül Özellikleri Tanım elemanları Gerçekleştirme elemanları Bir modül bir sistemin hem tanımlanma hem de gerçekleştirilme aşaması çalışmalarını içerir.
- 6. Modülün Gerçekleştirilmesi Tanım elemanları Gerçekleştirme elemanları ? • Gerçekleştirme elemanları subsytem’in içeriğini gösterir. • Modül gerçekleştirilmesi genellikle class’lar ve ilişkilerini içerir.
- 7. Modül Tanımlanması Tanım elemanları Gerçekleştirme elemanları ? Modül tanımı modülün dışarıdan nasıl görüldüğü belirtir
- 8. İçerik • Modüllerin Yapısı • Modül Tanımlama Teknikleri • Modül Gerçekleştirme Teknikleri • Modellerin Yapısı • Modellerin İlişkileri
- 9. Modül Tanımlanması • Modül tanımı – Modülün verdiği hizmetleri tanımlar – Sistemin kullanıcılarına yaşatacağı deneyimi tanımlar – Modülün iç yapısını gözler önüne dökmez – Modülün interface’lerini tanımlar
- 10. Tanımlama Teknikleri • Use Case yaklaşımı • State Machine yaklaşımı • Mantıksal Class yaklaşımı • Metod Yaklaşımı … ve bunların kombinasyonları
- 11. 1. Use Case Yaklaşımı Tanım elemanları Gerçekleştirme elemanları • Modülü sunduğu hizmetlerle alakalandırabilmek için • Spesifikasyonun teknik olmayan insanlara aktarılabilmesi için
- 12. 1. Use Case Yaklaşımı Çağrı Kontrol Tanım elamanları Realization elements Operator Change Digit Analysis Information Initiate Call Trunk Receive Digit and Connect Subscription Hook Signal and Disconnect
- 13. 2. State Machine Yaklaşımı Çağrı Kontrol Tanım elemanları Stopped Running Maintenance Error Exhausted • Duruma göre davranışı değişen modüller için (Simülasyon vs.) • Modülün yaşadığı durumlar ve bu durumlar arasındaki geçişlere odaklanır
- 14. 3. Mantıksal Class Yaklaşımı Çağrı Kontrol Tanım elemanları Number Analyzer Dictionary Network Manager • Modülün kullanımı nesnelerin manipülasyonu olarak görülüyorsa • Gereksinimler belli bir standarda uyum zorunluluğundan kaynaklanıyorsa
- 15. 4. Metod Yaklaşımı Çağrı Kontrol Metodlar initiateConnection (…) dialledDigit (…) throughConnect (…) bAnswer (…) bOnHook (…) aOnHook (…) • Basit (atomic) hizmetler veren modüller için • Metodlar birbirlerinden bağımsız olarak çağrılıyorlarsa
- 16. Tekniklerin Kombinasyonları Çağrı Kontrol Specification elements Metodlar changeDigitAnalysisInformation (...) Tanım elemanları Initiate Call Trunk Receive Digit and Connect Subscription Hook Signal and Disconnect
- 17. Eksiksiz Modül Notasyonu Operations Metodlar Gerçekleştirme elemanları Tanım elemanları • Üç tanımlı parçadan oluşur • Bu parçalar isteğe bağlı olarak kullanılmayabilir
- 18. İçerik • Modüllerin Yapısı • Modül Tanımlama Teknikleri • Modül Gerçekleştirme Teknikleri • Modellerin Yapısı • Modellerin İlişkileri
- 19. Tanım (Specification) – Gerçekleştirme (Realization) • Tanım ve gerçekleştirme birbirleriyle uyumlu olmalıdır • Tanım ile gerçekleştirme arasındaki ilişki (mapping) şu şekilde ifade edilebilir: – gerçekleştirme (realization) ilişkisi – birliktelik (collaboration)
- 20. Gerçekleştirme İlişkisi Metodlar Gerçekleştirme elemanları operation1( ) : Type1 «realize» operation1( ) operation2( ) : Type2 operation3( ) : Type3 operation4( ) : Type4 operation5( ) : Type5 Gerçekleştirme (Realization) özellikle tek seviyeli ilişkileri göstermekte faydalı
- 21. Gerçekleştirme İlişkisi Trafik Kontrol Metodlar Gerçekleştirme elemanları changeDigitAnalysisInformation ( ) «realize» Tanım elemanları Initiate Call changeDigitAnalysisInformation ( ) : : Trunk Receive Digit and Connect Subscription Hook Signal and Disconnect
- 22. Collaboration • Collaboration (Birliktelik): Belli bir hedefe yönelik olarak nesne etkileşimlerinin resmedilmesidir. Bu bir UC senaryosu veya class ilişkileri incelemesi olabilir. • Interaction (Etkileşim):Bir birliktelik içindeki nesnelerin arasındaki haberleşmelerdir.
- 23. Collaboration • Bir ‘collaboration’ bir iş yerine getirilirken gereken rolleri tanımlar • Bu roller birbirleriyle etkileşen nesneler aracılığıyla canlandırılır Sequence Şeması Collaboration Şeması 2: dialledDigit :Trunk :Traffic Control :Subscription 3: dialledDigit 6: bAnswer markBusy :Traffic Control dialledDigit 4: throughConnect dialledDigit :Trunk throughConnect markBusy bAnswer :Subscription 1: markBusy 5: markBusy
- 25. Collaboration Notasyonu Collaboration Rol Rol adı Rol adı Class Rol adı Rol adı Bir birliktelik (collaboration) ve katılımcıları
- 26. Collaboration Tanım elemanları Gerçekleştirme elemanları Initiate Call Network Interface Receive Digit and Connect Coordinator Analysis Database Hook Signal and Disconnect Collaboration genellikle daha karmaşık durumlarda faydalıdır
- 27. Collaboration Çeşitleri Rol modeli bir özel durumu ifade ederken Class modeli daha genele yönelik. Dolayısıyla her Class modeline karşılık birden fazla Rol modeli olacaktır.
- 28. Use Case Realization Collaboration Şeması: “Sipariş Alınması”
- 29. Use Case Realization (UCR)
- 30. Use Case Realization (UCR)
- 31. Use Case Realization (UCR)
- 32. Use Case Realization (UCR)
- 33. Model Bağımlılıkları Üniversite Kayıt Sistemi
- 34. Modüller Ne Zaman Gerekli? • Büyük bir sistemin hangi parçalardan oluştuğunu ve bu parçaların bağımlılıklarını göstermek gerektiğinde (Sistem Mimarisi) • Dağıtık (distributed) yazılım geliştirme yapılıyorsa • Bir grup modülün nasıl büyük bir sisteme dönüştürülebileceğini gözlemleyebilmek için (Sistem Mimarisi) • Bileşen bazlı yazılım geliştirme yapabilmek için
- 35. Modül Oluşturma Teknikleri • Büyük bir sistemin her kendine haslık gösteren parçasını bir modülle ifade edin • Tanımlama (specification) tekniğini sistem ve modülün özelliklerine göre belirleyin • Her modülü ayrı ayrı ve tanımlama elemanlarını (gereksinim) kullanarak gerçekleştirin (realize)
- 36. İçerik • Modüllerin Yapısı • Modül Tanımlama Teknikleri • Modül Gerçekleştirme Teknikleri • Modellerin Yapısı • Modellerin İlişkileri
- 37. Model Bir model sisteme belli nedenden dolayı farklı bir bakış şeklidir. Oluşturulma amacına uygun şekilde dokümantasyona ve detay seviyesine sahiptir.
- 38. Model Use Case Modeli Tasarım Modeli
- 39. Model Sembolleri Sembol Tanım Syntax Model Sistemi belli muhataplara onlara özel detay seviyesiyle sistemin İ sim ilgili yönlerinin gösterilmesidir. Trace Modeller arasındaki bağımlılık aynı «trace» konuların farklı bakış açıları altındaki ürünlerini temsil eder. İşaret tek veya çift yönlü olabilir.
- 40. Trace Analiz Tasarım «trace»
- 41. Model / Şema Şemalar modeli Use Case dokümante eder Modeli Tasarım Modeli
- 42. Model Ne Zaman Gerekli? • Farklı paydaşlara sisteme kendi ihtiyaçlarına göre bakabilmelerini sağlamak için • Sistemi gerektiğinde sadece tek bir yönden inceleyebilmek • Yazılım geliştirme sürecinde farklı aşamalarda üretilenleri dokümante edebilmek
- 43. Model Oluşturma Teknikleri • Her modelin amacını tanımlayınız • Her model amacına uygun şekilde sistemin eksiksiz bir resmini çizmelidir • Modelin amacına odaklanarak ilgisiz bilgileri modele eklemeyiniz
- 44. İçerik • Modüllerin Yapısı • Modül Tanımlama Teknikleri • Modül Gerçekleştirme Teknikleri • Modellerin Yapısı • Modellerin İlişkileri
- 45. Modeller ve Modüller Modeller ve Modüller arasında hiyerarşik ilişkiler kurulabilir: Analiz Modeli Bankacılık Sistemi Tasarım Modeli UC Realization Muhasebe Muhasebe Modülü Modülü
- 46. [1] Modeller İş Modeli (Seçeneğe Bağlı)
- 48. [3] Modeller Analiz ve Tasarım Modelleri
- 50. Rational Software Referans UML Modeli PearlCircle İnternette Açık Artırma
- 51. Model Elemanları Gereksinim, Analiz, Tasarım ve Kullanıcı Arayüzü Tasarımı çalışmalarının ilişkileri. Tasarım Realization Specification Analiz Kullanıcı Arayüzü Gereksinim Tasarımı Realization
- 52. Analiz Mdl. UC Mdl.
- 53. Tasarım Tasarım
- 54. User Experience Mdl.
- 55. Gereksinim → Analiz Etkileşim Şeması # <= Akış #
- 56. Analiz Çalışmaları Participants: Kullanılan class’ların UC bazında gruplanmasıdır. Analysis Elements: class’ların mantıki ilişkilerine göre yeniden gruplandırılmalarıdır. Bu geleneksel modüler yapıya karşılık gelir.
- 57. Analiz → Tasarım
- 58. Gereksinim → Kullanıcı Arayüzü
- 59. Bid on Item – Analiz - VOPC
- 60. Bid on Item – Analiz – Temel Akış
- 61. Bid on Item – Tasarım - VOPC
- 62. Bid on Item – Tasarım Temel Akış
- 63. Bid on Item – UX - VOPC
Editor's Notes
- Herşeyden önce, sık kullanacağımız kelimeler hakkında bir açıklama yapalım: Bu ünite boyunca pek çok kez eşanlamlı olarak kullanacağımız Paket ve Modül kelimelerini, oluşturduğumuz UML modelinin temel parçaları olarak anlamamız gerekiyor. Modül de aslında bir pakettir. Bununla birlikte genellikle Analiz ve Tasarım aşaması esnasında birbiriyle alakalı class gruplarını barındıran paketlere modül denmektedir. Bu yaklaşım altında bir modülün özelliklerini açıklamaya çalışırsak, modülün iki görünümü olduğunu saptarız: Dış Görünüm: Modülün o sistemin kullanıcıları tarafından nasıl algılandığını, nasıl görüldüğünü gösteren ve modülün sağladığı hizmetlere odaklanan görünümdür. İç Görünüm: Modülün kullanıcılarına verdiği hizmetin gerçekleşmesini sağlayan yapının özelliklerini gösteren, daha çok sistemin geliştiricilerine yönelik görünümdür. Bu iki görünüm, çıkarları çelişen, çalışma ve algılama şekilleri çok farklı olabilen iki ayrı dünyanın ‘görünümleridir.’ Unutulmaması gereken her başarılı çözümün bu iki görünümün ahenkli bir şekilde ilişkilendirilmesine bağlı olduğu ve bu görünümler arasında bire bir bir ilişki (Her dış görünüm öğesini destekleyen bir iç görünüm öğesi mevcuttur) olduğudur.
- Modülün iç ve dış görünümlerini biraz daha detaylı ifade edecek olursak, iç görünümün Tanım Elemanlarına (Specification), dış görünümünse Gerçekleştirme (Realization) Elemanlarına karşılık geldiğini görürüz. Yazılım geliştirme süreci boyunca modüller önce Tanım daha sonra da Gerçekleştirme öğelerini gruplandırmak için kullanılarak, tekrar kullanılabilirliği yüksek, anlaşılması kolay, yazılım kalite standartları kaideleriyle uyumlu ve belki de en önemlisi kaliteli yazılım geliştirmemizi sağlayan bir model yapısına ulaşmak mümkündür.
- Modülün Gerçekleştirilme (Subsystem Realization) elemanları sistemin modüler yapısını ve modüllerin ilişkilerini gösterir. Her modülün iç özellikleri çeşitli class grupları ve bu grupları oluşturan class’lar arasındaki etkileşimleri gösterir.
- Modülün Tanım (Subsystem Specification) elemanları sistemin gereksinimlerini belirterek, geliştirilecek gerçekleştirme elemanları için yönlendirici bilgileri ifade ederler.
- Modül Tanımı nasıl sorundan ziyade, ne sorusuna cevap olarak oluşturulur. Modülün kullanıcılarına verdiği hizmetleri onların yaşayacağı deneyimi detaylandırarak gösterir. Modülün kolay kullanımını sağlamak için interface’lerini (kullanıcı arayüzleri, modülün diğer sistemlerce kolay kullanımı için interface’ler, donanımlara yönelik hardware interface’ler) belirler. Ancak modülün gerçekleştirme elemanları tarafından cevaplandırılacak ‘nasıl’ sorusuna yönelmez. Modülün iç yapısını gizleyerek bu tür kararları sadece yönlendirir.
- Modüllerin Tanımlanmasının geliştirilecek sistemin özelliklerine bağlı olarak birden çok yolu vardır. Bazen bu yollar tek başlarına yeterli olurlar. Bazense bir kaç teknik bir araya gelerek bir tanımlama yolu oluştururlar. Eğer bu tanımlama tekniklerini sıralayacak olursak, Kullanım Senaryosu (Use Case) Yaklaşımı: Geliştirilecek sistemin Kullanıcılarına Sağladığı Fayda bazlı olarak tanımlanmasıdır. En büyük faydası senaryo bazlı olduğundan hata miktarını minimuma indirgemesi, görülmesi zor sorunlu alanları kolayca su yüzüne çıkarması ve farklı rollerin haberleşmesini kolaylaştırmasıdır. State Machine Yaklaşımı: Geliştirilecek sistemde “duruma göre davranış değişiklikleri” yaygınsa ve/veya sistem gerçek zamanlı bir sistemse projenin ilerleyen aşamalarında tasarımı çok etkili olarak yönlendiren bir tanımlama tekniğidir. Mantıksal Class (Logical View / Domain Model / Analysis Classes) Yaklaşımı: Geliştirilecek sistemin temel kelime haznesini tanımlamaya yönelik olarak class’lar aracılığıyla oluşturulan bir tanımdır. Tek başına gerçekleştirme elemanlarını yönlendirmek ziyade daha çok tamamlayıcı bir tekniktir. Metod Yaklaşımı: Geliştirilecek sistemi daha çok gerçekleştirilmesi gereken fonksiyonlar bazında tanımlamaya yarayan bir teknikdir. UML sürecinin aslında eksikliklerini giderdiği eski yazılım gereksinimleri tanımlama yöntemidir. Bu yüzden UML süreci içerisinde daha çok tamamlayıcı bir teknik olarak kullanılır. Burada dikkat edilmesi gereken nokta bu teknikler arasında birbirlerini tamamlayıcılık olduğu gibi, çalışılan proje konusuna bağlı olarak birbirlerinin yerini de alabildikleridir.
- [1] Kullanım Senaryoları (Use Case) Kullanımıyla Sistemi Tanımlamak Bu yöntemin en önemli özellikleri, Geliştirilecek modülün kullanıcılarına yaşatacağı deneyimleri tanımlama imkanı vermesi, Modül tanımlarının teknik kökenli olsun veya olmasın herkesçe kolaylıkla ve yoruma imkan vermeden anlaşılmasını sağlaması, Tüm yazılım mühendisliği çalışmalarını birbirleriyle alakalandırma imkanı vermesi, Proje süresince yapılacak tüm çalışmaları müşteriye sağlanan fayda ve onun önceliklerine göre yönetebilme imkanı vermesi, Değindiğimiz tüm Modül Tanımlama Tekniklerini ihtiyaç duyuldukça bünyesinde kolaylıkla barındırabilmesidir.
- Burada bir telekomünikasyon örneği verilmektedir. Use Case’lerin kapsamlarının ufaklığına dikkat ediniz. Bunların nedeni Use Case’lerin her zaman Aktör’ün referansı ile tanımlanmalarıdır.
- [2] State Machine Kullanımıyla Sistemi Tanımlamak Bu yöntemin en önemli özellikleri, davaranışı duruma göre değişen class’lar ve class gruplarını (class collaborations, module(s)) tanımlamak için en etkili yol olmasıdır. Özellikle simülasyon gibi gerçek zamanlı sistemlerin tanımlamalarında en etkili yöntemlerden biridir. Bu tanımlama tekniği kullanılırken modülün (object(s), interaction(s)) yaşadığı durumalar (state(s)) ve bu durumlar arasındaki geçişlere (transition(s)) odaklanılır. Söz konusu durumların neye istinaden geçerliliklerini yitirdiği, nesnelerin maruz kaldığı hangi etkilerin durumlar üzerinde etkili veya etkisiz oldukları, durumlar etkinliklerini korudukça ve durumlar arasındaki geçişlerde çalıştırılan metodların hangileri olduğu gibi sorulara cevap aranır.
- [3] Mantıksal Class Kullanımıyla Sistemi Tanımlamak Bu teknik, eğer birden çok tekniğin bir kombinasyonu kullanılıyorsa, gereksinim çalışmalarının analiz ve tasarım çalışmalarına aktarılmasında büyük önem arzeder. Bununla birlikte bazen gereksinimlerden tasarıma direkt olarak geçilebilmektedir. Eğer teknik yalnız başına bir tanımlama faaliyeti olarak kullanılıyorsa, bu genellikle iki anlama gelir: [1] Nesnelerin Manipülasyonu Geliştirilecek yeni hizmet mevcut nesnelerin yeniden organizasyonu, güncellenmeleri ve/veya bazı yeni nesnelerin eklenmesiyle genişletilmelerinden ibaretse ve herhangi bir gereksinim çalışmasının önemi çok yoksa. Öte yandan, durumunuz bu olsa bile eğer hedeflediğiniz kalite standartları ve/veya yazılım süreçleri açısından kurumunuzun olgunluğuna bağlı olarak sıkı bir ‘Müşteri İhtiyaçları – Gereksinimler – Analiz ve Tasarım’ takip edilebilirliğini hedefliyorsanız tek başına kullanmak istemeyeceğiniz bir teknikdir. [2] Standarda Uyum Geliştirdiğiniz sistemin gereksinimleri belli bir standarda uyum zorunluluğundan kaynaklanıyorsa Kullanılan bir tekniktir. Örneğin, yolcu uçaklarına yönelik bir Oto Pilot yazılımıysa ve uyması gereken güvenlik kriterleri, tasarım özellikleri dikte ediliyorsa. Diğer bir örnek olarak telekomünikasyon yazılımlarını verebiliriz. Gereksinimler ve Analiz açısından basit olabilen bu uygulamalarda, yazılım süreci boyunca zaman söz konusu olduğunda aslan payını Tasarım alabilmektedir. Bu durumda sistemin tanımlanmasını mantıksal class’larla yaparak süratle tasarım ve kodlamaya geçmek akıllıca olabilir.
- [4] Metod Kullanımıyla Sistemi Tanımlamak Eğer geliştireceğimiz sistemin modülleri basit (atomic) hizmetler veriyorlarsa ve bu hizmetler Metodların birbirlerinden bağımsız olarak çağrılmalarıyla sağlanıyorsa kullanılan bir tanımlama tekniğidir. Bu tür durumlarda, hizmetler basit olduklarından pek çok kez bir metod bir hizmete karşılık gelmektedir.
- En sık gördüğümüz Modül Tanımlama tekniği ise değindiğimiz tekniklerin ihtiyaçlara özel olarak oluşturulmuş kombinasyonlarıdır. Buradaki örnekte Metod Tekniği ile Kullanım Senaryosu Tekniğinin birlikte kullanıldığını görüyoruz. Nedenini ortaya koyamaya çalışırsak, geliştirilen sistemin bir telekom sistemi olduğu dolayısıyla basit (atomic) hizmetlerin mevcut olduğunu görürüz. Buna dayanarak, Metod Tekniğini aklıyoruz. Ayrıca, telekom sistemlerinde kullanıcı-sistem etkileşimlerinin çok sayıda alternatif içermesi ve genel olarak senaryo yaklaşımının faydalarından yararlanmak için Kullanım Senaryosu Tekniği (Use Case) kendini aklamaktadır. NOT: “ Trunk : In a network, a trunk is a communications path connecting two switching systems used to establish end-to-end connections between customers. Detaylar için Telekom Sözlüğünü ziyaret ediniz: http://www.carrieraccessbilling.com/telecommunications-glossary-a.asp “
- Öğrendiklerimizden hareketle, eksiksiz modül notasyonunun parçaları: [1] Modülün Tanımı (Adı): Örneğin, Cari Hesaplar, Raycaster, vs. [2] Modülün Metodları: Eğer metodla tanımlama tekniği kullanılıyorsa veya gerçekleştirme elemanları olarak vurgulanmak isteniyorsa. [3] Modülün Tanım Elemanları (Subsystem Specification): Gereksinimler [4] Modülün Gerçekleştirme Elemanları (Subsystem Realization): Analiz ve Tasarım Çalışmaları Bu öğeler yazılım süreci içerisinde ortaya çıkış zamanlarına bağlı olarak, UML modelinin 3 Boyutlu yapısı içerisinde yer alırlar ve ilişkilendirilirler. Öğeler proje, kurum ve kalite hedeflerinize bağlı olarak önem kazanıp, önemlerini yitirebilirler.
- Tanım (Specification) ve Gerçekleştirme (Realization) İlişkisi: Bir sistem geliştirilirken yapılan çalışmaların tanım ve gerçekleştirme ürünleri arasında bir uyum ve birbirini takip ilişkisi olmalıdır. Bu ilşkiyi göstermenin yolu Gerçekleştirme İlişki’leri kurmak (Realization) ve gerçekleştirme detaylarını birlikteliklerle (Collaboration) göstermektir.
- Gerçekleştirme (Realization) İlişkisi ‘ne’ ile ‘nasıl’ ilişkisini iki öğe arasında (modül, use case, interface ve class, vs.) göstermek istediğinizde kullanabileceğiniz bir ilişki çizgisidir. Projenin ilerleyen aşamalarında modüller arasındaki ilişkileri ve değişikliğin etkisini incelemek istediğinizde, İzlenebilirlik Matrisleri oluştururken işinize yarayacak, çalışmalarınız arasında ilerlediğiniz yok boyunca bıraktığınız işaretlerdir. Buradaki örnekte tanımlama elemanları Metod Tekniğiyle ifade edilmiş ve Gerçekleştirme Elemanları onları baz almıştır (realize).
- Burada ise tanımlama elemanları hem Metod hem de Kullanım Senaryosu Teknikleriyle ifade edilerek, hibrid bir yöntem kullanılmış ve Gerçekleştirme Elemanları onları baz almıştır (Realize).
- Bir UML Modelinin yapısını belirlerken ihtiyaç duyduğumuz en önemli ikinci tanıma geldik (Birincisi modül / paket tanımıydı). Collaboration (Birliktelik) uml sembollerinden aynı tür olanların bir arada bir hizmeti yerine getirdiklerinde gerçekleştirdikleri faaliyete denmektedir. UML modelinizin farklı parçaları arasındaki takip edilebilirliği ve birliktelik detaylarını incelemenizi sağlamaktadır. Her birlikteliğin içindeki öğeler birbirleriyle etkileşerek (interaction) bir görevi yerine getirirler. Bu söz konusu öğelerin ne olduklarına bağlı olarak şekil değiştirir. Örneğin, nesnelerin etkileşimi, ekranlar arasındaki etkileşim, vs.
- Birlikteliğin nedeni olan iş yerine getirilirken bu ortaklaşa faaliyet içindeki roller ortaya çıkarlar. Bu roller çeşitli class’lardan kaynaklanmış ve farklı streotype’larla işaretlenmiş nesneler aracılığıyla canlandırılırlar. Etkileşen nesneler o andaki sisteme bakış nedeni ve detay seviyesine bağlı olarak class’ların nesneleri olmanın ötesinde farklı öğeleri de (ekranlar gibi) temsil edebilirler. Ancak hangi etkileşim konusuyla alakalı olurlarsa olsunlar, birbirlerinin sorumluluklarının yerine getirilmesini talep ederek (birbirlerinin metodlarını çalıştırarak) etkileşirler ve bir hizmeti gerçekleştirirler.
- Collaboration (Birliktelik) Sembolleri Collaboration: Aynı tür UML sembollerinin birlikte belli bir amaca yönelik olarak etkileşmelerini sembolize eder. UML modeli içerisinde özellikle Analiz ve Tasarım Modelinde kullanılır. Seçeneğe bağlı olarak oluşturulabilecek Kullanıcı Deneyimi Modelinin de (User Experience Model / Human Interaction Model) önemli bir öğesidir. Interaction: Birliktelik içindeki UML sembollerinin birbirleriyle etkileşimlerini gösterir. Sorumluluklar, Mesajlar veya Fonksiyonlar olarak ifade edilir.
- UML 2.0 notasyonunda Composite Structure Şeması içerisinde çizilebilen, fakat sembol olarak eskiden beri mevcut birlikteliği (collaboration) açıklamak amacıyla kullanılan bir şemadır. Yararlılığı hakkında tartışmalar vardır. Kullanılsa dahi çok nadiren kullanıldığı dikkatleri çeker. Bunun en büyük nedeni bir birliktelik hakkında detaylı bilgiler vermek için class ve sequence / communication şemalarını kullanmanın zaruri olmasıdır. Bir kez böyle detaylı bir şekilde açıklanan şemaların bir sefer daha bu notasyonla ifadesi anlamını yitirmektedir. Daha da önemlisi, bir birlikteliği destekleyen tasarımı yapabilmenin yine class ve seqeunce / communication şema çalışmalarını gerektirmesidir. Bu durumda da yukarıdaki gibi ek bir notasyon anlamını yitirebilmektedir. Diğer bir husus da, UML ürünlerinin pek çoğunun yeni sürümlerinde Class Collaboration yapısını menü üzerinden ve/veya XML dosyaları aracılığıyla ürünün kabiliyetlerine eklemek ve ihtiyaç duyulduğunda kullanmak mümkündür. Burada belki de vurgulamamız gereken UML notasyonunun bir UML ürününün varlığını varsaymadığıdır. Kağıda çizilebilen bir sembolik dil olduğudur. Bu durumda konuya bakışımızın nasıl değişebileceğini düşününüz. Bununla birlikte eğer kullanılırsa, birlikteliği gerçekleştiren class’lar ve aldıkları roller (nesne) ifade edilerek bir açıklama oluşturulur.
- Gerçekleştirme Elemanlarının Tanım Elemanlarına collaboration yapısıyla bağlanmalarının önemli nedenleri arasında şunları sayabiliriz: Analiz ve Tasarım açısından karmaşık bir yapı üzerinde çalışmamız gerekmektedir, Yazılım süreci boyunda üretilen yan ürünleri (Gereksinimler, Analiz ve Tasarım çalışmaları, vs.) ilişkilendirmemiz gerekmektedir, Proje kontrolünü artırmak için Takip Edilebilirliği (Traceability) sağlamamız gerekmektedir, Hedeflediğimiz kalite standartları açısından (CMM-I, vs.) bir zaruriyet vardır.
- Rol Modeli: Her birlikte çalışan Class grubuna yönelik pek çok rol modeli vardır. Bunların alacakları değerlere göre her etkileşim özel bir durumu (anı, yeri vs.) ifade eder. Örneğin, Mühendislik Fakültesi öğretmeni Calculus 1 dersini verir gibi. Class Modeli: Bunun aksine daha genel bir yapıdır ve olası bütün nesne etkileşimlerinde gerekebilecek veri yapısına sahiptir. Az önceki örnekte öğretmen okuldan ayrılsa, o bölüm kapanıp başka bölüm de açılsa aynı Class yapısıyla çalışabiliriz.
- Use Case Realization En önemli Collaboration şeklidir. Bir UML modelinde Gereksinimleri Analize, Analizi Tasarıma ve Gereksinimleri Arayüzü Kullanım Senaryolarına bağlar. Kopuk kopuk UML şemalarının bir modele dönüştürülebilmesini sağlayan en önemli enstrümandır. Eğer bir UML modelinde ‘kayboluyorsanız’, büyük ihtimalle bu sembol başarılı olarak kullanılmamıştır. Yukarıdaki örneği okursak, Öğretmen Lara ve Öğretmen Ali aynı fakültede çalışmaktadırlar. Lara Hanım İngilizce dersleri vermektedir. Ali Bey’inse Şira ve Veli isimli öğrencileri vardır. Bu öğrencilerin her ikisi de aynı zamanda Lara Hanım’ın İngilizce dersini almaktadırlar.
- Use Case Realization Yapısı Yazılım geliştirme sürecinde ilk ortaya çıkacak ‘Gerçekleştirme İlişkilerinden’ biri Gereksinim Modeli ile Analiz Modeli arasındadır. Gereksinim Modelinizin fonksiyonel gereksinimler (Kullanım Senaryosu Modeli / Use Case Modeli) bölümünde yapılan çalışmaların Analiz ve Tasarım süreci içerisinde ilk olarak Analiz Modelini oluşturmak amacıyla kullanılmasıdır.
- Use Case Realization Yapısı Analiz Modeli çalışmasını takiben, bu çalışmaların ürünlerine dayanılarak yapılan ikinci çalışma Tasarım Modeli üzerindedir. Bunu UML ilişkilerini kullanarak tekrar ifade edersek, ((Analiz Modeli <<realizes>> Use Case Modeli) AND (Tasarım Modeli <<realizes>> Use Case Modeli) AND (Tasarım Modeli <<traces>> Analiz Modeli)) ortaya çıkar. Analiz Modeli Use Case Modelinde ifade edilen gereksinimlerin kavramsal bir problem çözümüne dönüştürülmüş halidir. Tasarım Modeli ise aynı gereksinimlerin seçilmiş bir teknoloji kullanılarak oluşturulmuş, yazılımın şablonunun kendisinden üretileceği çalışmadır. Analiz ve Tasarım Modelleri arasındaki trace ilişkisinin manası, tasarımın yazılım süreci içerisinde analize dayanılarak ve daha sonra yapıldığının vurgulanmasıdır. Hem Analiz hem de Tasarım Modelleri nesne tabanlı teknolojiler kullanılarak oluşturulmaktadırlar.
- Use Case Realization Yapısı Diğer bir ‘Gerçekleştirme İlişkisi’ Use Case Modeli ile Kullanıcı Etkileşim Modeli (User Experience Model / Human Interaction Model) arasında kurulabilir. Bu modelin içeriği Use Case akışları esnasında ekranların nasıl kullanıldığını ve ekranlar arasındaki ilişkileri vurgulamak amacıyla oluşturulduğundan, kullanımı sık olan bir yaklaşımdır.
- Use Case Realization Yapısı: Paralel Çalışmalar Sizin de gördüğünüz gibi ‘Gerçekleştirme İlişkileri’ kurmak UML modelinizi yapılandırmak için kullanmak zorunda olduğunuz etkili bir tekniktir. Modelin geneline baktığımızda, Gereksinimleri (Use Case Modeli, vs.) takip eden çalışmalar arasında paralellikler görürüz. Use Case Modeline bağlı olarak farklı roller aynı bilgileri tüketerek tasarım çalışmaları olarak adlandırılabilecek çeşitli çalışmalarda bulunurlar. Kullanıcı Arayüzü Tasarımcı: Bir yere kadar Sistem Analisti tarafından üstlenebilecek bir roldür. Kullanıcı Etkileşim Modelini oluşturur. Tasarımcı: Deneyimli Programcı hem kullanılan teknolojiye hem de teknolojinin uygulandığı proje konusu hakimdir. Sırasıyla ve kendi belirlediği önceliklere bağlı olarak Analiz ve Tasarım Modelini oluşturur.
- UML Modeli Yapısı Kurduğumuz ‘Gerçekleştirme İlişkilerinin’ model genelinde oluşturduğu yapıya bakacak olursak, En üst seviyede Gereksinim Modelini (‘Use Case Modeli’ ile ‘Vizyon ve Ek Gereksinimler’) görürüz. UML Modeli kullanım senaryosu (use case) bazında geliştirip, yönetildiği için ‘Gerçekleştirme İlişkilerini’ Use Case Modeline yöneltiyoruz. ‘ Vizyon ve Ek Gereksinimler’ ile ‘Use Case Modeli’ arasında ise bir ardından gelme (Vizyon - Use Case’ler) ve birbirini tamamlama (Ek Gereksinimler – Use Case’ler) ilişkisi söz konusudur. Bu yukarıdaki yapıda <<trace>> (ardından gelme) ilişkisini ortaya çıkarmaktadır. Yine benzer şekilde, ‘Analiz Modeli’ ve ‘Kullanıcı Etkileşim Modeli’ Use Case Modeliyle bir <<trace>> ilşkisine sahiptir. ‘ Tasarım Modeli’ ise ‘Analiz Modelini’ izlediğinden onunla bir <<trace>> ilişkisine sahiptir. Burada ‘Tasarım Modeli’ ile ‘ Use Case Modeli’ arasındaki <<realize>> ilişkileri bir bağımlılık ifade etseler de bu şemada dolaylı olarak zaten gösterildiğinden ve UML’in en temel kuralına (KISS: Keep It Simple and Stupid) uymak için göz ardı edilmiştir.
- Modüllerin en anlamlı kullanımlarının tasarım esnasında ortaya çıkan nesne modelini, class’ların aralarındaki mantık ilişkilerine bağlı olarak gruplamak olduğuna değinmiştik. Bu şekilde çalışmak aynı zamanda geliştirilen yazılımı katmanlara ayırmayı kolaylaştıracağından, sistemin tekrar kullanılabilirliğini en üst düzeye çıkaracaktır. Modüllerin ve Katmanların yardımıyla UML ‘sistem mimarisi odaklılık’ hedefini yerine getirmektedir. Bu yapılar yardımıyla sistemi oluşturan parçaların birbirleriyle olan bağımlılık ilişkileri (öncelik, sonralık) vurgulanabilir. Bunun da ötesinde geliştirilen sistemin mimarisi proje gelişimi süresince gözlenerek gerekli müdahaleler zamanında yapılabilir. Ayrıca oluşturduğumuz UML modelinin Senaryo Bazlı bölümleri “Analiz ve Tasarım” aşamasında modüllerle ilşkilendirilerek, bu iki bakış açısını bir araya getirir. Bunun sonucu olarak hem müşteri isteklerine duyarlılığımızı hem de sistem mimarisine verdiğimiz önemi korumuş oluruz.
- Modül Oluşturma Teknikleri Kendine Haslık (Gerçekleştirme Elemanları): Use Case kapsamında bakacak olursak, kullanım senaryolarını nesne etkileşim şemalarıyla nasıl gerçekleştireceğinizi incelerken ve kullanım senaryosu metinlerinden isim ayıklama yöntemiyle bulduğunuz class’ları aralarındaki mantık ilişkilerine göre gruplamak (Detayları Ünite 6 ve 7’de işlenecektir). Tanımlama Tekniği Seçimi (Tanımlama Elemanları): Modülün tanımlama elemanlarının özelliklerini ve kullanacağınız tanımlama tekniğini geliştireceğiniz sistemin özelliklerine göre belirleyiniz. İzlenebilirlik Yöntemi (Realization İlişkisi): Tanımlama elemanlarını sistemin gereksinimleri olarak değerlendirip, Analiz ve Tasarım çalışmalarına (Gerçekleştirme Elemanları) girdi olarak kullanınız. Her modülü (Gereksinim birimi, bizim çalışmalarımızda kullanım senaryoları) ayrı ayrı ele alarak Analiz ve Tasarım çalışmalarını yürütünüz. Tanım ve Gerçekleştirme Elemanları arasında ‘Gerçekleştirme İlişkileri’ (<<realize>>) kurunuz. Böylece, proje süresince birbirini takip eden faaliyetlerin ürettikleri model öğeleri ve dokümanlar arasındaki ilişkiler etkin bir şekilde incelenebilsin.
- Bir UML modeli hangi bakış açılarına yönelik parçalara sahip olacağı belli değilse sadece bir modele dönüştürülmemiş bir UML Şemaları Grubudur. Bir model olabilmesi için, Hangi rollere yönelik parçaları olacağı (Use Case Modeli, Analiz Modeli vs.) Bu parçaların nasıl ilişkilendirilecekleri (Use Case Realization, Daha genel şemalar ve hyperlink’ler vs.) belirlenmelidir. Faydalı bir model olabilmesi içinse, Çözmeyi taahhüt ettiği probleme uygunluğu saptanmalıdır. Örneğin, konu kavramsal olarak zorsa Analiz Modeli’nin önemi artar ve bu model parçası mutlaka hazırlanmalıdır. Yazılım Ekibinin ve şirketin güçlü yanlarını iyi temsil etmelidir. Örneğin, şirket CMMI Level 3 seviyesinde iş yapıyorsa dokümantasyon eksiksizliği, dinamik yapısıyla teknoloji üretiyorsa hızı ve isabetliliği daha fazla önem kazanır. Buna göre daha kapsamlı veya daha pratik süreçler kullanır ve modeller hazırlarlar.
- Bir UML Modelinin pek çok alt modeli vardır. Bunlardan bazıları oturmuş ve çoğu projede en azından bir ölçüde olması beklenen modellerdir. Başlıcaları, Use Case Modeli Analiz Modeli Tasarım Modeli Veritabanı Modeli’dir. Bunlardan başa kendi özel ihtiyaçlarınıza göre modeller oluşturabilirsiniz. Daha da önemlisi oluşturmalısınız. Çünkü bu tür modeller size sadece şirketinize özel çalışma ortamları yaratarak gelişmenize yardımcı olacaktır.
- Daha önce bahsettiğimiz modelleri oluşturuken dikkat edilmesi gereken oluşan modellerin (birbirlerinden yararlanma, bağımlılık, zaman içerisinde birbirini takip) birbirleriyle alakalandırılmaları gerektiğidir. Bu alakalandırmaları yapmanın en iyi yollarından bazıları Use Case Realization yapısını kullanmak, Standart paket isimleri kullanmak (Analiz Paketleri, Tasarim Paketleri vs.), Şemaları birbirlerine hyperlink’ler kullanarak bağlamaktır.
- Unutulmaması gereken önemli bir nokta Şemaların Modeli Dokümante Ettikleridir. Bunun manası şemaların çizilme ve kullanılma nedenlerinin Modellerin gereksinimlerine bağlı olduklarıdır. Örneğin bir Analiz Modeli çiziyorsak amacımız problem çözümünün nesne teknolojileri terminolojisiyle kavramsal olarak çözülmesidir. Bütün şema çalışmaları ve model paket yapısı oluşturma faaliyetlerimiz bu amaç doğrultusunda gelişmeli ve bu amaca ulaşıldığında sona erdirilmelidir.
- UML dili ve sürecinin en temel hedeflerinden birisi farklı rollere canlandıran, çelişen çıkarlara sahip ve uzmanlık alanları yüzünden farklı kelime haznelerini kullanarak işlerini gören; dolayısıyla, aralarında haberleşme problemleri olan ekip elemanlarını bir araya getirmektir. Bu elemanların yoruma açık olmayan bir şekilde düşünme şekilleri ve kararlarını diğerlerine aktarabilmeleri öngörülmektedir. Bu fayda kuşkusuz birbirleriyle alakalandırılmamış şemalar, belli ihtiyaç doğrultusunda bilinçli (disiplinli) bir şekilde oluşturulmamış bir UML modeliyle de sağlanabilir. Ancak, karmaşık bir modelin içinde yolunu bulabilmek ve belli bakış açılarının tüm çalışma ürünlerinin kolay tüketilebilmesi için modelin bir bütünlük (bir yöntem dahilinde) oluşturulması gerekmektedir. Buna dikkat edildiğinde, paydaşların UML modelinin 3 Boyutlu yapısı içinde sadece onları ilgilendiren bölümlerine süratle ev eksiksiz bir biçimde ulaşmaları mümkün olacaktır. Öyle ki modeli inceleyen kişi konu ve teknoloji hakkında hiçbirşey bilmese dahi modeli inceleyebilir ve ihtiyaç duyduğu bilgileri ne kadar karmaşık bir sistem olursa olsun, ona yönelik yapılmış model ve dokümantasyon çalışmalarından ayırabilir.
- Model Oluşturma Teknikleri Modelin Amacı: Oluşturacağınız modelin yapısı pek çok diğer konuda verdiğiniz kararlara bağlıdır. Eksiksiz bir liste olmamakla birlikte, aşağıda en önemli kriterleri bulabilirsiniz: Projenin konusu ve kullanılacak teknolojiler, Kullanılacak altyapılar, Proje sorumluluğunu paylaşacak roller (müşteriler, yazılım ekibi, vs.), Kullanılacak kalite standartları, Kullanılacak yazılım süreç tanımı, Kullanılacak yazılım mühendisliği doküman şablonları, Yazılım disiplinlerinin göreceli önemleri (Analiz - Tasarım), vs. vs.
- Bu örneklerden daha tipik olan tabii ki sağdakidir. Bir projeye ait bir UML modelinin bir parçası olan Tasarım Modeli’nin Tasarım Paketleri altında Muhasebe gibi pek çok modül olacağı açıktır. Soldaki örnekte ise Bir UML modelinin Analiz Modelindeki Use Case Realizations (Use Case Gerçekleştirimesi) bölümü altında VOPC (View of Participating Classes : Use Case’in Senaryolarını Destekleyen Class’lar) şemasında bir class grubu, bir ihtimal bir modül bulunabilir. Pratik uygulamalarda tavsiye edilen sağdaki gibi daha iyi yapılandırılmış bir UML Modeli oluşturulmasıdır.
- Unified Process kapsamında eksiksiz bir UML modeli oluşturduğumuzu varsayarsak (aslında gerçek UML modelleriniz ihtiyaçlarınıza göre kişiselleştirilerek, buradaki örneğin bir alt kümesi olur), [1] İş Modeli: İş Süreçleri Modeli (Business Process Model): İş akışlarınıza genel olarak bakabilirsiniz. İş Kullanım Senaryo Modeli (Business Use Case Model): İş ortamınızda müşteriye sağladığınız faydalara odaklanabilirsiniz. İş Analiz Modeli (Business Analysis Model): İş ortamınızdaki ürünler, roller ve iş dokümanlarına odaklanabilirsiniz. EK Modeller: Eğer kullandığınız UML ürünü Sparx Systems – Enterprise Architect ise, her türlü dokümanı modele taşıyabileceğinizden, neredeyse dokümansız bir proje çalışma ortamına sahip olabilirsiniz. Bütün dokümanlarınız UML modelinizin içinde yer alabilir. İş Vizyonu ve Ek Gereksinimleri (Business Vision & Supplementary Requirements): İşe girme koşullarınızı ve altyapı ihtiyaçlarınızı değerlendirebilirsiniz. İş Ortamı Yapısı (Business Architecture): İş ortamınızla ilgili her türlü konuyu dokümante edebilirsiniz.
- [2] Gereksinim Modeli Kullanım Senaryosu Modeli (Use Case Model): Sistem sınırları ve sağlayacağınız faydalara odaklanabilirsiniz. EK Modeller: Eğer kullandığınız UML ürünü Sparx Systems – Enterprise Architect ise, her türlü dokümanı modele taşıyabileceğinizden, neredeyse dokümansız bir proje çalışma ortamına sahip olabilirsiniz. Bütün dokümanlarınız UML modelinizin içinde yer alabilir. Vizyon ve Ek Gereksinimler (Vision and Supplementary Requirements): Proje yapılma nedenlerini aklayabilir, temel konularda anlaşabilmek için bir zemin hazırlayabilir ve Fonksiyonel olmayan gereksinimleri bulabilirsiniz.
- [3] Analiz ve Tasarım Modelleri Analiz Modeli (Analysis Model): Kavramsal problem çözümünüzü oluşturabilirsiniz. Tasarım Modeli (Design Model): Çözümünüzü seçtiğiniz teknolojiye uygulayabilirsiniz. Veritabanı Modeli (Data Model): Veri yapınızı (Tablolar, vs.) bu modelde tasarlayabilirsiniz. Kullanıcı Etkileşimi Modeli (Human Interaction / User Experience Model): Kullanıcıların işlerini görürken ekranlarla aralarındaki etkileşimleri resmedebilirsiniz. Deployment Modeli: Yazılımınız karmaşık ve/veya dağıtık bir donanım ortamında çalışıyorsa bu ilişkileri resmedebilirsiniz. Bileşen Modeli (Component Model): Kod ürettiğinizde ortaya çıkan yazılım fiziki öğeleri arasındaki run-time ilişkilerini vurgulayabilirsiniz. Ek Modeller: İhtiyaç duyuyorsanız (UML ürününe bağlı olarak zaruri olabilir: Rational XDE, Rational SA) kodla senkronize olacak modeli tasarım modelinden ayrıştırabilirsiniz. İmplementasyon Modeli (Implementation Model): Kod ürettiğiz ve kodla senkronize tutulan model.
- [4] Standart Dışı Ek Modeller Eğer kullandığınız UML ürünü Sparx Systems – Enterprise Architect (EA) ise, her türlü dokümanı modele taşıyabileceğinizden, neredeyse dokümansız bir proje çalışma ortamına sahip olabilirsiniz. Bütün dokümanlarınız UML modelinizin içinde yer alabilir. Bunun da ötesinde ürüne eklenebilen profiller sayesinde (Örneğin, SPEM) yazılım süreç yapınızı da modelin bir parçası yapabilirsiniz. Ayrıca, EA UML ürünlerine ek özellikler taşıdığından, örneğin test modeliniz de UML modelinizin bir parçası olabilir.
- UML referans modeli yaklaşımı Rational Software tarafından ortaya atılmıştır. Bu yaklaşım altında Rational şirketi ürünlerini alanlara bir referans modeli olarak PearlCircle İnternette Açık Artırma projesini sunmaktaydı. Günümüzde bu yaklaşım popülerleşmiş ve konu uzmanlığı ile teknoloji uzmanlığı transferlerini kolaylaştıran bir yöntem olarak kabul edilmeye başlanmıştır. Bu süre zarfında bazı farklılıklar olsa da PearlCircle modelinin oluşturuluş şekli bir endüstri standardı haline gelmiş ve benzer modellerde büyük ölçüde yinelenmiştir. Biz de örneklerimizde büyük ölçüde buradaki model oluşturma standardını kullanacağız.
- Pearl Circle Online Auction Referans Modeli: Traceabilities Geliştirilecek sistemin tanımlanması için Use Case Modeli kullanılmış. Bu model çalışması Daha sonra Analiz Modelini, analiz modeliyse daha sonra Tasarım Modelini beslemiş. Buna ek olarak Use Case Modeli çalışması Kullanıcı Etkileşimi modeline de bilgi sağlamış.
- Pearl Circle Online Auction Referans Modeli: Use Case Model – Analysis Model Use Case Modeli ile Analiz Modeli arasındaki ilişki Use Case Realization yapısı aracılığıyla sağlanmış. Yazılı olarak kullanım senaryosu başına akış, veri yapısı ve iş kuralları bilgilerine sahip use case modelinden önemli akışlar seçilerek Class ve Nesne Etkileşim Şemaları çizilmiş.
- Pearl Circle Online Auction Referans Modeli: Design Model Tasarım Modelinde ise aynı çalışma benzer faaliyetlerle Java/J2EE teknolojisine yansıtılmış.
- Pearl Circle Online Auction Referans Modeli: Kullanıcı Etkileşimi / Deneyimi Modeli yine Use Case Modelinden yararlanılarak, Analiz ve Tasarım Modellerinin yapısına benzer bir şekilde, o modellerdeki nesne modeli ve etkileşimlerine karşılık gelen Ekran Yapısı ve Senaryolar İçindeki Kullanımlarına odaklanır.
- Pearl Circle Online Auction Referans Modeli: Use Case Model – Analysis Model_Use Case Realizations Kullanım Senaryosu Dokümanının (Fonksiyonel Gereksinimler) akışlar bölümünden Tasarımcı insiyatifi (Nesne modelini tanımlamak amacı) ile seçilen senaryolar Nesne Etkileşim Şemalarına resmedilirler.
- Pearl Circle Online Auction Referans Modeli: Analysis Use Case Realizations – Analysis Elements Nesne etkileşim şeması çalışmaları yapılırken bulunan nesneler (dolayısıyla class’lar) kademe kademe Analiz Paketleri altına toplanarak, aralarında mantık ilişkisi olanlar alt gruplar oluştururlar.
- Pearl Circle Online Auction Referans Modeli: Analysis Model – Design Model Analiz Paketlerinde derlenen class grupları seçilen bir teknolojiye ve o teknolojinin kavramlarına (Java/J2EE, Çok Katmanlı Mimari) uyarlanır.
- Pearl Circle Online Auction Referans Modeli: Use Case Model – User Experience Model Use Case Dokümanındaki önemli görülen senaryolar (Ekranlar hakkında önemli bilgiler veren) seçilerek (Genellikle Analiz ve Tasarım Modelinde seçilen senaryoların aynısı olur) Ekran Yapıları ve Ekran İlşkileri resmedilir: Ekran Yapısı: Ekran üzerinde hangi öğeler var? (ekran olarak işaretlenmiş class’ların bir şeması) Ekran İlişkileri: Ekranların nesne etkileşimi şemalarında bir faydaya yönelik birlikte kullanımlarının incelenmesi.
- Pearl Circle Online Auction Referans Modeli: Analysis Model Analiz Modeli – “Teklif Ver” Kullanım Senaryosunu destekleyen analiz class’ları yapısı ve ilişkileri: Entity, Boundary ve Control Class’ları.
- Pearl Circle Online Auction Referans Modeli: Analysis Model VOPC şemasındaki class’lardan bir bölümünün “Teklif Ver” use case’inin temel akışını nasıl gerçekleştirdiğinin gösterilmesi.
- Pearl Circle Online Auction Referans Modeli: Design Model Tasarım Modeli – “Teklif Ver” Kullanım Senaryosunu destekleyen tasarım class’ları yapısı ve ilişkileri. Teknolojiye has sembollere dikkat ediniz: HTTP Servlet, Server Page, vs.
- Pearl Circle Online Auction Referans Modeli: Design Model VOPC şemasındaki tasarım class’lardan bir bölümünün “Teklif Ver” use case’inin temel akışını nasıl gerçekleştirdiğinin gösterilmesi. Teknolojiye has sembollere dikkat ediniz: HTTP Servlet, Server Page, vs.
- Pearl Circle Online Auction Referans Modeli: User Experience Model Kullanıcı Etkileşimi Modeli – “Teklif Ver” Kullanım Senaryosunu destekleyen ekranların yapısı ve ilişkileri: <<Screen>>, <<Input Form>> vs. olarak işaretlenmiş class’lara dikkat ediniz.
- Pearl Circle Online Auction Referans Modeli: User Experience Model VOPC şemasındaki ekranlardan bir bölümünün “Teklif Ver” use case’inin temel akışını nasıl desteklediğinin gösterilmesi.