YAZILIM MÜHENDİSLİĞİ
This presentation is the property of its rightful owner.
Sponsored Links
1 / 72

YAZILIM MÜHENDİSLİĞİ -ANALİZ PowerPoint PPT Presentation


  • 226 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Yazilim m hend sl anal z

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


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


  • Yazilim m hend sl anal z

    Yazılım İsterleri Çözümlemesi

    Birbilgisayarprogramınınbaşarısıönceliklemüşteriisteklerini tam olarakkarşılamasınabağlıdır.

    Yazılımisterleriçözümlemeaşaması

    Müşterininyazılımdanbekledikleribelirlenir

     Gereksinimler açıklığa kavuşturulur

     Yazılım isterleri modellenir ve tanımlanır

    Böylece de sonrakiaşamalariçintemeloluşturulur.


    Yazilim m hend sl anal z

    İster

     İster nedir? İster çeşitleri

     Kullanıcı ve sistem isterleri nelerdir?

     İşlevsel (functional) ve işlevsel-olmayan (non-functional)isterler nelerdir?


    Yazilim m hend sl anal z

    İster nedir?

    İster (gereksinim): gerekliolan, istenenveyaihtiyaç duyulan.*

     IEEE 729

    Kullanıcıtarafındanbirproblemiçözmeyadabirhedefigerçekleştirmekiçinihtiyaçduyulan durum yadayetenek

    * http://www.webster.com

    ** Pressman, R. Software Engineering: A Practitioner’s approach


    Yazilim m hend sl anal z

    İ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


    Yazilim m hend sl anal z

    İsterlernedenönemlidir?

     İsterlerden kaynaklı hatalargeç aşamalarda fark edilir

     Genellikle yanlış bilgi, ihmalve tutarsızlık kaynaklıdır

     Bu durumda da düzeltilmemaliyetleri yüksek olur


    Ster t rleri

    İster Türleri

    • Görevlerine Göre

      • İşlevsel (Functional)

      • İşlevsel Olmayan (Nonfunctional)

    • Detay Seviyesine Göre

      • Kullanıcı

      • Sistem

    • Alan İsterleri

    • Diğer İsterler??

    • İsterlerifarklıdetayseviyelerindeyazmakgereklidirçünküfarklıokuyucularonlarıfarklışekillerdekullanacaklardır


    Yazilim m hend sl anal z

    Kullanıcı İsterleri

    İşlevselveişlevselolmayangereksinimleritanımlamalı,böylecedetaylıteknikbilgiyesahipolmayansisteminkullanı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ünolduğunca tasarım özelliklerine girmekten kaçınmalıdır.

     Çoğunlukla, teknik-olmayan okuyucular tarafından okunurlar


    Yazilim m hend sl anal z

    Sistem İsterleri

    KullanıcıisterlerinindahadetaylıbelirtimidirSistemitasarlamakiçintemeloluşturur.

     İdeal olarak, basitçe, haricidavranışvekısıtlamalarıtanımlar.Tasarımveuygulamaileilgilenmemelidir.

     Fakat pratikte, tasarım bilgisi bulundurabilir.

     İster belirtimine yardımcı olabilmek için bir başlangıç mimarisitasarlanabilir  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.


    Uygulama alan isterleri

    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 isterleri1

    Uygulama Alanı isterleri

    • Mevcut gereksinimleri yeni fonksiyonel gereksinimleri, kısıtlamalar ekleyebilirBu 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


    Definitions and specifications

    Definitions and specifications


    Yazilim m hend sl anal z

    İşlevselisterler


    Yazilim m hend sl anal z

    İşlevsel-olmayanisterler


    Yazilim m hend sl anal z

    İşlevsel-olmayan ister çeşitleri

    İşlevsel-

    olmayanİsterler

    Kurumisterleri

    Hariciisterler

    Ürün

    isterleri

    TaşınaTeslimGerçekbilirlikleştirim

    StandartBirlikte

    EtikYasal

    KullanılaVerimGüven

    larişlerlik

    İsterleristerler

    bilirliklilikilirlik

    Gizlilikisterleri

    Performansisterleri

    Alanisterleri

    Güvenlikisterleri


    Yazilim m hend sl anal z

    İşlevsel-olmayan ister örnekleri

    İşlevselolmayanisterlerdiğerişlevselolmayanya daişlevselisterlerileçakışabilirya da etkileşebilir.

     Örn.

     Sistem tarafından kullanılacak maksimum hafiza 4 MB den fazlaolmayacak.

     Sistem ADA kullanılarak yazılacak.

    Ada programını istenen4MB den düşük hafıza isteri ile

    derlemek mümkün olmayabilir.

     Başka bir geliştirme dili seçimi Hafızayı arttırma


    Yazilim m hend sl anal z

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


    Yazilim m hend sl anal z

    İşlevsel-olmayanisterö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şlatmazamanı

    KullanımkolaylığıGereklieğitimsü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


    Yazilim m hend sl anal z

    İşlevsel-olmayan ister örnekleri

     Sistem, deneyimli bir kontrolör tarafından kolaycakullanılmalı ve kullanıcı hataları en aza indirilecek

    şekilde organize edilmelidir.

    Doğruluğusınanabilecekşekildeyenidenyaz:

     Deneyimli kontrolörler sistem fonksiyonlarını 2 saatlik bireğitim sonrasında kolaylıkla kullanabileceklerdir. Bueğitimden sonra, deneyimli kullanıcıların ortalama hatayapma oranı günde 2 defayı geçmeyecektir.


    Yazilim m hend sl anal z

    İşlevselveişlevsel-olmayanisterlerinilgisi

     Örn. Güvenlik ile ilgili bir işlevsel olmayan kullanıcı isterleribir takım işlevsel isterlerin oluşmasına neden olabilir

    Kimlikdenetlemeözelliği: oturumyönetimi, cookie, vb

     Kimlik denetleme işlevi hem işlevsel hem işlevsel-olmayanistere örnektir.

     Her iki çeşit ister arasında net bir ayrım yoktur.


    Di er sterler

    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


    Kullan c aray z

    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

    Yazılım Arayüzleri

    Digergerekli yazılım ürünlerinin kullanımı ve ürünün yazılımlar ile olan arayüzleriburada ortaya konmalıdır.

    Gerekli her bir yazılım ürünü için, isim, spesifikasyonnumarası, versiyon ve kaynak belirtilmelidir.

    Tanımlanan her bir arayüz, mesaj içerigive format yönünden açıklanmalıdır.


    Donan m aray zleri

    Donanım Arayüzleri

    Burada yazılım ürünü ile donanım bilesenleri arasındaki her bir arayüzünmantı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 iletisimarayüzleri burada açıklanmalıdır.


    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

      • 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ı)


  • Yazilim m hend sl anal z

    İster çözümleme aşamaları

    Çözümleyici (Analyst): Yeterideneyimesahipyazılımisteriçözümlemesiyapankişi

     Çözümleme çalışmaları beş başlık altındaincelenebilir:

     Problemin anlaşılması

     Problemin çözümlenmesi Modelleme

     Belirtim

     Gözden geçirme


    Yazilim m hend sl anal z

    İ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 dakabullenmeler 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ı


    Yazilim m hend sl anal z

    İsterlerin Belirlenmesi

     Sistemin başarısı, sistemden ne istendiğinin doğruolarak algılanmasına bağlıdır

     Bunun için düzeylere ayrılmış sistem isterlerindenYazılım İsterleri belirtimi (SRS) çıkartılmalıdır.


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


  • Gereksinim karma ve analizi zorluklar

    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

    Gereksinim Geçerleme

    • Gereksinimlerin müsterininistedigi 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

    • 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 ve Tasarım

    • Gereksinimler, sistemin “ne” yapacagını tanımlar.

    • Tasarım, sistemin tanımlanan gereksinimlerinin “nasıl” gerçeklestirileceginibelirtir.

    • 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 iliskiiçinde gerçeklestiriliyorolabilir.

    • 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 le lgili problemler

    Doğal Dile İle İlgili Problemler

    • Muglaklık (“Ambiguity”)

      • Gereksinimler, okuyan herkes tarafından aynı yorumlanacak sekildeyazı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ülerliginolmayısı (“Lack of modularisation”)

      • Dogal dilin ögeleri, sistem gereksinimlerini yapısallastırmak için yetersiz kalmaktadır.

    • Bu problemlere ragmendogal dilin kullanılması, müsteri ve gelistiriciarasındaki iletisim açısında önem tasımaktadır.


    Gereksinimleri yazmak in neriler do al dil kullan m in

    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

    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

    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

    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

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


    Izelge eklinde g sterim

    Çizelge şeklinde gösterim


    Yazilim m hend sl anal z

    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


    Yazilim m hend sl anal z

    VAD- Veri Akış Diyagramı

     Bilgi bilgisayar sistemi içerisinde akarken dönüşür

     Sistem çeşitli formlarda girdi alır ve bu girdileriyazı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ü vebilginin taşınmasını gösteren grafiksel bir tekniktir.


    Yazilim m hend sl anal z

    VAD simgeleri

    Anlam

    Simge - 1

    Simge - 2

    Örnek

    Dış varlık

    Öğrenci

    İşlem

    (süreç)

    Veri akışı

    Veri deposu

    Veri deposu


    Yazilim m hend sl anal z

    VAD Kuralları

    İşlemin sadece çıkışıolamaz.

    İşlemin sadece girişi

    olamaz.

    İşlem girişleri istenençıkışı verecek kadar

    yeterli olmalıdır.


    Yazilim m hend sl anal z

    VAD Kuralları

    Her veri deposu birişlemle ilgili olmalıdır

    Veri deposu bir

    varlıkla doğrudan

    ilişkide olamaz

    Veri akış oku çift yönlüolamaz. Bir işlemleveri deposu arasındakarşılıklı veri akışıvarsa farklı tek yönlüoklarla gösterilmelidir.


    Yazilim m hend sl anal z

    VAD Kuralları

    Bir işlemden farklı iki

    işleme gidecek olan

    aynı veri, aynı yöndeiki uçlu okla

    gösterilmelidir.

    Veri hiçbir işlemdengeçmeden çıktığıişleme doğrudandönmez

    Veri akış okları

    üzerinde gösterilen

    veri, sadece isim

    formatında olmalıdır


    Yazilim m hend sl anal z

    VAD Düzeyleri

     VAD bir sistemi ya da yazılımı herhangi bir soyutlamadü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 kapsamdiyagramı(temel sistem modeli) olarak daadlandırılır:Tüm sistem tek bir balon içerisinde

    gösterilerek girdi ve çıktılargelen ve çıkan oklar ile

    ifade edilirler.


    Yazilim m hend sl anal z

    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 bunlararasındaki akışları gösterir.

     Seviye 1 de gösterilen süreçler kapsam modelindeyer alan ana sistemin alt fonksiyonlarını içerir.


    Yazilim m hend sl anal z

    VAD Örneği

     Seviye 0 Diyagram


    Yazilim m hend sl anal z

    VAD Örneği

     Seviye 1 Diyagram


    Yazilim m hend sl anal z

    VAD Örneği

     Süreç 2.0 için Seviye

    2 Diyagram


    Yazilim m hend sl anal z

    VAD çizim yöntemi

     Süreç hikayesi gramer olarak ayrıştırılır. (tüm isim ve fiillerayrıştırılır)

     Eş anlamlı olan isim ve fiiller atılır.

     Gramatik ayrıştırmaya dayalı olarak bir model çıkmayabaşlar:

     Tüm fiiller sistem süreçleridir: VAD içerisinde balonlar içerisinde yeralı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 daSeviye 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

    Object

    Data

    Behavior

    State-chart diagram

    Interaction diagram

    Analysis Model - UML


    Unified modeling language uml

    UnifiedModeling 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


    Unified modeling language uml1

    UnifiedModeling Language (UML)

    • Sundukları:

      • Yazılım ürünlerinin gösterimi için yapı tasları ve ilişkiler

      • Sunmadıkları:

      • Sisteminin nasıl gelistirilmesigerektigini 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


    Uml t rleri

    UML Türleri


    Uml t rleri1

    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.


    S ral diyagramlar sequence diagrams

    Sıralı Diyagramlar (Sequencediagrams)


    Use case elemanlar

    Use Case Elemanları

    • Aktör: Sistemin kullanıcıları

    • Use-case: Sistemin destekleyeceği isler


    Use case elemanlar1

    Use Case Elemanları

    • .

    • "uses" ilişkisi ana usecase in bir alt kümesidir, “extends" ilişkisi ise ana usecase den farklı özellikleri (alternatif seçenekleri) olan bir usecase ile ilişkilendirilir.


    Gereksinim analizinde use case

    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 islevselligidegil, kullanıcılar için artı degerolusturacakislemleridüsünmemizisaglar


    Gereksinim analizinde use case1

    Gereksinim Analizinde Use Case

    • Kullanıcının gereksinimi olmayan özellikleri tanımlamamızı engeller

    • Kullanıcının da anlayabilecegisekilde sistemin davranıslarını ve sorumluluklarını tanımlar

    • Kullanıcı ile iletisimikolaylastı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


    Aktivite diyagramlar

    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


    Atm aktivite diyagram

    ATM Aktivite Diyagramı


  • Login