Yazılım Mühendisliği

Sistem Modelleme

Dr. Öğr. Üyesi Oğuz Emre Kural

2026

İçindekiler

• Sistem Modellemeye Giriş
• Bağlam Modelleri
• Etkileşim Modelleri
• Yapısal Modeller
• Davranışsal Modeller
• Model Güdümlü Mühendislik
• Bölüm Özeti

Sistem Modellemeye Giriş

Bu bölümde sistem modellemenin ne olduğuna ve neden tek bir çizimle yetinmediğimize bakacağız. Sistem modelleme, bir sistemin soyut modellerini geliştirme sürecidir. Her model, sistemi farklı bir açıdan gösterir.

Model, seçilmiş bir görünümdür

Aynı şehrin metro haritası ile yol haritası farklı sorulara cevap verir. Metro haritasında sokak adları yoktur. Bu bir eksiklik değil, bilinçli bir seçimdir: Harita, yolcunun sorusuna gereken kadarını gösterir. Yazılım modelleri de böyledir. Bir model sistemin bütününü değil, belirli bir soruya cevap veren yönünü gösterir.

Soyutlama ve temsil

Soyutlama

Önemli olanı seçer, gerisini bilerek dışarıda bırakır.

Bir maçın beş dakikalık özeti.

Temsil

Bilginin tamamını korur, yalnızca biçimi değiştirir.

Maçın baştan sona kaydı.

Sistem modeli bir soyutlamadır; sistemin eksiksiz bir kopyası değildir.

Burada iki kavramı ayırmak gerekiyor: soyutlama ve temsil. Bir maçın beş dakikalık özeti bir soyutlamadır. Önemli anları seçer, gerisini bilerek atar. Maçın baştan sona kaydı ise bir temsildir. Bilginin tamamını korur, sadece biçimi farklıdır. Sistem modeli bir soyutlamadır. Anlaşılmayı kolaylaştırmak için ayrıntıyı bilerek dışarıda bırakır.

Modeller ne zaman kullanılır?

Modeller yazılım sürecinin birçok yerinde kullanılır. Gereksinim mühendisliğinde ayrıntılı gereksinimleri çıkarmaya yardım eder. Tasarımda, sistemi uygulayacak mühendislere ne yapılacağını anlatır. Uygulama bittikten sonra ise sistemin yapısını ve işleyişini belgelemek için kullanılır.

Var olan sistemin modelini de, geliştirilecek yeni sistemin modelini de çizebiliriz. Mevcut sistemin modeli bugünkü işleyişin güçlü ve zayıf yanlarını konuşmaya yarar. Yeni sistemin modeli ise önerilen gereksinimleri paydaşlara anlatmaya ve tasarım fikirlerini tartışmaya.

Dört bakış açısı

Dış bakış · Bağlam

Sistem hangi ortamda, hangi sistemlerle birlikte çalışıyor?

Etkileşim

Kullanıcılar, sistemler ve bileşenler birbiriyle nasıl haberleşiyor?

Yapı

Sistem nasıl örgütlenmiş, hangi verileri işliyor?

Davranış

Sistem çalışırken olaylara ve verilere nasıl tepki veriyor?

Bir sisteme dört farklı açıdan bakabiliriz. Dış bakış açısı sistemin bağlamını gösterir: Sistem hangi ortamda, hangi sistemlerle birlikte çalışıyor?

Etkileşim bakış açısı, sistemle çevresi ya da sistemin parçaları arasındaki haberleşmeyi gösterir.

Yapısal bakış açısı, sistemin nasıl örgütlendiğini ve hangi verileri işlediğini gösterir.

Davranışsal bakış açısı ise sistemin çalışırken olaylara ve verilere nasıl tepki verdiğini gösterir. Sonraki bölümler bu dört bakış açısını tek tek ele alıyor.

Model ne kadar kesin olmalı?

Tartışmayı odaklamak

Eksik olabilir; gösterim serbestçe kullanılabilir. Tartışmanın ana noktalarını kapsaması yeterli.

Belgelemek

Eksik olabilir; ama gösterdiği kısım doğru olmalı ve gösterim doğru kullanılmalı.

Kod üretmek

Hem eksiksiz hem doğru olmalı. Benzer iki sembolü karıştırmak bile sonucu değiştirir.

daha serbestdaha katı

Modelin ne kadar ayrıntılı ve kesin olması gerektiği, onu ne için kullanacağımıza bağlıdır. Tartışmayı odaklamak için çizilen bir model eksik olabilir ve gösterimi serbestçe kullanabilir. Çevik ekipler modelleri çoğunlukla böyle kullanır. Belgeleme için çizilen model de eksik olabilir; ama gösterdiği kısım doğru olmalıdır. Modelden kod üretilecekse model hem eksiksiz hem doğru olmak zorundadır. Burada iki benzer ok ucunu karıştırmak bile üretilen kodu değiştirir.

UML nedir?

• UML (Unified Modeling Language, Birleşik Modelleme Dili), yazılım sistemlerini görselleştirmek, belirtmek, oluşturmak ve belgelemek için kullanılan standart bir grafik modelleme dilidir.
• Bir programlama dili ya da yöntem değildir; modellerin ortak gösterimidir. Hangi süreçte, hangi sırayla kullanılacağını söylemez.
• Standardı, kâr amacı gütmeyen OMG (Object Management Group) yönetir; araçlar arasında model alışverişi bu sayede mümkündür.
• Grafik modellerin yanında, sistemi matematiksel olarak tanımlayan biçimsel modeller de vardır; güvenilirliği kritik sistemlerin ayrıntılı belirtiminde kullanılır.

Sistem modelleme bugün çoğunlukla UML diyagramlarıyla yapılır. UML’in bir yöntem olmadığını vurgulayın: Çevik bir ekip de, geleneksel bir ekip de aynı gösterimi kullanabilir. Biçimsel modeller bu bölümün konusu değildir; güvenilir sistemler konusunda ele alınır.

UML’in tarihçesi

Doksanlı yıllarda nesneye dayalı modelleme için birbirine benzeyen ama ayrı ayrı gösterimler vardı. En bilinenleri Booch, Rumbaugh ve Jacobson’ın yöntemleriydi.

Bu gösterimler birleşti ve 1997’de standart kuruluşu OMG, UML’i ortak modelleme dili olarak kabul etti.

Büyük revizyon UML 2, 2004’te tamamlandı ve 2005’te yayımlandı. Bugün kullandığımız diyagram türleri bu sürümle netleşti.

2012’de UML 2.4.1, ISO ve IEC tarafından uluslararası standart olarak yayımlandı.

Güncel sürüm 2017’de yayımlanan UML 2.5.1’dir. UML’den türetilen SysML ise yazılımın ötesinde, donanımı da içeren genel sistem modellemesi için kullanılır.

UML diyagramlarının sınıflandırması

UML diyagramları iki ana kategoride toplanır. Yapısal diyagramlar sistemin durağan yapısını, yani parçalarını ve aralarındaki ilişkileri gösterir. Davranışsal diyagramlar ise sistemin zaman içinde nasıl davrandığını gösterir.

Yapısal tarafta yedi tür var: sınıf, nesne, bileşen, bileşik yapı, paket, dağıtım ve profil diyagramı.

Davranışsal tarafta etkinlik, kullanım durumu ve durum makinesi diyagramları var. Etkileşim diyagramları davranışsal diyagramların bir alt grubudur: sıra, iletişim, zamanlama ve etkileşime genel bakış.

Toplam on dört tür eder. Sommerville on üç der; aradaki fark, sonradan eklenen profil diyagramıdır. Kullanıcıların çoğu sistemin özünü beş türle anlatabildiğini söylüyor. Vurgulanan bu beş tür, bölüm boyunca kullanacağımız diyagramlar.

Bu bölümde kullanacağımız beş diyagram

• Etkinlik diyagramları: bir süreçteki ya da veri işleme görevindeki etkinlikleri gösterir.
• Kullanım durumu diyagramları: sistem ile çevresi arasındaki etkileşimi gösterir.
• Sıra diyagramları: aktörler ile sistem ve sistem bileşenleri arasındaki etkileşimleri zaman sırasıyla gösterir.
• Sınıf diyagramları: nesne sınıflarını ve aralarındaki ilişkileri gösterir.
• Durum diyagramları: sistemin iç ve dış olaylara nasıl tepki verdiğini gösterir.

UML dışında da yaygın gösterimler var: bağlam ve mimari için C4, iş süreçleri için BPMN. Gösterim değişse de ilke aynı kalır.

Her türü bölümün ilgili kısmında ayrıntılı göreceğiz: etkinlik diyagramını bağlam ve davranışsal modellerde, kullanım durumu ve sıra diyagramlarını etkileşim modellerinde, sınıf diyagramını yapısal modellerde, durum diyagramını yine davranışsal modellerde.

Örnek sistemimiz: AS-HYS

Bölüm boyunca tek bir örnek sistem kullanacağız: AS-HYS, yani Akıl Sağlığı Hasta Yönetim Sistemi. Bu sistem ruh sağlığı kliniklerinde hasta kayıtlarını, randevuları, tedavi bilgilerini ve yönetim raporlarını yönetiyor. Aynı sisteme her bölümde farklı bir sorunun gözlüğüyle bakacağız.

Özet: Sistem Modellemeye Giriş

• Model, sistemin seçilmiş bir görünümüdür: bir soyutlama.
• Sisteme bağlam, etkileşim, yapı ve davranış açılarından bakarız.
• Modelin kesinliği, onu ne için kullandığımıza bağlıdır.
• UML’in on dört diyagram türünden beşi çoğu ihtiyaç için yeterlidir.

Özetleyelim. Model, sistemin seçilmiş bir görünümüdür; bir soyutlamadır. Sisteme bağlam, etkileşim, yapı ve davranış açılarından bakarız. Modelin ne kadar kesin olacağı ise onu ne için kullandığımıza bağlıdır.

Bağlam Modelleri

Bu bölümde sistem modellemenin ilk adımına, bağlam modellerine bakıyoruz. Örneğimiz, ruh sağlığı kliniklerinde hasta kayıtlarını, randevuları ve tedavileri yöneten AS-HYS olacak.

Önce sınırı çizmek gerekir

Bir sistemi tanımlarken ilk kararlardan biri sınırdır: Hangi işler bizim yazılımımızda yapılacak, hangileri çevredeki başka sistemlere ya da insanlara kalacak? Bu karar paydaşlarla birlikte ve erken verilmelidir. Çünkü sınır netleşmeden ne maliyeti ne de gereksinimleri anlamak için gereken zamanı kestirebiliriz.

Mevcut sistemlerle işlev çakışması

Sınırı çizerken yeni sistemin işlevlerini, çevredeki mevcut sistemlerin işlevleriyle yan yana koyarız. Amaç, aynı işin iki sistemde birden geliştirilmesini önlemektir.

Burada randevu hatırlatma iki tarafta da var. Bu bir çakışmadır: Ya iki ekip aynı işi yapar ya da hastalar iki ayrı hatırlatma alır.

Karar, işlevin nerede yaşayacağını belirler. Örneğin hatırlatmayı mevcut randevu sistemi yapar, AS-HYS yalnızca onu tetikler. Bu kararlar erken verilirse hem maliyet hem de gereksinimleri anlamak için gereken süre sınırlanır.

Sınır her zaman tartışmalı değildir

Eski bir sistemin yerine geçiliyorsa

Yeni sistemin çevresi çoğunlukla eskisinin çevresiyle aynıdır. Sınır büyük ölçüde hazırdır.

Yeni bir iş destekleniyorsa

Hangi işin yazılıma gireceği, gereksinim mühendisliği sırasında paydaşlarla tartışılarak belirlenir.

Bazı projelerde sınır kendiliğinden bellidir. Eski bir sistemin yerine yenisini yazıyorsanız, yeni sistemin çevresi genellikle eskisiyle aynıdır. Ama yeni bir işi destekleyecekseniz, neyin içeride kalacağına gereksinim mühendisliği sırasında birlikte karar verirsiniz.

Bir sınır kararı: hasta bilgileri nerede?

Hasta kayıt sisteminden alınır

＋ Aynı veri iki yerde tutulmaz.

－ Her erişim o sisteme bağlıdır; yavaşlayabilir.

－ O sistem çalışmazsa AS-HYS de iş göremez.

AS-HYS kendi kopyasını tutar

＋ Dış sisteme bağımlılık azalır.

－ İki kopyanın tutarlı kalması gerekir.

－ Saklama ve bakım sorumluluğu projeye girer.

Tek bir doğru yok; önemli olan kararın bilinçli verilmesi ve kayda geçmesi.

Somut bir örnek düşünelim. AS-HYS, hastanın kimlik ve iletişim bilgilerini kendisi mi tutmalı, yoksa hastanenin hasta kayıt sisteminden mi almalı? Dış sistemden alırsak aynı veriyi iki yerde tutmaktan kurtuluruz. Buna karşılık her erişim o sisteme bağlı olur. O sistem yavaşlarsa ya da çalışmazsa AS-HYS de iş göremez.

Veriyi kendimiz tutarsak bağımlılık azalır. Ama bu kez iki kopyanın tutarlı kalmasından ve verinin bakımından biz sorumlu oluruz. Hangisi doğru? Tek bir doğru yok. Önemli olan, bu kararın bilinçli verilmesi ve kayda geçmesi.

Sınırı yalnızca teknik nedenler belirlemez

Maliyet ve iş bölümü

Sınırın yeri, işin hangi ekipte yürüyeceğini ve projenin bütçesini değiştirir.

Kurum içi ilişkiler

Sınır bazen analizin tek bir birimde bitebilmesi ya da belirli bir onay sürecine girilmemesi için kaydırılır.

Farklı kullanıcı grupları

Gruplar çok farklıysa sınır sabitlenmez; kurulumda ayarlanabilen, yapılandırılabilir bir sistem tasarlanır.

Sınırın yeri her zaman teknik bir hesapla belirlenmez. Maliyet, işin hangi ekipte yürüyeceği ve kurum içi ilişkiler de bu kararı etkiler. Örneğin sınır, analizin tek bir birimde tamamlanabilmesi ya da belirli bir onay sürecine girilmemesi için bilinçli olarak kaydırılabilir. Kullanıcı grupları çok farklıysa bir yol daha vardır: Sınırı sabitlemek yerine, kurulum sırasında ayarlanabilen, yapılandırılabilir bir sistem tasarlamak. Aynı yazılımın hem küçük bir muayenehanede hem de büyük bir hastanede kullanılacağını düşünün. İkisinin ihtiyaç duyduğu sınır aynı değildir.

Bağlam diyagramı

Sınır kararları netleşmeye başlayınca, sistemi çevresiyle birlikte gösteren basit bir çizim yaparız: bağlam diyagramı. Ortada geliştirdiğimiz sistem durur.

Solda, AS-HYS’nin veri paylaştığı sistemler var: hastanenin genel hasta kayıt sistemi, hasta kabul sistemi ve randevu sistemi.

Sağda ise AS-HYS’nin bilgi gönderdiği ya da hizmet aldığı sistemler var: reçete sistemi, araştırma için veri toplayan istatistik sistemi ve yönetim raporlama. Bu çizim, sistemi ve çevresini kaba bir yapı olarak gösterir. Bu yüzden mimari modellemenin de ilk adımı sayılır.

Dikkat edin: Çizgiler yalnızca bir ilişki olduğunu söyler. Dış sistem veri mi üretiyor, veri mi tüketiyor? Bağlantı ağ üzerinden mi, yoksa hiç doğrudan bağlantı yok mu? Bağlam diyagramı bunları göstermez. Bu yüzden bağlam modeli tek başına yeterli olmaz; başka modellerle birlikte kullanılır.

Süreç perspektifi

• Bağlam modelleri, ortamdaki diğer sistemleri gösterir; geliştirilen sistemin o ortamda nasıl kullanıldığını göstermez.
• Süreç modelleri, sistemin daha geniş iş süreçlerinin içinde nasıl kullanıldığını ortaya çıkarır.
• İş süreçlerini tanımlamak için UML etkinlik diyagramları kullanılır: etkinlikler, kararlar, eşzamanlı işler ve bunları destekleyen sistemler.

Bağlam diyagramından süreç modeline geçerken soru değişir: “Sistem kimlerle çevrili?” yerine “Sistem hangi işin hangi adımında kullanılıyor?” Sonraki iki slayt bunun iki örneği: basit bir randevu süreci ve daha kapsamlı bir gözaltı süreci.

Süreç modeli: insanlar ve sistemler birlikte

Bağlam diyagramının göstermediği bir şey daha var: Sistemin, içinde çalıştığı iş sürecine nasıl oturduğu. Bunu UML etkinlik diyagramıyla çizilen bir süreç modeliyle gösterebiliriz. Örneğimiz, klinikte yeni bir randevunun oluşturulması.

Görevli hastayla bir gün ve saat konuşur; randevu sistemi o saatin uygun olup olmadığına bakar. Elmas bir karar noktasıdır. Saat doluysa başa döneriz; uygunsa randevu kaydedilir.

Kayıttan sonra iki iş birbirini beklemeden başlar: Hastaya bildirim gider ve kliniğin iş listesi güncellenir. Kalın çubuklar bu eşzamanlılığı gösterir. İki iş de bitince süreç tamamlanır.

Mavi kutular bir sistemin desteklediği adımlardır; beyaz kutu ise insanın yaptığı iştir. Böylece süreç modeli, hangi adımların AS-HYS’ye, hangilerinin başka sistemlere ya da insanlara düştüğünü de görünür kılar.

Daha kapsamlı bir süreç: istemsiz gözaltı

Süreç modellerinin gücü, daha karmaşık iş süreçlerinde ortaya çıkar. Kitaptaki örneği AS-HYS’ye uyarlayalım: kendisi ya da başkaları için tehlike oluşturan bir hastanın istemsiz olarak gözaltına alınması. Bu, sıkı yasal güvencelere bağlı bir süreçtir. Önce gözaltı kararı onaylanır. Ardından hastaya hakları bildirilir ve karar AS-HYS’ye kaydedilir; bu iki iş birbirini beklemez.

Karar noktasında hastanın durumu değerlendirilir. Hasta tehlikeliyse güvenli bir yer aranır: Yer varsa güvenli bir hastaneye, yoksa geçici olarak karakola nakledilir. Hasta tehlikeli değilse hastaneye yatırılır. Bu adımı hasta kabul sistemi destekler.

Hasta nereye nakledilirse edilsin, ardından üç iş paralel yürür: Sosyal hizmetler ve hastanın yakınları bilgilendirilir, gözaltı kaydı güncellenir. Üçü de tamamlanınca süreç biter.

Bu model, bağlam diyagramında gördüğümüz sistemlerin süreçteki yerini gösterir: AS-HYS iki adımı, hasta kabul sistemi bir adımı destekler. Diğer adımlar insanlar tarafından yürütülür. Köşeli parantez içindeki ifadeler koşullardır; hangi akışın izleneceğini belirler.

Özet: Bağlam Modelleri

• Bağlam modeli, sistemin sınırını ve çevresindeki diğer sistemleri gösterir.
• Sınır kararı erken verilir; maliyeti, bağımlılıkları ve sorumlulukları belirler.
• Teknik olmayan etkenler de sınırı etkiler; gerekirse sınır yapılandırılabilir bırakılır.
• Bağlam diyagramının göstermediği iş akışını süreç modeli tamamlar.

Özetleyelim. Bağlam modeli sistemin sınırını ve çevresindeki sistemleri gösterir. Sınır kararı erken verilir; maliyeti, bağımlılıkları ve sorumlulukları belirler. Bağlam diyagramının göstermediği iş akışını ise süreç modelleriyle tamamlarız.

Düşünün

Proje ilerledikçe kapsam durmadan genişliyor. İyi çizilmiş bir bağlam modeli bunu önlemeye nasıl yardım eder?

Son olarak bir soru bırakalım: Proje ilerledikçe kapsam durmadan genişliyorsa, iyi çizilmiş bir bağlam modeli bunu önlemeye nasıl yardım eder? Cevabınızı not alın; derste birlikte tartışacağız.

Alıştırma: Sınır ve maliyet

Sistem sınırının nasıl çizildiği ve bağlam modelinin nasıl kurulduğu, projenin karmaşıklığını ve maliyetini ciddi biçimde etkileyebilir. Bunun geçerli olduğu iki durum örneği verin.

Örnek cevaplar: (1) Ödeme alma işini sistemin içine almak; güvenlik denetimi, sertifikasyon ve bakım maliyeti projeye girer. Dış bir ödeme servisi kullanmak bu maliyeti azaltır ama o servise bağımlılık yaratır. (2) Eski bir hasta kayıt sistemiyle veri paylaşmak; bütünleştirme, veri dönüştürme ve test maliyeti doğar. Veriyi kopyalamak bu maliyeti azaltır ama tutarlılık sorunu getirir. Öğrencilerden her örnekte sınırın iki farklı konumunu karşılaştırmalarını isteyin.

Alıştırma: Etkinlik planlama süreci

Düğün, mezuniyet ve doğum günü gibi etkinliklerin planlanmasına yardım eden bir sistem geliştireceksiniz. Mekân ayırma, davetiye gönderme gibi etkinlikleri ve her aşamada kullanılabilecek sistem öğelerini gösteren bir etkinlik diyagramı çizin.

Beklenen öğeler: başlangıç; tarih ve bütçe belirleme; mekân arama ve ayırma (mekân rezervasyon sistemi); davetli listesi hazırlama; davetiye gönderme (e-posta ya da mesaj sistemi); katılım yanıtlarını toplama; ikram ve süsleme siparişi (eşzamanlı işler, kalın çubuklarla); ödeme (ödeme sistemi); bitiş. Sistem desteği olan adımlar, süreç modelindeki gibi ayrıca işaretlenmeli. Karar noktalarına örnek: mekân uygun değilse yeni mekân aranır.

Etkileşim Modelleri

Bu bölümde etkileşim modellerine bakıyoruz: kullanım durumu diyagramları ve sıra diyagramları. Her sistemde bir tür etkileşim vardır. Kullanıcı veri girer, sistem başka bir sisteme sorar, bileşenler birbirini çağırır.

Etkileşimin üç düzeyi

Etkileşimi üç düzeyde modelleyebiliriz. Kullanıcı ile sistem arasındaki etkileşimi modellemek, gereksinimleri bulmamıza yardım eder.

Sistemler arasındaki etkileşimi modellemek, iletişimde çıkabilecek sorunları erkenden görmemizi sağlar.

Bir sistemin bileşenleri arasındaki etkileşimi modellemek ise önerilen yapının performans ve güvenilirlik beklentilerini karşılayıp karşılamayacağını anlamamıza yardım eder.

Etkileşim modelleme yaklaşımları

Etkileşimi modellemenin birbiriyle ilişkili iki yaklaşımı var:

Kullanım durumu modelleme

Çoğunlukla sistem ile dış aktörler (insanlar ya da diğer sistemler) arasındaki etkileşimi modeller.

Sıra diyagramları

Çoğunlukla sistem bileşenleri arasındaki etkileşimi modeller; dış aktörler de diyagrama katılabilir.

İkisi etkileşimi farklı ayrıntı düzeylerinde gösterir; bu yüzden birlikte kullanılır: Üst düzey bir kullanım durumunun ayrıntısı bir sıra diyagramıyla belgelenebilir.

UML’de etkileşim için iletişim diyagramları da vardır; ileride göreceğimiz gibi bunlar sıra diyagramlarının farklı bir gösterimidir.

Kullanım durumu modelleme

• Kullanım durumları, gereksinimlerin ortaya çıkarılmasını desteklemek için 1990’larda Ivar Jacobson tarafından geliştirildi; daha sonra UML’e dahil edildi.
• Her kullanım durumu, sistemle dış etkileşim içeren ayrı bir görevi temsil eder.
• Kullanım durumundaki aktörler insanlar ya da diğer sistemler olabilir.
• Diyagram genel bir bakış verir; ayrıntı için metin açıklamasına temel oluşturur.

Aktörün bir insan olması gerekmediğini özellikle vurgulayın; AS-HYS örneklerinde randevu sistemi ve hasta kayıt sistemi de aktördür. Metin açıklaması için standart bir biçim yoktur; Sommerville tablo biçimini önerir.

Kullanım durumu diyagramı

Kullanım durumu modeli, etkileşimi en üst düzeyde gösterir. Çöp adam bir aktördür: Sistemle etkileşen bir insan ya da başka bir sistem. Elips ise aktörün sistemden beklediği bir iştir. Burada klinik görevlisi randevu arıyor. Arama için AS-HYS dış randevu sisteminden veri alıyor; bu dış sistem de bir aktördür.

Diyagramı diğer işlerle genişletebiliriz: ayrıntı görüntüleme, randevu oluşturma ve iptal. Dikkat edin: Çizgiler yalnızca kimin hangi işe katıldığını gösterir; adımların sırasını göstermez. Biçimsel olarak çizgiler oksuz çizilir, çünkü UML’de ok mesajın yönünü belirtir ve burada mesajlar iki yönde de akar. Bazı çizimlerde ok, işi kimin başlattığını göstermek için gayriresmî olarak kullanılır.

Örnek: Veri aktarımı kullanım durumu

Tek bir kullanım durumuna yakından bakalım. Klinik görevlisi, AS-HYS’deki hasta bilgilerini hastanenin genel hasta kayıt sistemine aktarıyor. Aktarılan bilgi, güncellenmiş iletişim bilgileri ya da tanı ve tedavi özeti olabilir.

İkinci aktör bir insan değil, başka bir sistem: hasta kayıt sistemi. Aktörler insanlar da olabilir, diğer sistemler de. Buradaki oklar gayriresmî kullanılmıştır: İşi görevlinin başlattığını ve verinin kayıt sistemine aktarıldığını gösterir.

Diyagramın göstermediği ayrıntılar yine metin açıklamasına yazılır: aktarılan veri, işi başlatan uyaran, sistemin tepkisi ve güvenlik izni gibi notlar.

Bileşik kullanım durumu diyagramları

Bir aktörün sistemle bütün etkileşimleri tek bir bileşik diyagramda gösterilebilir. Kullanım durumu sayısı arttıkça bu mümkün olmaz. O zaman birbiriyle ilgili kullanım durumlarını ayrı diyagramlarda toplarız. Burada görevlinin randevu işlemleri bir arada.

Aynı aktörün hasta kaydıyla ilgili işleri ise ikinci bir diyagramda durur.

Diyagramdaki her kullanım durumu, daha önce gördüğümüz tablo biçiminde ayrıca açıklanır. UML’de kullanım durumlarını paylaşmak için yapılar da vardır. Sommerville, son kullanıcıların bunları zor anladığını söyleyerek ayrıntısına girmez.

Diyagram yetmez: metin açıklaması

Kullanım durumu	Randevu ara
Aktörler	Klinik görevlisi, Randevu sistemi
Açıklama	Görevli, seçtiği klinik ve gün için randevuları listeler.
Veri	Klinik, gün, görevlinin yetkili olduğu birimler, randevu kayıtları
Uyaran	Görevli klinik ve günü seçip aramayı başlatır.
Tepki	Eşleşen randevular saat sırasıyla listelenir.
Notlar	Yetki yoksa liste açılmaz; eşleşme yoksa boş sonuç gösterilir.

Kullanım durumu diyagramı yalnızca genel bir bakış verir. Ayrıntıyı metinle anlatırız. Bu açıklama çoğunlukla bir tabloyla yazılır: aktörler, kısa bir açıklama, kullanılan veri, işi başlatan uyaran, sistemin tepkisi ve notlar. Notlar satırında, diyagramda hiç görünmeyen bir durumu yakalıyoruz: Görevlinin yetkisi yoksa liste açılmaz.

Sıra diyagramları

• Sıra diyagramları, bir sistemdeki aktörler ve nesneler arasındaki etkileşimleri modellemek için kullanılan UML diyagramlarıdır.
• Belirli bir kullanım durumu sırasında gerçekleşen etkileşimlerin sırasını gösterir.
• İlgili nesneler ve aktörler diyagramın üstünde listelenir; her birinden aşağı doğru kesikli bir yaşam çizgisi iner.
• Nesneler arasındaki etkileşimler etiketli oklarla gösterilir; diyagram yukarıdan aşağıya okunur.

Kullanım durumu “hangi iş” sorusunu cevaplıyordu; sıra diyagramı “bu iş adım adım nasıl yürüyor” sorusunu cevaplar. Sonraki slaytta randevu aramanın sıra diyagramını adım adım çiziyoruz.

Sıra diyagramı

Kullanım durumu hangi işin yapıldığını gösterir. Sıra diyagramı ise bu işte mesajların hangi sırayla gönderildiğini gösterir. Üstte, etkileşime katılan aktörler ve nesneler yan yana dizilir. Her birinden aşağı inen kesikli çizgi, onun yaşam çizgisidir. Zaman yukarıdan aşağıya akar.

Görevli klinik ve günü seçer. Arayüz önce yetki servisine, bu görevlinin o kliniği görmeye yetkisi olup olmadığını sorar. Kesikli ok bir yanıttır: Yetki servisi sonucu arayüze döndürür.

Köşesinde alt yazan çerçeve, koşullu bir seçimi gösterir. Köşeli parantezdeki koşullardan hangisi doğruysa o bölüm çalışır. Görevli yetkiliyse arayüz randevuları dış randevu sisteminden ister ve gelen listeyi gösterir.

Yetkisi yoksa yalnızca bir uyarı gösterilir. Kullanım durumu tablosundaki notu hatırlayın: Aynı kural, şimdi zaman sırasıyla birlikte görünüyor.

Sıra diyagramında ayrıntı

Aynı randevu aramasını şimdi tasarıma yakın bir ayrıntıyla çizelim. Yaşam çizgisi üzerindeki ince dikdörtgen, o nesnenin etkileşimde rol aldığı süreyi gösterir. Arayüz, aramayı aldığı andan sonuç dönene kadar etkindir.

Okların üzerindeki etiketler artık yalnızca işi değil, çağrının kendisini gösterir: işlem adı ve parametreleri. Kesikli ok dönüş değeridir. Yetki servisi doğru ya da yanlış değerini döndürür.

Randevu sistemi de parametrelerle çağrılır ve bir randevu listesi döndürür. Arayüz bu listeyi görevliye gösterir.

Kod üretmeyecek ya da ayrıntılı belge hazırlamayacaksanız bu düzeydeki her etkileşimi çizmeniz gerekmez. Gereksinim aşamasında uygulamaya bağlı kararlar sonraya bırakılabilir.

Aktörler arası iletişim ve nesne oluşturma

Sıra diyagramı, aktörlerin sistem dışında kendi aralarındaki iletişimini de gösterebilir. Burada hekim, görevliden hasta için bir kontrol randevusu istiyor. Bu mesaj sisteme girmeden önce iki insan arasında geçiyor.

Görevli isteği arayüze girer. Arayüz bu çağrıyla etkinleşir.

Etkileşim sürerken yeni bir nesne de oluşturulabilir. Arayüz bir randevu nesnesi yaratır. Nesnenin kutusu diyagramın tepesinde değil, oluşturulduğu anın hizasında çizilir; yaşam çizgisi de oradan başlar.

Randevu nesnesi randevu sistemine kaydedilir; onay döner ve görevli randevu numarasını hekime iletebilir.

İletişim diyagramı: aynı etkileşim, başka gösterim

UML’de etkileşimi göstermenin bir yolu daha var: iletişim diyagramı. Burada zaman ekseni yoktur. Nesneler serbestçe yerleştirilir; çizgiler, birbirine mesaj gönderen nesneleri bağlar.

Mesajların sırasını numaralar verir: Önce arama, sonra yetki denetimi, en son liste isteği. Sıra diyagramındaki etkileşimin aynısı.

İkisi aynı bilgiyi taşır: Sıra diyagramı zamanı, iletişim diyagramı ise kimin kiminle bağlantılı olduğunu öne çıkarır. Sommerville iletişim diyagramlarını ayrıca anlatmaz, çünkü sıra diyagramlarının yalnızca farklı bir gösterimidir. Yine de araçlarda ve belgelerde karşınıza çıkabilir.

Ne kadar ayrıntı?

Gereksinim aşamasında

Her mesajı ve parametreyi çizmeyiz. Önemli etkileşimleri gösteririz.

Tasarım ilerledikçe

Mesajlar gerçek işlem adlarına ve parametrelere dönüşür; model koda yaklaşır.

Kullanım durumu hangi işin yapıldığını, sıra diyagramı bu işin adım adım nasıl yürüdüğünü anlatır.

Gereksinim aşamasında çizilen bir sıra diyagramında her mesajı ya da her parametreyi göstermek gerekmez. Tasarım ilerledikçe mesajlar gerçek işlem adlarına ve parametrelere dönüşür, model koda yaklaşır. Kullanım durumu ve sıra diyagramı birlikte iyi çalışır: Biri hangi işin yapıldığını, diğeri bu işin adım adım nasıl yürüdüğünü anlatır.

Özet: Etkileşim Modelleri

• Kullanım durumları, sistemle dış aktörler arasındaki etkileşimi gösterir.
• Metin açıklaması, diyagramda görünmeyen kuralları ve istisnaları yakalar.
• Sıra diyagramları, aynı etkileşimin zaman içindeki akışını gösterir.

Bir öğrencinin derse kaydı için sıra diyagramı çizin. Kontenjan dolu olabilir; kayıttan önce yer kontrolü yapılmalı.

Özetle: Kullanım durumları sistemle dış aktörler arasındaki etkileşimi, sıra diyagramları ise bu etkileşimin zaman içindeki akışını gösterir. Kendiniz deneyin: Bir öğrencinin derse kaydını gösteren bir sıra diyagramı çizin. Dersin kontenjanı dolu olabileceği için kayıttan önce yer kontrolü yapılmalı.

Alıştırma: Hekimin kullanım durumları

AS-HYS’de hastaları muayene eden, ilaç ve tedavi öneren hekim ile sistem arasındaki etkileşimleri gösteren bir kullanım durumları kümesi önerin.

Örnek kullanım durumları: hasta kaydını görüntüle, görüşme notu ekle, tanı koy, ilaç reçete et (reçete sistemi aktör olarak), tedavi planı oluştur, kontrol randevusu iste (randevu sistemi aktör olarak), hasta geçmişini incele. Öğrencilerden en az birini tablo biçiminde (aktörler, açıklama, veri, uyaran, tepki, notlar) açıklamalarını isteyin.

Yapısal Modeller

Bu bölümde yapısal modellere bakıyoruz. Yapısal modeller, sistemin hangi parçalardan oluştuğunu ve bu parçaların birbiriyle nasıl ilişkili olduğunu gösterir.

Statik ve dinamik yapı

Statik yapı

Tasarımın örgütlenmesi: sınıflar ve aralarındaki ilişkiler.

Bu bölümün konusu.

Dinamik yapı

Sistemin çalışırken nasıl örgütlendiği: süreçler, iş parçacıkları.

Mimari tasarımda ele alınır.

Yapısal modeller iki türlü olabilir. Statik modeller tasarımın örgütlenmesini gösterir. Dinamik modeller ise sistemin çalışırken nasıl örgütlendiğini. Burada statik yapıya, özellikle sınıf diyagramlarına odaklanıyoruz. Yapısal modeller, sistemin mimarisini tartışırken de kullanılır.

Sınıf diyagramları

• Sınıf diyagramları, nesneye dayalı bir sistem modeli geliştirilirken sistemdeki sınıfları ve aralarındaki ilişkileri göstermek için kullanılır.
• Bir nesne sınıfı, bir tür sistem nesnesinin genel tanımıdır.
• Bir ilişki (association), iki sınıf arasında bir bağ olduğunu gösteren bağlantıdır.
• Yazılım sürecinin ilk aşamalarında nesneler gerçek dünyadaki şeyleri temsil eder: hasta, reçete, hekim, randevu gibi.

Erken modellerde sınıflar alanın kavramlarıdır; tasarım ilerledikçe yazılımdaki sınıflara dönüşürler. Sonraki slaytlarda en basit hâlden başlayıp ayrıntıyı adım adım artırıyoruz.

En basit sınıf diyagramı

Sınıf diyagramı, sistemdeki nesne sınıflarını ve bunlar arasındaki ilişkileri gösterir. En basit hâliyle her sınıf, içinde yalnızca adı yazan bir kutudur. Aradaki çizgi bir ilişkiyi gösterir. Çizginin uçlarındaki ifadeler çokluktur: Bir randevu tam olarak bir hastaya aittir. Bir hastanın ise hiç randevusu olmayabilir ya da birçok randevusu olabilir.

Bu ifadeler yalnızca çizim ayrıntısı değildir; birer iş kuralıdır. Örneğin hastası belirtilmemiş bir randevu kaydedilemez.

Çoka çok ilişki

İlişkiler iki yönde de çoklu olabilir. Bir hastanın birden fazla tanısı olabilir; aynı tanı da birçok hastada görülür. Buna çoka çok ilişki diyoruz.

AS-HYS’deki sınıflar ve bağlantıları

Sınıf diyagramının gücü, birçok sınıfı ve ilişkiyi tek bakışta göstermesidir. AS-HYS’nin hasta etrafındaki sınıflarına bakalım. Bir hastaya bir ya da daha fazla tanı konur. Hasta bir aile hekimi tarafından sevk edilir ve bir konsültan hekime sevk edilir.

Hasta görüşmelere katılır. Her görüşmeyi en az bir, en fazla dört hastane hekimi yürütür. Çokluktaki bir ile dört ifadesi doğrudan bir iş kuralıdır.

Görüşmede ilaç ve tedavi reçete edilir. Böylece hastanın bakımıyla ilgili bütün kavramlar ve aralarındaki ilişkiler tek bir şemada toplanmış olur.

Özellikler ve işlemler

Bir sınıfı daha ayrıntılı tanımlamak için kutuyu üç bölüme ayırırız. En üstte sınıfın adı, ortada özellikleri, en altta ise işlemleri yer alır. Özellikler nesnenin taşıdığı bilgileri, işlemler ise nesnenin yapabildiklerini anlatır. Java gibi dillerde işlemlere metot denir.

İlişkileri tartışırken sınıfları en sade hâliyle, yalnızca adlarıyla çizmek çoğu zaman daha okunaklıdır. Ayrıntıyı gerektiğinde ekleriz.

Özellik türleri ve parametreler

Erken modellerde sınıfın özelliklerini yalnızca adlarıyla yazarız. Türler isteğe bağlıdır.

Tasarım ilerledikçe özelliklere türleri, işlemlere de parametreleri ve dönüş türleri eklenir. Durum özelliğinin türü bir sınıf da olabilir: Randevunun durumları ayrı bir tür olarak tanımlanır ve durum diyagramıyla bağlantı kurulur.

Ne kadar ayrıntı yazacağımız, modelin amacına bağlıdır. Kod üretilecekse türler zorunlu hâle gelir.

Sınıf diyagramı ve veri modeli

Bu düzeyde bir sınıf diyagramı, veritabanı tasarımında kullanılan anlamsal veri modellerine çok benzer. Varlıkları işlemleri olmayan sade sınıflar, nitelikleri sınıf özellikleri, ilişkileri de adlandırılmış bağlantılar olarak düşünebilirsiniz. UML’de ayrı bir veritabanı diyagramı yoktur. Veriyi nesneler ve aralarındaki ilişkilerle modelleriz.

Genelleştirme nedir?

• Genelleştirme, karmaşıklığı yönetmek için her gün kullandığımız bir tekniktir.
• Her varlığın ayrıntılarını tek tek öğrenmek yerine onları genel sınıflara (hayvanlar, arabalar, evler) yerleştirir, bu sınıfların özelliklerini öğreniriz.
• Böylece farklı üyelerin ortak özellikleri olduğu sonucuna varırız: Sincap ve sıçan birer kemirgendir; bütün kemirgenlerin kemirmeye uygun dişleri vardır.
• Modellemede de sınıfları inceleyip genelleştirme fırsatı ararız: Ortak bilgi tek yerde tutulur, değişiklik en genel düzeyde yapılır.

Günlük örnekten başlayın, sonra yazılıma geçin. Java gibi nesneye dayalı dillerde genelleştirme, sınıf kalıtımıyla gerçekleştirilir. Alt sınıflar üst sınıfın özelliklerini ve işlemlerini devralır, sonra kendilerine özgü olanları ekler.

Genelleştirme

Genelleştirme, karmaşıklığı yönetmek için her gün kullandığımız bir tekniktir: Her şeyi tek tek öğrenmek yerine genel sınıfları öğrenir, farklara odaklanırız. Sistemde de ortak bilgiyi bir üst sınıfta toplarız. Klinik görevlisi de hekim de birer kullanıcıdır; ikisinin de numarası, adı ve oturum açma işlemi vardır. İçi boş üçgen, genel sınıfı gösterir. Alt sınıflar üst sınıfın özelliklerini ve işlemlerini devralır, sonra kendilerine özgü olanları ekler.

Hiyerarşi birden fazla düzeyli olabilir: Psikiyatrist bir hekimdir, hekim de bir kullanıcıdır. Bunun faydası şudur: Ortak bilgi tek yerde durduğu için bir değişikliği en genel düzeyde yapar, bütün alt sınıflara yansıtırız. Nesneye dayalı dillerde genelleştirme, kalıtım mekanizmasıyla gerçekleştirilir.

Bir genelleştirme hiyerarşisi

Kitaptaki örnek bir hekim hiyerarşisidir. Bütün hekimler önce iki gruba ayrılır: hastanede çalışan hekimler ve bağımsız çalışan aile hekimleri.

Hastane hekimleri de ikiye ayrılır: tam karar yetkisi olan kıdemli konsültanlar ve bir konsültanın ekibinde çalışan hekimler.

Ekip hekimleri de yeni mezun olup gözetim altında çalışan asistanlar ve bağımsız çalışabilen uzmanlar olarak ayrılır. Hiyerarşi üç düzey derinliğindedir. Her alt sınıf üst sınıfının bütün özelliklerini devralır.

Ek ayrıntı içeren bir genelleştirme hiyerarşisi

Aynı hiyerarşinin üst kısmını şimdi özellik ve işlemleriyle çizelim. Bütün hekimlerin adı, telefonu ve e-postası vardır; sisteme kaydedilir ya da kayıtları silinir.

Hastane hekimlerinin ayrıca bir personel numarası ve çağrı cihazı vardır. Aile hekimleri bağımsız çalıştığı için bunlara sahip değildir; onların muayenehanesi ve adresi vardır. Alt sınıflar ortak özellikleri tekrar yazmaz: ad, telefon, e-posta ve kayıt işlemleri üst sınıftan devralınır.

Bütünleme: parça ve bütün

Gerçek dünyadaki nesneler çoğu zaman parçalardan oluşur. UML bunu bütünleme ilişkisiyle gösterir. Boş elmas bütün tarafına konur. Bir klinik bir ya da daha fazla oda içerir.

Benzer şekilde bir hasta dosyası, hastanın her görüşmesi için ayrı bir görüşme kaydı barındırır. Bunu genelleştirmeyle karıştırmayın: Klinik bir oda değildir, odaları içerir.

Sınıf diyagramı neyi göstermez?

• Zaman ve sıra: Hangi işlem önce çalışır?
• Durum: Bu randevu şu an onaylı mı, iptal mi?
• Bunlar için sıra diyagramlarına ve davranışsal modellere bakarız.

Sınıf diyagramı sistemin durağan yapısını gösterir. İşlemlerin hangi sırayla çalıştığını ya da bir nesnenin şu anki durumunu göstermez. Bunlar için sıra diyagramlarına ve davranışsal modellere ihtiyacımız var.

Özet: Yapısal Modeller

• Sınıf diyagramları sınıfları, ilişkileri ve çoklukları gösterir.
• Genelleştirme ortak bilgiyi üst sınıfta toplar.
• Bütünleme parça–bütün ilişkisini gösterir.

Kullandığınız e-posta uygulamasında posta kutusu ve e-posta mesajını temsil edecek sınıfları modelleyin.

Özetle: Sınıf diyagramları sistemin durağan yapısını, sınıfları ve aralarındaki ilişkileri gösterir. Genelleştirme ortak bilgiyi bir üst sınıfta toplar; bütünleme ise parça ile bütün arasındaki ilişkiyi gösterir. Kendiniz deneyin: Kullandığınız e-posta uygulamasında posta kutusu ve e-posta mesajını temsil edecek sınıfları modelleyin.

Davranışsal Modeller

Bu bölümde davranışsal modellere bakıyoruz. Davranışsal modeller, sistem çalışırken ne olduğunu ya da ne olması gerektiğini gösterir: Sistem çevresinden gelen bir uyarana nasıl tepki verir?

İki tür uyaran

Veri

Yeni veri gelir ve işlenmesi gerekir; verinin gelmesi işlemi tetikler.

Ay sonunda reçete kayıtlarından maliyet raporu.

Olay

Bir olay olur ve sistem tepki verir. Olayla birlikte veri gelebilir de, gelmeyebilir de.

Hasta randevusunu iptal eder.

İş sistemlerinin çoğu veri güdümlüdür; gerçek zamanlı sistemler çoğunlukla olay güdümlüdür.

Bir sistemi harekete geçiren iki tür uyaran vardır: veri ve olay. Veri güdümlü durumda yeni veri gelir ve bu verinin işlenmesi gerekir. Ay sonunda reçete kayıtlarından maliyet raporu üretmek buna örnektir. Olay güdümlü durumda ise bir olay olur ve sistem buna tepki verir. Hastanın randevusunu iptal etmesi gibi.

İş sistemlerinin çoğu ağırlıkla veri güdümlüdür. Gerçek zamanlı sistemler ise çoğunlukla olay güdümlüdür; az veri işler, çok olaya tepki verir.

Veri güdümlü model: etkinlik diyagramı

Veri güdümlü bir modelde, veriyi girişten çıkışa kadar işleyen adımların sırasını gösteririz. Örneğimiz AS-HYS’nin aylık ilaç maliyeti raporu. Sistem ay içindeki reçete kayıtlarını alır, klinik bazında gruplar ve maliyeti hesaplar.

Sonra raporu oluşturur ve yöneticilere gönderir. Yuvarlak köşeli kutular işlemlerdir; köşeli kutular ise adımlar arasında akan veridir.

Bu tür modellerin geçmişi eskidir. Yetmişli yıllarda veri akış diyagramları kullanılırdı. UML bu amaçla etkinlik diyagramını sunar. Bu modellerin gücü, veriyi uçtan uca izlemeleridir. Teknik bilgisi olmayan paydaşlar bile adımları kolayca takip edebilir.

Aynı işlem, sıra diyagramıyla

Aylık maliyet raporunu bu kez bir sıra diyagramıyla çizelim. Rapor sorumlusu, ilgili ay için raporun oluşturulmasını başlatır. Dikdörtgenler, her katılımcının etkin olduğu süreyi gösterir. Sorumlu ve rapor nesnesi işlem boyunca etkindir.

Rapor nesnesi önce kendi işlemini çağırır: Ay ve kapsam bilgisinin geçerli olduğunu doğrular. Kendine dönen ok bunu gösterir.

Doğrulama başarılıysa, köşeli parantezdeki koşul sağlanmış olur ve rapor, reçete deposundan o ayın kayıtlarını ister.

Kayıtlar maliyet hesaplayıcıya parametre olarak verilir; klinik bazında maliyet tablosu döner.

Son olarak rapor yöneticiye gönderilir. Etkinlik diyagramındaki her adım burada bir işlev çağrısına dönüştü. Bu diyagram, hangi nesnenin hangi işi yaptığını gösterdiği için tasarıma bir adım daha yakındır.

Olay güdümlü modelleme

• Gerçek zamanlı sistemler çoğunlukla olay güdümlüdür ve az veri işler. Örneğin bir telefon santrali, “ahize kaldırıldı” olayına çevir sesi üreterek tepki verir.
• Olay güdümlü modelleme, bir sistemin iç ve dış olaylara nasıl tepki verdiğini gösterir.
• Sistemin sınırlı sayıda durumu olduğu ve olayların (uyaranların) bir durumdan diğerine geçişe yol açtığı varsayımına dayanır.
• Durum makinesi modelleri, durumları düğümler, olayları da bu düğümler arasındaki oklar olarak gösterir.

Veri güdümlü modelde soru “veri hangi adımlardan geçiyor?” idi; burada soru “sistem şu an hangi durumda ve hangi olay onu başka bir duruma götürür?” Randevu örneğiyle başlayıp ardından gerçek zamanlı bir cihaza geçeceğiz.

Olay güdümlü model: durum diyagramı

Olay güdümlü sistemleri modellemek için UML durum diyagramlarını kullanırız. Durum diyagramı, sistemin ya da bir nesnenin bulunabileceği durumları ve onu bir durumdan diğerine geçiren olayları gösterir. Bir randevu talep olarak başlar. Görevli onaylarsa onaylı durumuna geçer.

Onaylı bir randevu üç şekilde son bulabilir: Görüşme yapılır, hasta gelmez ya da randevu iptal edilir. Talep aşamasındaki bir randevu da onaylanmadan iptal edilebilir. Yuvarlak köşeli kutular durumlardır. Okların üzerindeki adlar ise geçişi tetikleyen olaylardır.

Süper durum: ayrıntıyı içeri almak

Durum sayısı arttıkça diyagram hızla karmaşıklaşır. Bunu yönetmenin bir yolu süper durumlardır. Ana diyagramda tek kutu olarak görünen onaylı durumu, içinde kendi alt durumlarını barındırabilir. Önce hatırlatma planlanır; randevu günü gelince sistem hastayı beklemeye geçer. Do ile başlayan satır, o durumdayken sürdürülen işi gösterir.

Böylece ana diyagram sade kalır, ayrıntı ayrı bir diyagramda anlatılır.

Durum–olay tablosu

Mevcut durum	Olay	Sonraki durum
Talep	Görevli onaylar	Onaylı
Talep	Görevli iptal eder	İptal
Onaylı	Görüşme biter	Tamamlandı
Onaylı	Hasta gelmez	Gelinmedi
Onaylı	Görevli iptal eder	İptal

Eksik bir olay var: Hasta randevusunu başka bir güne almak isterse?

Durum diyagramını bir tabloyla tamamlamak, geçişleri tek tek sınamayı kolaylaştırır: Her durumda hangi olay gelirse nereye gidilir?

Tabloya bakınca bir eksik göze çarpıyor: Hasta randevusunu başka bir güne almak isterse ne olacak? Model bize eksik bir iş kuralını gösterdi. Mevcut randevu mu güncellenecek, yoksa iptal edilip yenisi mi açılacak? Buna paydaşlarla birlikte karar vermemiz gerekir.

Durum diyagramları ve Statecharts

• UML durum diyagramları, Harel’in Statecharts gösterimine (1987) dayanır.
• Sistemin durumlarını ve geçişi tetikleyen olayları gösterir; sistem içindeki veri akışını göstermez, ama her durumda yapılan işi (do) belirtebilir.
• Statecharts’ın getirdiği en önemli kolaylık süper durumlardır: Ayrıntı iç içe durumlara alınır, ana diyagram sade kalır.
• Durum diyagramı genel bir bakış verir; ayrıntı için durumları ve uyaranları açıklayan tablolarla tamamlanır.

Randevu örneği bir iş nesnesinin yaşam döngüsüydü. Kitabın vurgusu ise kontrol yazılımlarıdır: bir vananın açık durumdan kapalı duruma operatör komutuyla geçmesi gibi. Sommerville bunu basit bir mikrodalga fırınla örnekler; biz benzer bir cihaz olarak kahve makinesini modelliyoruz.

Kahve makinesinin çalışma sırası (varsayım)

1. Kullanıcı bir içecek seçer.
2. Ödemeyi yapar.
3. Makine suyu ısıtır, kahveyi demler ve bardağa doldurur.
4. Kullanıcı bardağı alır; makine yeniden bekler.

Hazırlık sürerken kapak açılırsa makine güvenlik için durur; kapak kapanınca beklemeye döner.

Durum diyagramını çizmeden önce cihazın nasıl kullanıldığını varsayımlar olarak yazmak işi kolaylaştırır. Gerçek bir makine çok daha karmaşıktır; bu basitleştirilmiş bir modeldir.

Gerçek zamanlı örnek: kahve makinesi

Olay güdümlü modelleme özellikle gerçek zamanlı ve gömülü sistemlerde kullanılır: az veri işlenir, çok olaya tepki verilir. Kitap bunu basit bir mikrodalga fırınla örnekler. Biz benzer bir cihazı, bir kahve makinesinin kontrol yazılımını modelleyelim. Makine bekler; kullanıcı bir içecek seçince seçim yapıldı durumuna geçer.

Ödeme alınınca makine hazırlanıyor durumuna geçer. Bu bir süper durumdur; içinde kendi sırası vardır. Su ısıtılır, sıcaklık hazır olunca kahve demlenir, demleme süresi dolunca bardağa doldurulur.

Hazırlık bitince makine hazır durumuna geçer. Hazırlanırken kapak açılırsa, hangi alt durumda olursa olsun makine devre dışı kalır. Süper durumdan çıkan tek bir ok bunu bütün alt durumlar için söyler.

Bardak alınınca ya da kapak kapanınca makine yeniden beklemeye döner. Durum diyagramı veri akışını göstermez; ama her durumda ne yapıldığını ve hangi olayın geçişi tetiklediğini açıkça gösterir.

Kahve makinesi: durumlar

Durum	Açıklama
Bekliyor	Ekranda “İçecek seçin” yazar; ısıtıcı kapalıdır.
Seçim yapıldı	Seçilen içecek ve fiyatı gösterilir; ödeme beklenir.
Hazırlanıyor	Su ısıtılır, kahve demlenir, bardağa doldurulur; kapak kilitlidir.
Devre dışı	Isıtıcı ve pompa durur; ekranda “Kapağı kapatın” yazar.
Hazır	Ekranda “İçeceğiniz hazır” yazar; sesli uyarı verilir.

Randevu için kullandığımız durum–olay tablosu yalnızca geçişleri listeliyordu. Kitaptaki tablolar bir adım ileri gider: Önce her durumun ne anlama geldiği açıklanır.

Kahve makinesi: uyaranlar

Uyaran	Açıklama
İçecek seçildi	Kullanıcı bir içecek düğmesine bastı.
Ödeme alındı	Ödeme birimi tutarın alındığını bildirdi.
Sıcaklık hazır	Sıcaklık algılayıcısı hedef değere ulaşıldığını bildirdi.
Süre doldu	Demleme zamanlayıcısı sona erdi.
Kapak açıldı / kapandı	Kapak anahtarı konum değiştirdi.
Bitti	Doldurma tamamlandı.
Bardak alındı	Bardak algılayıcısı bardağın alındığını bildirdi.

Uyaranların çoğunun bir algılayıcıdan ya da zamanlayıcıdan gelmesi, gerçek zamanlı sistemlerin tipik özelliğidir. Her uyaranın nereden geldiğini yazmak, donanım arayüzlerinin gereksinimlerini de ortaya çıkarır.

Özet: Davranışsal Modeller

• Davranışsal modeller, sistemin çalışırken nasıl tepki verdiğini gösterir.
• Veri güdümlü davranış: etkinlik (ya da sıra) diyagramı.
• Olay güdümlü davranış: durum diyagramı; karmaşıklık için süper durumlar.

Farklı yıkama programları olan bir çamaşır makinesinin kontrol yazılımı için durum diyagramı çizin.

Özetle: Davranışsal modeller sistemin çalışırken nasıl tepki verdiğini gösterir. Veri güdümlü davranışı etkinlik diyagramlarıyla, olay güdümlü davranışı durum diyagramlarıyla modelleriz. Kendiniz deneyin: Farklı yıkama programları olan bir çamaşır makinesinin kontrol yazılımı için bir durum diyagramı çizin.

Alıştırma: ATM’den para çekme

Bir ATM’den para çekerken gerçekleşen veri işleme adımlarını gösteren bir etkinlik diyagramı, ardından aynı iş için bir sıra diyagramı çizin. Bir sistemin davranışını modellerken neden ikisine birden ihtiyaç duyabileceğinizi açıklayın.

Önce öğrencilerin kendi çözümlerini çizmelerine fırsat verin; sonraki iki slayt örnek çözümdür. Tartışmada şunu vurgulayın: Etkinlik diyagramı kararları ve hata yollarını, sıra diyagramı bileşenler arasındaki sorumluluğu gösterir.

Örnek çözüm: ATM etkinlik diyagramı

Alıştırmanın bir örnek çözümüyle başlayalım. Müşteri kartı takar ve PIN girer. PIN yanlışsa ve deneme sayısı üçten azsa müşteri yeniden dener.

Üçüncü yanlış denemede makine kartı tutar ve işlem biter.

PIN doğruysa müşteri tutarı girer. Banka sistemi bakiyeyi kontrol eder. Bakiye yetersizse bir uyarı gösterilir ve müşteri yeni bir tutar girebilir.

Bakiye yeterliyse para verilir ve tutar hesaptan düşülür. Bu iki iş birbirini beklemez; kalın çubuklar bunu gösterir. İkisi de tamamlanınca kart iade edilir.

Örnek çözüm: ATM sıra diyagramı

Aynı işi şimdi bir sıra diyagramıyla çizelim. Katılımcılar müşteri, ATM, banka sistemi ve hesap.

Müşteri kartı takar ve PIN girer; ATM, PIN’i banka sistemine doğrulatır.

Müşteri tutarı girer; banka sistemi hesaptan düşer ve ATM’ye onay verir. ATM parayı ve kartı verir. Neden iki diyagram? Etkinlik diyagramı kararları ve eşzamanlı işleri, özellikle hata yollarını açıkça gösterir. Sıra diyagramı ise hangi bileşenin hangisiyle konuştuğunu ve sorumlulukları gösterir; tasarıma daha yakındır.

Model Güdümlü Mühendislik

Bu bölümde model güdümlü mühendisliğe bakıyoruz. Şimdiye kadar modelleri tartışmak ve belgelemek için kullandık. Peki model, programın kendisine dönüşebilir mi?

Modelin rolü değişir

Geleneksel geliştirmede model, programcıya yol gösteren bir belgedir; kodu insan yazar.

Model güdümlü mühendislikte ise asıl çıktı modeldir. Program, modelden araçlar yardımıyla otomatik olarak üretilir. Böylece mühendisler programlama dilinin ayrıntılarıyla değil, daha yüksek bir soyutlama düzeyinde çalışır.

MDA ve MDE

MDA · Model güdümlü mimari

OMG’nin önerdiği, UML tabanlı yaklaşım. Tasarım ve uygulamaya odaklanır. Model güdümlü mühendisliğin öncüsüdür.

MDE · Model güdümlü mühendislik

Daha geniş yaklaşım: Modeller tasarımın yanında doğrulama ve test gibi diğer süreç etkinliklerinde de merkezdedir.

Bu alanda iki terim sıkça karşımıza çıkar. Model güdümlü mimari, yani MDA, OMG adlı standart kuruluşunun önerdiği, UML tabanlı ve tasarımla uygulamaya odaklanan bir yaklaşımdır. Model güdümlü mühendislik, yani MDE, bu fikri genişletir: Modeller yalnızca tasarımda değil, doğrulama ve test gibi diğer süreç etkinliklerinde de merkezdedir.

MDA’nın üç model düzeyi

MDA üç tür soyut model önerir. En üstte hesaplamadan bağımsız model vardır. Alanın önemli kavramlarını anlatır; bu yüzden bazen alan modeli de denir. Hasta, randevu ve tanı gibi.

Sonra platformdan bağımsız model gelir. Sistemin işleyişini, nasıl uygulanacağından bağımsız olarak anlatır. Genellikle UML sınıf ve durum modelleriyle çizilir.

En altta platforma özgü model vardır: Platformdan bağımsız modelin belirli bir platforma dönüştürülmüş hâli. Bir sistem birden fazla kavramsal modelden beslenebilir. Örneğin bir modeldeki rol kavramı, başka bir modeldeki personel kavramıyla eşleştirilebilir.

Bir PIM, iki platform

Bu yaklaşımın vaadi şuydu: Tek bir platformdan bağımsız model tutarsınız; çeviriciler her platform için ayrı modeli ve kodu üretir. Sistem yeni bir platforma taşınacaksa, yalnızca o platform için bir çevirici yazmak yeterli olur. Böylece mühendisler daha yüksek bir soyutlama düzeyinde düşünür, modelleri de platformlar arasında yeniden kullanır.

Neden ana akım olmadı?

1 · Yerel çeviriciler

Şirkete özgü kütüphaneler ve dış hizmetler için özel çeviriciler gerekir; geliştirmesi ve bakımı pahalıdır.

2 · Soyutlama uyumsuzluğu

Tartışmaya yarayan soyutlamalar, uygulama için her zaman doğru soyutlamalar değildir.

3 · Asıl zorluk başka yerde

Karmaşık sistemlerde asıl güçlük kod yazmak değil; gereksinimler, güvenlik, bütünleştirme ve testtir.

4 · Platform bağımsızlığının bedeli

Kazanç uzun ömürlü büyük sistemlerde görülür; standart platformlarda araç maliyeti kazancı aşabilir.

Bu vaat, beklenen yaygınlığa ulaşmadı. Bunun birkaç nedeni var. Birincisi, çalışma ortamı yalnızca standart bir platformdan ibaret değildir. Şirkete özgü kütüphaneler ve dış hizmetler için özel çeviriciler yazmak gerekir. Bunları geliştirmek ve sürdürmek pahalıdır; küçük araç firmalarına bağımlı kalmak da risklidir. İkincisi, tartışmaya yarayan soyutlamalar uygulama için her zaman doğru soyutlamalar değildir. Bazen hazır bir uygulamayı yeniden kullanmak daha iyi bir yoldur.

Üçüncüsü, karmaşık sistemlerde asıl güçlük çoğunlukla kodu yazmak değildir. Gereksinim mühendisliği, güvenlik, eski sistemlerle bütünleşme ve test daha büyük sorunlardır. Dördüncüsü, platform bağımsızlığı yalnızca platformların sistem ömrü içinde eskidiği büyük ve uzun ömürlü sistemlerde kazanç sağlar. Standart platformlara yönelik ürünlerde araç ve kurulum maliyeti bu kazancı aşabilir. Aynı yıllarda çevik yöntemlerin yaygınlaşması da dikkati model güdümlü yaklaşımlardan uzaklaştırdı.

Nerede işe yaradı?

• Donanım ve yazılımın birlikte geliştirildiği ürünler: otomotiv, hava trafik kontrolü.
• Yazılımın ömrü uzun, alan iyi biliniyor; kavramsal model çıkarmak kolay.
• Endüstride kullanıcıların çoğu verimlilik artışı ve bakım maliyetinde düşüş bildirdi; en büyük kazanç yeniden kullanımda görüldü (Hutchinson ve ark., 2012).

Yine de yaklaşımın başarılı olduğu alanlar var. Başarı örnekleri çoğunlukla donanım ve yazılımın birlikte geliştirildiği ürünlerden geliyor: otomotiv ya da hava trafik kontrolü gibi. Bu alanlarda yazılımın ömrü uzun ve alan iyi biliniyor. Endüstride yapılan bir çalışmada kullanıcıların çoğu verimliliğin arttığını ve bakım maliyetinin düştüğünü bildirdi. En büyük kazanç yeniden kullanımda görüldü.

Çalıştırılabilir UML (xUML)

Modelden tam bir program üretebilmek için UML’in bir alt kümesi tanımlandı: çalıştırılabilir UML. Bu yaklaşımda üç tür model kullanılır: sistemin temel kavramlarını gösteren alan modelleri, özellik ve işlemleriyle sınıf modelleri ve her sınıfın yaşam döngüsünü anlatan durum modelleri. İşlemlerin ne yaptığı da bir eylem diliyle modele eklenir; araçlar bu modellerden çalışan kod üretir.

Çevik çalışmayla ilişkisi

Gerilim

Model güdümlü geliştirme baştan ayrıntılı ve dönüştürülebilir modeller ister; çevik yaklaşım fazla ön tasarımdan kaçınır.

Uzlaşma

Bazı çevik yazarlara göre MDA’nın bazı yönleri çevik süreçlerde kullanılabilir. Motorola, çevik geliştirmeyi otomatik kod üretimiyle birlikte kullandığını bildirdi.

Model güdümlü geliştirme baştan ayrıntılı ve dönüştürülebilir modeller gerektirir. Bu, çevik yaklaşımın fazla ön tasarımdan kaçınma fikriyle çelişiyor gibi görünür. Ama ikisi tamamen karşıt değildir. Bazı çevik yazarlar MDA’nın belirli yönlerinin çevik süreçlerde kullanılabileceğini savunur. Yayımlanmış bir endüstri deneyiminde de Motorola, çevik geliştirmeyi otomatik kod üretimiyle birlikte başarıyla kullandığını bildirdi.

Bugün aynı fikir nerede?

Güncel not · kitabın yayımından sonraki gelişmeler

Düşük kodlu platformlar

Formlar, iş akışları ve veri modelleri görsel olarak tanımlanır; uygulama bunlardan üretilir.

API tanımından kod

OpenAPI gibi sözleşmelerden istemci ve sunucu iskeleti otomatik üretilir.

Veri modelinden kod

Şema ve ORM araçları, veri modelinden tabloları ve erişim kodunu üretir.

Kitabın yazıldığı dönemden bu yana, modelden kod üretme fikri farklı biçimlerde yaygınlaştı. Düşük kodlu platformlarda formlar, iş akışları ve veri modelleri görsel olarak tanımlanır; uygulama bunlardan üretilir. OpenAPI gibi API sözleşmelerinden istemci ve sunucu iskeleti otomatik üretilir. Veri modelinden veritabanı şeması ve erişim kodu üreten araçlar da aynı fikrin parçasıdır. Yani tam otomatik dönüşüm ana akım olmasa da, kodun bir kısmını modelden üretmek bugün sıradan bir uygulama.

Özet: Model Güdümlü Mühendislik

• Model güdümlü mühendislikte model, programın kaynağıdır; kod araçlarla üretilir.
• MDA üç düzey önerir: CIM, PIM ve PSM.
• Tam otomatik dönüşüm yaygınlaşmadı; fikir bugün yeni araçlarda yaşıyor.

Yüksek düzeyli bir modelden, elle müdahale etmeden çalışan program üretmenin önündeki engeller nelerdir?

Özetle: Model güdümlü mühendislikte model programın kaynağıdır ve kod araçlarla üretilir. Tam otomatik dönüşüm ana akım olmadı; ama fikir bugün yeni araçlarda yaşamaya devam ediyor. Tartışmak için bir soru: Yüksek düzeyli bir modelden, elle hiç müdahale etmeden çalışan bir program üretmenin önündeki engeller nelerdir?

Bölüm Özeti

Bölümü toparlarken her model türünü cevapladığı soruyla birlikte hatırlatın. Ayrıntıya girmeyin; amaç, öğrencinin elinde bir model seçme haritası kalması.

Hangi soru, hangi model?

Bakış açısı	Cevapladığı soru	Başlıca UML diyagramı
Bağlam	Sistemin sınırı nerede, çevresinde hangi sistemler var?	Bağlam diyagramı, etkinlik (süreç) diyagramı
Etkileşim	Kim, kiminle, hangi sırayla konuşuyor?	Kullanım durumu, sıra diyagramı
Yapısal	Sistem hangi sınıflardan ve ilişkilerden oluşuyor?	Sınıf diyagramı (genelleştirme, bütünleme)
Davranışsal	Sistem verilere ve olaylara nasıl tepki veriyor?	Etkinlik diyagramı, durum diyagramı
Model güdümlü	Model, kodun kaynağı olabilir mi?	Sınıf ve durum modelleri (xUML), CIM → PIM → PSM

Tabloyu soldan sağa okuyun: Önce soruyu sorun, sonra öğrencilerden modeli bulmalarını isteyin. Aynı sistemin bütün bu modellerle anlatıldığını, AS-HYS örneğinin her bölümde tekrar ettiğini hatırlatın.

Akılda kalacaklar

• Model, sistemin bilinçli olarak sadeleştirilmiş bir görünümüdür; ne kadar kesin olacağı kullanım amacına bağlıdır.
• Sınır kararı erken verilir ve maliyeti, bağımlılıkları, sorumlulukları belirler.
• Diyagramlar tek başına yetmez: metin açıklamaları ve tablolar ayrıntıyı ve istisnaları yakalar.
• Modeller birbirini tamamlar; bir modeldeki karar (ör. çokluk, durum geçişi) diğerlerine ve gereksinimlere yansır.
• Model güdümlü mühendislik tam otomatik dönüşümde yaygınlaşmadı; ama modelden kod üretme fikri bugün yeni araçlarda yaşıyor.

Beş maddeyi tek tek okumak yerine öğrencilere sorun: “Bu bölümden tek bir cümle hatırlayacak olsanız hangisi olurdu?” Birkaç cevabı bu maddelere bağlayarak kapatın.