Merhaba, Tek kişiklik bir yazılım ekibiyim :) Deneysel olarak başlayacağım projede XP tekniklerini kullanmak istiyorum. Bolca okududum ve araştırdım ve kafam oldukça karışık.

Use case diagramı çizmek ve senaryoları oluşturmak istiyorum. Başlangıçta tüm sistem yerine sadece kodlayacağım bölümü modellemek istiyorum. Örneğin kullanıcı girişi için bir model, fatura kesme işlemi için ayrı bir model oluşturup ayrı ayrı bunların kullanım senaryolarını oluşturmak istiyorum. Bu doğru bir yaklaşım mı?

Ayrıca use case senaryoları XP ortamında sanırım kullanıcı hikayeleri (user story) olarak isimlediriliyor. Bu ikisini nasıl bağdaştırabilirim. Kısaca nasıl başlarım? Eksik veya yanlış bir soru olduysa kusura bakmayın bir çok kavram halen havada olduğundan kafamda bir netlik oluşturamıyorum.

soruldu: 07 May '15, 10:04

zafer's gravatar image

zafer
41591019
cevap kabul oranı: 11%


Merhaba, öncelikle "UML Design" ile ilgili tutorial okumanı tavsiye ederim. UML Design temel olarak use-case, activity diagram, sequence diagram, class diagramlardan oluşur. Doğru ve tam olarak anlaşılabilir bir yapı için hepsinin tam ve eksiksiz oluşturulması önemlidir. Use-case bu diagramların ilk aşamasını oluşturur dolayısıyla use-caselerden direk olarka kodlama kısmına geçmen doğru bir yöntem olmaz. Use- Case'lerin temel görevi programın doğru akışını, özelliklerini anlatmaktır. Örneğin, Kullanıcı Girişi için oluşturduğum bir use-case atayım.

Login Use-Case Bu use-case'de Get UserName, Get Password olmadan da anlaşılabilir ama ben daha iyi anlaşılabilmesi için ekledim. extend "Return to beginning" de aynı şekilde. Bunların yanı sıra altta not biçiminde akış ve sırası ayrıca alternate flow'lar var.

Aynı şekilde bu bölümün activity diagramı da şu şekilde : alt text

Gördüğün gibi Activity Diagram programatik terimlere daha yakın ve daha detaylı bir anlatım yapıyor.

Class Diagramları şu şekilde :

Servera istek yollayan sınıf alt text

İlgili view sınıfı :

alt text

Localization vb. için de bir sürü sınıf yer alıyor, bu sınıf diagramları "Login Use-Case"inin tamamlanması için gerekli ögelerin bir kısmı. Burda da görüldüğü gibi birbirinden iyi izole edilmiş bir mimaride bir use-case için birden çok sınıf gerekiyor. Dolayısıyla use-case'lerden direk olarak kodlamaya geçmek sizi bir süre sonra değişimlere izin vermeyen, zor okunabilen ve burnu aşağıya doğru eğilmiş bir yapıyla/uygulamayla başbaşa bırakıcaktır. Öncelikle oturup üzerine bayağı kafa yormanız lazım, çeşitli patternları denemeniz en doğru olanı seçmeniz lazım. Bu süreci XP'ye uygun hale getirmek için de ben şöyle bir yöntem izledim, XP'de bahsedilen en önemli şeylerden biri de "small releases" kısmıdır. Bunu sağlayabilmek için uygulamanın tek modülünü tasarlayın, örneğin sadece User Register, Edit, gibi kısımları yazın. Bu kısımı tasarlarken öteki kısımlarda kullanıcağınız şeyleri de düşünün ona göre bir mimari oluşturun. Bunların yanı sıra BDD yöntemini de araştırın, o yöntem de çok işinize yarıyıcaktır. Umarım kafanızdaki soruları bi miktar giderebilmişimdir :)

permanent link

cevaplandı: 08 May '15, 11:54

ArnesTwin's gravatar image

ArnesTwin
1.1k1511
cevap kabul oranı: 14%

değiştirildi: 08 May '15, 11:57

Öncelikle çok çok teşekkür etmek isterim. Elinize sağlık. Aslında benim soruma son paragrafta cevap vermişsiniz. Bende projemi parça parça tasarlayabilirmiyim diye sormak istemiştim. Kullanıcı girişi, müşteri işlemleri gibi modüllere ayırıp bunları ayrı ayrı geliştirmeyi düşünüyorum. Ben mühendis değilim, kullandığım teknikleri daha çok bana sağladığı fayda/maliyet analizine göre seçmeye çalışıyorum.

(11 May '15, 04:06) zafer zafer's gravatar image

Use-case'leri sevdim. Ancak use-case ve activity bana fazla ikisini birleştirip deha detaylı "Gereksinim Senaryoları" oluşturmayı düşünüyorum. Bu senaryolar aynı zamanda birim testlerim için rehber olacaklar.

Eğer Ankara'daysanız sizinle tanışmayı, görüşmeyi çok isterdim. Çok değerli bilgilere haizsiniz. Tekrardan teşekkürler ;)

(11 May '15, 04:06) zafer zafer's gravatar image

Modüllere ayırıp geliştirebilirsiniz, yalnız burda şu nokta çok önemli, sizin uygulamayı modüllere ayırabilicek mimariyi oluşturmanız gerekli. Bunun için "design patterns"ları iyice araştırmanız gerekli. "N-Tier Application", "Decoupling", "Loosely-Decoupled" gibi keywordleri araştırıp, iyice anlarsanız size bayağı yardımcı olur. Ankara'da oturuyorum, beklentiniz biraz farklı olabilir ama öğrenciyim, eğer görüşmek isterseniz benim için uygundur. Bi de son olarak sorunuzun cevabını aldıysanız cevaplandı olarak işaretlerseniz sevinirim.

(11 May '15, 04:22) ArnesTwin ArnesTwin's gravatar image

Kusuruma bakmayın son mesajınızı yeni fark ettim. Benim herhangi bir beklentim yoktu. Fikirleri benimle aynı kişilerle görüşmek, tanışmak ve ufkumu dahada geliştirmek benim için her zaman ilginç bir deneyim olmuştur. Elbette görüşmeyi çok isterim.

(18 May '15, 11:01) zafer zafer's gravatar image

Yok ne kusuru, Kişisel websitenizden mesaj attım :)

(20 May '15, 14:35) ArnesTwin ArnesTwin's gravatar image

Merhabalar gerçekten detaylı ve açıklayıcı bir cevap olmuş.

(25 May '15, 07:28) caglarturkurka caglarturkurka's gravatar image

Merhaba :) Benimde bu konuda bir sorum vardı ve sizin cevaplarınızı görünce benim soruma çok yakın olduğu için size danışmak istedim :) Yardımcı olursanız sevinir.Bir app uygulaması için iş akış şeması çizmem lazım user olarak bakıldığında kayıtlı ise devam database kaydet,değil ise sign in aşamalarını oluştur gibi bir uygulama girişi olacak ve bunu daha nasıl anlaşılır ve nasıl türetebilirim ? Bu şekili nasıl çizmeliyim ? Teşekkürler.

(15 Haz '15, 14:25) secrett secrett's gravatar image
1

Use caselerde <<extend>> alternatif akışları belirtir. Yani örneğin sizin programınızın normal akışında dediğiniz gibi kullanıcı geldi, kayıtlı olduğu için "devam database kaydet" kısmı yapılıyorsa, kayıtlı olmama durumu alternatif bir akıştır. Benim diyagramımdaki ilk diagramdaki
"2) Return to beginning" olan yeri " Sign in aşamalarını oluştur " şeklinde değiştirirseniz muhtemelen istediğinizi yaptırmış olursunuz. Tabi şunu da söyleyim, use-case illa böyle illa şöyle olur gibi kural da yok. Sadece yaygın ve ortak kullanımları var ve onlar da yukarda belirttiğim şekilde :)

(15 Haz '15, 17:14) ArnesTwin ArnesTwin's gravatar image

Sizin örneğinizden de yararlanarak bir flowchart oluşturdum.Buradan nasıl gönderebileceğimi bilmiyorum.Sizin de görmenizi isterim bir hata var mı diye.Umarım yaptığım doğrudur.Teşekkür ederim.

(16 Haz '15, 08:20) secrett secrett's gravatar image

Tamamdır bakarım. İsterseniz mail atın burayı kirletmeyelim :) ozancansel@gmail.com

(19 Haz '15, 09:17) ArnesTwin ArnesTwin's gravatar image
10 yorumdan 5 tanesi gösteriliyor hepsini göster

Merhabalar ilk önce ilk sorunuzdan başlayacak olursak yani modül modül tasarlama fikri, bu genel olarak mühendislik kavramına uymuyor. Çünkü bir ev projesi düşünürsek biz bunun önce 2. katını tasarlayıp oluşturup sonra 1. katını oluşturup yerleştirmiyoruz. Bunun gibi yazılım alanında da diğer mühendislik alanları gibi adım adım gitmek en doğru sonucu bize sunacaktır. Yani yazılım hayat döngüsü kavramına bakacak olursak;

Gereksinim belirleme - Analiz - Sistem Tasarımı - Nesne Tasarımı - Uygulama - Test

olarak ilerlediğini görürüz yani sadece use-case'ler ile de uygulama kısmına geçmek doğru bir yaklaşım olmaz. İlk önce problemin ne olduğu anlaşılır sonra nasıl bir çözüm sunulacağı belirlenir, sonra gereksinimler çıkartılır(fonksiyonel & fonksiyonel olmayan). Daha sonra kullanım senaryoları oluşturulur. Bu senaryolardan aktörler ve eylemler tespit edilir. Sonra tespit edilen aktörlere görevleri diyagram üstünde gösterilir(Use-Case). Daha sonra yapısal model ve dinamik model adımları gelir. Yani sınıf diyagramı - durum diyagramı, sequence diyagram ve aktivite diyagramları oluşturulur. Bu kısıma olan eylemler projenin her alanında faydalanılır. Yani Sistem tasarımında, nesne tasarımında, uygulama kısımında ve test kısmında oluşturduğumuz diyagamlar ve senrayolar çok önemli görevler görürler. Mesela test kısmında neye göre test yapılacağı senaryodan belli olur, çünkü sistemin ne gerçekleştirmesi gerektiği test yapan arkadaşın hangi durumlara göre hangi girdileri verip hangi çıktıları beklemesi gerektiğini belirler. Yani tüm sistemi tasarlamadan modül modül gitmek size maliyet olarak geri döner.

  1. sorunuzun cevabı da sanırım üstte var. Ama tekrarlarsak; kullanıcı senaryoları (hikayeleri) yazmak bize sistemde hangi aktörler görev alacak ve bu aktörlerin ne görevi olacak belirlememizi sağlar. Bunu Use-Case diyagramı ile birleştirme işlemi de burada gerçekleşir aktörler çizilir ve görevleri bağlanır.

Biraz uzattım sanırım... Umarım sorunuza cevap olmuştur.

permanent link

cevaplandı: 09 May '15, 19:47

frknkntr's gravatar image

frknkntr
62681122
cevap kabul oranı: 26%

1

Söylediğiniz yöntem "Traditional" bir yöntem. Zaten XP'nin ortaya çıkma amacı da bu yönteme farklı bir bakış açısı getirmek, mevcut olanları derleyip toplamak ve bazılarında değişiklikler yapmak. Örneğin, Test aşamasını uygulama kısmından önceye alır. Bütün sistemi tasarlamak yerine "small release"leri tercih eder. Ben XP'yi şu anda uygulamamda kullanıyorum, "a magic wand" olmadığı gibi, doğru yöntemlerle ve uygun patternlarla oluşturulduğu zaman gerçekten çok güçlü, kolay değiştirilebilir bir mimari oluşturuyor.

(10 May '15, 05:54) ArnesTwin ArnesTwin's gravatar image

Evet hocam haklısınız ben XP yöntemlerine göre cevaplamamışım soruyu şimdi dikkat ettim bilgilendirdiğiniz için teşekkürler.

(10 May '15, 07:34) frknkntr frknkntr's gravatar image
Cevabınız
toggle preview

Bu soruyu takip et

E-Posta üzerinden:

Üyelik girişi yaptıktan sonra abonelik işlemlerini yapabilirsiniz

RSS üzerinden:

Cevaplar

Cevaplar ve Yorumlar

Yazı Formatlama

  • *italic* ya da _italic_
  • **bold** ya da __bold__
  • link:[text](http://url.com/ "başlık")
  • resim?![alt text](/path/img.jpg "başlık")
  • liste: 1. Foo 2. Bar
  • temel HTML etiketleri de kullanılabilir

Bu sorunun etiketleri:

×2
×2
×2
×1

Soruldu: 07 May '15, 10:04

Görüntüleme: 741 kez

Son güncelleme: 19 Haz '15, 09:17

powered by BitNami OSQA