YAZILIM MÜHENDİSLİĞİ-ANALİZ

... konulu sunumlar: "YAZILIM MÜHENDİSLİĞİ-ANALİZ"— Sunum transkripti:

1 YAZILIM MÜHENDİSLİĞİ-ANALİZ

2 İçerik Yazılım İster (Gereksinim) Analizi İster Nedir? İster Türleri
Alan İşlevsel, işlevsel olmayan Sistem, Kullanıcı Diğer İster Çözümleme Aşamaları İster Çözümleme Yöntemleri Doğal Dil Yapısal Doğal Dil Formlar, şablonlar aracılığı ile ifade Grafiksel Gösterim Veri Akış Şemaları UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi Geçerleme,Gözden Geçirme Sonuç: The software requirements document (Yazılım İster (Gereksinim) Dökümanı)

3 Yazılım İsterleri Çözümlemesi
 Bir bilgisayar programının başarısı öncelikle müşteri isteklerini tam olarak karşılamasına bağlıdır.  Yazılım isterleri çözümleme aşaması  Müşterinin yazılımdan bekledikleri belirlenir  Gereksinimler açıklığa kavuşturulur  Yazılım isterleri modellenir ve tanımlanır  Böylece de sonraki aşamalar için temel oluşturulur.

4 İster  Kullanıcı ve sistem isterleri nelerdir?
 İster nedir?  İster çeşitleri  Kullanıcı ve sistem isterleri nelerdir?  İşlevsel (functional) ve işlevsel-olmayan (non-functional) isterler nelerdir?

5 İster nedir?  İster (gereksinim): gerekli olan, istenen veya ihtiyaç duyulan.*  IEEE 729  Kullanıcı tarafından bir problemi çözme ya da bir hedefi gerçekleştirmek için ihtiyaç duyulan durum ya da yetenek * ** Pressman, R. Software Engineering: A Practitioner’s approach

6 İster mühendisliği nedir?
 Tüm bu hizmet ve kısıtlamaların  belirlenmesi  çözümlenmesi  belgelendirilmesi  ve kontrol edilmesi sürecine İster (Gereksinim) Mühendisliği denir

7 İsterler neden önemlidir?
 İsterlerden kaynaklı hatalar geç aşamalarda fark edilir  Genellikle yanlış bilgi, ihmal ve tutarsızlık kaynaklıdır  Bu durumda da düzeltilme maliyetleri yüksek olur

8 İster Türleri Görevlerine Göre İşlevsel (Functional) İşlevsel Olmayan (Nonfunctional) Detay Seviyesine Göre Kullanıcı Sistem Alan İsterleri Diğer İsterler?? İsterleri farklı detay seviyelerinde yazmak gereklidir çünkü farklı okuyucular onları farklı şekillerde kullanacaklardır

9 Kullanıcı İsterleri  İşlevsel ve işlevsel olmayan gereksinimleri tanımlamalı, böylece detaylı teknik bilgiye sahip olmayan sistemin kullanıcıları tarafından da anlaşılabilmelidir.  Kullanıcı isterleri, doğal dil, basit tablo ve formlar ve şemalar ile tanımlanır.  Sadece sistemin harici davranışlarını belirtmeli ve mümkün olduğunca tasarım özelliklerine girmekten kaçınmalıdır.  Çoğunlukla, teknik-olmayan okuyucular tarafından okunurlar

10 Sistem İsterleri  Kullanıcı isterlerinin daha detaylı belirtimidir  Sistemi tasarlamak için temel oluşturur.  İdeal olarak, basitçe, harici davranış ve kısıtlamaları tanımlar. Tasarım ve uygulama ile ilgilenmemelidir.  Fakat pratikte, tasarım bilgisi bulundurabilir.  İster belirtimine yardımcı olabilmek için bir başlangıç mimarisi tasarlanabilir  tasarımda yeniden kullanılabilir  Başka var olan sistemlerle arayüzü bulunabilir  tasarıma kısıt getirir  İşlevsel olmayan isterlere özel bir mimariye karar verilebilir  tasarıma kısıt getirir.

11 Uygulama Alanı isterleri
İşlevsel veya işlevsel olmayan?? Her ikisi de olabilir. Alana özel gereksinimler, sistemin çalışacağı ortam. Kullanım ortamında gözlem yapılarak nelere gereksinim duyulduğu ve işin kapsamı belirlenir. Benzer ürünler incelenir, onlardan temel isterler çıkarılır. Gerekirse bu bilgiler bir kapsam tanımlama belgesinde toplanır

12 Uygulama Alanı isterleri
Mevcut gereksinimleri yeni fonksiyonel gereksinimleri, kısıtlamalar ekleyebilir Bu gereksinimler yerine getirilmezse sistem çalışamaz. Kütüphane sistemi uygulama alanı isterleri: Z39.50 standardı esas alınacaktır tüm veritabanları için standart bir kullanıcı arayüzü olacaktır. Telif kısıtlamalarıdan dolayı, bazı belgeleri ulaştığında hemen silinmelidir.Kullanıcı gereksinimlerine bağlı olarak, bu belgeler ya elle kullanıcıya yönlendirme veya bir ağ yazıcısı yönlendirilirilerek sistem sunucusu üzerinde yerel olarak basılacaktır. Tren sinyalizasyon sistemi Trenin yavaşlama gibi hesaplanacaktır: Dtrain = Dcontrol + Dgradient

13

14 Definitions and specifications

15 İşlevsel isterler

16 İşlevsel-olmayan isterler

17 İşlevsel-olmayan ister çeşitleri
olmayan İsterler Ürün Kurum isterleri Harici isterler isterleri Kullanıla Verim Güven Taşına Teslim Gerçek bilirlik leştirim Standart Birlikte Etik Yasal bilirlik lilik ilirlik lar işlerlik İsterler isterler Performans isterleri Gizlilik isterleri Alan isterleri Güvenlik isterleri

18 İşlevsel-olmayan ister örnekleri
 İşlevsel olmayan isterler diğer işlevsel olmayan ya da işlevsel isterler ile çakışabilir ya da etkileşebilir.  Örn.  Sistem tarafından kullanılacak maksimum hafiza 4 MB den fazla olmayacak.  Sistem ADA kullanılarak yazılacak. Ada programını istenen 4MB den düşük hafıza isteri ile derlemek mümkün olmayabilir.  Başka bir geliştirme dili seçimi  Hafızayı arttırma

19 İşlevsel-olmayan isterlerin ölçümü
 Doğruluğunu sınamak zordur: Kullanılabilecek olası ölçüm yolları (metric) vardır.  Ama bazılarını belirlemek zordur: bakım gibi  Mümkün olduğunca doğruluğu sınanabilecek işlevsel- olmayan ister yazmaya çalışmalısınız

20 İşlevsel-olmayan ister ölçütleri (metrics)
 Hız:  Güvenilirlik  İşlenen işlem/saniye  Ekran yenileme  Ortalama hata sayısı zamanı (MTF-Mean Time to failure)  Kullanımda olmama olasılı ğ ı  Sağlamlık  Boyut:  K bytes  Ram miktarı  Hata sonrası yeniden başlatma zamanı  Kullanım kolaylığı  Gerekli eğitim süresi  Hataya neden olan olay yüzdesi  Yardım ekranlarının sayısı  Taşınabilirlik  Hedef sistem sayısı  Hedefe bağımlı anlatım yüzdesi

21

22 İşlevsel-olmayan ister örnekleri
 Sistem, deneyimli bir kontrolör tarafından kolayca kullanılmalı ve kullanıcı hataları en aza indirilecek şekilde organize edilmelidir.  Doğruluğu sınanabilecek şekilde yeniden yaz:  Deneyimli kontrolörler sistem fonksiyonlarını 2 saatlik bir eğitim sonrasında kolaylıkla kullanabileceklerdir. Bu eğitimden sonra, deneyimli kullanıcıların ortalama hata yapma oranı günde 2 defayı geçmeyecektir.

23 İşlevsel ve işlevsel-olmayan isterlerin ilgisi
 Örn. Güvenlik ile ilgili bir işlevsel olmayan kullanıcı isterleri bir takım işlevsel isterlerin oluşmasına neden olabilir  Kimlik denetleme özelliği: oturum yönetimi, cookie, vb  Kimlik denetleme işlevi hem işlevsel hem işlevsel-olmayan istere örnektir.  Her iki çeşit ister arasında net bir ayrım yoktur.

24 Diğer İsterler Davranış şeklinde ifade edilemeyen isterlerdir. (non-behavioral requirements) Arayüz İsterleri (Interface Requirements) Kullanıcı Arayüzleri Yazılım Arayüzleri Donanınım Arayüzleri İletişim Arayüzleri

25 Kullanıcı Arayüzü Yazılım ürünü ile kullanıcısı arasındaki her bir arayüzün mantıksal özellikleri açıklanmalıdır. Bu özellikler, yazılım ihtiyaçlarının giderilmesine yönelik olan ekranformatları, pencere görünümleri, menü ya da rapor içerikleri, programlanabilir fonksiyon tusları gibi konfigürasyon özellikleridir. Ayrıca arayüzler ile sistemin kendisini kullananlara nasıl görünmesi gerektigi de tarif edilmelidir.

26 Yazılım Arayüzleri Diger gerekli yazılım ürünlerinin kullanımı ve ürünün yazılımlar ile olan arayüzleri burada ortaya konmalıdır. Gerekli her bir yazılım ürünü için, isim, spesifikasyon numarası, versiyon ve kaynak belirtilmelidir. Tanımlanan her bir arayüz, mesaj içerigi ve format yönünden açıklanmalıdır.

27 Donanım Arayüzleri İletişim Arayüzleri
Burada yazılım ürünü ile donanım bilesenleri arasındaki her bir arayüzün mantıksal özellikleri verilmelidir. Bunun yanında örnek olarak; hangi cihazların desteklenecegi, nasıl ve hangi protokollerle desteklenecegi gibi noktalar da belirtilmelidir. İletişim Arayüzleri Yerel ag protokolleri..vs gibi iletisim arayüzleri burada açıklanmalıdır.

28 İçerik Yazılım İster (Gereksinim) Analizi İster Nedir? İster Türleri
Alan İşlevsel, işlevsel olmayan Sistem, Kullanıcı Diğer İster Çözümleme Aşamaları İster Çözümleme Yöntemleri Doğal Dil Yapısal Doğal Dil Formlar, şablonlar aracılığı ile ifade Grafiksel Gösterim Veri Akış Şemaları UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi Geçerleme,Gözden Geçirme Sonuç: The software requirements document (Yazılım İster (Gereksinim) Dökümanı)

29 İster çözümleme aşamaları
 Çözümleyici (Analyst): Yeteri deneyime sahip yazılım isteri çözümlemesi yapan kişi  Çözümleme çalışmaları beş başlık altında incelenebilir:  Problemin anlaşılması  Problemin çözümlenmesi  Modelleme  Belirtim  Gözden geçirme

30 İsterlerin değişmesi  İsterlerin çözümlenmesi ne kadar iyi yapılırsa yapılsın, süreç sırasında da isterlerde değişiklik meydana gelebilir:  Müşteri ve geliştirici arasındaki iletişimin yeterli olmaması  Bu aşamaya çabuk geçebilmek için bazı varsayım ya da kabullenmeler yapılmış olması  Müşterinin ne istediğini tam bilememesi ve sık sık fikir değiştirmesi  Geliştiricinin deneyim eksikliği  Ayrıntılı tasarıma geçilince yeni isterlerin gerekliliğinin ortaya çıkması

31 İsterlerin Belirlenmesi
 Sistemin başarısı, sistemden ne istendiğinin doğru olarak algılanmasına bağlıdır  Bunun için düzeylere ayrılmış sistem isterlerinden Yazılım İsterleri belirtimi (SRS) çıkartılmalıdır. 

32 İçerik Yazılım İster (Gereksinim) Analizi İster Nedir? İster Türleri
Alan İşlevsel, işlevsel olmayan Sistem, Kullanıcı Diğer İster Çözümleme Aşamaları İster Çözümleme Yöntemleri Doğal Dil Yapısal Doğal Dil Formlar, şablonlar aracılığı ile ifade Grafiksel Gösterim Veri Akış Şemaları UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi Geçerleme,Gözden Geçirme Sonuç: The software requirements document (Yazılım İster (Gereksinim) Dökümanı)

33 Gereksinim Çıkarma ve Analizi – Zorluklar
Yazılım gelistirme çalısmalarının ön asamaları Kimse birbirini tanımıyor, sistemi bilmiyor Yöntem, teknoloji, vb. yeni olabilir Kullanıcı odaklı problemler yasanabilir. Kullanıcılar ne istediklerini bilmeyebilir. Kullanıcılar isteklerini kendi terimleriyle ifade edebilir. Farklı kullanıcıların çelisen istekleri olabilir. Farklı grupların beraber çalısmasını gerektiriyor. Kullanıcı grupları, analiz uzmanları, mimari/tasarım uzmanları Kurumsal ve politik etkenler sistem gereksinimlerini etkileyebilir. Analiz boyunca gereksinimler degisebilir; yeni kullanıcılar çıkabilir ve is ortamı degisebilir.

34 Gereksinim Geçerleme Gereksinimlerin müsterinin istedigi sistemi tanımladıgını güvence altınaalmayı hedefler. Gereksinimlerden kaynaklanan bir hatayı sonradan düzeltmenin maliyeti yüksek oldugundan, geçerleme büyük önem tasır. Gereksinim geçerleme teknikleri: Gözden geçirme – gereksinimlerin sistematik ve paydaslara dayalı analizi Prototip olusturma – sistemin çalısan bir taslagı üzerinden kontrol Test durumu gelistirme – sistemin test edilebilirligini kontrol amacıya gereksinimler için test durumu gelistirme

35 Gözden Geçirme Gözden geçirme çalısmalarında hedefimiz, yazılım gereksinimlerinin asagıdaki özellikleri tasıdıgından emin olmaktır: Tam ve dogru Anlasılabilir Tutarlı Test edilebilir Diger belgelerde tanımlanan is/kullanıcı/sistem gereksinimlerine izlenebilir

36 Gereksinimler ve Tasarım
Gereksinimler, sistemin “ne” yapacagını tanımlar. Tasarım, sistemin tanımlanan gereksinimlerinin “nasıl” gerçeklestirilecegini belirtir. Pratikte, gereksinimler ve tasarım her zaman net olarak ayrılamayabilir. Sistem mimarisi, gereksinimleri yapısallastırmak için tasarlanır. Sistem islevleri, tasarımı kısıtlayan diger sistemlerle iliski içinde gerçeklestiriliyor olabilir. Müsteri tarafından, sistemin özel bir tasarıma uyması isteniyor olabilir. Gereksinimlerin türlerine göre ayrı baslıklar altında tanımlanması, bu karısıklıgı azaltacaktır.

37 Doğal Dile İle İlgili Problemler
Muglaklık (“Ambiguity”) Gereksinimler, okuyan herkes tarafından aynı yorumlanacak sekilde yazılmalıdır. Dogal dil muglak ifadelere açıktır. Asırı esneklik (“Over-flexibility”) Bir gereksinim, dogal dil ile çok farklı sekillerde ifade edilebilir. Modülerligin olmayısı (“Lack of modularisation”) Dogal dilin ögeleri, sistem gereksinimlerini yapısallastırmak için yetersiz kalmaktadır. Bu problemlere ragmen dogal dilin kullanılması, müsteri ve gelistirici arasındaki iletisim açısında önem tasımaktadır.

38 Gereksinimleri Yazmak İçin Öneriler:Doğal Dil Kullanımı İçin
Standart bir biçim belirleyerek gereksinimleri tanımlarken kullanın. Her gereksinime bir numara verin. Dogal dili tutarlı olarak kullanın. Zorunlu ve seçimli gereksinimleri farklı kalıplarla ifade edin. Gereksinimlerin önemli kısımlarını ayırt etmek için farklı yazı tipi (büyük harf, alt çizme, farklı renk, vb.) kullanın. Bilgisayar terimlerini kullanmaktan kaçının.

39 Gereksinimlerin Bulanıklıgı
Gereksinimler net olarak ifade edilmedigi zaman problemler yasanır. Bulanık gereksinimler gelistiriciler ve kullanıcılar tarafından farklı algılanabilir. Örnek: “Sistem, kullanıcının doküman ambarındaki dokümanları okuması için, uygun görüntüleyiciler saglamalıdır.” “uygun görüntüleyiciler”: Kullanıcı yorumu : her farklı doküman tipi için farklı kullanıcı Gelistirici yorumu : her dokümanın içerigini gösteren bir metin görüntüleyici

40 Gereksinimlerin Tamlığı ve Tutarlılıgı
Gereksinimler tam ve birbiriyle tutarlı olarak ifade edilmelidir. Tamlık : Sistemin beklenen tüm özellikleri tanımlanmalıdır. Tutarlılık: Sistemin tanımlanan özellikleri arasında çeliskiler bulunmamalıdır. Pratikte, dogal dilden kaynaklanan zorluklar sebebiyle, gereksinimleri tam ve tutarlı olarak ifade etmek çok kolay degildir. Tanımlanan gereksinimlerin ilgili tüm kisilerce gözden geçirilmesi, tamlıgı ve tutarlılıgı büyük ölçüde saglamanın en basit yoludur. VAD kullanılması durumunda aşağıdaki gibi kriterler denetlenmelidir Bütün süreçlerin girdi ve çıktıları var mı? Süreçler, veri akışları, dış birim ve veri depoları uygun şekilde adlandırılıp numaralandırılmış mı? Planlama aşamasında öngörülen belirtimlerin hepsi ele alınmış mı?

41 Doğal Dile Alternatifler
Yapısal Doğal Dil Formlar, şablonlar aracılığı ile ifade Grafiksel Gösterim VAD UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi

42 Yapısal Dogal Dil – Örnek: Form Esaslı Tanımlama

43 Çizelge şeklinde gösterim

44 VAD- Veri Akış Diyagramı
 Sistem içinde her verinin nasıl taşındığı ve bu veri akışını sağlayan fonksiyonların (işlevlerin) neler olduğu veri akış diyagramında (VAD-DFD) tarif edilir.  Sistemin varlıkları  Süreçleri  Sistemdeki veri depoları  Ve bunlar arasındaki verinin nasıl aktığını gösterir

45 VAD- Veri Akış Diyagramı
 Bilgi bilgisayar sistemi içerisinde akarken dönüşür  Sistem çeşitli formlarda girdi alır ve bu girdileri yazılım, donanım ve insan elemanları ile işleyerek çeşitli formdaki çıktılara dönüştürür.  VAD verinin girişten çıkışa dek olan dönüşümü ve bilginin taşınmasını gösteren grafiksel bir tekniktir.

46 VAD simgeleri Anlam Simge - 1 Simge - 2 Örnek Dış varlık İşlem (süreç)
Öğrenci İşlem (süreç) Veri akışı Veri deposu Veri deposu

47 VAD Kuralları İşlemin sadece çıkışı olamaz. İşlemin sadece girişi
İşlem girişleri istenen çıkışı verecek kadar yeterli olmalıdır.

48 VAD Kuralları Her veri deposu bir işlemle ilgili olmalıdır
varlıkla doğrudan ilişkide olamaz Veri akış oku çift yönlü olamaz. Bir işlemle veri deposu arasında karşılıklı veri akışı varsa farklı tek yönlü oklarla gösterilmelidir.

49 VAD Kuralları Bir işlemden farklı iki işleme gidecek olan
aynı veri, aynı yönde iki uçlu okla gösterilmelidir. Veri hiçbir işlemden geçmeden çıktığı işleme doğrudan dönmez Veri akış okları üzerinde gösterilen veri, sadece isim formatında olmalıdır

50 VAD Düzeyleri gösterilerek girdi ve çıktılargelen ve çıkan oklar ile
 VAD bir sistemi ya da yazılımı herhangi bir soyutlama düzeyinde göstermek için kullanılabilir.  VAD artan bilgi akışı ve işlevsel detayları içerecek şekilde çeşitli seviyelere bölünebilir.  Seviye 0 olarak gösterilen VAD aynı zamanda kapsam diyagramı(temel sistem modeli) olarak da adlandırılır:Tüm sistem tek bir balon içerisinde gösterilerek girdi ve çıktılargelen ve çıkan oklar ile ifade edilirler.

51 VAD Düzeyleri olan VAD daha detaylı bilgi akışı ve
 Seviye olan VAD daha detaylı bilgi akışı ve süreçleri içerecek şekilde ek süreçlere (balonlara) ayrılır.  Seviye 1 VAD 5 ya da 6 süreç(balon) ve bunlar arasındaki akışları gösterir.  Seviye 1 de gösterilen süreçler kapsam modelinde yer alan ana sistemin alt fonksiyonlarını içerir.

52 VAD Örneği  Seviye 0 Diyagram

53 VAD Örneği  Seviye 1 Diyagram

54 VAD Örneği  Süreç 2.0 için Seviye 2 Diyagram

55 VAD çizim yöntemi  Süreç hikayesi gramer olarak ayrıştırılır. (tüm isim ve fiiller ayrıştırılır)  Eş anlamlı olan isim ve fiiller atılır.  Gramatik ayrıştırmaya dayalı olarak bir model çıkmaya başlar:  Tüm fiiller sistem süreçleridir: VAD içerisinde balonlar içerisinde yer alır  Tüm isimler harici varlıklar, veri öğesi ya da veri deposudur.  Seviye 0 VAD çizilir  Seviye 0 Seviye 1 modele detaylandırılır daha sonra da Seviye 1’deki süreçler Seviye 2 olarak detaylandırılırlar

56 Analysis Model - UML Function Data Behavior Class diagram
Object State-chart diagram Interaction diagram Class diagram Object diagram Use case diagram Activity diagram Data Behavior Function

57 Unified Modeling Language (UML)
Yazılım sistemlerinin modellemesi için geliştirilmiş standart bir dildir Yazılım is ürünlerinin; tanımlanması, görsel hale getirilmesi, belgelendirilmesi Açık standarttır; birçok araç tarafından desteklenir Tüm yazılım geliştirme sürecini destekler Çıkış hedefleri: Kullanımı kolay, görsel bir modelleme dili sunmak Programlama dillerinden ve geliştirme sürecinden bağımsız olmak En iyi yöntemleri bütünleştirmek

58 Unified Modeling Language (UML)
Sundukları: Yazılım ürünlerinin gösterimi için yapı tasları ve ilişkiler Sunmadıkları: Sisteminin nasıl gelistirilmesi gerektigini tanımlamaz Nesne yönelimli yazılım modellemesi için yapılar sunar, ancak; Bu yapıların hangi sıra ile kullanılması gerektigini tanımlamaz Yapıların gelistirme sürecinin hangi asamalarında kullanılması gerektigini tanımlamaz

59 UML Türleri

60 UML Türleri Use case diyagramı:       Aktörler ve use case’ler arasındaki ilişkiyi gösterir. Etkinlik (Activity) diyagram:        Çoğu durumun eylem durumu olduğu ve geçişlerin bir durumdaki eylemin sonuçlanması ile tetiklendiği özel bir durum diyagramı türüdür. Bu diyagram daha çok iç işlemler esnasındaki akışı gösterir.

61 Sıralı Diyagramlar (Sequence diagrams)

62 Use Case Elemanları Aktör: Sistemin kullanıcıları
Use-case: Sistemin destekleyeceği isler

63 Use Case Elemanları . "uses" ilişkisi ana use case in bir alt kümesidir, “extends" ilişkisi ise ana use case den farklı özellikleri (alternatif seçenekleri) olan bir use case ile ilişkilendirilir.

64

65

66

67

68

69 Gereksinim Analizinde Use Case
Bakıs açısı: Sistem, kullanıcısı için “ne” yapacak ? Sistem kapalı bir kutu (“black-box”) Sistem-kullanıcı etkilesimi Sistemin dısarıdan görünen davranısı Ilgilenmediklerimiz: Sistemin iç yapısı Sistem belirlenen davranısı “nasıl” yapacak ? Belirlenen davranıs “nasıl” kodlanacak ? Bu bakıs açısı, sistemdeki tüm islevselligi degil, kullanıcılar için artı deger olusturacak islemleri düsünmemizi saglar

70 Gereksinim Analizinde Use Case
Kullanıcının gereksinimi olmayan özellikleri tanımlamamızı engeller Kullanıcının da anlayabilecegi sekilde sistemin davranıslarını ve sorumluluklarını tanımlar Kullanıcı ile iletisimi kolaylastırır Kullanıcı arayüzlerinin tasarlanmasını kolaylastırır Kullanıcı kılavuzlarını yazarken baslangıç noktasını olusturur Gelistirme sürecini baslatır ve tüm temel is adımlarını birbirine baglar Tasarlanacak test durumlarına esas olusturur

71 Aktivite Diyagramları
Genel olarak bir akısı veya islemi göstermek için kullanılırlar. (“flowchart” benzeri bir yapı) Activity diyagramın içerisinde Etkinlik (“activity”) Sistem ve aktörler tarafından yapılan isleri ifade etmek için kullanılır Geçis (“transition”) Etkinlikler arasındaki geçisleri ifade etmek için kullanılır

72 ATM Aktivite Diyagramı