YAZILIM MÜHENDİSLİĞİ - 2

Transkript

1 YAZILIM MÜHENDİSLİĞİ - 2 BÖLÜM 12: NESNE-TABANLI ANALİZ (OBJECT-ORIENTED ANALYSIS) Bölüm Kapsamında İncelencek Konular: Analiz iş akışı Entity sınıfların çıkartılması Nesne-tabanlı analiz: Asansör problemi örnek olay incelemesi İşlevsel modelleme: Asansör problemi örnek olay incelemesi Entity sınıf modelleme: Asansör problemi örnek olay incelemesi Dinamik modelleme: Asansör problemi örnek olay incelemesi Test iş akışı: Nesne-tabanlı analiz Boundary ve control sınıfların çıkartılması İlk işlevsel model: MSG Vakfı örnek olay incelemesi Başlangıç sınıf diyagramı: MSG Vakfı örnek olay incelemesi Başlangıç dinamik modeli: MSG Vakfı örnek olay incelemesi Boundary sınıfların çıkartılması: MSG Vakfı örnek olay incelemesi Control sınıfların çıkartılması: MSG Vakfı örnek olay incelemesi Use case leri iyileştirme: MSG Vakfı örnek olay incelemesi Use-case leri gerçekleştirme: MSG Vakfı örnek olay incelemesi Sınıf diyagramlarını arttırma: MSG Vakfı örnek olay incelemesi Birleştirilmiş Süreçte şartname dokümanı Use case lerin ve aktörlerin daha fazlası Nesne-tabanlı analiz iş akışı için CASE araçları Nesne-tabanlı analiz iş akışının sorunları

2 NESNE-TABANLI ANALİZ (OBJECT-ORIENTED ANALYSIS) Nesne-Tabanlı Analiz, nesne-tabanlı paradigm için yarı resmi bir analiz tekniğidir. Nesne-Tabanlı Analiz, nesne-tabanlı paradigm ın bir anahtar bileşenidir. 11. Bölümde yapısal sistem analizi için birbirine eşdeğer birçok teknik olduğunu söylemiştik. Benzer olarak; Nesne-Tabanlı Analiz içinde birbirine eşdeğer 60 ın üzerinde teknik ve metodoloji vardır. Günümüzde, Birleştirilmiş Süreç (Unified Process) en geçerli alternatif metodolojidir. Birleştirilmiş Süreç in (Unified Process), nesne-tabanlı analiz tekniklerinden en iyisi olduğu iddia edilir. Bu iş akışı esnasında sınıfları (classes) tespit edip, ortaya çıkarıyoruz. Bu sınıfların (classes) birbirleriyle olan ilişkilerini UML diyagramları ile göstereceğiz. Use case ler ve sınıflar nesne-tabanlı bir yazılım ürünü geliştirmek için temeldir

3 ANALİZ İŞ AKIŞI (THE ANALYSIS WORKFLOW) Analiz iş akışının iki hedefi vardır; Gereksinimlerin (requirements), daha derin anlaşılmasını sağlamak, Sürdürülebilir bir tasarım (design) ve gerekleştirmeyi (implementation) sağlayacak şekilde bu gereksinimleri tanımlamak. Birleştirilmiş Süreç (Unified Process), use-case lere dayalıdır. Nesne-tabanlı analiz iş akışı esnasında, use case ler yazılım ürünün sınıfları olarak tanımlanmaktadır. Birleştirilmiş Süreç (Unified Process) üç tip sınıfa sahiptir: Entity sınıflar, Boundary sınıflar, Control sınıfları

4 ENTITY CLASS Uzun süre kullanacağımız bilgileri modellerken kullandığımız sınıflardır. Örnekler: Bir banka yazılım ürününü düşünelim. Burada entity sınıfa örnek olarak Hesap Sınıfı (Account Class) nı verebiliriz. Çünkü hesap bilgileri yazılım ürünü içinde uzun süre kullanılmaktadır. Bir başka örnek olarak da MSG Vakfı yazılım ürünündeki Yatırım Sınıfı (Investment Class) nı verebiliriz. Burada da yatırım bilgileri yazılım ürünü içinde uzun süre kullanılmaktadır

5 BOUNDARY CLASS Yazılım ürünü ile ortam arasındaki etkileşimi modeller. Genellikle giriş/çıkış ve raporlama işlemleri ile ilişkilendirilmiş sınıflardır. Örnekler: MSG Vakfı yazılım ürününde, Vakıf çalışanı yatırımların listesini ve mortgage kredilerinin listesini bir rapor olarak alabilmekteydi. Bu yazılım ürününü göz önüne bulundurduğumuzda; Investments Report Class ve Mortgages Report Class bizim için boundary sınıflardır

6 CONTROL CLASS Karmaşık işlemlerin ve algoritmaların yürütüldüğü sınıflardır. Örnek: MSG Vakfı yazılım ürünü içinde, haftalık kullanılabilir birikimleri hesaplamak ve tahmin etmek için control sınıfı olarak; Estimate Funds for Week Class ı verebiliriz. Bu Üç Sınıf (Class) Tipi için UML Gösterimi - 6 -

7 ENTITY SINIFLARIN ÇIKARILMASI Entity sınıfların çıkarılması, iterative ve incremental olarak uygulanmış üç adımı içerir: İşlevsel Modelleme (Functional Modeling) Use case lerin tamamı için senaryolar hazırlanıp, sunulur. (Senaryo use case in bir örneğidir.) Sınıf Modelleme (Class Modeling) Entity sınıflar ve bu entity sınıfların nitelikleri (attributes) belirlenir. Entity sınıflar arasındaki etkileşimler ve karşılıklı ilişkiler belirlenir. Bu bilgiler sınıf diyagramları (class diagram) içinde sunulur. Dinamik Modelleme (Dynamic Modeling) Her bir entity sınıf tarafından icra edilen işlemler belirlenir. Bu bilgiler de durum diyagramı (statechart) ile sunulur

8 NESNE-TABANLI ANALİZ: ASANSÖR PROBLEMİ ÖRNEK OLAY İNCELEMESİ m katlı bir binada n tane asansörü kontrol etmek için bir yazılım ürünü ayarlanmıştır. Problem aşağıdaki kısıtlara göre katlar arasında asansörleri hareket ettirmek için gerekli mantık ile ilgilidir. 1. Her bir asansör, her kat için bir m tane düğmeye sahiptir. Bunlar, basılı olduğu zaman ışığı yanar ve asansörün ilgili kata çıkmasını sağlar. Asansör ilgili kata geldiğinde düğmenin ışığı söner. 2. Giriş katı ve en üst kat hariç, her bir kat iki düğmeye sahiptir, bu düğmelerden biri asansörü aşağı istemek için, diğeri ise asansörü yukarı istemek içindir. Bu düğmeler, basılı olduğu zaman yanar. Asansör istenen yönde hareket eder ve asansör kata geldiğinde düğmenin ışığı söner. 3. Eğer asansör için hiçbir istek yoksa kapıları kapalı bir şekilde bulunduğu katta kalır

9 İŞLEVSEL MODELLEME: ASANSÖR PROBLEMİ ÖRNEK OLAY İNCELEMESİ Use case, bir yazılım ürünü (product) ile bu yazılım ürününün kullanıcıları (actors) arasındaki etkileşimi modeller. USE CASE LER Asansör problemi için, sadece iki olası use case vardır; Press an Elevator Button Press a Floor Button - 9 -

10 SENARYOLAR Use case bütün işlevselliğin genel bir tanımını verir. Senaryo use case in bir örneğidir. Modellenecek olan hedef yazılım ürünü hakkında kapsamlı bir görüşe sahip olmak için yeterli miktarda senaryo yazılmalı ve onlar üzerinde çalışılmalıdır

11 ASANSÖR PROBLEMİ İÇİN NORMAL SENARYO 1. A kullanıcısı, 3. cü katta asansör çağırmak için Yukarı kat düğmesine basar. A kullanıcısı 7. ci kata çıkmak istemektedir. 2. Yukarı kat düğmesi yanar. 3. Asansör 3. cü kata varır. Asansörün içinde, asansöre 1. ci katta binmiş ve 9. cu kata çıkmak için asansör düğmesine basmış B kullanıcısı vardır. 4. Asansörün kapıları açılır. 5. Zamanlayıcı (timer) başlar. A kullanıcısı asansöre girer. 6. A kullanıcısı 7. ci kata çıkmak için asansör düğmesine basar. 7. Asansör düğmesi 7. ci kat için yanar. 8. Asansör kapıları zaman bitimi kapanır. 9. Yukarı kat düğmesi söner. 10. Asansör 7. ci kata gider. 11. Asansör 7. ci kata geldiğinde, asansörün 7. ci kat düğmesi söner. 12. A kullanıcısının asansörden dışarı çıkması için asansörün kapıları açılır. 13. Zamanlayıcı (timer) başlar. A kullanıcısı asansörden dışarı çıkar. 14. Asansör kapıları zaman bitimi kapanır. 15. Asansör B kullanıcı ile 9. cu kata çıkmak için ilerler

12 ASANSÖR PROBLEMİ İÇİN İSTİSNAİ SENARYO 1. A kullanıcısı, 3. cü katta asansör çağırmak için Yukarı kat düğmesine basar. A kullanıcısı 1. ci kata gitmek istemektedir. 2. Yukarı kat düğmesi yanar. 3. Asansör 3. cü kata varır. Asansörün içinde, asansöre 1. ci katta binmiş ve 9. cu kata çıkmak için asansör düğmesine basmış B kullanıcısı vardır. 4. Asansörün kapıları açılır. 5. Zamanlayıcı (timer) başlar. A kullanıcısı asansöre girer. 6. A kullanıcısı 1. ci kata gitmek için asansör düğmesine basar. 7. Asansör düğmesi 1. ci kat için yanar. 8. Asansör kapıları zaman bitimi kapanır. 9. Yukarı kat düğmesi söner. 10. Asansör 9. cu kata gider. 11. Asansör 9. cu kata geldiğinde, asansörün 9. cu kat düğmesi söner. 12. B kullanıcısının asansörden dışarı çıkması için asansörün kapıları açılır. 13. Zamanlayıcı (timer) başlar. B kullanıcısı asansörden dışarı çıkar. 14. Asansör kapıları zaman bitimi kapanır. 15. Asansör A kullanıcı ile 1. ci kata inmek için ilerler

13 ENTİTY SINIF MODELLEME: ASANSÖR PROBLEMİ ÖRNEK OLAY İNCELEMESİ Bu adımda entity sınıfları (classes) ve bu sınıfların nitelikleri (attributes) ortaya çıkarılır ve bunlar bir UML diyagramı kullanılarak sunulur. Entity sınıfları belirlemenin bir alternatif yolu, use case ler ve bu use case lerin senaryolarından entity sınıfları ortaya çıkarmaktır. Geliştiriciler hem normal hem de istisnai bütün senaryoları dikkatlice incelemeli ve use case ler içinde rol oynayan bileşenleri tanımlamalıdır. Bu senaryoları incelerken olası tehlike ise, bazen çok fazla use case ve senaryo olabilir. Bu yüzden çok fazla aday sınıf (candidate class) olabilir. Entity sınıfları belirlemenin diğer alternatif yolları ise; CRC Cards (Class Responsibility Collaboration): Eğer yazılım ürününün çalışma ortamı çok iyi biliniyorsa, bu yöntem kullanışlıdır. Noun Extraction (İsim Çıkartma Yöntemi)

14 İSİM ÇIKARTMA (NOUN EXTRACTİON) YÖNTEMİ Uygulama sahası hakkında tecrübe sahibi olmayan geliştiriciler için, aday entity sınıfları ortaya çıkarmada kullanılan bir yöntemdir. İsim çıkartma yöntemi iki adımda gerçekleştirilen bir süreçtir. 1. Adım: Problemin Kısa Tanımı Yazılım ürününü kısaca tek bir paragraf içinde tanımlanır. Asansörlerde ve katlarda bulunan düğmeler, m katlı bir binada n tane asansörün hareketini kontrol eder. Düğmeler belirli bir katta duran asansörü istemek için basıldığında yanar; istek yerine getirildiğinde düğmelerin ışığı söner. Asansör için hiçbir istek olmadığı zaman, asansör bulunduğu katta kapıları kapalı şekilde durur

15 2. Adım: İsimleri Belirleme Bu adım informal bir stratejidir. Yukarıda tanımlanan paragraftaki isimlerin altı çizilir. Asansörlerde ve katlarda bulunan düğmeler, m katlı bir binada n tane asansörün hareketini kontrol eder. Düğmeler belirli bir katta duran asansörü istemek için basıldığında yanar; istek yerine getirildiğinde düğmelerin ışığı söner. Asansör için hiçbir istek olmadığı zaman, asansör bulunduğu katta kapıları kapalı şekilde durur. Asansör (elevator), kat (floor), düğme (button), hareket (movement), bina (building), ışık (illumination), istek (request) ve kapı (door) altı çizilen isimlerdir. Bu isimler aday sınıf olarak kullanılır

16 İsimler (nouns) düğme (button), asansör (elevator), kat (floor), hareket (movement), bina (building), ışık (illumination), istek (request), kapı (door) kat (floor), bina (building), kapı (door) isimleri problemin sınırları dışında kalıyor. Bu yüzden bu isimler aday sınıf olamaz diye çıkarıyoruz. hareket (movement), ışık (illumination), istek (request) isimleri soyut isimlerdir. Bu yüzden bu isimleri de aday sınıf olamaz diye çıkarıyoruz. Sonuç olarak, kalan isimler aday sınıflarımız (candidate classes) oluyor: Asansör Sınıfı (Elevator Class) ve Düğme Sınıfı (Button Class) Altsınıflar: Asansör Düğme Sınıfı (Elevator Button Class) ve Kat Düğme Sınıfı (Floor Button Class)

17 SINIF DİYAGRAMININ İLK İTERASYONU Burada bir problem var: Düğmeler (buttons) asansörle doğrudan ilişkili değil. Burada çoktan çoğa ilişli söz konusudur. Bu yüzden ek bir sınıfa daha ihtiyacımız var: Asansör Kontrol Sınıfı (Elevator Controller Class)

18 SINIF DİYAGRAMININ İKİNCİ İTERASYONU Bütün ilişkiler şimdi, 1 den çoğa dır. Sınıflar arası böyle bir ilişki kurmak tasarım (design) ve gerçekleştirmeyi (implementation) daha kolay bir hale getirir

19 CRC (CLASS RESPONSIBILITY COLLABORATION) CARDS 1989 dan beri kullanılan bir nesne-tabanlı analiz tekniğidir. Bazı organizasyonlar post-it tarzı not kâğıtları kullanarak, bunları beyaz bir tahtaya yapıştırıyorlar ve post-it lerde yazılı olan sınıflar arasında çizgiler çizerek bağlantı kuruyorlardır. Her sınıf için, kart (post-it) şu şekilde doldurulmaktadır: Sınıfın Adı (Name of Class) İşlevselliği [Functionality (Responsibility)] İlişkili Olduğu Sınıfların Listesi [List of classes it invokes (Collaboration)] Günümüzde CRC kartlar otomatikleştirilmiştir. (CASE aracı bileşeni) Örneğin Visual Studio.Net te sınıflara ilişkin bilgiler ve bu sınıflar arasındaki ilişkiler otomatik olarak oluşturulmaktadır

20 CRC Kartlar Kullanmanın Güçlü Yönleri: CRC kartlar bir takım tarafından kullanıldığında, bir sınıf içindeki eksik veya hatalı alanlar, niteliklerin veya metotların olup olmadığı ve takım üyeleri arasındaki etkileşim ortaya çıkarabilmektedir. Aynı zamanda, sınıflar arasında ilişkiler CRC kartlar kullanıldığında açık bir şekilde anlatılmaktadır. Güçlü teknik özelliklerinden biri, sorumluluğa göre takım üyeleri arasında kartları dağıtmaktır. CRC Kartlar Kullanmanın Zayıf Yönleri CRC Kartlar entity sınıfları belirlemek için kullanılacaksa, uygulama ortamının çok iyi bilinmesi gerekir

21 DİNAMİK MODELLEME: ASANSÖR PROBLEMİ ÖRNEK OLAY İNCELEMESİ Dinamik modellemenin hedefi, her bir sınıf için durum diyagramı (statechart) elde etmektir. Burada; durum (state), olay (event) ve önerme (predicate) durum diyagramı (statechart) üzerinde dağıtılmıştır

22 Bu UML durum diyagramı (statechart), Şekil ve Şekil de gösterilen durum geçiş diyagramına (state transition diagram) eşdeğerdir. Dinamik modellemede bu durum belirli senaryolar ile gösterilir. Aslında bir durum diyagramı (statechart), senaryolara ait olayların modellenmesi ile yapılır. CRC kartların kullanımı, mükemmel bir test tekniğidir

23 Sorumlulukları (responsibility) düşünelim. 1. Turn on elevator button Bu, nesne-tabanlı paradigm için tamamen uygun olmayan bir durumdur. Sorumluluğa-dayalı tasarım (responsibility-driven design) ihmal edilmiştir. Bilgi gizleme (information hiding) ihmal edilmiştir. Sorumluluklar; 1. Turn on elevator button yerine 1. Send message to Elevator Button Class to turn itself on şeklinde olmalıdır

24 Ayrıca, bir sınıfı da gözden kaçırdık. Asansör kapıları, execution boyunca değişen bir durum (state) dur. (bu sınıfın özelliğidir) Bu yüzden Asansör Kapıları Sınıfını (Elevator Doors Class) eklemeliyiz. Güvenliği de düşünmeliyiz. CRC Kart değiştirilir

25 Sınıf diyagramının değiştirilmesiyle, bazı kısımların yeniden gözden geçirilmesi gerekmektedir. Use-case diyagramı (değişim yok), Sınıf diyagramı (bir sonraki slâytta göreceğiz), Durum diyagramları, Senaryolar (bir sonraki slâyttan sonra göreceğiz),

26 ASANSÖR PROBLEMİ İÇİN NORMAL SENARYO 1. A kullanıcısı, 3. cü katta asansör çağırmak için yukarı kat düğmesine basar. A kullanıcısı 7. ci kata çıkmak istemektedir. 2. Kat düğmesi basıldığında, kat düğmesi asansör kontrol mekanizmasını bilgilendirir. 3. Asansör kontrol mekanizması, yukarı kat düğmesine on (yanması) konumuna geçmesi için bir mesaj gönderir. 4. Asansör kontrol mekanizması, asansörün 3. cü kata hareket etmesi için bir dizi mesaj gönderir. Asansörün içinde, asansöre 1. ci katta binmiş ve 9. cu kata çıkmak için asansör düğmesine basmış B kullanıcısı vardır. 5. Asansör kontrol mekanizması, asansöre kapılarını açması için bir mesaj gönderir

27 6. Asansör kontrol mekanizmasının zamanlayıcısı (timer) saymaya başlar. A kullanıcısı asansöre girer. 7. A kullanıcısı 7. ci kata çıkmak için asansör düğmesine basar. 8. Asansör düğmesi basıldığında, asansör düğmesi asansör kontrol mekanizmasını bilgilendirir. 9. Asansör kontrol mekanizması, asansörün 7. ci kat düğmesine on (yanması) konumuna geçmesi için bir mesaj gönderir. 10. Asansör kontrol mekanizması, asansöre zaman bitimi kapılarını kapaması için bir mesaj gönderir. 11. Asansör kontrol mekanizması, yukarı kat düğmesinin off (sönmesi) konumuna geçmesi için mesaj gönderir. 12. Asansör kontrol mekanizması, asansörün 7. ci kata hareket etmesi için asansöre bir dizi mesaj gönderir. 13. Asansör kontrol mekanizması, asansör 7. ci kata geldiğinde, asansörün 7. ci kat düğmesi off (söner) konumuna geçer. 14. Asansör kontrol mekanizması, A kullanıcısının asansörden dışarı çıkması için asansöre kapılarını açması yönünde bir mesaj gönderir. 15. Asansör kontrol mekanizmasının zamanlayıcısı (timer) saymaya başlar. A kullanıcısı asansörden çıkar. 16. Asansör kontrol mekanizması, asansöre zaman bitimi kapılarını kapaması için bir mesaj gönderir. 17. Asansör kontrol mekanizması, asansörün 9. cu kata hareket etmesi için asansöre bir dizi mesaj gönderir

28 Nesne-tabanlı analiz iyi mi? Şimdilik, nesne-tabanlı analiz iyi, ama her zaman değişiklik olabilir. Daha iyi bir alternatifi yok. Nesne-tabanlı tasarım iş akışı boyunca, nesne-tabanlı analiz iş akışına geri dönmeye gereksinim duyabiliriz

29 BOUNDARY VE CONTROL SINIFLARIN ÇIKARILMASI Boundary sınıflar, yazılım ürünü ile ortam arasındaki etkileşimi modeller. Genellikle giriş/çıkış işlemleri ve raporlama işlemleri ile ilişkilendirilmiş sınıflardır. Control sınıflar ise; karmaşık işlemlerin, hesaplamaların ve algoritmaların yürütüldüğü sınıflardır

30 MSG Vakfı yazılım ürününe ait use-case diyagramının yedinci iterasyonunu tekrar hatırlayalım

31 MORTGAGE YÖNETME USE CASE İÇİN BİR SENARYO MSF Vakfı çalışanı, vakfın bir mortgage kredisini sağlayabilmesi için, bir evin yıllık emlak vergilerini güncellemek ister. 1. Çalışan yıllık emlak vergisinin yeni değerini girer. 2. Bilgi sistemi, yıllık emlak vergisinin en son değişmiş olduğu tarihi günceller. Olası Alternatif A. Çalışan mortgage kredisine ait numarayı hatalı olarak girer

32 MORTGAGE YÖNETME USE CASE İÇİN İKİNCİ BİR SENARYO MSG Vakfından borç para alan bir çiftin haftalık gelirinde değişiklikler olabilir. Çiftler haftalık gelirlerinin MSG Vakfı çalışanı tarafından vakıf kayıtlarında güncellenmesini isterler. Böylece çiftlerin haftalık mortgage ödemeleri doğru olarak hesaplanmış olur. 1. Çalışan, haftalık gelirin yeni değerini girer. 2. Bilgi sistemi, haftalık gelirin en son değişmiş olduğu tarihi günceller. Olası Alternatif A. Çalışan mortgage kredisine ait numarayı hatalı olarak girer. B. Borçlular yeni gelirlerine ait doküman getirmezler

33 HAFTALIK KULLANILABİLİR BİRİKİMLERİ TAHMİN ETME USE CASE İÇİN BİR SENARYO MSG Vakfı çalışanı, haftalık kullanılabilir birikimleri belirlemek ister. 1. Bilgi sistemi her yatırım için, tahmini yıllık yatırım getirisini çıkartır. Bilgi sistemi ayrı ayrı getirileri toplar ve haftalık tahmini yatırım gelirini elde etmek için sonucu 52'ye böler. 2. Bilgi sistemi, MSG Vakfının tahmini yıllık işletme giderlerini çıkartır ve sonucu 52 ye böler. 3. Her bir mortgage için: 3.1. Bilgi sistemi, anapara, faiz ödemesi, yıllık emlak vergisinin toplamının 1/52 si ve evin yıllık sigorta primi toplamının 1/52 sini toplayarak haftalık ödeme miktarını hesaplar Bilgi sistemi, çiftin haftalık güncel brüt gelirinin yüzde 28 ini hesaplar

34 3.3. Eğer adım 3.1. in sonucu adım 3.2. nin sonucundan büyükse, içinde bulunulan hafta için mortgage ödemesi adım 3.2 de elde edilen sonuçtur. Ayrıca içinde bulunulan hafta için yapılacak olan bağışın miktarı, adım 3.1. in sonucu ile adım 3.2. nin sonucu arasındaki farktır Aksi durumda, içinde bulunulan hafta için mortgage ödemesi adım 3.1 de elde edilen sonuçtur ve o hafta için bağış yapılmaz. 4. Bilgi sistemi; haftalık tahmini toplam mortgage ödemelerini elde etmek için Adım 3.3 ve 3.4 teki mortgage ödemelerini toplar. 5. Bilgi sistemi; haftalık tahmini toplam bağış ödemelerini elde etmek için Adım 3.3 teki bağış ödemelerini toplar. 6. Bilgi sistemi; Adım 1 ile 4 ün sonucunu toplar, Adım 2 ve 5 in sonucundan çıkartır. Elde edilen sonuç, içinde bulunulan haftada mortgage için kullanılabilir toplam miktardır. 7. Sonuç olarak yazılım ürünü, içinde bulunulan haftada yeni bir mortgage kredisi için kullanılabilir toplam miktarı yazdırır

35 RAPOR ÜRETME USE CASE İÇİN BİR SENARYO MSG Vakfı çalışanı, bütün mortgage kredilerinin listesini yazdırmak ister. 1. Çalışan, bütün mortgage kredilerinin listesini rapor olarak almak ister. RAPOR ÜRETME USE CASE İÇİN DİĞER BİR SENARYO MSG Vakfı çalışanı, bütün yatırımların listesini yazdırmak ister. 1. Çalışan, bütün yatırımların listesini rapor olarak almak ister

36 BAŞLANGIÇ SINIF DİYAGRAMI: MSG VAKFI ÖRNEK OLAY İNCELEMESİ Entity sınıf modelleme adımının hedefi, entity sınıfları ortaya çıkarmak, bu entity sınıfların niteliklerini (attributes) bulmak ve bu entity sınıflar arasındaki karşılıklı ilişkileri belirlemektir. Genellikle, bu adıma başlamak için en iyi yol, iki-adımlı isim çıkartma (noun extraction) metodunu kullanmaktır. İSİM ÇIKARTMA (NOUN EXTRACTİON) 1. Adım: Tek bir paragrafta bilgi sistemini tanımlama Haftalık raporlar, mortgage kredileri için ne kadar kullanılabilir para olduğunu göstermek amacıyla basılacaktır. Ayrıca, yatırımların ve mortgage kredilerinin listesi talep edildiğinde basılmalıdır

37 2. Adım: Bu paragraf içindeki isimleri belirleme Haftalık raporlar, mortgage kredileri için ne kadar kullanılabilir para olduğunu göstermek amacıyla basılacaktır. Ayrıca, yatırımların ve mortgage kredilerinin listesi talep edildiğinde basılmalıdır. İsimler; rapor (report), para (money), mortgage, liste (list) ve yatırım (investment)

38 Rapor (report) ve liste (list) isimlerini uzun süreli kullanmayacağız, bu yüzden bu isimleri entity sınıf olamaz diye çıkarıyoruz. (rapor ismi şüphesiz bir boundary sınıfı meydana getirektedir) Para (money) ismi, soyut isimdir. Geriye iki aday entity sınıf kalmaktadır: Mortgage Class and Investment Class Başlangıç Sınıf Diyagramının İlk İterasyonu

39 BAŞLANGIÇ SINIF DİYAGRAMININ İKİNCİ İTERASYONU Bu iki entity sınıf üzerinde gerçekleştirilen ekleme, silme ve değişiklik işlemlerinin; Yatırım Yönetme (Manage an Investment) ve Mortgage Yönetme (Manage a Mortgage) use case lerinin tanımlarını (description) yeniden gözden geçirdiğimizde benzer olarak yapıldığını görürüz. Bu iki entity sınıf arasında bir etkileşim (interaction) olduğunu görürüz. Ayrıca, her iki entity sınıfa ait bütün raporlar, talep halinde basılmaktadır. Mortgage Sınıfı (Mortgage Class) ve Yatırım Sınıfı (Investment Class), bir üst sınıf olarak adlandırılan Mal Varlığı Sınıfının (Asset Class) bir alt sınıfıdır. Aşağıda başlangıç sınıf diyagramının ikinci iterasyonu görülmektedir

40 Gereksinimler İş Akışına Geri Dönersek; 11. Bölümde yedinci iterasyonun sonunda oluşan use case diyagramımızda Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week), Yatırım Yönetme (Manage an Investment), Mortgage Yönetme (Manage a Mortgage), Tahmini Yıllık İşletme Giderlerini Güncelleme (Update Estimated Annual Operating Expenses) ve Rapor Üretme (Produce a Report) use case i olmak üzere beş tane use case vardı. Mortgage Sınıfı (Mortgage Class) ve Yatırım Sınıfı (Investment Class), bir üst sınıf olarak adlandırılan Mal Varlığı Sınıfının (Asset Class) bir alt sınıfıdır demiştik. O zaman, Yatırım Yönetme (Manage an Investment) ve Mortgage Yönetme (Manage a Mortgage) use case lerini tek bir use case, yani Mal Varlığını Yönetme (Manage an Asset) use case i altında birleştirebiliriz

41 Use-Case Diyagramının sekizinci iterasyonu sonucunda oluşan yeni use case diyagramı şekilde görüldüğü gibidir. Yeni eklenen use case, yani Mal Varlığı Yönetme (Manage an Asset) use case i farklı renkte gösterilmektedir

42 Son olarak, MSG Vakfı yazılım ürünü için, sınıf diyagramında her bir sınıfın niteliklerini (attributes) ekledik. Bunu bir sonraki slâytta göreceğiz. Her bir kutunun altındaki boş dikdörtgenler, daha sonra sınıfın (class) gerçekleştireceği işlemler ile doldurulacak. Başlangıç Sınıf Diyagramının İkinci İterasyonu

43 BAŞLANGIÇ DİNAMİK MODELİ: MSG VAKFI ÖRNEK OLAY İNCELEMESİ Dinamik modelleme, entity sınıfları ortaya çıkartmada üçüncü adımdır. Bir durum diyagramı (statechart), yazılım ürününe göre veya yazılım ürünü tarafından gerçekleştirilen bütün işlemleri göstermek için yapılmaktadır. İşlemler, senaryolardan belirlenmektedir

44 Şekilde görülen durum diyagramında (statechart), MSG Vakfı Bilgi Sistemi nin bütün işlemleri gösterilmektedir. En üst soldaki içi dolu çember, başlangıç durumunu temsil eder, durum diyagramının (statechart) başlangıç noktası. En üst sağda küçük siyah çemberi içiren beyaz çember ise, son durumu temsil eder. İlk ve son durumlardan başka durumlar, köşeleri yuvarlaklaştırılmış dikdörtgenler ile temsil edilir. Oklar, durumdan duruma olası geçişleri temsil eder

45 MSG Vakfı Bilgi Sistemi Çevriminde, beş olaydan (events) biri meydana gelir. MSG çalışanı aşağıdaki beş komuttan birini seçebilir: Haftalık birikimleri tahmin etme (estimate funds for the week) Mal varlığı yönetme (manage an asset) Tahmini yıllık işletme giderlerini güncelleme (update estimated annual operating expenses) Rapor üretme (produce a report), veya Çıkış (quit)

46 Bu olasılıklar beş olay (events) ile gösterilir. Haftalık birikimleri tahmin etme (estimate funds for the week) menüsünü seçme, Mal varlığı yönetme (manage an asset) menüsünü seçme, Tahmini yıllık işletme giderlerini güncelleme (update estimated annual operating expenses) menüsünü seçme, Rapor üretme (produce a report) menüsünü seçme veya Çıkış (quit) menüsünü seçme. Bir olay (event), durumlar (states) arasındaki geçişleri sağlar. OO Paradigm da sistemi bütün olarak ele almak yerine, her sınıf için bir dinamik model oluşturulur. Önemli bir not: OO Paradigm da bir sınıfın nesnesi (object) adım değiştirmiyorsa, asla durum diyagramı (statecharts) çizilmez

47 MSG Vakfı çalışanı, menü üzerinde tıklayarak bir seçeneği seçer. Yukarıdaki şekilde görüldüğü gibi bir grafiksel kullanıcı ara yüzü (graphical user interface GUI) hazırlarken, özel yazılımlara gereksinim duyulur. Metinsel bir kullanıcı ara yüzü bir önce gösterilen grafiksel kullanıcı ara yüzüne eşdeğerdir. Bu metinsel kullanıcı ara yüzü de her hangi bir bilgisayarda çalıştırılabilir

48 ENTİTY SINIFLARDA DÜZELTMELER YAPMA: MSG VAKFI İlk işlevsel model, başlangıç sınıf diyagramı ve ilk dinamik model tamamlanmıştır. İlk işlevsel model, başlangıç sınıf diyagramı ve ilk dinamik modeli kontrol ederek hataları ortaya çıkarırız. Başlangıç durum diyagramında (statechart), Tahmini Yıllık İşletme Giderlerini Güncelle (Update the estimated annual operating expenses) işlemi ile Tahmini Yıllık İşletme Giderlerini Güncelle (Update Estimated Annual Operating Expenses) durumunu (state) düşünelim. Bu işlem, tahmini yıllık işletme giderlerinin güncel değeri üzerinde gerçekleştirilmek zorundadır

49 Fakat tahmini yıllık işletme giderlerinin değeri nerede bulunmaktadır? Güncel olarak, bu değer yalnızca tek sınıftan (Mal Varlığı Sınıfı Asset Class) elde edilir ve bu sınıfın iki alt sınıfı vardır. Bu sınıfların hiçbiri, tahmini yıllık işletme giderlerine ait değerleri saklamak için uygun değildir. Bir değerin uzun süre saklanabilmesi için tek yol, bir sınıf veya o sınıfın alt sınıflarına ait bir nesnenin niteliği ile sağlanır. Tahmini yıllık işletme giderlerini saklamak için başka bir entity sınıfa, ihtiyaç vardır; MSG Uygulama Sınıfı (MSG Application Class)

50 MSG Vakfı için başlangıç sınıf diyagramının üçüncü iterasyonu sonucunda; MSG Uygulama Sınıfı (MSG Application Class) aynı zamanda, Mal Varlığı Sınıfına (Asset Class) ait olmayan diğer niteliklere de sahip olur. Prototipleri göstermek için sınıf diyagramını yeniden çizeriz. Burada görülen dört sınıfın tamamı, entity sınıftır

51 BOUNDARY SINIFLARIN ÇIKARTILMASI: MSG VAKFI ÖRNEK OLAY İNCELEMESİ Boundary sınıfları çıkartmak genellikle kolaydır. Çünkü genellikle her bir giriş ekranı, çıkış ekranı ve rapor yazdırma bir boundary sınıf olarak modellenir. MSG Vakfının dört use case i için tek bir ekran yeterli olacaktır. Estimate Funds Available for Week Manage an Asset Update Estimated Annual Operating Expenses Produce a Report Buna göre, başlangıç olarak ilk boundary sınıfı: Kullanıcı Arayüz Sınıfı (User Interface Class)

52 Üç rapor basılacaktır: Haftalık tahmini birikimlere ait rapor, Bütün mortgage ların listesi, Bütün yatırımların listesi. Bu raporların her biri ayrı bir boundary sınıf olarak modellenecektir: Tahmini Birikimler Rapor Sınıfı (Estimated Funds Report Class) Mortgage lar Rapor Sınıfı (Mortgages Report Class) Yatırımlar Rapor Sınıfı (Investments Report Class) Başlangıç olarak, burada dört tane boundary sınıf vardır

53 Daha önce burada alınacak üç rapor olduğunu söylemiştik; Haftalık tahmini birikimlere ait rapor, Bütün mortgage ların listesi, Bütün yatırımların listesi. Dikkat edersek, her bir raporun içeriği farklıdır. Bu yüzden her bir raporu ayrı birer boundary sınıf olarak modelliyoruz

54 CONTROL SINIFLARIN ÇIKARTILMASI: MSG VAKFI ÖRNEK OLAY İNCELEMESİ Genellikle her bir hesaplama işlemi, control sınıfları tarafından modellenir. MSG Vakfı yazılım ürünü için, karmaşık hesaplama işlemleri sadece haftalık kullanılabilir birikimleri tahmin ederken yapılmaktadır. Buna göre, başlangıç olarak ilk control sınıf: Haftalık Birikimleri Tahmin Etme Sınıfı (Estimate Funs for Week Class) Sınıf çıkartma işlemlerimizi tamamladık. Artık buradan Birleştirilmiş Sürece (Unified Process) geri dönebiliriz

55 USE-CASE LERİ GERÇEKLEŞTİRME: MSG VAKFI ÖRNEK OLAY İNCELEMESİ Use case leri yeniden düzenleme ve genişletme süreci use-case i gerçekleştirme (use-case realization) olarak adlandırılır. "Gerçekleştirme Realize" fiili, en az 3 farklı anlamda kullanılır: Anlama Understand ("Harvey yavaş yavaş yanlış sınıfta olduğunu anlamaya başladı"); Alma. ("Ingrid, stok işlemiyle $ 45,000'ın karını alacak"); Gerçekleştirme. ("Janet, bir bilgisayar şirketine başlama rüyasını gerçekleştirmeyi umut ediyor"). "use case gerçekleştirme" sözcük grubundaki, "gerçekleştirme realize" sözcüğü bu son anlamda kullanılır

56 Use case in belirli bir senaryosunun gerçekleştirilmesi, bir etkileşim diyagramı kullanılarak gösterilir. Etkileşim diyagramı olarak ta ya sequence diyagram ya da collaboration diyagram kullanılır. Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case ini düşünelim. Bir sonraki slâytta, Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case ini ve bu use case in tanımını göreceğiz

57 HAFTALIK KULLANILABİLİR BİRİKİMLERİ TAHMİN ETME USE CASE İ Kısa Açıklama Haftalık Kullanılabilir Birikimleri Tahmin Etme use case i, MSG Vakfı çalışanına, MSG Vakfı nın mortgates kredilerini haftalık ne kadar para finanse edeceğini yani ne kadar para kaynağı ayıracağını tahmin etmesinde yardımcı olur. Adım Adım Açıklama 1. Her yatırım için, yatırımlardan tahmini yıllık yatırım getirisi çıkartılır. Yıllık getiriler ayrı ayrı toplanır ve haftalık tahmini yatırım gelirini elde etmek için sonuç 52'ye bölünür. 2. MSG Vakfının tahmini haftalık işletme giderlerini belirlemek için MSG Vakfının tahmini yıllık işletme giderleri çıkartılır ve sonuç 52 ye bölünür. 3. Her bir mortgage için: 3.1. Anapara, faiz ödemesi, yıllık emlak vergisinin toplamının 1/52 si ve evin yıllık sigorta primi toplamının 1/52 si toplanarak haftalık ödeme miktarı hesaplanır

58 3.2. Çiftin haftalık güncel brüt gelirinin yüzde 28 i hesaplanır Eğer adım 3.1. in sonucu adım 3.2. nin sonucundan büyükse, içinde bulunulan hafta için mortgage ödemesi adım 3.2 de elde edilen sonuçtur. Ayrıca içinde bulunulan hafta için yapılacak olan bağışın miktarı, adım 3.1. in sonucu ile adım 3.2. nin sonucu arasındaki farktır Aksi durumda, içinde bulunulan hafta için mortgage ödemesi adım 3.1 de elde edilen sonuçtur ve o hafta için bağış yapılmaz. 4. Haftalık tahmini toplam mortgage ödemelerini elde etmek için Adım 3.3 ve 3.4 teki mortgage ödemeleri toplanır. 5. Haftalık tahmini toplam bağış ödemelerini elde etmek için Adım 3.3 teki bağış ödemeleri toplanır. 6. Adım 1 ile 4 ün sonucunu toplanır, Adım 2 ve 5 in sonucundan çıkartılır. Elde edilen sonuç, içinde bulunulan haftada mortgage için kullanılabilir toplam miktardır. 7. İçinde bulunulan haftada yeni bir mortgage kredisi için kullanılabilir toplam miktar yazdırılır

59 HAFTALIK KULLANILABİLİR BİRİKİMLERİ TAHMİN ETME USE CASE İ Şekilde gösterilen bir sınıf diyagramı (class diagram) dır. Bu diyagramda sınıflar arasındaki ilişkiler ve use case i gerçekleştirirken ortak olarak kullanılan sınıflar gösterilmektedir

60 HAFTALIK KULLANILABİLİR BİRİKİMLERİ TAHMİN ETME USE CASE İ Haftalık Kullanılabilir Birikimleri Tahmin Etme use case inde rol oynayan altı sınıf vardır: Kullanıcı Arayüz Sınıfı (User Interface Class) Bu sınıf, kullanıcı arayüzünü modeller. Haftalık Birikimleri Tahmin Etme Sınıfı (Estimate Funds for Week Class) Bu kontrol sınıfı, hafta boyunca motrgage lar için kullanılabilir birikimleri tahmin ederken yapılan hesaplamaları modeller. Mortgage Sınıfı (Mortgage Class) Bu sınıf, haftalık tahmini bağışları ve ödemeleri modeller. Yatırım Sınıfı (Investment Class) Bu sınıf, yatırımların haftalık tahmini getirilerini modeller. MSG Uygulama Sınıfı (MSG Application Class) Bu sınıf, haftalık tahmini işletme giderlerini modeller. Tahmini Birikimler Rapor Sınıfı (Estimated Funds Report Class) Bu sınıf, raporların basılmasını modeller

61 HAFTALIK KULLANILABİLİR BİRİKİMLERİ TAHMİN ETME USE CASE İÇİN BİR SENARYO MSG Vakfı çalışanı, haftalık kullanılabilir birikimleri belirlemek ister. 1. Bilgi sistemi her yatırım için, tahmini yıllık yatırım getirisini çıkartır. Bilgi sistemi ayrı ayrı getirileri toplar ve haftalık tahmini yatırım gelirini elde etmek için sonucu 52'ye böler. 2. Bilgi sistemi, MSG Vakfının tahmini yıllık işletme giderlerini çıkartır ve sonucu 52 ye böler. 3. Her bir mortgage için: 3.1. Bilgi sistemi, anapara, faiz ödemesi, yıllık emlak vergisinin toplamının 1/52 si ve evin yıllık sigorta primi toplamının 1/52 sini toplayarak haftalık ödeme miktarını hesaplar

62 3.2. Bilgi sistemi, çiftin haftalık güncel brüt gelirinin yüzde 28 ini hesaplar Eğer adım 3.1. in sonucu adım 3.2. nin sonucundan büyükse, içinde bulunulan hafta için mortgage ödemesi adım 3.2 de elde edilen sonuçtur. Ayrıca içinde bulunulan hafta için yapılacak olan bağışın miktarı, adım 3.1. in sonucu ile adım 3.2. nin sonucu arasındaki farktır Aksi durumda, içinde bulunulan hafta için mortgage ödemesi adım 3.1 de elde edilen sonuçtur ve o hafta için bağış yapılmaz. 4. Bilgi sistemi; haftalık tahmini toplam mortgage ödemelerini elde etmek için Adım 3.3 ve 3.4 teki mortgage ödemelerini toplar. 5. Bilgi sistemi; haftalık tahmini toplam bağış ödemelerini elde etmek için Adım 3.3 teki bağış ödemelerini toplar. 6. Bilgi sistemi; Adım 1 ile 4 ün sonucunu toplar, Adım 2 ve 5 in sonucundan çıkartır. Elde edilen sonuç, içinde bulunulan haftada mortgage için kullanılabilir toplam miktardır. 7. Sonuç olarak yazılım ürünü, içinde bulunulan haftada yeni bir mortgage kredisi için kullanılabilir toplam miktarı yazdırır

63 Yazılım ürünü çalışırken, sınıflardan (classes) ziyade nesneleri (objects) kullanır. Örneğin; belirli bir mortgage ı Mortgage Sınıfı ile gösteremeyiz. Bunun yerine bir mortgage ı Mortgage Sınıfının bir örneği ile temsil ederiz ve bunu :Mortgage Sinifi (:Mortgage Class) şeklinde gösteririz. Bir sınıf diyagramı (class diagram), use case içindeki sınıfları (classes) ve bu sınıflar (classes) arasındaki ilişkileri gösterir. Sınıf diyagramları ne nesneleri (objects), ne de nesneden nesneye gönderilen mesajların sırasını göstermez

64 COLLABORATION (İŞBİRLİĞİ) DİYAGRAMI Bir sistemin amacını yerine getirebilmesi için, sistemin bütün parçalarının işlerini yerine getirmesi gerekir. Bu işler genellikle birkaç parçanın beraber çalışmasıyla mümkün olabilir. Bu tür ilişkileri göstermek için Collaboration (İşbirliği) Diyagramları kullanılır. Collaboration (işbirliği) diyagramları, mesaj yollayan ve alan nesnelerin yapısal organizasyonları üzerinde duran bir tür etkileşim diyagramıdır. Collaboration (işbirliği) diyagramları, yazılım sisteminin statik yapısını ve dinamik davranışlarını birlikte gösterir

65 HAFTALIK KULLANILABİLİR BİRİKİMLERİ TAHMİN ETME USE CASE Use case ait senaryoyu Collaboration Diyagramı ile gerçekleştiriyoruz

66 Collaboration (işbirliği) diyagramı, belirli bir senaryo içinde gönderim sırasına göre numaralandırılmış mesajlara ek olarak nesneleri gösterir. Madde 1: Vakıf çalışanı, haftalık kullanılabilir birikimleri hesaplamak ister. Collaboration diyagramda bu istek, MSG Vakfı çalışanından : User Interface Class nesnesine (User Interface Class ın bir örneği (instance)) gönderilen; 1: Request estimate of funds available for week mesajı ile modellenmiş olur

67 Madde 2: Bu istek, asıl hesaplamalarını yerine getiren kontrol sınıfının bir örneği (instance) olan : Estimate Funds for Week Class nesnesine iletilir. Bu istek, 2: Transfer request mesajı ile modellenmiş olur. : Estimate Funds for Week Class tarafından tespit edilen mali tahminler dörde ayrılır

68 Madde 2: Senaryonun 1. Adımında, her bir yatırım için tahmini yıllık yatırım getirileri toplanıp, çıkan sonuç 52 ye bölünüyordu. Bu tahmini haftalık getirileri çıkartma işlemi; : Estimate Funds for Week Class ından, : Investment Class ına gönderilen 3: Request estimated return on investments for week mesajı ile modellenmiş olur. Bu mesajı diğer yönde cevap olarak gönderilen; 4: Return estimated weekly return on investments mesajı izler

69 Madde 4: Senaryonun 2. Adımında, tahmini işletme giderleri alıp çıkan sonucu 52 ye bölerek, haftalık işletme giderleri tahmin edilmekteydi. Bu haftalık işletme giderlerini çıkartma işlemi; : Estimate Funds for Week Class ından, : MSG Application Class ına gönderilen 5: Request estimated operating expenses for week mesajı ile modellenmiş olur. Bu mesajı diğer yönde cevap olarak gönderilen; 6: Return estimated operating expenses for week mesajı izler

70 Madde 5: Senaryonun 3, 4 ve 5. Adımlarında, haftalık tahmini bağışlar ve ödemeler tespit edilerek tahmin edilir. Bu işlemleri; : Estimate Funds for Week Class ından, : Mortgage Class ına gönderilen 7: Request estimated grants and payments for week mesajı ile modellenmiş olur. Bu mesajı diğer yönde cevap olarak gönderilen; 8: Return estimated grants and payments for week mesajı izler

71 Madde 6: Senaryonun 6. Adımında, aritmetik hesapla gerçekleştirilir. Bu işlem; 9: Compute estimated amount available for week mesajı ile modellenmiş olur. Bu işlem aynı çağrı üzerinde gerçekleşir. Yani burada bir döngü (loop) durumu söz konusu. : Estimate Funds for Week Class ın bir kontrol sınıfı idi, bu yüzden hesaplama işlemleri bu sınıf üzerinde gerçekletirilmektedir. Hesaplama sonucu saklanmak üzere; 10: Transfer estimated amount available for week mesajı ile : MSG Application Class ına gönderilir

72 Madde 7: Senaryonun 7. Adımında, sonuç rapor olarak basılmaktadır. Bu işlem, : MSG Application Class ından, : Estimated Funds Report Class ına gönderilen 11: Print estimated amount available mesajı ile modellenmiş olur

73 Madde 6: Sonunda, MSG Vakfı çalışanına görevin başarılı bir şekilde tamamlanmış olduğuna dair bir geri bildirim mesajı yollanır. Bu işlemler sırasıyla aşağıdaki mesajları ile modellenmiş olur. 12: Send successful completion message 13: Send successful completion message 14: Transfer successful completion message 15: Display successful completion message

74 Hiçbir müşteri, önerilen yazılım ürününün ne yapacağını anlamadan şartname dokümanını onaylamayacaktır. Bundan dolayı, collaboration (işbirliği) diyagramının yazılı bir açıklamasına ihtiyaç duyulur. Bu yazılı açıklamaya, olayların akışı (flow of events) denir. Use case e senaryosu gerçekleştirilmek için kullanılan collaboration (işbirliği) diyagramına ait olayların akışı (flow of events) aşağıdaki gibidir. MSG Vakfı çalışanı, haftalık kullanılabilir birikimleri tahmin etmek ister (1, 2). Bilgi sistemi, haftalık yatırım getirilerini (3, 4), haftalık işletme giderlerini (5, 6), haftalık bağışları ve ödemeleri (7, 8) tahmin eder. Daha sonra bu değerleri göz önüne alarak hesaplama yapar (9), hesaplama sonucunu saklar (10) ve haftalık kullanılabilir birikimlerine ait raporun çıktısını alır (11-15)

75 SEQUENCE DİYAGRAMI Class ve Object diyagramları statik bilgiyi modeller. Hâlbuki gerçek zamanlı sistemlerde zaman içinde değişen etkileşimler bu diyagramlarla gösterilemez. Bu tür zamanla değişen durumları belirtmek için Sequence Diyagramları kullanılır. NOT: Object Diyagram Bir nesne (object) sınıfın (class) bir örneğidir. Bu tür diyagramlarda sınıfın yerine gerçek nesneler kullanılır

76 HAFTALIK KULLANILABİLİR BİRİKİMLERİ TAHMİN ETME USE CASE Use case ait senaryoyu Sequence Diyagramı ile gerçekleştiriyoruz. Sequence diyagamı, collaboration diyagramına eşdeğerdir

77 ETKİLEŞİM DİYAGRAMLARI (INTERACTION DIAGRAMS) Sequence diyagramının gücü, mesajların akışını ve mesajların sırasını açık bir biçimde gösterir. Mesajların sırası özellikle önemlidir. Analiz iş akışı esnasında bilgiler aktarılırken çoğu zaman sequence diyagram kullanan geliştiricilerin dikkat merkezi, collaboration (işbirliği) diyagram kullanan geliştiricilere göre daha üst düzeydedir. Collaboration (işbirliği) diyagram, sınıf diyagramına benzemektedir. Geliştiriciler sınıflara yoğunlaştığında, collaboration diyagramı eşdeğeri sequence diyagramından daha kullanışlıdır

78 Şekil dan Şekil e kadar, rastgele toplanmış UML bileşenleri (artifacts) anlatılmamaktadır. Bunun yerine, bir use case ve bu use case den türemiş bileşenler anlatılmaktadır. Bir sonraki slâytta daha ayrıntılı göreceğiz

79 Şekil da Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case i anlatılmaktadır. Bu şekil, MSG Vakıf çalışanı yani aktör ile MSG Vakfı yazılım ürünü arasındaki bütün olası etkileşimlerin kümesini ve haftalık kullanılabilir birikimlerin tahmini ile ilgili olayları modeller. Şekil da Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case inin tanımı yer almaktadır. Bu şekil, Şekil daki Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case inin detaylarının yazılmasını sağlar

80 Şekil 13.31, Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case ini gerçekleştiren sınıfları gösteren bir sınıf diyagramıdır. Bir sınıf diyagramı (class diagram), use case in bütün olası senaryolarını modellemek için ihtiyaç duyulan sınıfları (classes) ve bu sınıflar (classes) arasındaki ilişkileri gösterir. Şekil 12.32, bir senaryodur. Şekil deki senaryoda, Şekil daki Haftalık Kullanılabilir Birikimleri Tahmin Etme (Estimate Funds Available for Week) use case inin belirli bir örneği anlatılmaktadır

81 Şekil 12.33, Şekil de verilen senaryonun gerçekleştirilmesinde kullanılan bir collaboration (işbirliği) diyagramıdır. Collaboration diyagramı, Şekil de verilen senaryonun gerçekleştirilmesinde nesneler ve nesneler arasında gönderilen mesajları anlatır. Şekil 12.34, Şekil deki senaryonun gerçekleştirilmesinde kullanılan collaboration (işbirliği) diyagram için olayların akışını (flow of events) gösterir. Şekil 12.34, Şekil deki senaryonun gerçekleştirilmesinde yazılmış bir açıklamadır

82 Şekil te gösterilen bir sequence diyagramdır. Bu diyagram, Şekil te gösterilen collaboration diyagrama tamamen eşdeğerdir. Sequence diyagramı, Şekil de verilen senaryonun gerçekleştirilmesinde nesneler ve nesneler arasında gönderilen mesajları anlatır. Sequence diyagramı için olayların akışı (flow of events), Şekil gösterildiği gibidir

83 MAL VARLIĞI YÖNETME (MANAGE AN ASSET) USE CASE İ Şekilde, Mal Varlığı Yönetme use case ve bu use case in aktörleri gösterilmektedir. Burada, vakıf çalışanı ve borçlular olmak üzere iki aktör vardır

84 Mal Varlığı Yönetme Use Case inin Açıklaması Kısa Açıklama Mal Varlığı Yönetme use case i, MSG Vakfı çalışanının, mal varlığı eklemesi ve silmesinde, mal varlıkları ile ilgili portföyün yönetilmesinde yardımcı olur. (mal varlığı yatırımlar ve mortgage lar) Bir mortgage ın yönetimi, Vakıftan borç para alan bir çiftin haftalık gelirinin güncellenmesini içerir. Adım Adım Açıklama 1. Bir yatırım veya mortgage ı ekle, düzenle veya sil, ya da borçlunun haftalık gelirini güncelle

85 Use case i gerçekleştirirken kullanacağımız sınıflar, sınıf diyagramında gösterilmektedir. Mal Varlığı Yönetme Use Case i ile İlgili Bir Senaryo MSG Vakıf çalışanı, Vakfın bir mortgage kredisini sağlayabilmesi için; evin yıllık emlak vergisini güncellemek ister. 1. Çalışan, yıllık emlak vergisinin yeni değerini girer. 2. Bilgi sistemi, yıllık emlak vergisinin en son değişmiş olduğu tarihi günceller

86 Mal Varlığını Yönetme use case ine ait senaryoyu gerçekleştirdiğimizde oluşan collaboration diyagram şekilde görüldüğü gibidir

87 : Investment Class nesnesi bu collaboration diyagramda aktif rol oynamıyor. Çünkü verilen senaryo yatırımlarla ilgili değil, sadece mortgage kredileri ile ilgilidir. Borçlular aktörü de bu use case ait senaryoda rol oynamıyor

88 Mal Varlığını Yönetme use case ine ait senaryoyu gerçekleştirdiğimizde oluşan collaboration diyagrama eşdeğer sequence diyagramı şekilde görüldüğü gibidir

89 Mal Varlığı Yönetme Use Case i ile İlgili Farlı Bir Senaryo MSG Vakfından borç para alan bir çiftin haftalık geliri değişebilir. Borç para alan çiftler, haftalık mortgage ödemelerinin doğru olarak hesaplanması için haftalık gelirleri ile ilgili güncellemenin MSG Vakfı çalışanı tarafından Vakıf kayıtlarında yapılmasını ister. 1. Çalışan, haftalık gelirin yeni değerini girer. 2. Bilgi sistemi, haftalık gelirin en son değişmiş olduğu tarihi günceller

90 Mal Varlığını Yönetme use case ine ait senaryoyu gerçekleştirdiğimizde oluşan collaboration diyagramı şekilde görüldüğü gibidir

91 Borç Alan Kişilerin (Barrowers) isteği ile MSG çalışanı, çiftin haftalık gelirini günceller. Yani burada senaryo Borç Alan Kişiler (Barrowers) tarafından başlatılmaktadır. Borç Alan Kişilere (Barrowers) ait veriler, MSG çalışanı tarafından yazılım ürününe girilecektir. Bu collaboration diyagramda bir not biçiminde belirtilmiştir

92 Mal Varlığını Yönetme use case ine ait senaryoyu gerçekleştirdiğimizde oluşan collaboration diyagrama eşdeğer sequence diyagramı şekilde görüldüğü gibidir

93 Mal Varlığını Yönetme use case i için, iki farklı senaryo sunulmuştur. Aynı use case üzerinde farklı senaryolar olmasına rağmen sınıf diyagramları aynıdır. Buna rağmen, collaboration veya sequence diyagramları, bu iki senaryo arasındaki farkları yansıtır

94 Kullanıcı Ara Yüzü Sınıfı (User Interface Class), bütün gerçekleştirmelerde ortaya çıkmaktadır. Bilgi sisteminin, bütün komutları için aynı ekran kullanılacaktır. Bundan dolayı kullanıcı ara yüzündeki menüde yeniden bir düzenleme yapmalıyız. Buna göre metinsel ara yüzde de düzenleme yapmalıyız

95 Şekilde, Yıllık İşletme Giderlerini Güncelleme (Update Annual Operating Expenses) use case ine ait sınıf diyagramı gösterilmektedir. Yıllık İşletme Giderlerini Güncelleme (Update Annual Operating Expenses) use case ine ait senaryoyu gerçekleştirdiğimizde oluşan collaboration diyagramı şekilde görüldüğü gibidir

96 Yıllık İşletme Giderlerini Güncelleme (Update Annual Operating Expenses) use case ine ait senaryoyu gerçekleştirdiğimizde oluşan sequence diyagramı şekilde görüldüğü gibidir

97 RAPOR ÜRETME (PRODUCE A REPORT) USE CASE İ Şekilde, Rapor Üretme (Produce a Report) use case ve bu use case de aktif rol oynayan aktör gösterilmektedir. Burada, vakıf çalışanı aktördür

98 Rapor Üretme (Produce a Report) Use Case i Kısa Açıklama Rapor Üretme (Produce a Report) use case i, MSG Vakfı çalışanına bütün yatırımların veya mortgage kredilerinin listesini yazdırmasında yardımcı olur. Adım Adım Açıklama 1. Aşağıdaki raporlar üretilebilmelidir: 1.1. Yatırım raporları isteğe bağlı basılır: Bilgi sistemi, bütün yatırımların bir listesini yazdırır. Her bir yatırım için aşağıdaki nitelikleri yazdırır: - Yatırım numarası - Yatırım adı - Tahmini yıllık getiri - Tahmini yıllık getirinin en son güncellenmiş olduğu tarih 1.2. Mortgage raporları isteğe bağlı basılır: Bilgi sistemi, bütün mortgage ların bir listesini yazdırır. Her bir mortgage için aşağıdaki nitelikleri yazdırır: - Hesap numarası - Mortgage kredisine başvuran kişinin soyadı - Evin gerçek fiyatı - Mortgage ın düzenlenmiş olduğu tarih - Anapara ve faiz ödemeleri - İçinde bulunulan hafta için haftalık brüt gelir - İçinde bulunulan hafta için haftalık brüt gelirin en son güncellendiği tarih - Yıllık emlak vergisi - Yıllık emlak vergisinin en son güncellendiği tarih - Evin yıllık sigorta primi - Evin yıllık sigorta primi en son güncellendiği tarih

99 Şekilde, Rapor Üretme (Produce a Report) use case ine ait sınıf diyagramı gösterilmektedir. Rapor Üretme (Produce a Report) Use Case i ile İlgili Bir Senaryo MSG Vakfı çalışanı, bütün mortgage lara ait bir listeyi raporlamak ister. 1. Çalışan, bütün mortgage ların listelendiği raporu almak ister

100 Rapor Üretme (Produce a Report) use case ine ait senaryoyu gerçekleştirdiğimizde oluşan collaboration diyagramı şekilde görüldüğü gibidir

101 Rapor Üretme (Produce a Report) use case ine ait senaryoyu gerçekleştirdiğimizde oluşan sequence diyagramı şekilde görüldüğü gibidir

102 Rapor Üretme (Produce a Report) Use Case i ile İlgili İkinci Bir Senaryo MSG Vakfı çalışanı, bütün yatırımlara ait bir listeyi raporlamak ister. 1. Çalışan, bütün yatırımların listelendiği raporu almak ister

103 Rapor Üretme (Produce a Report) use case ine ait senaryoyu gerçekleştirdiğimizde oluşan collaboration diyagramı şekilde görüldüğü gibidir

104 Rapor Üretme (Produce a Report) use case ine ait senaryoyu gerçekleştirdiğimizde oluşan sequence diyagramı şekilde görüldüğü gibidir

105 SINIF DİYAGRAMLARINI ARTTIRMA: MSG VAKFI ÖRNEK OLAY İNCELEMESİ Bu bölüm boyunca MSG Vakfı ile ilgili olarak ortaya çıkartmış olduğumuz entity, boundary ve control sınıflarını kullanarak çeşitli use case leri gerçekleştirmiş olduk. Burada sınıflar arasındaki ilişkiler açık bir hale gelmiştir. Buna göre gerçekleştirilen sınıf diyagramlarının birleşimi aşağıda görülen şekildedir

106 Sınıf Diyagramının dördüncü iterasyonu sonucu oluşan diyagram şekilde görüldüğü gibidir. YAZILIM PROJE YÖNETİM PLANI Klasik paradigm da olduğu gibi, burada da Yazılım Proje Yönetim Planı (SPMP) bu noktada oluşturulmalıdır. SPMP, Ek F de verilmiştir. Bu plan, IEEE SPMP formatına uymaktadır