Use-case - WordPress.com

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

İster nedir?

İster çeşitleri

Kullanıcı ve sistem isterleri nelerdir?
İşlevsel (functional) ve işlevsel-olmayan (non-functional)
isterler nelerdir?

İ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

* 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 okunurlar
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.

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:

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
User requir emen t definition
1. The so ftware m ust pr ovide a means o f represen tin g an d
1. accessin g e xtern al files crea ted b y oth er too ls.
System requir emen ts specificatio n
1. 1 T h e user sho uld be p r ovided with facilities to defin e the ty pe o f
1. 2 external files.
1. 2 E ach extern al file ty pe may have an asso cia ted too l w hich ma y be
1. 2 app lied to the file.
1. 3 E ach extern al file ty pe may be r epr esen ted as a specific ico n o n
1. 2 th e user’s disp la y.
1. 4 Facilities sh ould be p r o vided for the ico n r epresen tin g an
1. 2 extern al file ty pe to be defined b y the user.
1. 5 W hen a user selects an icon r epr esen tin g an e xtern al file, th e
1. 2 effect of th at selection is to app ly the to ol associated with the ty pe o f
1. 2 th e ex ternal file to the file rep resen ted by th e selected icon .
İşlevsel isterler
İşlevsel-olmayan isterler
İşlevsel-olmayan ister çeşitleri
İşlevselolmayan
İsterler
Ürün
isterleri
Kullanıla
bilirlik
Verim
lilik
Güven
ilirlik
Kurum
isterleri
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 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

İş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şlevselolmayan ister yazmaya çalışmalısınız

İşlevsel-olmayan ister ölçütleri (metrics)




Hız:
 İşlenen işlem/saniye
 Ekran yenileme
Boyut:
 K bytes
 Ram miktarı
Kullanım kolaylığı

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


Güvenilirlik
 Ortalama hata sayısı zamanı
(MTF-Mean Time to failure)
 Kullanımda olmama olasılı ğ
Sağlamlık
 Hata sonrası yeniden başlatma
zamanı
 Hataya neden olan olay 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ı 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.

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ü
 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

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ı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

İ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ı
İ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.


İç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 İ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.
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ışı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
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.

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 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.

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 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.

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 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

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
ile 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






70
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
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