007 Uml Modelleri Analiz Ve Tasarim [74 Slides]
•Descargar como PPT, PDF•
6 recomendaciones•7,583 vistas
Unified Process ve UML ile Yazılım Geliştirme - 7 - Analiz ve Tasarım
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (17)
Similar a 007 Uml Modelleri Analiz Ve Tasarim [74 Slides]
Similar a 007 Uml Modelleri Analiz Ve Tasarim [74 Slides] (20)
007 Uml Modelleri Analiz Ve Tasarim [74 Slides]
- 1. UML/UP ile Yazılım Geliştirme Bölüm 7/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. Neredeyiz?
- 6. Analiz Modeli Oluşturma Aşamaları } 1<N<5
- 7. Analiz ve Tasarım Model Yapısı • Analiz (veya Tasarım) Paketleri • Gerek duyulduğunda class başına ve/veya modül genelinde State Machine şemaları • Kullanım Senaryosu Gerçekleştirilmeleri (Use Case Realizations) • Temel Soyutlamalar (Sadece Analiz Modelinde) • Katmanlar ve Modüller (Özellikle Tasarım Modelinde)
- 8. Use Case Realizations İçeriği Analiz/Tasarım Modeli Çalışmaları Analiz veya Tasarıma aitliğine bakılmaksızın Use Case başına, • Bir Class Şeması: VOPC (View of Participating Classes) 2. Bir Class Şeması: Traceabilities 3. N sayıda Etkileşim Şeması 1 < N < Akış Sayısı 1 = Temel Akış her zaman alınır.
- 9. Modeller ve Modüller “Analysis Elements”
- 10. Modeller ve Modüller “Design Elements”
- 11. Modeller ve Modüller “UCR – Analysis Mapping”
- 12. Modeller ve Modüller “UCR – Design Mapping”
- 13. Senaryo – Class İlişkisi ‘1’ ‘2’ ‘3’ Aynı class birden fazla UCR’da, kullanılabilir. Böylece class’ların sorumlulukları bir takım çalışmasıyla senaryo ihtiyaçlarına bağlı olarak zamanla eksiksizleşir.
- 14. Diğer Tasarım Seviyesi Modelleri Tasarımcı: • Deployment Modeli • İmplementasyon Modeli (*) Veritabanı Analisti: • Veritabanı Modeli (Data Model) Kullanıcı Arayüzü Tasarımcısı: • Kullanıcı Etkilişimi Modeli (Human Interaction / User Experience Model)
- 15. Diğer Tasarım Seviyesi Modelleri “Deployment Modeli”
- 17. Diğer Tasarım Seviyesi Modelleri “Veritabanı Modeli”
- 18. Diğer Tasarım Seviyesi Modeli “Kullanıcı Etkileşimi Modeli”
- 19. Diğer Tasarım Seviyesi Modelleri “Kullanıcı Etkileşimi Modeli”
- 20. İçerik • Analiz ve Tasarım Modelleri Yapısı • Analiz Class’ları • Class Bulma Teknikleri • Tasarıma Geçiş Teknikleri
- 21. Analiz Class’ları Nelerdir? • Analiz class’ları bulunurken üç farklı referans kullanılır: • Sistem ve aktörleri birbirlerinden ayıran sınırlar • Sistemin kullandığı bilgi türleri • Sistemin akış mantığı
- 22. Analiz Class’ları Nelerdir? Stereotype aynı <<boundary>> sembolle ifade = edilen nesneleri ayrıştırmaya yarar. <<entity>> = <<control>> =
- 23. Analiz Class’ı Çeşitleri <<boundary>> Use Case <<boundary>> davranışını koordine eder Aktör1 <<control>> <<boundary>> Aktör2 Sistemin dış Sistemdeki dünyayla <<entity>> <<entity>> verileri depolar etkileşimini ve yönetir sağlar
- 24. Boundary Class • Sistemin sağladığı işlevler ile kullanıcıları arasındaki etkileşimleri sağlar – User interface class’ları • Kullanıcıya sağlanan bilgilere odaklanır • UI detay özellikleri bu aşamada göz önüne alınmaz • Örnek: ViolationsDialog – System / Device interface class’ları • Hangi protokollerin tanımlanması gerektiğine odaklanır. Protokollerin implementasyon detayları bu aşamada göz önüne alınmaz • Örnek: OffendersDBProxy
- 25. Entity Class • Sistemin temel kavramlarının bir modelidir • Genellikle saklanacak bilgileri ifade eder • Sistem seviyesindeki mantığı içerir • Ortamdan bağımsızdır • Birden fazla use case’de kullanılabilir
- 26. Control Class • Use case’in davranışını kontrol ve koordine eder • Use case’in yerine getirmesi gerekenleri iş bazında class’lara atar – Bir control class’ı diğer class’lara bir şey yapmaları isteğini iletmeli ve kesinlikle atama haricinde bir iş yapmamalıdır • Boundary ve entity class’larını bir araya getirir • Genellikle her use case için bir control class’ı vardır
- 27. Çok Katmanlı Mimari Tasarımdaki karşılıkları aşağıdaki gibi olabilir (Java/J2EE): • Arayüz Katmanı: JSP • İş Mantığı Katmanı: Session Beans + Servlets • Veri Katmanı: Entity Beans • + Veri Erişim Katmanı, vs. vs.
- 28. İçerik • Analiz ve Tasarım Modelleri Yapısı • Analiz Class’ları • Class Bulma Teknikleri • Tasarıma Geçiş Teknikleri
- 29. Analiz Class’larını Bulma Yolları 1. Her use case için: a. Dokümanına başvurunuz. b. Entity class’larını bulunuz c. Boundary ve Control class’larını bulunuz d. Her class için: i. Değişkenlerini bulunuz ii. İlişkilerini (Mesajları da içerir) bulunuz 2. Modelin bir sağlamasını yapınız
- 30. Analiz Class’larını Bulma Yolları //
- 31. Class’ları Bulacağımız Yerler 1 Birincil kaynağın UC Dokümanı olduğunu aklımızda tutarak, Eğer Use Case Dokümanı sorunluysa: • UC tanımı her zaman analiz class’larını bulmak için kafi olmayabilir – Önce Entity class’ları bulunmalıdır • Müşteriye yönelik yazılan uc tanımına gerekli sistem reaksiyonlarını ifade edecek detaylar (sistem içi davranışlar) eklenebilir • Sistemin dışarıdan gözlenen davranışlarına sebep olan iç özelliklerine odaklanmak gerekebilir
- 32. Class’ları Bulacağımız Yerler 2 • Class’lar aşağıdaki dokümanlarda gizlenebilirler: – Gereksinim Dokümanları – Use case modeli – Müşteri istekleri – Problem domain – Proje dokümanları
- 33. Class’ları Bulacağımız Yerler 3 • Boundary class’ları – Her aktör / uc ikilisi için en az bir tane olmalıdır • Control class’ları – Genellikle her uc için bir tane vardır – Benzer control class’ları varsa ait oldukları uc’ler birleştirilebilirler • Örnek: “manage traffic report”, “edit/add/remove traffic report” use case’lerini barındırabilir.
- 34. İsim Ayıklama Yöntemi “Noun Filtering”
- 35. İsim Ayıklama Yöntemi “Noun Filtering” • Entity Class’ları – Problem tanımı, gereksinim ve diğer mevcut dokümanlardaki isimleri inceleyerek bulunur – Bulunan isimler: • Nesneler • Nesnelerin değişkenleri • Aktörler • Hiçbiri olabilir
- 36. İsim Ayıklama Yöntemi “Noun Filtering” Problem metninin dikkatle okunarak, herhangi bir hatalı düşünce şeklinden kötü olarak etkilenmemek için bulunan tüm isimlerin listelenmesidir. Daha sonra bulunan isimlerden entity class’ı olamayacaklar elenir.
- 37. İsim Eleme Nedenleri 1 • Birbirine eş class’lar – Yalnızca isimlendirme farklı • İlgisiz class’lar – Oluşturulacak sistem için anlamsız • Değişkenler / Metodlar – İlkel veri tipleri – Veri işleme şekilleri
- 38. İsim Eleme Nedenleri 2 • Roller – Class’dan ziyade bir class’dan türetilebilecek nesne adayları • Örnek: “Asistan” ve “Öğrenci” “Kişi” class’ın farklı rolleridir. • Soyut kavramlar – Fiziki olarak mevcut olmayan değerlerdir – Nadiren analiz class’ına dönüşürler. Daha çok değişken adaylarıdır: “İstek”, “Satış” – Tasarım aşamasında class’lara dönüşebilirler.
- 39. Değişkenleri Bulma Yolları • Saptanan class’ların özelliklerini ifade ederler – Bu class’larca taşınacak veri yapılarıdır • Class’a dönüşmeyen isimler – Akış içinde değeri önemli olan veri yapılarıdır – Bir nesne tarafından benzersiz bir biçimde sahiplenilecek değerlerdir
- 40. İlişkileri Bulma Yolları • İlişki (Association) genellikle bir fiile karşılık gelir – Mekan: yanında, içinde, üstünde … – Eylem: oluşturmak, yönetmek … – Haberleşme: konuşur, dinler, onaylar, uyarır … – Sahiplik: aidiyet, parça, bütün ... – Diğer: çalışır, evlidir, okur ... • Problem ve Çözümle ilgisiz ilişkileri göz ardı ediniz • Nesne Etkileşim Şemaları ilişkileri bulmanın en etkili yoludur
- 41. Örnek: Trafik Denetim Sistemi • Entity Class adayları: Trafik Raporu Suçlu ID Süpervizör Police memuru Password Rapor Okuması Araç no Polis merkezi Konfirmasyon Plaka no Kapanma Suçlu Detayları Formu Hata Tarih T. Raporuna Eklenen Trafik polisi Hız Sistem Polis şefi Trafik hatası Suç Memur
- 42. Eşdeğer Class’ları Eleme Trafik Raporu Suçlu ID Süpervizör Police memuru Password Rapor Okuması Araç no Polis merkezi Konfirmasyon Plaka no Kapanma Suçlu Detayları Formu Hata Tarih T. Raporuna Eklenen Trafik polisi Hız Sistem Polis şefi Trafik hatası Suç Memur Memur ve Bilirkişi Kişi ile temsil edilecek
- 43. İlgisiz Class’ları Eleme Trafik Raporu Suçlu ID Kişi Police memuru Password Rapor Okuması Araç no Polis merkezi Konfirmasyon Plaka no Kapanma Suçlu Detayları Formu Trafik polisi Tarih T. Raporuna Eklenen Polis şefi Hız Suç
- 44. Değişken ve Metod Eleme Trafik Raporu Suçlu ID Kişi Police memuru Password Rapor Okuması Araç no Kapanma Konfirmasyon Plaka no Tarih Suçlu Detayları Formu Trafik polisi Hız T. Raporuna Eklenen Polis şefi Suç
- 45. Soyut Kavramları Eleme Trafik Raporu Suçlu Kişi Police memuru Konfirmasyon Trafik polisi Suçlu Detayları Formu Suç
- 46. Örnek: Trafik Denetim Sistemi Ayıklama Öncesi: Trafik Raporu Suçlu ID Süpervizör Police memuru Password Rapor Okuması Araç no Polis merkezi Konfirmasyon Plaka no Kapanma Suçlu Detayları Formu Hata Tarih T. Raporuna Eklenen Trafik polisi Hız Sistem Polis şefi Trafik hatası Suç Memur
- 47. Örnek: Trafik Denetim Sistemi Ayıklama Sonrası: Trafik Raporu Suçlu Kişi Police memuru Suçlu Detayları Formu Trafik polisi Suç
- 48. Entity class’ları • Trafik raporu • Kişi • Suçlu Detayları Formu Bazen bu listede boundary class’ları da kendilerini • Suçlu bariz olarak gösterirler. • Polis memuru Ancak bu class’ları • Trafik polisi bulmanın en iyi yolu UC • Suç akışını incelemektir. • …
- 49. Boundary class’ları • RaporDetaylariFormu • PolisDetaylariFormu • RaporIzlemeFormu • KonfirmasyonEkrani Veri Tabanına erişim • SucluDBProxy katmanındaki interface’ler. • PolisDBProxy • ...
- 50. Control Class’ları • RaporKontrol • LoginKontrol
- 51. Use Case’ler • Rapor Et – Rapor Ekle – Rapor Sil – Rapor İzle – Rapor Güncelle • Sisteme Bağlan
- 53. Analiz Class’ları 2 ReportDetailsForm 1 Of f endersDBProxy <<boundary >> 1 <<boundary >> Of f endersDB EditReportController <<control>> Clerk Conf irmationDialog 1 1 PolicemanDBProxy <<boundary >> 1 <<boundary >> PolicemenDB Traf f icReport Violation Of f ender Traf f icPoliceman
- 54. İçerik • Analiz ve Tasarım Modelleri Yapısı • Analiz Class’ları • Class Bulma Teknikleri • Tasarıma Geçiş Teknikleri
- 55. Tasarıma Geçiş Gereksinim ve Analiz Aşamalarında odağımız: – “Doğru işi yapmak” – Konuyu anlamak – Gereksinim ve kısıtlamaları anlamak ve berraklaştırmak – Tasarımdan ziyade problemi anlamak Tasarım Aşamasında odağımız: – “İşi doğru yapmak” – Paydaşların isteklerini karşılayan yazılımı onlara sunabilmek.
- 56. Gereksinimlerden Tasarıma Gereksinim ürünleri Tasarımı yönlendirir. Supplementary Specs Domain Model Use Case Model ... (Req list and attributes,. . . ) Software Architecture Design Model Data Model ... Document
- 57. Nesne Etkileşim Şemaları • Communication şemaları nesnelere tepeden bakarak birlikteliği değerlendirebilmemizi sağlar. • Sequence şemaları nesneler arasındaki mesajlaşma ve nesne ömürlerine odaklanarak nesne sorumluluklarını güncellememize yardımcı olur.
- 58. Nesnelere Sorumluluk Atama Şimdi ne olacak? Bu mesajı hangi nesne kabul edecek? Bu isteği yerine getirmek için hangi mesajlar nasıl sıralanacak? Video Store Presentation Video ID ... ... ... ... Clerk Record Rental ... Application appLogicRequest() Logic Now what happens? ???
- 59. Sorumluluk Odaklı Tasarım Detaylı class tasarımı genellikle aşağıdaki varsayımlarla yapılır: – Nesnelerin sorumlulukları vardır – Nesneler birlikte çalışırlar – Tıpkı insanlara benzerler Dolayısıyla Sorumluluk Odaklı Tasarım’da aşağıdaki soruları soracağız: – Bu nesnenin sorumlulukları nelerdir? – Hangi nesnelerle birlikte çalışması gerekiyor?
- 60. Class Sorumlulukları Sorumluluklar çeşitli kapsamlarda olabilirler: – Veri saklanması (persistence) sorumluluğu. Üst seviyedeki bir sorumluluk. – K.D.V. hesaplanması sorumluluğu. Daha alt seviyedeki bir sorumluluk. Bu sorumluluklar genellikle class’lara fonksiyonlar olarak ekleneceklerdir. Gerekiyorsa bir grup class tarafından gerçekleştirilebilirler.
- 61. Tasarım Teknikleri • Size/Kurumunuza özel yaklaşımlar • Proje teknolojisine has yaklaşımlar • Proje konusuna has yaklaşımlar • Popüler yaklaşımlar: GOF Tasarım Kalıpları • Denenmiş Nesne Tabanlı Teknoloji Yaklaşımları: GRASP • Kullandığınız altyapıyla dikte edilen yaklaşımlar • vs. vs.
- 62. GOF Tasarım Kalıpları “Strategy” Örneğin, borcunu düzenli ödeyen kredi kartı sahibiyle ödemeyene farklı yaklaşmak istememiz.
- 63. GRASP Teknikleri (Patterns) Sorumlulukları atarken izleyebileceğimiz kılavuzlar var mı? Bu kılavuzların en yaygını GRASP teknikleridir (patterns). – General Responsibility Assignment Software Patterns. – Çok temel ve basit nesne tabanlı tasarım ilkeleridir.
- 64. 9 GRASP Tekniği 1. Expert (Konu Uzmanı) 2. Creator (Oluşturan) 3. Low Coupling (Nesne Bağımlılıklarını Azalt) 4. High Cohesion (Metod Alakalarını Yükselt) 5. Controller 6. Polymorphism 7. Pure Fabrication 8. Indirection (Dağıtma) 9. Don’t Talk to Strangers (Yabancılarla Konuşma)
- 65. 1. (Information) Expert “Konu Uzmanı” En temel sorumluluk atama ilkesi nedir? Bir sorumluluğu yerine getirmek için gereken veriye sahip nesneye o sorumluluğu atayınız – “İşi yapan gereken bilgiye sahip olandır.” – Örnek: K.D.V.’yi hangi nesne hesaplar? 3. Bu hesaplama için hangi bilgiler gerekli? 4. Hangi nesne veya nesneler bu bilgilerin çoğuna sahipler?
- 66. 2. Creator “Oluşturan” Hangi nesne X nesnesini oluşturur? Bir C nesne bulmalıyız ki: – C X’i içerir veya ikisi arasında aggregation vardır – C X’i yoğun olarak kullanır – C’de X’’i oluşturmak için gereken ilk veri değerleri mevcuttur – Vs. vs. Liste ne kadar uzunsa o kadar iyidir.
- 67. 3. Low Coupling “Nesne Bağımlılığını Azalt” Class’lara sorumlulukları dağıtırken önemlidir. ‘Low coupling’ ne demek? – Coupling bir elemanın bir diğerine ne derecede bağımlı olduğunu, onun bilgisine sahip olduğu veya ihtiyaç duyduğunu belirten bir ölçüm birimidir. Yüksek coupling’e sahip bir class: – Ilişkili olduğu class’lar değiştiğinde değişmek zorunda kalabilir. – Tek başına ne işe yaradığı zor anlaşılır. – Tekrar kullanımı zordur.
- 68. 4. High Cohesion “Metod Alakalarını Artır” Class’lara atanan sorumlulukların birbirlerine yakınlıklarıyla ilgilidir. ‘Cohesion’ ne demek? – Bir elemanın sorumluklarının ne derecede alakalı ve odaklanmış olduğunu gösteren bir ölçüm birimidir. Birbiriyle çok alakalı sorumluluklara sahip ve çok çeşitli işleri yapmaya kalkmayan bir nesne yüksek ‘cohesion’a sahiptir. Düşük ‘cohesion’a sahip bir class: – Ne işe yaradığını anlamak, tekrar kullanmak ve bakımını yapmak zordur. – Kırılgandır; Durmaksızın değişikliklerden etkilenir.
- 69. 5. Controller Hangi nesne UI katmanından gelen (Presentation Layer) istekleri topluyor (Application Coordination Layer)? Video Store Presentation Video ID ... ... ... ... Clerk Record Rental ... Application appLogicRequest() Logic What object should this be? ???
- 70. 6. Polymorphism Değişen fakat benzerlikler de gösteren durumların tasarımı için bir yol. Farklı durumlara sahip class grubuna bir polymorphic fonksiyon ekleyiniz. – Alternatifi case logic. Örneğin, çiz() – Kare, Daire, Üçgen
- 71. 7. Pure Fabrication “Suni Class / Katman” Expert (uzman) yaklaşımı coupling (nesne bağımlılığı) ve cohesion (metod alakası) problemlerine yol açıyorsa veya başka bir nedenden dolayı bu yaklaşım arzu edilmiyorsa kullanılır. Suni bir class oluşturularak mutlaka konuyla alakalı olması gerekmeyen bir isim verilir. Örneğin videocu’daki veri tabanı kayıtlarını düşünürsek, – Video (mevcut class) – DatabaseFacade (Bir Pure Fabrication)
- 72. 8. Indirection “Dağıtma” Coupling (nesne bağımlılığı) azaltma yöntemi olarak kullanılır. Sorumluluğu ikincil nesnelere verip birlikte çalışma (collaboration) derecesini azaltmak.
- 73. 9. Don’t Talk to Strangers “Birliktelik Oluştur” Coupling (nesne bağımlılığı) seviyesini nesnelerin yapısal komşuları arasındaki birlikteliğe (collaboration) indirgemek. Bir metodu çalıştırmak için çok sayıda nesneye erişmeyiniz. Bir işi daha çok o nesnenin ‘yakınlarına’ veriniz.
- 74. İlham Kaynakları Christopher Alexander Martin Fowler Peter Coad Kelli Houston Don Box
Notas del editor
- Analiz ve Tasarım Modellerini hazırlayan rol Tasarımcıdır. Burada dikkat edilmesi gereken geleneksel yaklaşım altında analiz olarak nitelendirilen çalışmaların tamamıyla gereksinim yönetimi aşamasına kaydırılmış olmalarıdır. Diğer bir deyişle, Akış, Kullanılan Veri Yapısı, Yapılan Kontroller ve İş Kuralları gibi bilgiler gereksinim yönetimi aşamasında derlenmektedirler. Bu yaklaşım altında Analiz ve Tasarım Modeli çalışmaları kavramsal anlamda ve seçilen teknolojiye yönelik olarak nesne tabanlı yaklaşımın kullanıldığı çalışmalar olduklarından onları hazırlayan deneyimli bir programcıdır (Proje konusu ve kullanılan teknolojide deneyim sahibi). Bu çalışmaların yapılması için gerekli bilgileri üreten ve gerektiğinde danışılan kişi Sistem Analistidir. Analiz ve Tasarım Modellerini denetleyen ve en iyi çözümün seçildiğinden emin olunmasını sağlayan bir başka Tasarımcıdır.
- Gereksinim Dokümanları en önemli girdi olarak kullanılır. Use Case Dokümanına özel bir önem verilir. Sistem Analisti gereken eksik bilgiler için sorgulanır. Bir başka Tasarımcıyla çözüm yaklaşımları değerlendirilir.
- Tasarımcının Analiz ve Tasarım çalışmalarına başlamadan önce ilk yapacağı iş Nesne Modelini oluştururken kendisine yardımcı olacak önemli akışları belirlemektir: 1) İterasyon kapsamındaki use case dokümanlarına erişilir. 2) Önem sırasıyla metinler okunur: a) İsim Ayıklama yöntemi ile kendini gösteren Entity Class’ları bulunur. b) Alternatif Akışlardan önemlileri seçilir. c) Temel Akış’la başlanarak, seçilen Alternatif Akışlar için Use Case Gerçekleştirme yapısı oluşturulur. Sonuçta ortaya çıkan çalışmada kullanılan nesne etkileşim şeması sayısı toplam akış sayısından küçük, birden de (temel akış) her zaman büyüktür.
- Analiz ve Tasarım Modeli Parçaları [1] Analiz Modeli (Analysis Model): [i] Analysis Elements (Analiz Paketleri) Aralarındaki mantık ilşkilerine gruplanmış class’ların oluşturduğu modüller. Modüller arasındaki bağımlılık (öncelik, sonralık: <<trace>>) ilişkileri. [ii] Kullanım Senaryolarının Gerçekleştirilmeleri (Use Case Realizations) Kullanım senaryosu bazında yararlanılan class grupları ve ilişkileri. Bu class gruplarından türetilen nesnelerin belli (tanımlı) hizmetleri verirken nasıl etkileştikleri. Class’ların sorumluklarının (CRC: Class Responsibility Card egzersizi benzeri) belirlenmesi. [iii] Temel Soyutlamalar (Key Abstractions) Geliştirilecek sistemin kelime haznesinin özeti. En temel class’lar ve ilişkileri. [2] Tasarım Modeli (Design Model): [i] Design Elements (Tasarım Paketleri) Aralarındaki mantık ilşkilerine gruplanmış class’ların oluşturduğu modüller. Modüller arasındaki bağımlılık (öncelik, sonralık: <<trace>>) ilişkileri. EK: Katmanlar ve Modüller Modüllerin katmanlara bölünmesi ve istenen referanslara göre düzenlenmesi. Örneğin, çok katmanlı mimari katmanları, tekrar kullanılabilirlik seviyeleri, altyapılar ve sizin geliştireceğiniz katmanlar, vs. [ii] Kullanım Senaryolarının Gerçekleştirilmeleri (Use Case Realizations) Kullanım senaryosu bazında yararlanılan class grupları ve ilişkileri. Bu class gruplarından türetilen nesnelerin belli (tanımlı) hizmetleri verirken nasıl etkileştikleri. EK: Daha fazla detay Class’ların değişken ve fonksiyonlarının veri tipi, return type ve kullanılan parametreler seviyesinde belirlenmesi. Fonksiyonların şema ve pseudocode kullanılarak algoritmaları.
- Use Case Realizations (UCR) yapısı Analiz ve Tasarım Modellerini oluştururken kullanacağımız en güçlü araçtır. Tasarımcı olarak hangi modeli oluşturduğunuzdan bağımsız olarak her kullanım senaryosu başına iki class şeması oluşturulur: VOPC: Birinci class şemasının oluşturulma nedeni use case senaryoları sırasında nesneleri etkileşen class’ları bir bütünlük içinde sergilemektir. Bu yüzden şemanın adı ‘View of Participating Classes’ (VOPC: Use Case Kapsamında Kullanılan Class’lar) olarak verilmektedir. Şemadaki class’lar arasında bariz olan veya etkileşim şemalarında ortaya çıkartılan ilişkiler (association, generalization, aggregation, composition) kurulur. Trace: İkinci class şemasının oluşturulması aslında bariz olmakla birlikte Gereksinim Modelindeki bir use Case’i (Örneğin, “Para Çek”) Analiz Modelindeki bir UCR’ye (Yine, “Para Çek”) bağlamak ya da Analiz Modelindeki bir UCR’yi (Örneğin, “EFT Yap”) Tasarım Modelindeki bir UCR’ye (Yine, “EFT Yap”) bağlamak amacıyla kullanılır. Bu yüzden şemaya genellikle ‘Trace’ (sonra gelme) adı verilir. İlişki kurulan UC ve UCR veya UCR ve UCR arasında sonra gelenden öncekine <<realize>> ilişkisi çekilir. Class şemalarına ek olarak temel akışı her zaman içerecek şekilde ve birden büyük, use case sahip olduğu toplam senaryo sayısından küçük sayıda etkileşim şeması UCR kapsamına eklenir. Etkileşim Şemaları: Use Case senaryolarından nesne modelini oluştururken Tasarımcının yararlanacağını düşündükleri ve analiz ve tasarım dokümantasyonu açısından modelde bulunması gerekenler etkileşim şemalarında (Sequence / Communication Şemaları) resmedilirler.
- Analiz Paketleri Analiz class’larını buldukça ‘Analiz Paketleri’ (Analysis Elements) adı altında class gruplarının aralarındaki mantık ilşkisini ifade edecek şekilde adlandırılmış paketlere dağıtınız. Bu paketler ve aralarındaki ilişkiler tasarım aşamasındaki modüllerin tanımlanması ve katmanların oluşturulması aşamasında çalışmalarınıza büyük katkı sağlayacaktır.
- Tasarım Paketleri Analiz aşamasında kavramsal bir problem çözümünün temel öğelerini ifade eden ‘ Analiz Paketleri’, tasarım modelinin Tasarım Paketleri (Design Elements) oluşturma aşamasında geliştirilerek sistemin modüllerine dönüşeceklerdir. Bu modüller kendi aralarında kurum için önem arzeden bir konuya yönelik olarak gruplanarak katmanları oluşturabilirler. Yukarıda günümüzde en sık rastlanan katman yapılarından birisi olan “Çok Katmanlı Mimari” yapısını görüyorsunuz. Sayısı daha da artırılabilecek olan bu katmanlar Arayüz Katmanı (Presentation Layer), İş Mantığı Katmanı (Business Logic Layer), Veri Katmanı (Data Layer) ve Veri Erişimi Katmanıdır (Data Access Layer).
- Kullanım Senaryosu Gerçekleştirme – Analiz Paketleri İlişkisi Kullanım Senaryoları detaylandırılırken, her biri için oluşturulan VOPC class ve Etkileşim Şemaları aracılığıyla saptanan class’lar, daha önce use case dokümanı metninden hemen belli olanlarla (Gereksinim Yönetimi ünitesindeki isim ayıklama –noun filtering- yöntemiyle entity class’larını nasıl bulduğumuzu hatırlayınız) birlikte Analiz Paketlerine yerleştirilirler. Analiz Paketleri altında ise class’lar aralarında mantık ilişkisi bulunan class’larla daha alt gruplara (Paketlere Bu ilişkinin mahiyetini belirtecek bir isim verilerek. Örneğin, muhasebe paketi gibi) yerleştirilirler.
- Kullanım Senaryosu Gerçekleştirme – Tasarım Paketleri İlişkisi Eğer yazılım geliştirilen işin mantığı basitse ve çözümü önce kavramsal olarak oluşturmak gerekmiyorsa, bir önceki çalışmanın aynı yapılarak Tasarım Modeli oluşturulur. Bu durumda bir Analiz Modeli yoktur. Eğer Analiz Modeli çalışması yapılmışsa, bu çalışmadan yararlanılarak aynı çalışmalar seçilmiş bir teknolojiye uygulanır. Çalışma şekli ve sırası bir öncekine benzerdir: Analiz modelinden iterasyon kapsamındaki use case’lerin sırayla gerçekleştirilme detaylarının incelenmesi. Etkileşim Şeması ve Class Şeması çalışmalarının seçilen teknolojideki karşılıklarının belirlenmesi. Ortaya çıkan class’ların aralarındaki mantık ilişkilerine ve proje açısından anlamlı diğer referanslara göre (Örneğin, çok katmanlı mimari katmanları: Arayüz, İş Mantığı, Veri katmanları gibi) alt gruplar oluşturularak Tasarım Paketlerinin tanımlanması.
- Bir use case’in senaryolarını nesne etkileşim şemalarıyla incelerken ortaya çeşitli nesnelere (dolayısıyla class’lara) ihtiyaç çıkar. Bu durumda ilk yapmamız gereken Analiz Modeli çalışması yapıyorsak Analiz Paketleri, Tasarım Modeli çalışması yapıyorsak Tasarım Paketleri içeriğine bakarak ihtiyaç duyduğumuz class’ların zaten mevcut olup olmadıklarına bakmaktır. Eğer ihtiyaç duyduğumuz class (veya class’lar) mevcutsa, bu sefer de bu class’ların ihtiyaç duyduğumuz sorumluluklara (veya fonksiyonlara) sahip olup olmadıklarına bakmalıyız. Eğer istediğimiz sorumluluklara sahip değillerse, nesne etkileşim şeması çalışmalarımız esnasında bunları bizler eklemeliyiz. Buradan da anlayacağınız gibi geliştirdiğimiz sistemin nesne modeli bu şekilde bir takım çalışmasıyla - yazılım takımımızın birbirlerini tamamlamasıyla – kademe kademe eksiksizleşir.
- Tasarım Modeli çalışmaları esnasında gerçekleştirilen diğer çalışmaları özetlemek istersek, Tasarımcı’nın yapacağı ek çalışmalar: Eğer gerek duyuyorsa, Deployment Modeli yapısını belirlemek ve Deployment Modelini oluşturmak, İmplementasyon Modeli yapısını belirlemek. Veritabanı Analisti (veya diğer eşdeğer ismiyle veritabanı tasarımcısı): Veritabanı Modelini oluşturmak. Kullanıcı Arayüzü Tasarımcısı: Sistem Analistinden de yararlanarak Kullanıcı Etkileşimi Modelini oluşturmak.
- Hatırlarsanız, gereksinim yönetimi slaytlarımızda (bölüm 6) elimizde tıpkı marangozların sahip olduğu gibi bir alet çantasına nasıl sahip olacağız demiş ve teker teker aletlerimizi tanımlamaya başlamıştık. Bu ‘aletlerden’ analiz açısından en önemlilerinden birisi Analiz Class’ları ve Türleri ayrımını yapmaktır. Böylece Sistemin sınırlarını netleştirmek, Sistemin dayanacağı veri yapısını ayrıştırmak ve netleştirmek, Sistemin taahhüt ettiği hizmetleri verirken kullanacağı iş mantığını ayrıştırmak ve netleştirmek mümkün hale gelmektedir.
- Analiz Class’larını diğer class’lardan ayıran az önce değindiğimiz özelliklerini işaret etmek üzere yapılarına eklenmiş işaretlerdir (stereotype). Analiz Class’ları üçe ayrılırlar: Boundary Class’ları: Sistemin sınırlarını teşkil eder. Entity Class’ları: Sistemin kullanacağı veri yapısını ifade eder. Control Class’ları: Sistemin hizmet verirken izleyeceği iş mantıklarıdır.
- Dikkat ederseniz Analiz Class’ları bulduktan sonra onların kullanılma şekilleri her zaman aynıdır. Böylece ‘marangozluk alet kutumuza’ yeni bir ‘alet’ daha koymuş oluyoruz. Kullanım şeklini belirtecek olursak, Aktörlerle Sistem (İlgili oldukları: çalıştırdıkları veya bağımlı oldukları use case’ler) arasına Boundary Class’larını, Boundary Class’ları ile o arayüz aracılığıyla yapılacak iş için gereken veri yapısı (ilgili Entity Class’ları) arasına Control Class’larını ve Vereceğiniz iş için gereken mantığı da her zaman arada kalan Control Class’ına yerleştiriniz.
- [1] Analiz Class’ları: Boundary Class Örnek verecek olursak, Markette gördüğünüz Bar Code Okuyucular (Device Interface), İnternetten havale gönderirken kullandığınız İnternet Bankacılığı Arayüzü (User Interface), ATM’den para çekerken, (görmediğiniz) banka merkezindeki sisteme erişilip bakiyenize bakmak için için kullanılması gereken interface (System Interface), vs. vs. Yapıları tamamen ilgili oldukları duruma bağlı olduğu için kullanılacak haberleşme protokollerine ve UI bileşenlerine bağımlıdırlar: Boundary Class’ları Ortama Bağımlıdır.
- [2] Analiz Class’ları: Entity Class En önemli Analiz Class’i türüdür. Diğer türler kendilerini daha kolay gösterdiğinden ilk bulunan ve üzerine daha fazla zaman ayrılan bir class türüdür.
- [3] Analiz Class’ları: Control Class Örnek verecek olursak, Control Class’ları tıpkı Trafik Polisleri gibi davranırlar. Bir caddede elinde düdüğüyle araçlara geç ve dur diyen bir trafik polisini düşününüz. Kendisi bir iş yapmaz (Hareketlilik anlamında). Fakat ne zaman ne yapılacağına karar verir, bu kararları eyleme geçirir ve yönetir. Ondan izinsiz hiçbirşey yapılmaz. Aynı şekilde, Control Class’ları kendilerine Boundary Class’larından iletilen işi yapmazlar ama işi yapacak nesneleri bilirler ve işi bunlara doğru yönlendirirler. İşin sonuçlarının kullanıcıya (veya bir diğer sisteme) iletilmesinde bu akış sırası tersine döner. Yani işin neticesini de Control Class’ları vasıtasıyla elde ederiz. Control Class’ları use case’e ve ortama bağımlıdır. Yani bir use case’in iş akışını temsil eder diğerinkini değil ve kullanılan teknolojiye göre değişir: Örneğin, ViolationsController: SessionBean: J2EE.
- Analiz Class’larının ortaya çıkmasında referans çok katmanlı mimari olmakla birlikte diğer teknolojilerde de oldukça faydalıdırlar. İhtiyaçlarımıza göre onları kısmen de kullanmak mümkündür. Çok Katmanlı Mimari kullanmayanların kullandığı en yaygın yöntemse analiz class’larının hepsini kullanmak ama buradan tasarım class’larına geçerken birebir bir ilişki kurmamaktır. Örnek olarak bir entity class’ıyla bir control class’ının tek bir class’a dönüşmesini verebiliriz.
- Analiz Class’larını Bulma Yolları Analiz Class’larını bulmak için tek başına büyük ölçüde kafi olması gereken doküman Kullanım Senaryosu Dokümanıdır (use case specification). Bu dokümandaki akış bilgilerini okurken gerekli entity class’larını kolaylıkla bulabilmeyiz. Akışların sayısının çokluğu ve hem başarılı hem de başarısız ihtimallere göre ayrılmaları zaten bu yüzdendir. Entity Class’larının nasıl bulunduklarına ilerideki İsim Ayıklama Tekniğine (Noun Filtering) değinirken eğileceğiz. Önemli entity class’larını saptadıktan sonra aşağıdaki kurallara uyarak Boundary ve Control class’larını bulunuz: Boundary Class’ları: Ne zaman bir kişi veya bir sistem bizim sistemmizle etkileşmek ihtiyacı duyarsa orada bir Boundary Class’ı vardır. Analiz aşamasında bu boundary class’ının kaç dinamik sayfa veya kaç ekran olduğu çok önemli değildir. Bununla birlikte ihtiyaç kendini gösterdiğinde bu tür detaylar da incelenebilir. Control Class’ları: Her kullanım senaryosu başına bir tane olmak üzere oluşturulur.
- Analiz Class’larını Bulma Yolları Daha sonra bulduğunuz class’ları Class Şemanıza (incelemekte olduğunuz use case’in Use Case Realization yapısını oluştururken, onun VOPC class şemasının üzerine) yerleştiriniz. Bu class’lar büyük çoğunlukla (veya tamamen) entity class’ları olacaklardır. Daha boundary ve Control class’larını aramadıysanız endişe etmeyiniz, onlar nesne etkileşim şemalarını (sequence, communication) çizerken yerlerini belli edeceklerdir. Kendi class’larınızı tanımlamadan bunların zaten mevcut olup olmadıklarını Analiz Modeli altındaki Analiz Paketlerine bakarak kesinleştiriniz. VOPC şemanızda class’ların bazı ilişki türleri kendilerini hemen gösterirler: Generalization, Aggregation, Composition. Tür ve parça/bütün ilişkilerinde bulabildiklerinizi ilişkilerini kurarak belirtiniz. Yine aynı şekilde elinizdeki Kullanım Senaryosu Dokümanı entity class’larının değişkenleri hakkında pek çok bilgi verir. Değişken türü vs. gibi tasarım öğelerine dalmadan sadece hangi class’a ait olduklarını ve adlarını belirtiniz. Daha sonra nesne modelini oluştururken yararlanacağınızı düşündüğünüz alternatif akışları teker teker (Temel Akış her zaman alınır) nesne etkileşim şemalarıyla (daha çok sequence kullanılır) resmediniz. Bu çalışma esnasında ortaya çıkan nesne eksikliklerini VOPC şemasına yeni class’lar ekleyerek gideriniz. Class’ların yavaş yavaş sorumluluklarını (Tasarım Modelinde fonksiyonlara dönüşecekler) belirleyiniz. VOPC class şeması ile Etkileşim şeması çalışmalarını dairesel bir şekilde ve birbirlerini beslemelerine imkan vererek yapınız.
- Analiz Class’larını bulmak için birincil kaynağın Kullanım Senaryosu Dokümanları olduğuna Değinmiştik. Ayrıca, tek başına bu kaynağın büyük ölçüde class’ları bulmaya kafi gelmesi gerektiğini Söylemiştik. Eğer bunun aksi söz konusu ise, elinizdeki Kullanım Senaryosu Dokümanının detay seviyesini tekrar Gözden geçirmeniz gerekmektedir. Doğru seviyeyi saptamak için aşağıdaki testi yapabilirsiniz: Müşteri Testi: Dokümanı sistem analistine geri gönderiniz. Sistem Analisti müşteriyle üzerinden geçerek, dokümanın hala ‘Ne’ye odaklandığını ve ‘Nasıl’a (Tasarıma) girmediğini onaylasın. Tasarımcı Testi: Dokümanı sistem analistine geri gönderiniz. Sistem Analisti müşteriyle üzerinden geçerek, detay eksikliklerini gidersin.
- Class’lar kendilerini pek çok diğer dokümanda da gösterebilirler. Eğer Senaryo Odaklı yöntem başka yöntemlerle birlikte kullanılıyorsa bu durum daha ciddi bir şekilde ortaya çıkacaktır. Aslında, verilmesi gereken karar “Ya O Ya O” sorusuna bir cevap bulmaktır. Bununla birlikte, senaryo odaklı yaklaşım proje başından itibaren uygulanmamışsa veya süreç geriye doğru (reverse engineering) takip ediliyorsa pek çok dokümanı taramak, parçalamak ve birleştirmek kaçınılmazdır.
- Use Case kapsamında verilecek hizmetlere erişimi sağlamak ve diğer sistemlerle etkileşim için Boundary Class’larını tanımlayınız. Kullanıcıya fayda sağlamak için kullanılması gereken her dış servis (kredi kartları provizyonu gibi) ve her cihaz (bar code reader gibi) birer boundary class’ı ile ifade edilmelidir. Bunlara kullanıcıların arayüzlerini de eklediğinizde Boundary Class’larını bulmuş olursunuz. Control Class’larına gelince, her use case için hemen hemen her zaman bir tane vardır. Dolayısıyla her use case’e düşünmeden birer tane atayabiliriz. Onları araştırıp bulmamız gerekmez.
- İsim Ayıklama nesne modelini oluşturma (class’ları bulma, entity class’larını bulma) amaçlı olarak kullanım senaryosu dokümanlarının taranması işlemine denmektedir.
- Entity Class’ları ilk olarak bulmaya çalıştığımız en önemli analiz class’larıdır. Bulunmaları için kullanılan en yaygın yöntem, İsim Ayıklama Yöntemidir. Bu yöntem konuyla ilgili dokümanların taranması ve isimlerin saptanarak bir liste oluşturulmasına dayanır. En önemli doküman yine Kullanım Senaryosu Dokümanlarıdır. Bu doküman tek başına büyük ölçüde kafi gelmelidir. Dokümanda bulunan isimler, isim gibi yazılmış fiiler, Nesneler, Class’lar, Aktörler, Soyut kavramlar, Çalışma kapsamımız açısından önemsiz terimler vs. olabilirler.
- İsim Yönteminde dikkat edilmesi gereken konulardan birisi, metinde saptanan ve listeye eklenen isimlerle işin başında detaylı uğraşmamak, geçerliliklerini düşünmemektir. Temel varsayım bu aşamada filtreleyeceğimiz isimlerde hata yapabileceğimizdir. Çalışmanın ikinci aşamasında isimler teker teker incelenerek, eğer bir entity class’ına dönüşmüyorlarsa elenerek ve ismin yanına elenme nedeni yazılarak devam edilir.
- İsim Eleme Nedenlerine örnekler verirsek, Eşdeğer Class’lar: Öğretmen, Eğitmen, Öğretim Görevlisi İlgisiz Class’lar: ‘Otobüs’ Üniversite Kayıt Sistemi alakasızlığı gibi, cümlelerde geçen fakat başka sistemlerde (Örneğin, Taşıt Takip Sistemi) bir anlamı olabilecek entity class’ı adayları. Değişkenler / Sorumluluklar: Class’dan ziyade class’ların içinde yer alacak veri tipleri ve bu class’ların sorumlulukları (tasarım aşamasında fonksiyonları) olan isimler. Örneğin, Öğrenci class’ına ait “isim” değişkeni ve “dersin listesine eklenme” sorumluluğu gibi.
- İsim Eleme Nedenlerine örnekler verirsek, Roller: Nesne adayları. Örneğin, Öğrenci olabilen çeşitli kişiler ve roller: Asistanlar, Yarım Zamanlı Öğrenciler, Burslu Öğrenciler vs. Kuşkusuz duruma göre bazı nesne görünümü veren isimler bir başka class’ın türü olabilecektir (generalization, inheritance). Soyut Kavramlar: Bir değer veya bilgi türü içermekten çok olan bitenin bir tanımı olan isimlerdir. Örnek olarak ‘Satış’ı verebiliriz. Bir plakçıdan bir CD alınması, CD ve Plakçı isimleri altında pek çok bilginin tutulabileceği hissini (bunların entity class’ları olabilecekleri) verirken, satış sadece olanların bir isim altına toplanmasıdır. Bununla birlikte satışın kendisi bir konu olursa (satış tutarı, satılan ürün türü vs.) buradan da entity class’ları çıkabilecektir.
- Değişkenlerin bulunması aynı zamanda bizlere class hiyerarşisi hakkındaki ilk fikirlerimizi geliştirme fırsatını sağlar. Class’ları aralarında kademelendirirken Abstract ve Super Class ayrımlarını yapmaya başlar ve Parent-Child ilişkilerini tanımlarız. Konunun özelliklerine göre isimler bir değişken olabilir veya dikkatimizi çekerek bir class adayına dönüşenebilir.
- Class’lar arasındaki ilişkileri şu sırayla inceleyebilirsiniz, 1) İyi hazırlanmış Kullanım Senaryosu Dokümanlarında bazen cümleler direkt olarak association bilgisi verir: “Öğrenci kütüphaneden seçtiği kitapları 15 günlüğüne ödünç alır.” Öğrenci ve Kitap etkileşimi barizdir. 2) Kabaca VOPC şemamızı çizerken tür (generalization) ve parça-bütün (aggregation/composition) ilişkileri kendilerini göstermeye başlarlar. 3) Kullanım Senaryosu Dokümanından seçtiğimiz senaryoların nesne etkileşim şemalarını çizerken birbirleriyle etkileşen nesneler (dolayısıyla class’lar) kendilerini göstermeye başlarlar: Association İlişkileri adayları.
- İsim Ayıklama Egzersizi: Trafik Denetim Sistemi [1] Tüm İsimlerin Listesinin Oluşturulması Bu sistem aracılığıyla trafik kurallarını ihlal eden sürücüler hakkında eski kayıtların incelenmesi ve yeni kayıtların yapılabilmesi sağlanacaktır. Kullanım Senaryosu Deokümanlarındaki tüm isimler –üzerlerinde fazla düşünülmeksizin- bulunarak, bir liste oluşturulur.
- [2] Ayıklama Çalışmaları: Eş Değerlik Eşdeğer (Aynı class’ı işaret eden) isimler yerlerine sadece bir tanesi kalacak şekilde ayıklanırlar. Geriye kalan isim mümkün olan en açıklayıcı isim olmalıdır.
- [3] Ayıklama Çalışmaları: İlgisizlik Bir class olabilecek ancak geliştirdiğimiz sistemle ilgisi bulunmayan isimler de göz ardı edilerek ayıklanırlar.
- [4] Ayıklama Çalışmaları: Değişkenler ve Sorumluluklar Bir class olmaktan çok (başka bir kapsamda class olmaları mümkündür) bir class’ın içindeki değişkenler ve sorumluluklar (metodlar, tasarım aşamasında fonksiyonlar) olabilecek veri tipleri ilgili class’ların altlarına not edilerek ayıklanırlar.
- [5] Ayıklama Çalışmaları: Soyut Kavramlar Herhangi bir veri yapısı hakkında bir bilgi vermeyen, soyut ve sadece isim oldukları için listeye alınmış olanlar da ayıklanırlar. Burada unutulmaması gereken sistem kapsamının bu tür ayıklamaları konusuna göre onaylayıp onaylamadığıdır. Başka sistem kapsamları başka class yapılarını doğurur.
- Trafik Denetimi Sistemi Entity Class’ları: TrafikRaporu Kisi Suclu Polis TrafikPolisi Suc vs. vs.
- Trafik Denetimi Sistemi Boundary Class’ları: RaporFormu PolisFormu RaporIzlemeEkrani KonfirmasyonEkrani iSuclu (Interface) iPolis (Interface)
- Trafik Denetimi Sistemi Control Class’ları: Her Kullanım Senaryosu başına birer tane olmak üzere, RaporKontrol LoginKontrol
- Trafik Denetimi Sistemi Kullanım Senaryoları Use Case 1: Rapor Et Use Case 2: Sisteme Bağlan “ Rapor Et” Temel Akışı: Rapor Ekle, Alternatif Akışlar (Başarılı): Rapor Sil, Rapor İzle, Rapor Güncelle, … “ Rapor Et” <<includes>> “Sisteme Bağlan” Aktör direkt olarak da “Sisteme Bağlan”ı çalıştırabilir: Aktörden UC2’ye association.
- Trafik Denetimi Sistemi olası bir temel soyutlamalar (Key Abstractions Class Şeması) şeması, (*) Sistem Bakımı: Daha önce yapılmayan Trafik Polisi ayrımı ortaya çıkmıştır. Dolayısıyla Polis ile TrafikRaporu arasındaki ‘Association’ ilişkisi TrafikPolisi ile TrafikRaporu arasına kayacaktır. Şema içeriğini okuyacak olursak, Polisler ikiye ayrılır: Tipik Polis ve Trafik Polisi. Her iki tür de sicil numarası, ad ve rütbeye sahiptir. Trafik Raporunun yazılabilmesi için her zaman bir kural ihlali (suç) vardır veya tersi. Trafik Raporlarında rapor numarası, tanımı ve tarihi bulunur. Suçluların sicil numaraları ve adlarını bellidir. Bir polis pek çok tarfik raporu yazabilir, her raporda pek çok suça değinilebilir ve aynı suçlara sahip çok sayıda suçlu olabilir.
- Şema içeriğini okuyacak olursak, Polis Memuru ReportDetailsForm’unu kullanarak suçlu taraması yapar (örneğin plaka numarası girerek). Eğer suçlunun daha önce işlediği suçlar varsa, bu bilgiler raporu veren polis memuru bilgileriyle birlikte getirilir. Polis Memuru yeni suçu ekleyerek, onayladığında Trafik Raporu Suç, Suçlu ve Trafik Polisi kayıtlarını günceller.
- Artık yapacağımız işin gereksinimleri üzerinde kontrolmüz olduğundan ve kavramsal bir problem çözümünü geliştirdiğimizden, bu çözümü seçtiğimiz bir teknolojiye uygulayabiliriz.
- Tasarıma geçişin iki yaygın yöntemi vardır. Bu yöntemlerin geçerlilikleri Analiz Modelinin hazırlanıp hazırlanmayacağına (Çözümün kavramsal bir güçlük içerip içermediğine) bağlıdır. Bir tanesinde Gereksinim Modeli (Çeşitli dokümanlar ve Use Case Modeli) Analiz Modeli çalışmasını besler ve bu çalışmada üretilen iş ürünleri içinde kullanım senaryosu bazında Analiz Class’ları tanımlanır. Diğer yöntemde ise Gereksinim Modelinden yararlanılarak bir Domain Modeli (Temel Soyutlamalar, Kullanım Senaryosu Bazında Gruplanmamış analiz class’ları) oluşturularak Tasarım çalışmalarına geçilir.
- Bu aşamada Nesne Etkileşim Şemaları hakkında bildiklerimizi hatırlarsak, Communication (Eski adıyla Collaboration) şemaları ve Sequence Şemaları nesne ilişkilerini, bu ilişkilerin ne tür gruplar oluşturduklarınbı saptayarak (Örneğin, Strategy tasarım kalıbı gibi) ve bu işbirliklerinin ne tür mesajlaşmalara yol açtığını bularak, incelememize imkan verirler.
- Bu aşamadaki temel sorunlardan bir tanesi (Eğer analiz class’larından yararlanmamışsak) hangi nesnelerin birbirleriyle etkileşeceklerini belirlemektir. Bu durumda pek çok hata da çalışmalar esnasında tasarıma katılmaktadır. Bizim yaklaşımımız altında (Analiz Modeli çalışmasından sonra) hem temel class ilşkileri ortaya çıkmış hem de nesneler katmanlara ayrılmış oluyor (Boundary, Control, Entity Class’larını hatırlayınız).
- Yaygın nesne tabanlı tasarım yöntemlerinden bir tanesi, Sorumluluk Odaklı Tasarım’dır (Responsibility Driven Design). Bu yaklaşımın en çok kullandığı UML öncesi teknik CRC (Class Responsibility Card) çalışmalarıdır. Bu çalışmada yazılım ekibi class adları verilmiş küçük kartlara o class’ların sorumluluklarını sırasıyla yazar. Bu çalışma UML içinde, daha etkin bir biçimde Use Case Realization – Analiz/Tasarım Paketleri yapısıyla sağlanmaktadır.
- Derlediğimiz sorumluluklar çok farklı seviyerde olabilirler. Yine UML süreci kullanılıyorsa, buna da bir çare vardır. UML süreci içerisinde dikkatimiz sadece ilgili konulara ve detay seviyesine sınırlandırıldığından farklı detay seviyelerindeki bilgileri sıralarıyla derleriz ve bu sayede karmaşıklıklar azaltılır.
- Pek çok tasarım tekniğini kullanmak mümkündür. Bizler nesne tabanlı analiz ve tasarım açısından en önemlisi olan ve UML içine de iyice yer etmiş GRASP (General Responsibility Assignment Software Patterns) tekniklerini kullanacağız.
- Detaylı örnekler için aşağıdaki web sitesini ziyaret ediniz: http://www.dofactory.com/Patterns/Patterns.aspx
- [1] GRASP: Information Class’ların bir konuda (ve sadece bir konuda) uzmanlaşmış olmaları gerekir. Bu yüzden uzmanlık alanlarına göre sorumluluk ataması yapınız. Bu alanları saptamak için class’ın veri yapısına ve etkileşim içinde olduğu diğer class’lara verdiği hizmetlere (onların kullanmasına izin verdiği public metodlarına) bakınız.
- [2] GRASP: Creator İşini görmek için kompleks bir veri tipinin (class) oluşturulmasına ihtiyaç duyan ve muhtemelen aralarında parça bütün ilşkisi bulunan (aggregation veya composition) class’lar arasında tanımlanan bir metoddur.
- [3] GRASP: Low Coupling Class’ların tek başlarına yeterliliklerinin artırılmasıdır. Yine UML süreci sayesinde bir class’ın takım çalışmasıyla (Use Case Realizations – Analiz/Tasarım Paketleri) sorumluluklarının eksiksizleştirildiğini hatırlayınız.
- [4] GRASP: High Cohesion Class sorumluluklarının net bir odağa sahip olmalarını birbirleriyle olan alaklarını artırarak sağlamak. Class’ların birer utility class’ına dönmesini önler.
- [5] GRASP: Controller İş akışı bilgisinin bir class’a çekilmesidir (Control Class’ını hatırlayınız).
- [6] GRASP: Polymorphism Kolay class kullanımı için polimorfik bir yapı sağlayınız. İmplementasyon karmaşıklıklarını class’ın kullanıcılarından gizleyiniz.
- [7] GRASP: Pure Fabrication Gerekli görüldüğü durumlarda yeni bir katman oluşturmak için tanımlanan class’lardır. Örnek olarak verebileceğimiz veri erişimi katmanı gibi tamamıyla tasarım ihtiyaçlarına bağlıdırlar.
- [8] GRASP: Indirection Nesne etkileşimlerindeki class sayısını artırarak her işi birbiriyle birlikte yapan grupların sayılarını azaltmak.
- [9] GRASP: Don’t Talk to Strangers İşlerin birlikte ahenkli bir şekilde çalışan nesne gruplarınca yapılmasına dikkat ederek, tek başına her işi yapmaya çalışan class’ların oluşmalarını engelleyiniz. Aynı zamanda bir ‘komşuluk’ alanı oluşturarak, birlikte iş yapma kapsamını tahmin edilebilir hale getiriniz.
- İlham Kaynakları Christopher Alexander: www.patternlanguage.com Martin Fowler: www. martinfowler.com Peter Coad: www.pcoad.com Kelli Houston: www-306.ibm.com/software/rational/bios/houston.html Don Box: www.pluralsight.com/blogs/dbox/default.aspx Gang of Four: http://www.amazon.com/exec/obidos/tg/detail/-/0201633612/002-1957271-5861609?v=glance