16 Eylül 2014 Salı günü Ertan Deniz Bey'in Gelişim Platformu'nda gerçekleştirmiş olduğu "Yazılım Gereksinim Mühendisliği" başlıklı seminer içeriğidir.

1. GELİŞİM PLATFORMU
Ertan Deniz
Ertan.deniz70@gmail.com
Ertan.deniz@wordpress.com

2. Ajanda
 Yazılım Mühendisliği
 Yazılım Gereksinim Mühendisliği

3. Ana referans
 Object-Oriented Software Engineering Using UML,
Patterns, and Java (3rd Edition) Bernd Bruegge & Allen H.
Dutoit,Prentice Hall

4. Önemli Sorular ?
 Büyük yazılımlar nasıl geliştirilir ?
 Büyük yazılım ekiplerinde nasıl çalışılır ve iletişim
kurulur ?
 Yazılım Mühendisliği sadece kod yazmaktan mı
ibarettir ?
 Yazılım Sistemlerindeki karmaşıklık ve değişiklik
nasıl yönetilir ?

5. 20
Yazılım Mühendisliği
Yazılım Mühendisliği;
tahsis edilen bütçeye ve zaman planına göre,
sürekli değişimin olduğu bir ortamda,
yüksek kalite yazılım sistemleri geliştirmeye
yardım eden teknikler, metodolojiler ve araçlar
kümesidir.

6. 20
Yazılım Mühendisliği
 Yazılım Sistemi, Kurumsal Bilgi Sisteminin bir
parçasıdır.
 Yazılım sistemi karmaşıktır. (Karmaşıklık her
geçen gün artmaktadır.)
 Yazılım Mühendisliğinde modellerden yararlanılır.
(Soyutlama ile basitleştirme ve karmaşıklığın
yönetimi)
 Yazılım Mühendisliği, sadece kod yazmak değildir.
 Yazılım Mühendisliği, diğer mühendislik
alanlarından farklıdır.
Karmaşıklığın ve değişikliğin yönetimi (Beklenen)

7. Yazılım Geliştirme zordur
 Kullanıcı beklentileri (Yüksek Esneklik)
 Yazılım değişir. (Değişiklik Yönetimi)
 Geliştirme sürecini yönetmek zordur.
 Yazılımlar, başka yazılımlar üzerinde çalışır. (Teknoloji
bağımlılıkları)

8. Yazılım Mühendisliği ve Diğer Mühendislik alanları
20
 Yazılım ürünü geliştirme, ev ve araç gibi ürünlerin
üretilmesinden farklıdır.
 Diğer Mühendislik alanları ile karşılaştırma
(İnşaat,Elektrik,Makine)
 Matematiksel modeller
 Ölçülebilirlik (Kabul Edilebilir ? Kullanıcı isteklerini
karşılama ?)
 Esneklik
 Değişiklik yönetimi (Yeni ihtiyaçlar, Değişiklik
istekleri)

9. Yazılım Mühendisliği Kavramları
 Sistem
 Birbirine bağlı parçalar topluluğu (Alt Sistemler)
 Model
 Sistemin soyutlanmış hali
 Katılımcılar ve Roller
 İş Analisti, Yazılım Mimarı, Geliştirici, Test Uzmanı, Proje
Yöneticisi, Teknik Doküman Yazarı, Müşteri, Kullanıcı
 Süreçteki ürünler (Work Products)
 Geliştirme sürecinde üretilen ürün (Test klavuzu)
 Müşteriye verilecek ürün. (Kullanım klavuzu)
 Görev
 Yönetilecek birim iş.
 Rol, bir görev kümesi ile ilişkilendirilir.

10. Yazılım Mühendisliği Kavramları - Devamı
20
 Aktiviteler (Fazlar)
 Süreç içinde birbiri ile ilişkili büyük görevler (Bir görev
kümesi)
 Kaynak
 Zaman, Araç, İşçilik
 Fonksiyonel Gereksinim
 Sistemin destekleyeceği fonksiyon tanımları
 Fonksiyonel olmayan gereksinim
 Sistemin işleyişi ile ilgili olan, fakat fonksiyonlar ile
ilişkilendirilmeyen gereksinimler (Performans, Kurum
standartlarına uygunluk)
 Gösterim (Notation)
 Grafik veya metin olarak ifade edilen ve bir modeli temsil
eden kurallar

11. Yazılım Mühendisliği Kavramları - Devamı
20
 Metot
 Belirli bir problemi çözmek için kullanılan adımlar
 Metodoloji
 Problemleri çözmek için sunulan metotlar ve bu metotların
her birisinin nasıl ve ne zaman kullanılacağının
belirlenmesi

12. Yazılım Mühendisliği ve Modelleme
 Modelleme
 Karmaşık bir sistemin, basitleştirilmiş bir görünüm şeklidir.
(Soyutlama)
 Modelleme ile karmaşıklığın yönetilmesi. (İlgili bölüme
yoğunlaşma ve diğer bölümlerin düşünülmemesi.)
 Sistemlerin görsel hale getirilmesi ve anlaşılırlığın
kolaylaştırılması
 Sistemin farklı görünümlerini elde etmek ve sistemi çeşitli
yönlerden değerlendirmeye destek olurlar. (Çözümleme)
 İletişim için önemlidir.
 Model detayları
 Sistem elemanları tanımı, işleyişi ve diğer elemanlar ile etkileşimi
 Bu bilgiye sahip olmadan, bir değişiklik nasıl gerçekleştirilebilir ?
 Model olmazsa, nereye başvurulacaktır ? Yazılım Kodlarına mı ?
Herkes kodu anlayamaz ?
 Takım içi ortak dil nasıl olmalıdır ?

13. Yazılım Mühendisliği ve Modelleme
 Modellere örnekler
 Bir binaya ait farklı mimari çizimler (İç yapısı, Dış Yapısı)
 İş akışını gösteren aktivite diyagramları
 Bilgi İşlem alt yapısını oluşturan alt sistemler ve
etkileşimi. (Ortam modeli)

14. UML nedir?
 Birleştirilmiş modelleme dili anlamındadır. (UML :
Unified Modelling Language)
 Nesne temelli yazılım modelleme standardıdır.
 Yazılım süreci ile ilgili model diyagramlarının
çizilmesi için kullanılan grafik temelli modelleme
dilidir. (OMG standardı)
http://www.omg.org/technology/documents/formal/
uml.htm

15. Niçin UML kullanırız ?
 Yazılım geliştirme sürecinin yönetilmesini
kolaylaştırmak.
 İletişim
 Kendimizle, Proje ekibimizle, Müşterilerimizle (İstek
yapanlar)
 Diğer kişiler ile, anlayışımız aynı mı ?
 Modeller ile sunum yapmak daha kolay (Görsel,
İlişkisel)
 Daha iyi gereksinim belirleme.
 Zayıf ve eksik olan gereksinimlerin ortaya çıkardığı
problemler.
 Yazılım sisteminin dokümantasyonu
 Toplamda; maliyetlerin ve projenin/ürünün sunulması
süresinin kısaltılması.

16. Ajanda
 Yazılım Mühendisliği
 Yazılım Gereksinim Mühendisliği

17. Yazılım geliştirme aktiviteleri (Hayat
döngüsü)
Yapısallaştırılır.
Alt
Sistemler
Geliştirilir.
Gerçekleştirili
sınıf...
sınıf...
Kod
r
Çözüm
nesneleri
Gereksinim
Mühendisliği
İfade edilir.
Uygulama
Alan
nesneleri
Doğrulanır.
?
sınıf...?.
Test
Model
Use Case
Model
Sistem
Tasarımı
Nesne
Tasarımı
Uygulama Test
Gereksinim
belirleme
Analiz

18. Gereksinim belirleme ve Analiz
Analiz
Problem İfadesi
Gereksinim
Belirleme
Fonksiyonel olmayan
Gereksinimler
Fonksiyonel Model
Analiz Model
Analiz Nesne Modeli
Gereksinim
Belirleme
Dinamik Model
Daha detaylı
inceleme (İstisnai
durumlar, Sınır
koşulları)

19. Gereksinim belirlemede ilk adım
 Gereksinim belirleme
 Müşteri / Kullanıcı tarafından anlaşılabilecek şekilde
sistemin tanımı (Gereksinim belirleme) (Beyanname)
 Konuşma dilimiz.
 Analiz
 Yazılım geliştirici tarafından anlaşılabilecek şekilde
sistemin tanımı (Analiz modeli)
 Formal gösterimler
 Gereksinim prosesi (Gereksinim Mühendisliği)
 Gereksinim belirleme ve analiz aktivitelerinden oluşur.

20. 20
Yazılım Gereksinim Mühendisliği
 Yazılım geliştirmek bir mühendislik yaklaşımı olduğu için,
alt süreci de, bir mühendislik yaklaşımıdır.
 Model temelli bir yaklaşım kullanılır.
 Sistem tasarımından önce, gereksinimler ortaya koyulur.
Çözümlenir. (Analiz) Kalite kontrol adımı olarak doğrulanır.
(Gereksinimlerde detay ayrı bir değerlendirmedir.)
 Beş katlı bir bina mı ? Yoksa, gökdelen mi?
 Okul mu? Hastane mi?

21. 20
Yazılım Geliştirme Aktiviteleri
 İhtiyaçların ortaya çıkarılması
 Sistemin amacının belirlenmesi (Aktörler & Aksiyonlar (Use Case))
 Aktörler - > Roller
 Analiz
 Sistemin modelinin üretilmesi (“Use Case” lerin dönüştürülmesi)
 Yapısallık ve dinamik işleyiş açısından modelin tanımlanması
(Nesne Modeli & Sıralı(Sequence) Diyagramı)
 Tutarsızlıkların ve belirsizliklerin çözülmesi
 Sistem tasarımı
 Tasarım hedeflerinin tanımlanması (Sistemin sağlaması gereken
kalite özellikleri)
 Sistemin, alt sistemlere ayrıştırılması
 Stratejilerin belirlenmesi (Yazılım/Donanım Platformu, Veri
yönetimi, Genel kontrol akışı, Erişim politikaları)
 Dağıtım (Deployment) Diagramı (Yazılım/Donanım planlaması –
Yerleşim Planı)

22. 20
Yazılım Geliştirme Aktiviteleri - Devamı
 Nesne tasarımı
 Nesnelerin, Alt sistem arayüzlerinin tanımlanması ve
bileşenlerin seçilmesi
 Nesne modelinin performans amaçlı iyileştirilmesi
 Detaylı Nesne modeli (Kısıtlar & Her bir elemanın
detaylı tanımı)
 Uygulama geliştirme
 Çözüm modelinin, koda dönüştürülmesi
 Test
 Sistemin, örnek veri ile çalıştırılması
 Sistemin dağıtımı yapılmadan önce, hataların bulunması
 Test çeşitleri
 Birim (Unit) Testleri
 Entegrasyon Testleri
 Sistem Testleri

23. Gereksinim çıkarma teknikleri
 Son kullanıcı ve yazılım geliştirici arasındaki boşluğun
doldurulması
 Son kullanıcıya, önceden seçilmiş sorular sorulması
 Son kullanıcıları, çalışma ortamlarında gözlemlenmesi
 Belirli bir son kullanıcı ile, sistem arasındaki etkileşimin
tanımlanması (Senaryo)
 Bir grup senaryoyu tanımlayan soyutlamaların
çıkarılması (Use Cases)
Soyutlama
/Genelleme
Use Cases
Senaryolar

24. Gereksinimlerin çıkarılması - Zorluklar
 Kullanıcılar ve yazılım geliştiriciler arasındaki
boşluğun doldurulması
 Kullanıcılar / Müşteri, işin kendisini bilir. (İş alanı)
 Yazılım geliştiriciler, çözüm alanını bilir. (Teknik)
 Sistem sınırının belirlenmesi
 Doğru sistemin tanımlanması
 İstenmeyen özelliklerin dışarıda bırakılması

25. Senaryolar
 Sistemin kullanımının metin şeklinde ifade
edilmesidir.
 Bir aktör tarafından kullanılan, sistemin bir özelliği.
 Son kullanıcı bakış açısı ile yazılır.
 Müşteri iş alanından (Problemin kendisi) anlar.
Çözüm alanını bilmez.
 Gereksinimlerin çıkarılmasında, müşteriye yardım
ederiz. (Yönlendirme)
 Senaryolar geliştirildikçe, gereksinim belirleme
süreci olgunlaşır.
 Kullanıcı ile iletişimde, işlevleri doğrulamak için,
senaryoları kullanırız.

26. Senaryo temelli tasarım
 Yazılım hayat döngüsünde farklı kullanımları
olabilir :
 Mevcut durum (Gereksinim belirleme)
 Test senaryosu (Müşteri kabul testleri)
 Eğitim senaryosu (Sistem dağıtımı)
 Senaryo temelli tasarım : Yazılım hayat
döngüsünde senaryoların kullanımı

27. Örnek Senaryo
1) Hasta, randevu öncesi, hastaneye gelir.
2) Hasta, randevusunu, görevliye bildirir.
3) Görevli, muayene ücretini talep eder.
4) Hasta, muayene ücretini, görevliye öder.
5) Görevli, ödeme makbuzunu, hastaya verir.
6) Görevli, hastayı doktora yönlendirir.
7) Hasta, doktorun odasına gider.
8) Hasta, kapıdaki ekranda ismini görürse, odaya girer. Diğer durumda,
isminin ekranda görünmesini bekler.
9) Doktor, sıradaki hastayı çağırır.
10) Doktor, hastaya, teşhis amaçlı bazı sorular sorar.
11) Doktor, hastayı muayene eder.
12) Doktor gerekli görürse, farklı laboratuvarlardan tetkik ister.
13) Laboratuvar görevlisi, sıradaki tetkik isteğini alır.
14) Laboratuvar görevlisi, hastayı çağırır ve numune alır.
15) Laboratuvar görevlisi, tetkik üzerinde çalışır ve raporu yayınlar.

28. Örnek Senaryo - Devamı
15) Sistem, hastayı ve doktorunu e-mail ile uyarır.
1) E-mail içinde rapor linki vardır. Hasta raporunu, web üzerinden
inceleyebilir.)
16) Doktor tetkikleri inceler.
17) Doktor ilaç yazar.
18) Doktor muayene kaydını kapatır.

29. Diğer senaryolar
 Randevusuz gelen hasta
 Sadece kontrol için gelen hasta
 Acil hasta (Ambulans)
 Ameliyat gerektiren hasta

30. Gereksinim çeşitleri
 Fonksiyonel gereksinimler
 Kullanıcı işleri (İşlemler)
 “Bildir …”, “Planla …”
 Fonksiyonel olmayan gereksinimler
 Fonksiyonel işleyişle direkt ilgisi olmayan yönler
 “Cevap süresi, 1 sn altında olmalıdır.”
 Kısıtlar
 Müşteri veya ortamdan kaynaklanan kısıtlar
 Özel (fonksiyonel olmayan) gereksinimler
(Uygulanabilirlik, Operasyonel, Kanun kısıtları)
 “Uygulama geliştirme dili Java olmalı.“

31. Gereksinim belirlemede olmaması gerekenler
 Sistem yapısı, kullanılacak teknoloji
 Geliştirme metodolojisi
 Geliştirme ortamı / Dili
 Tekrar kullanılabilirlik
Yukarıdakilerin hiç birinin, müşteri tarafından kısıtlanmaması
arzumuzdur.

32. Gereksinim çıkarma aktiviteleri
 Aktörlerin belirlenmesi
 Senaryoların belirlenmesi
 Senaryolar, gerekli işlevselliğin somut örnekleridir. (Bir durumu
gösterir.)
 [Use Cases] belirlenmesi
 [Use Case] ler, tüm mümkün durumları tanımlayan soyutlamalardır.
 Sistemin sınırlarını belirler.
 [Use Cases] geliştirilmesi (Detaylandırılması)
 Özellikler ve kısıtlar hakkında daha detaylı çalışma
 Erişim hakları (Hangi aktör, Hangi işlem)
 Eksik istisnaların (Exception) tespiti ve yönetimi
 [Use Case] ler arasındaki ilişkilerin belirlenmesi
 Karmaşıklığın azaltılması
 İstisna ve genel olay akışlarının ayrıştırılması (Genişletme -
Extend)
 Ortak işlevsellik( Kullanır - Include)
 İlk Analiz nesnelerinin belirlenmesi (Terminoloji, Sözlük)
 Fonksiyonel olmayan gereksinimlerin belirlenmesi

33. Fonskiyonel olmayan gereksinimlerin belirlenmesi
Kullanabilirlik
 Kullanıcının uzmanlık seviyesi, Kullanıcı arayüz standartları ,
Kullanıcıya sağlanacak dokümanlar
Güvenilirlik
 Süreklilik (Sistemin işlerliği), Sağlamlık, Hata yönetimi,
Güvenlik gereksinimleri
Performans
 Cevap verme süresi, Eş zamanlı kullanıcı sayısı
 Desteklenebilirlik
 Bakım modeli (Kim), Farklı donanım ve yazılım ortamlarının
desteklenmesi

34. Fonskiyonel olmayan gereksinimlerin belirlenmesi
 Uygulama (Geliştirme)
 Donanım, Yazılım geliştirme araçları, Bileşenler, İşletim
sistemi ile ilgili kısıtlar
 Arayüz
 Diğer sistemler ile entegrasyon (Nasıl)
 İşletim
 Çalışma ortamının yönetimi (Kim, Nasıl)
Paketleme
 Kurulum (Nasıl)
Kanun ile ilgilii
 Lisanslama Modeli (Nasıl)

35. Gereksinim doğrulama
Kalite kontrol adımıdır. Genellikle, gereksinim belirleme veya
analiz safhasından sonra yapılır.
 Doğruluk : Gereksinimler, müşterinin görüşünü temsil
eder.
 Tamlık : Sistemde kullanılabilecek tüm muhtemel
senaryolar, tanımlanır.
 Tutarlılık : Birbirleriyle çelişen gereksinimler yoktur.
 Açıklık : Gereksinimler, sadece tek bir şekilde
yorumlanabilir.
 Gerçekçilik : Gereksinimler, uygulanabilir ve teslim
edilebilir.
 İzlenebilirlik : Yazılım geliştirme boyunca sistem
fonksiyonları ve gereksinimler arasındaki ilişki takip
edilebilir olmalıdır.

36. UML Diyagramları
 Gereksinim ve analiz safhasında en çok kullanılan
UML diyagramları
 Kullanım senaryosu (Use case) diyagramı (Fonksiyonel
Model)
 Kullanıcı bakış açısı ile, sistemin işlevlerini tanımlar.
 Sınıf (Class) Diyagramı (Yapısal Model)
 Nesneler ve nesnelerin özellikleri, ilişkileri ve operasyonları ile
birlikte sistemin yapısını tanımlar.
 Analiz süresince - > Analiz Nesne Modeli (Uygulama kavramları)
 Tasarım süresince -> Design Object Model (Çözüm
kavramlarının detaylı açıklanması)
 Sıralı (Sequence) Diyagram(Dinamik Model),
 Bir nesne kümesi arasındaki davranışı, nesneler arası
gönderilen mesajlar olarak tanımlar.
 Durum (State) Diyagramı (Dinamik Model),
 Bir nesnenin durumlarını ve durumlar arası geçişi tanımlar.
 Aktivite Diyagramı (Dinamik Model),
 Kontrol (Karar yapıları) ve veri akışını tanımlar.

37. [Use Case] Model Diyagramı
 [Use case] modeli, sistemin tüm fonksiyonlarını tanımlayan
[Use Case] kümesidir.
 [Use Case] lerin toplu olarak görülebildiği indeks yapısı
gibidir.
uc Primary Use Cases
ÖğrenciBilgiSistemi
DersSeç
KayıtGörev lisi
Öğrenci
KayıtOl
ÖğretimGörev lisi
DersOnay
Sınav Yap
Sınav Organizatörü
Sınav Planla
Sınav Duyur
Sınav Gözetmeni

38. Örnek [Use Case] Modeli
uc Use Case Model
Kuyruk Sistemi
DoktorİçinSonrakiniVer SonrakiHastayıVer
Laboratuvar İçinSonrakiniVer
Laboratuvar
Muayene
Hasta Kabul
Görev li
Hasta
Kuyruk Yöneticisi
Doktor
Uyarı Sistemi
MuayeneTalepEt
ÜcretÖde
MuayeneYap
ReçeteYaz
TeşhisSorularıSor
MuayaneKaydıKapat
Laboratuv ar Asistanı
TetkikRaporuYayınla
Tetkikİste
TetkikRaporuKontrolEt
TektikYap
ÖrnekAl
DoktorÇalışmıyor
MalzemeAl
«include»
«include» «include»
«include»
«extend»
«extend»
«include»
«include»
«include»
«include»

39. Kullanım senaryosu (Use Case) formatı
Adı
Katılımcı
Aktörler
Giriş Koşulu
Çıkış Koşulu
Olay Akışı
İstisnalar
Özel
Gereksinimler

40. Kullanım senaryosu (Use Case) formatı
Adı MuayeneTalepEt
Katılımcı
Görevli,Hasta
Aktörler
Giriş Koşulu Hasta, görevliye muayene talebini iletir.
Çıkış Koşulu Sistem, talebi, doktora iletir.
Görevli, Hasta ücretini ödemediği için , talebi iptal eder.
Olay Akışı 1) Hasta, randevusunu, görevliye bildirir.
2) ÜcretÖde [UseCase] i çalıştırılır.
3) Görevli, talep işlemini onaylar.
İstisnalar Yok.
Özel
Gereksinimler
Yok.

41. Kullanım senaryosu (Use Case) formatı
Adı ÜcretÖde
Katılımcı Aktörler Görevli,Hasta
Giriş Koşulu Hasta, görevliye muayene talebini iletir.
Çıkış Koşulu Hasta ücretini ödeyip, ödeme makbuzunu alır.
Olay Akışı 1) Görevli, muayene ücretini talep eder.
a) Hasta, yeterli parası olmadığı için, ücreti ödeyemez.
Görevli, talebi iptal eder.
2) (Görevli, ödeme şeklini sorar.) (Senaryoda yok.
Detaylandırmak için eklendi.)
3) Hasta, muayene ücretini, görevliye öder.
4) Görevli, ödeme makbuzunu, hastaya verir.
İstisnalar Yok.
Özel
Gereksinimler
Yok.

42. Sınıf Diyagramı
 Sistemin yapısını temsil eder. (Yapısal Modelleme)
 Gereksinim toplanma aşamasında, alana özel
kavramların toplanması
 Sistem tasarım aşamasında, alt sistemlerin
modellenmesi
 Sınıf tasarım aşamasında, sınıfların detaylı özellik ve
davranışlarının modellenmesi
 Sınıflar arasındaki ilişkiyi gösterir.

43. Sınıf gösterimi
 Sınıflar, dikdörtgen olarak temsil edilir. Sınıf ismi,
özellikleri (durumu) ve metodları, şekil içinde yer alır.
 Sınıf ismi, özellikleri ve metodları bölümler halinde
sunulur.
 Her bir özelliğin tipi, her bir metodun
parametrelerini gösteren imzası vardır.
class Class Model
Musteri
+ Adi: string
+ Adres: string
+ AktifDurumu: boolean
+ Cep Telefonu: string
+ Tipi: int
+ AdresDegistir(string) : void
+ AktifDurumuDegistir() : void

44. Gereksinimden nesne modeline
 Bankamıza gelen müşteriler, birden fazla hesap
açtırabilirler. Kullanmadıkları hesapları, pasif hale
getirebilirler.
class Class Model
Musteri
+ Adi: string
+ Adres: string
+ AktifDurumu: boolean
+ Cep Telefonu: string
+ Tipi: int
+ AdresDegistir(string) : void
+ AktifDurumuDegistir() : void
Hesap
+ AcilisTarihi: string
+ AktifDurumu: boolean
+ Numarası: int
1..*

45. Genelleştirme ilişkisi
 Kalıtım ilişkisini göstermek için kullanılır.
 Türetilen (Çocuk) sınıflar, temel sınıfın özelliklerini ve
operasyonlarını kullanır.
 İşbirliği (Association) ilişkisinin, “Çeşididir” bilgisini
veren özel bir şeklidir.
 Kalıtım, gruplama kavramını ortaya çıkararak, analiz
modelini basitleştirir.
class Class Model
Hesap
+ Acil isTarihi : string
+ Akti fDurumu: boolean
+ Numarası: i nt
+ MasrafHesapla() : void
KurumsalHesap
+ MasrafHesapla() : void
BireyselHesap
+ MasrafHesapla() : void

46. Örnek Sınıf Diyagramı (Analiz Nesne Modeli)
class Class Model
Musteri
+ Adi: string
+ Adres: string
+ AktifDurumu: boolean
+ Cep Telefonu: string
+ Tipi: int
+ AdresDegistir(string) : void
+ AktifDurumuDegistir() : void
Hesap
+ AcilisTarihi: string
+ AktifDurumu: boolean
+ Numarası: int
+ MasrafHesapla() : void
KurumsalHesap
+ MasrafHesapla() : void
BireyselHesap
+ MasrafHesapla() : void
«interface»
IGuv enlikKontrol
+ YetkiKontrol() : void
A
1..*

47. Örnek Nesne Modeli class Class Model
Görünüm sınıfları (Formlar) Yönetici Sınıfları(Controller)
KuyrukGörünümForm
+ SonrakiniGetirKomutu() : void
Görünüm Sınıfları (Web Formları)
Varlık sınıfları (İşçi & Veri)
Hasta
+ No: int
+ Adı: string
Hastaİşlemleri
+ Ekle() : void
+ Güncelle() : void
+ Sil() : void
+ NumaraİleGetir() : void
Doktor
+ No: int
+ Adı: string
Doktorİşlemleri
+ Ekle() : void
+ Güncelle() : void
+ Sil() : void
+ NumaraİleGetir() : void
MuayeneTalepForm
+ KaydetKomutu() : void
Muayeneİşlemleri
+ Ekle() : void
+ Güncelle() : void
+ Sil() : void
+ NumaraİleGetir() : void
Muayene
+ No: int
+ TalepTarihi: date
+ Doktor: Doktor
+ Hasta: int
+ SorularaCevaplar: string
+ ReçeteBilgisi: string
HastaİlişkilerYöneticisi
+ TalepKaydet() : void
+ ÜcretAl() : void
+ DoktoraYönlendir() : void
DoktorHastaListesiForm
+ HastaGetirKomutu() : void
DoktorYöneticisi
+ SonrakiHastayıGetir() : void
+ MuayeneKaydet() : void
+ LabaratuvaraGönder() : void
+ MuayeneKaydıKapat() : void
+ ReçeteYaz() : void
MuayeneForm
+ MuayeneKaydetKomutu() : void
+ T etkikT alebiAçKomutu() : void
TetkikTalepForm
1
+ LaboratuvaraGönderKomutu() : void
+ T etkikRaporuAçKomutu() : void
TetkikForm
+ TetkikKaydetKomutu() : void
+ RaporYayınlaKomutu() : void
TetkikYöneticisi
+ TetkikKaydet() : void
+ ÖrnekAl() : void
+ RaporYayınla() : void
+ TetkikRaporuGetir() : void
+ SonrakiHastayıGetir() : void
Tetkikİşlemleri
+ Ekle() : void
+ Güncelle() : void
+ Sil() : void
+ NumaraİleGetir() : void
Tetkik
1 1
+ No: int
+ TalepTarihi: date
+ Hasta: Hasta
+ Doktor: Doktor
+ ÖrnekNo: int
+ RaporDetayları: string
ÖrnekAlmaİşlemleri
+ Ekle() : void
+ Güncelle() : void
+ Sil() : void
+ NumaraİleGetir() : void
Örnek
+ No: int
+ İşlemT arihi: date
+ Açıklama: string
Emailİşlemleri
+ Gönder() : void
TetkikRaporForm
+ RaporAçKomutu() : void
1 1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1 1 1
1 1
1
1
1
1
1 1
1
1
1
1
11
1
1

48. Örnek Sıralı Diyagram
sd Doğrula
HesapGoruntulemeEkranı
SubeYetkilisi
HesapIslemleri Hesap
HesapGoruntuleKomutu()
HesapGetir()
:Hesap
Doğrula()
HesapDetaylarınıAl()
:Hesap

49. Durum (State) Diyagramları
 Durum diyagramı, tek bir
nesnenin davranışını
modeller.
 Nesnenin; iç ve dış olaylara
karşılık, hayat döngüsünde
geçirdiği durumları belirtir.
 Bir olay gerçekleştiğinde,
sistem bir durumdan,
diğer bir duruma geçer.
 Kullanıcı arayüzlerindeki
navigasyon için
kullanılabilir. Durumlar,
ekran isimleridir.
stm DynamicState
Basla
İlkBasv uru
Degerlendirme
Kabul Red
Son
Tum Evraklar Tamam
Olumlu Olumsuz

50. Aktivite diyagramları
act Activ ity
Şube yetkilisi, müşterinin
talebini alır.
Şube müdürü, talebi
değerlendirir.
İşlem İptal
Edildi.
Başla
Şube müdürüne onaya
gönderir.
Değerlendirme Sonucu
Talep iptal
edilir.
Talep
onaylanır.
İşlem
tamamlandı.
Olumsuz
Olumlu

51. Örnek Aktivite Diagramı
act Dynamic
MuayeneBaşl at
T al epİptalEdi l di
Hasta, görev liden
muayene talep eder
Görev li, muayene ücretini
talep eder
Ücret
ödendi mi ?
Görev li, hastayı doktora
yönlendirir
Talebi iptal et
Hasta, doktorun odasına
gider
Hasta, kuyruğu kontrol
Hasta i lk
sırada mı?
eder
Hasta, doktorun odasına
girer.
Doktor, hastaya, teşhis
amaçlı bazı sorular sorar
Doktor, hastayı muayene
eder
Tetkik
gerekl i mi
? (Veya
yeni tetkik
gerekl i mi
?
Doktor, hastayı muayene
eder
Doktor gerekli görürse,
farklı laboratuv arlardan
tetkik ister
Doktor muayene kaydını
kapatır
MuayeneT amaml andı.
Laboratuv ar görev lisi,
sıradaki tetkik isteğini alır
Laboratuv ar görev lisi, tetkik
için, numune alır
Laboratuv ar görev lisi, tetkik
üzerinde çalışır v e raporu
yayınlar
LaboratuvardaT etki kBaşl at
RaporYayınl andı
RaporKontrol üBaşl at
T etki kLaboratuvaraGönderi l di
Yes
Hayır
Evet
Hayır
Evet
 [Use Case] ler
üzerinde genel bir
akış.

52. Özet
 Yazılım mühendisliği sadece kod yazmak değildir.
 Yazılım geliştirme bir süreçtir ve takım işidir. Süreçte
farklı roller çalışır.
 Yazılım geliştirme sürecinde iletişim önemlidir. Ortak
bir iletişim dili gereklidir.
 Modelleme ile gerçek sistem basitleştirilir.
Karmaşıklık daha kolay yönetilir.
 Müşteri ve Kullanıcı gibi gereksinimleri ortaya
koyanlar ile yazılım geliştiriciler arasında, aracı
gereklidir. (Köprü Rolü – Analist)
 Gereksinimlerin belirlenmesi ve analizi, bir
mühendislik çalışmasıdır. (Gereksinim Mühendisliği)
 Görsel destek için ekran çizimleri (Mock-ups)
kullanılabilir.

53. Referanslar
 Practical Software Engineering, Leszek A. Maciaszek &
Bruc Lee Liong, Pearson, 2005.
 Software Engineering 9, Ian Sommerville, Addison
Wesley,2011
 Professional Software Development, Steve McConnell,
Addison Wesley,2004