İşlevsel - WordPress.com
Download
Report
Transcript İşlevsel - 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 r equir
em ent def inition
1. T he sof tw ar e m ust pr ovide a m eans of
r epr esenting and
1. acce ssing e xter nal files cr ea t ed b y ot her t ools .
Syst em requir
em ents specif ication
1.1 T he user should be pr
ovided wit h facilit ie s to def ine the t ype of
1.2 exte rnal files .
1.2 E ach e xter nal file t ype m a y ha ve an associa t ed tool w hich m a y be
1.2 applie d to the f ile .
1.3 E ach e xter nal file t ype m a y be r epr esented as a spec if ic icon on
1.2 the user ’ s displa y.
1.4 F acilitie s should be pr
o vided f or t he ic on r epr esenting an
1.2 e xter nal file t ype t o be defined b
y the user .
1.5 When a user select s an icon r
epr esenting an e xter nal file , the
1.2 ef fect of t hat se le ction is to apply t he tool associated with the t ype of
1.2 the ext ernal f ile t o the file r epresente d by t he selec ted icon.
İş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 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.
Include” ilişkisi ise bir “use-case”in digerinin
davranısını içermesi
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
66
Gereksinim Analizinde Use Case
Kullanıcının gereksinimi olmayan özellikleri
67
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
68
ATM Aktivite Diyagramı
69