YAZILIM MHENDSLANALZ erik Yazlm ster Gereksinim Analizi ster

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

İç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ı)

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.

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

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

İ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

İ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

İ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

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 okunurla

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ımla 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 getir İşlevsel olmayan isterlere özel bir mimariye karar verilebilir tasarıma kısıt getirir.

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

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: � Z 39. 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önlendirilerek sistem sunucusu üzerinde yerel olarak basılacaktır. � Tren sinyalizasyon sistemi � Trenin yavaşlama gibi hesaplanacaktır: Dtrain = Dcontrol + Dgradient

Definitions and specifications

İşlevsel isterler

İşlevsel-olmayan isterler

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

İş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 4 MB den düşük hafıza isteri ile derlemek mümkün olmayabilir. Başka bir geliştirme dili seçimi Hafızayı arttırma

İşlevsel-olmayan isterlerin ölçümü Doğruluğunu sınamak zordur: Kullanılabilecek ola ö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şlevse olmayan ister yazmaya çalışmalısınız

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

İş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.

İşlevsel ve işlevsel-olmayan isterlerin ilgisi Örn. Güvenlik ile ilgili bir işlevsel olmayan kullanıcı isterle 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-olmaya istere örnektir. Her iki çeşit ister arasında net bir ayrım yoktur.

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

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.

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.

Donanım 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.

İç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ı)

İster çözümleme aşamaları Çözümleyici (Analyst): Yeteri deneyime sahip yazı 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

İ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 fikir değiştirmesi Geliştiricinin deneyim eksikliği Ayrıntılı tasarıma geçilince yeni isterlerin gerekliliğinin ortaya çıkma

İ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 isterlerind Yazılım İsterleri belirtimi (SRS) çıkartılmalıdır.

İç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ı)

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.

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

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

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.

Doğal Dile İ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.

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.

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

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ı?

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

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

Çizelge şeklinde gösterim

VAD- Veri Akış Diyagramı Sistem içinde her verinin nasıl taşındığı ve bu veri akış 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

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ü bilginin taşınmasını gösteren grafiksel bir tekniktir.

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

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

VAD Kuralları Her veri deposu bir işlemle ilgili olmalıdır Veri deposu bir 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.

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

VAD Düzeyleri VAD bir sistemi ya da yazılımı herhangi bir soyutlam 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 kaps 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.

VAD Düzeyleri Seviye 0 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 bunla 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.

VAD Örneği Seviye 0 Diyagram

VAD Örneği Seviye 1 Diyagram

VAD Örneği Süreç 2. 0 için Seviye 2 Diyagram

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 ye 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

Analysis Model - UML Function Class diagram Object diagram Use case diagram Activity diagram Data Object Behavior State-chart diagram Interaction diagram Software Engineering Lab. , FCU 56

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 57

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 58

UML Türleri

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. 60

Sıralı Diyagramlar (Sequence diagrams)

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

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 ilişkilendirilir. 63

64

65

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 69

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ı 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 70

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 71

ATM Aktivite Diyagramı 72