Analiz modellerini doğrulama ve geliştirme: walkthrough, balancing, katmanlar

Analiz evresinin sonunda elinde üç model var: fonksiyonel (use case diyagramı, description’lar, activity diyagramları), yapısal (CRC, class, object diagram) ve davranışsal (sequence, communication, state machine). Bu modeller farklı kişiler tarafından, farklı zamanlarda çizildi. Tasarıma geçmeden önce iki soru sorulur: Her model kendi içinde doğru mu? Modeller birbiriyle tutarlı mı? Tutarsız modelle tasarıma geçmek, yanlış planla bina yapmaktır. Sınavda iki ya da üç model parçası verilir ve “find the inconsistencies” denir.

Altın kurallar:

1. Verification: modelleri doğru mu kurduk? Validation: doğru sistemi mi modelliyoruz?
2. Walkthrough hatayı bulur, düzeltmez.
3. Her şey bir yerden gelir ve bir yere gider: her sınıf bir use case’te geçer, her mesaj bir operation’dır, her event bir mesajdır.
4. Bir modeli değiştirirsen diğerlerini de güncelle.

Walkthrough

Walkthrough, bir modelin ekip tarafından adım adım gözden geçirilmesidir. Model, onu yapan kişi dışındaki gözlerle test edilir.

Kurallar:

• Amaç hata bulmak, düzeltmek değil. Düzeltme oturumdan sonra yapılır.
• Model değerlendirilir, kişi değil. Bu yüzden presenter’ın yöneticisi genelde katılmaz.
• Kullanıcılar katılırsa walkthrough aynı zamanda validation olur: “Bu sizin işinizi doğru anlatıyor mu?”
• Erken ve sık yapılır; hata ne kadar geç bulunursa o kadar pahalıdır.

Her modeli kendi içinde doğrulama

Fonksiyonel model:

• Use case diyagramındaki her use case’in bir description’ı var mı? Her description bir diyagram ovaline karşılık geliyor mu?
• Description’daki “relationships” alanı diyagramdaki include/extend/generalization ile aynı mı?
• Activity diyagramındaki her aksiyon bir description adımına karşılık geliyor mu (ve tersi)?
• Activity diyagramındaki her object node, description’larda geçen bir isme karşılık geliyor mu?

Yapısal model:

• Her CRC kartı bir sınıfa karşılık geliyor mu? Kartlardaki “collaborators” class diagram’da bir ilişki olarak var mı?
• Kartlardaki “knowing” sorumlulukları sınıfın attribute’ları mı, “doing” sorumlulukları operation’ları mı?
• Object diagram class diagram’daki multiplicity’leri ihlal ediyor mu?

Davranışsal model:

• Her sequence diyagramındaki mesajlar communication diyagramındakiyle aynı mı?
• State machine’deki her durum ve geçiş, nesnenin gerçek yaşam döngüsünü (description’larda anlatılan) yansıtıyor mu?

Modelleri dengelemek (balancing)

Üç model çift çift karşılaştırılır.

           Functional
          (use case,
           activity)
           /       \
          /         \
 Structural ------- Behavioral
 (CRC, class,       (sequence,
  object)            comm., state)

Fonksiyonel ↔ yapısal

Fonksiyonel ↔ davranışsal

Yapısal ↔ davranışsal

Çözümlü örnek: tutarsızlığı bul

Spor salonu sisteminden üç parça:

Use case description (Book Class), normal flow:

1. Member ders listesini görüntüler.
2. Member bir ders seçer.
3. Sistem üyeliği doğrular.
4. Sistem derste boş yer olduğunu kontrol eder.
5. Sistem rezervasyon oluşturur.
6. Sistem onay gösterir.

Class diagram (ilgili kısım):

Sequence diagram mesajları:

1 aMember -> :BookingCtrl : selectSession()
2 :BookingCtrl -> :ClassSession : listSessions()
3 :BookingCtrl -> :Member : verifyMembership()
4 :BookingCtrl -> :ClassSession : hasFreeSeat()
5 :BookingCtrl -> :Booking : create()
6 :BookingCtrl -> :Trainer : notifyTrainer()

Bulunan tutarsızlıklar:

Modelleri geliştirmek (evolving): tasarıma köprü

Doğrulanan modeller tasarıma hazırlanır.

Factoring

Ortak davranışı ayrı bir sınıf ya da modüle çıkarmak.

• Abstraction: ortak özellikleri üst sınıfa topla. Member ve Trainer’ın ad, telefon, e-posta attribute’ları → Person.
• Refinement: bir sınıfı özel alt sınıflara ayır. Membership → MonthlyMembership, AnnualMembership.

Partitions ve collaborations

Birlikte çok mesajlaşan sınıflar bir collaboration oluşturur ve bir partition (alt sistem) olarak gruplanabilir. Ölçüt: aralarındaki mesaj sayısı (CRUDE matrisi bunu gösterir). Rezervasyon, ders ve üyelik sınıfları birlikte çalışıyorsa “Booking” alt sistemi olur.

Paketler ve package diagram

Package, ilgili öğeleri (sınıflar, use case’ler) gruplayan bir kaptır. Package diagram paketleri ve aralarındaki dependency ilişkisini (kesik ok) gösterir.

+----------+     +-----------+     +----------+
|    UI    |- - >|  Domain   |- - >|   Data   |
+----------+     +-----------+     +----------+

Bağımlılık: Domain değişirse UI etkilenebilir. İyi tasarımda bağımlılıklar tek yönlü ve döngüsüzdür.

Katmanlar (layers)

Analizde sadece problem domain katmanı modellenir. Tasarımda diğer katmanlar eklenir; 12. hafta physical architecture katmanını ele alır.

Sık yapılan hatalar