Etkili Use Case Yazımı - Tavsiyeler

Cockburn'ün kitabından yaptığım özete devam ediyorum:

1. Her use case bir düz yazıdır (makale, prose)

İyi bir makale yazmak için geçerli olan bütün kurallar, use case yazımında da geçerlidir.

2. Kolay okunabilir yaz:

Use casei kimin için yazarız?

İnsanlar için. İnsanların kolay anlaması use caselerin kalite kriteridir. Use caseler kaliteli olmalıdır ki, nihai yazılım kaliteli olsun.

- Doğrudan amaca yönelik ve kısa olsun.
- İsim verirken, aktif fiillerle kullanıcı hedefini belirt.
- Aktif fiiller kullan

3. Tek cümle formu:

- Geniş zaman kullan
- Bir amacı gerçekleştiren bir aktörün dilinden yaz:

"Customer enters card and PIN."
"System validates that customer is authorized and has sufficient funds."
"PAF intercepts responses from the web site, and updates the user's portfolio."
"Clerk finds a loss using search details for "loss"."

Extensionların koşul kısmında farklı bir gramer biçimi kullan. Büyük oranda geçmiş ve : ile ayrılmış olsun.

"Time-out waiting for PIN entry:"
"Bad password:"
"File not found:"
"User exited in the middle:"
"Data submitted is not complete:"

4. Alt use caseleri metnin içine dahil et

Extends ve specializes özelliklerini kullanmaktan kaçın. Karışıklığa sebep oluyor. Normalde nasıl yazacak idiysen öyle yaz:

"Clerk finds a loss using search details for "loss"."

Finds a loss, alt bir use casedir.

5. Hedef seviyesini iyi ayarla

Deniz seviyesindeki amaçların özellikleri:

- Tek kişi tarafından tek yerde ve zamanda yapılır (2-20 dakika)
- İş bittiğinde aktör mutlu olarak ayrılabilir.
- Çok sayıda yaparsa, zam isteyebilir.

9´dan fazla adım varsa, adımları azalt.

- Kullanıcı hareketleri
- Benzer işler (veri girişi)
- Niçin bunu yapıyor?
- İki aktör arasında çok sayıda gidip gelme. Bu tarz bir müzakere sürecinin amacı nedir?

6. GUI´yi dışarıda bırak

- Doküman çok uzar.
- Kırılgan ve değişmeye çok müsait hale gelir.
- GUI kararları erkenden alınmış olur.

Kötü örnek:

2. The system displays the Login screen with fields for username and password.
3. The user enters username and password and clicks ’OK’.
4. The system verifies name and password.
5. The system displays the Main screen, containing function choices.
6. The user selects a function and clicks ’OK’.

7. Başarısızlık durumu

Başarısızlık durumu bütün alt use caseler için de ele alınmalı. Eğer alt use case, ana senaryodan çağrıldıysa, başarısızlık alternatif senaryolar kısmında ele alınır. Eğer alternatif akış içinde ele alındıysa, aynı yerde başarısızlık durumu da çözülür.

8. Bütün paydaşların (stakeholders) korunması:

Bir use case sadece ana aktörün (primary actor) amacına hizmet etmez. Bütün paydaşların beklentilerine hizmet etmeli. Eğer öyle olsaydı zaten, o zaman sadece kullanıcı etkileşimi tarif edilirdi.

Kullanıcı use casei sürer, ancak use case bütün paydaşların beklentilerini (garanti) karşılar.

- Ana aktörün amacı, use casein ismidir.

- Şirketin amacı, ödediği şeyin karşılığını almak.

- Düzenleyici kurum: Şirketin yönetmelikleri uyguladığı. Bir tür log tutulması.

- Paydaşlardan biri, hata durumunda kurtarmaya yönelik amacı vardır. Bu yüzden daha çok log ister.

Son koşullar (guarantees) kısmı, bütün paydaşların beklentilerinin nasıl karşılandığını ifade eder.

Son koşulları, ana senaryodan önce yazmakta fayda var. Çünkü bu sayede senaryo sırasında kimlerin hangi beklentilerini karşılamak gerektiği daha kolay ortaya çıkar.

10. Önkoşullar:

En yaygın önkoşullar, kullanıcının login olması ve yetkili olmasıdır.

Başka önemli bir önkoşul da, bir use casein bir başka use casede sağlanan koşula dayanmasıdır. Mesela bir use casede kullanıcı bir ürünü seçer. İkincisinde bu seçilmiş ürünün bilgisi işlenir.

Dolayısıyla ne zaman ki bir önkoşul varsa, daha üst seviye bir use case vardır.

11. Çek listesi:

İyi bir use casein sağlaması gereken özellikler:

- Use case başlığı: Aktif bir fiil cümlesi mi? Ana aktörün amacını mı ifade ediyor? Sistem bu amacı yerine getiriyor mu?

- Kapsam ve sevyie: Kapsam ve seviye alanları dolduruldu mu?

- Kapsam: Eğer use case bir srs dokümanıysa "kara kutu" olmak zorunda.

- Ana aktör: Ana aktörün davranışı var mı?

- Önkoşullar: Use case içinde hiç kontrol edilmiyorlar, değil mi?

- Paydaşlar: Onlardan hiç bahsediliyor mu?

- Sonkoşullar: Bütün paydaşların beklentileri karşılanıyor mu?

- Asgari garanti: Bütün paydaşların menfaatleri korunuyor mu?

- Ana senaryo: Tetikleyiciden mi başlatılıyor? Adım sırası doğru mu? 3-9 adım arası mı?

- Senaryodaki her adım: Bir amaç ifade ediyor mu? Hangi aktör tarafından yapıldığı belirtiliyor mu? Aktörün amacı açık mı? Amaç seviyesi, use casein amaç seviyesinden tam bir seviye mi düşük? Kullanıcı etkileşimini ifade etmiyor değil mi? Hangi bilginin aktarıldığı açık mı? Adım, "onaylama" yapıyor mu, bir koşulun "kontrol edilmesi" yerine?

- Alternatif adım koşulu: Sistem bunu tespit edebiliyor mu? Sistem bunu ele almak zorunda mı?

- Genel içerik: Sponsor ve kullanıcılara: "Bu sizin istediğiniz şey mi?" "Teslimattan sonra, bunu alıp almadığınızı söyleyebilecek misiniz?" Geliştiricilere: "Bunu gerçekleştirebilir misiniz?"

12. Sürekli açılan bir hikaye

Birçok projede en üst seviyede bir use case tanımlanır: "XXX Sistemini kullan". Bu aslında çok sayıdaki use casei toplayan bir içindekiler tablosu gibidir. Bu use caselerin arasındaki ilişkileri gösterebilir.

İnsanlar bir başlangıç noktası olarak böyle en üst seviye bir use case tanımlamayı faydalı buluyor.

Deniz seviyesindeki use caselerden bir alt seviyeye inince, daha derindeki indigo (lacivert) use caselere erişiriz. Bunlar genellikle sofistike bir adımın kendi başına tanımlanması şeklindedir. Müşteri bul, ürün bul gibi use caseler bu tarz alt fonksiyonlar olarak tanımlanabilir.

Ancak her use casein bakım maliyeti vardır. Bu yüzden bunlarda mümkün olduğunca tutumlu olmak lazım.

Prensip olarak alt seviye use caseler istenildiği kadar derinleştirilebilir.

13. İş kapsamı ve sistem kapsamı

Bir sistemin tasarımında sınırları belirlemek çoğu zaman muğlaklık içerir.

Use caseler tanımlanırken, özellikle, iş use caseleriyle (business) sistem use caseleri arasındaki ayrım net olmalı.

İş use casei, iş operasyonlarıyla ilgilidir. Bir iş akış şemasında, bir sürecin baştan sona gösterilmesindeki use caselerdir. Dolayısıyla iş use casei, otomasyon sisteminin içinde değildir. Sadece belirli adımları otomasyona dahildir.

İş use casei, açık kutu formunda ifade edilir. Sistem use casei ise kapalı kutu.

14. Temel değerler ve farklılaştırmalar

Bir konferansta iki makale, bir düzine kadar önemli hatayı özetledi. Bu makalelerde belirtilen temel değerler şunlardı:

- Amaç temellilik. Use caseler, ana aktörün amaçları ve diğer aktörlerin alt amaçları etrafında oluşur.

- Kuş bakışı perspektifi. Use case, sistemı kuş bakışıyla tasvir eder. İçeriden bir bakışla değil.

- Okunabilir. Use casein veya herhangi başka bir spesifikasyonun nihai amacı insanlar tarafından anlaşılmasıdır. Eğer insanlar kolaylıkla dokümanı anlayamazsa, doküman esas amacını gerçekleştiremez. Bu yüzden gerektiğinde hassasiyetten ve belki hatta doğruluktan bile bir miktar fedakarlık edilebilir. Bu açığı, daha fazla iletişim ve diyalogla kapatırsınız. Ancak eğer ki okunabilirlikten fedakarlık yaparsanız, yazılım geliştiricileriniz/müşterileriniz/yöneticileriniz onları okumaz.

- Çok çeşitli amaçlara hizmet eder.

- Kapalı kutu fonksiyonel ihtiyaçlar

- İş sürecinin yeniden tasarımının ihtiyaçları

- Süreç dokümantasyonu

- İhtiyaçların ortaya çıkarılması ve onaylanması için bir araç

- Test vakalarının belirlenmesi

- Sistemin iç yapısının dokümantasyonu

- Bir tasarım çerçevesinin davranışının dokümantasyonu

- Kapalı kutu ihtiyaçlar. Use caselerin açık kutu ihtiyaçların tanımlanmasında kullanılması durumunda, okunabilirlik düşüyor, daha kırılgan oluyor.

- Alternatif yollar, ana senaryodan sonra. Alternatif yolları, ana senaryonun içine yerleştirmek, anlaşılmayı güçleştiriyor. Jacobson´ın orjinal modeli, daha faydalı.

- Az enerji harcamak. Sürekli olarak use caseleri inceltmeye çalışmak, çok değer eklemiyor. İlk taslak, değerin yarısını zaten inşa ediyor. Cümlelerin ifade ediliş şekli gibi detaylarla oynamak, iletişimi kötüleştiriyor bile. Bunun yerine iş kurallarının tanımlanması, kullanıcı arayüzlerinin, harici arabirimlerin kontrolü gibi diğer ihtiyaçlarla ilgilenmek daha faydalı olur. Tabi ki, projenin kritikliği de inceltme noktasında önemli bir karar kriteri.

Değişebilecek noktalar:

- Numaralanmış adımlar veya basit paragraflar. İnsanlar hangisiyle daha rahat çalışıyorsa, o tercih edilmeli.

- Tam doldurulmuş veya serbest yazılmış. Bazı zamanlar fonksiyonel ihtiyaçların eksiksiz bir şekilde detaylandırılması doğrudur, bazen hafif olarak doldurulması yeterlidir. Dolayısıyla use case şablonları da mutlak bir şekilde dikte edilmemeli.

- Ön iş modellemesi, use caselerle veya use caselersiz. İş sürecinin dokümantasyonu, sistemin fonksiyonel ihtiyaçlarının tanımlanmasından önce de olur, sonra da.

Uygunsuz noktalar:

- Ana başarı senaryosunun içinde "eğer" cümlelelri

- Use case metni yerine, sequence şemaları. Sequence şemaları, use case metninin yerine geçemez. Çünkü,

- okunması daha zordur (özel bir notasyon içerir)
- paydaşların beklentilerinin korunup korunmadığını ifade etmez.
- Okların üzerine yeterli metin yerleştirmek imkansızdır
- Metnin bir pop-up diyalog kutusuna yazılmasını gerektirir. Bu da hikayenin takibini zorlaştırır.

- GUI detaylarının fonksiyonel spesifikasyonlarda yer alması. Bunun yanlışlığı konusunda genel bir uzlaşma vardır.

16. Use caseler sadece bir chapterdır.

Başka chapterlar da var, ihtiyaç analizinde ele alınması gereken: Veri tanımları, iş kuralları, kullanıcı arayüzü tasarımı, iş alanının modeli ve sair. Use caseler bunların hepsinin merkezindeki bir çekirdek gibi.

Bu çok önemli bir nokta. Çünkü çok sayıda ekipte, use caseler ihtiyaç analizinin tümünü içeren bir parça olarak ele alınıyor.

17. Önce genişlik.

Genişlik, derinlikten önce gelir. Düşük hassasiyetten, yüksek hassasiyete doğru gidilmeli. Bu enerjinizi daha verimli yönetmenizi sağlayacak. Şu sıra ile çalışın:

1. Baş aktörler. Bütün baş aktörleri tespit edin. Beyin fırtınası...

2. Amaçlar. Bütün baş aktörlerin bütün amaçlarını listelemek, bütün sistemin tek bir seferde görünmesini sağlamak için son şans olacaktır. Bu listenin tam ve doğru olması için yeterli zaman ve enerjiyi harcamanın getirisi çok olacaktır.

3. Ana başarı senaryosu. Ana senaryo genellikle kısa ve çok açıktır. Alternatif akışları ortaya koymadan önce ana senaryo bir ortaya çıkmalı.

4. Hata ve genişletme koşulları. Nasıl ele alınacaklarının tespit edmeden önce, hangi farklılaşma koşulları olabilir, bunları tespit etmek önemli. Bu da yine bir beyin fırtınası etkinliğidir, araştırmadan ziyade.

5. Düzeltme davranışı. Hata koşullarının ne olacağını önce tespit etmeli. Sonra bunların nasıl düzeltileceği belirlenmeli.


18. 12 adımlık reçete:

1. Sistemin sınırlarını bul
2. Baş aktörleri beyin fırtanası ile listele.
3. Baş aktörlerin amaçlarını beyin fırtanası ile listele.
4. En üst seviye özet use caseleri yaz.
5. Stratejik use caseleri değerlendir ve gözden geçir.
6. Malzemeyi daha iyi anlamak için, bir use casei al ve hikayesini yaz.
7. Paydaşları, menfaatlerini (interest), önkoşullarını ve sonkoşullarını yaz.
8. Ana başarı senaryosunu yaz. Menfaatler ve sonkoşullarla kıyasla.
9. Beyin fırtınası ile, bütün hata ve alternatif başarı koşularını listele.
10. Aktörlerin ve sistemin her alternatifte nasıl davranacağını yaz.
11. Alt use caseleri ayır.
12. En üstten başla ve use caseleri yeniden ayarla. Ekle, çıkar, birleştir. Tamlığı, okunabilirliği ve hata koşullarını gözden geçir.

19. Hataların maliyeti.

Her projenin hassasiyet seviyesi, o proje takımındaki iletişim seviyesine ve projenin kritikliğine bağlıdır. Mesela Chrysler Bordrolama programında, kısa use caseler yeterli olmuştu. Çünkü müşteriyle yazılımcıların arasındaki iletişim çok yüksekti.

20. Blue jeanler tercih edilir.

Kulağa tuhaf gelse de, daha az yazmanın zararı daha çok yazmaya göre daha düşüktür. Eğer şüpheye düşüyorsanız, daha az metin yazın. Daha üst seviye amaçları kullanın. Hassasiyeti düşürün. Böylece kısa ve okunabilir bir dokümanınız olur. İnsanlar, okuyunca, sorularını sorar.

Eğer çok uzun yazarsan, insanlar okumaya üşenecektir. Takım içindeki iletişim azalacaktır.

Bu çok sık yaşanan bir sorundur.

21. Hataları ele al.

Use caselerin en büyük değerlerinden biri, alternatif koşulları isimlendirmektir. Hataları tanımlamak ve bunların nasıl ele alınacağını incelemek, çoğu zaman sistemle ilgili bilinmeyen birçok şeyi (aktörleri, amaçlarını, iş kurallarını) ortaya çıkaracaktır.

Hemen hemen her programcı şöyle bir şeyi yaşar:

If (condition)
    then 
    else ..?.

else kısmına gelince durur. "Bu durumda ne yapılacak?" Hemen kendisi bir şey tahmin eder ve onu kodlar.

Halbuki else kısmında yazılması gereken şey, ihtiyaç dokümanında belirtilmiş olmalıydı.

22. İş ünvanları erken ve geç

İş ünvanları projenin başlangıcında da sonunda da önemlidir. Ama ortasında değil.

İş ünvanlarını başta ortaya çıkararak, sistemin gerçekleştirmesi gereken amaçları ortaya çıkarırsın.

Projenin sonunda yine önemli hale gelir. Çünkü izin seviyelerini ayarlamak, eğitim malzemelerini hazırlamak, paketlemek bu aşamada olur.