yazılım gereksinim mühendisliği semineri
DESCRIPTION
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.TRANSCRIPT
GELİŞİM PLATFORMU
Ertan [email protected]
Ajanda
Yazılım Mühendisliği
Yazılım Gereksinim Mühendisliği
Ana referans
Object-Oriented Software Engineering Using UML, Patterns, and Java (3rd Edition) Bernd Bruegge & Allen H. Dutoit,Prentice Hall
Ö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 ?
20
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.
Yazılım Mühendisliği
20
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)
Yazılım Mühendisliği
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ı)
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)
Yazılım Mühendisliği ve Diğer Mühendislik alanları
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.
20
Yazılım Mühendisliği Kavramları - Devamı 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
20
Yazılım Mühendisliği Kavramları - Devamı
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
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 ?
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)
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
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ı.
Ajanda
Yazılım Mühendisliği
Yazılım Gereksinim Mühendisliği
Yazılım geliştirme aktiviteleri (Hayat döngüsü)
Alt Sistemler
Yapısallaştırılır.
sınıf...sınıf...
Kod
Geliştirilir.
Çözüm nesneleri
Gerçekleştirilir
UygulamaAlan
nesneleri
İfade edilir.
Test Model
?
Doğrulanır.
sınıf....? Use Case
Model
SistemTasarımı
Nesne Tasarımı
Uygulama TestGereksinim
belirlemeAnaliz
Gereksinim Mühendisliği
Gereksinim belirleme ve Analiz
Analiz
Problem İfadesi
Fonksiyonel Model
Fonksiyonel olmayan
Gereksinimler
Analiz Nesne Modeli
GereksinimBelirleme
Dinamik Model
Analiz Model
GereksinimBelirleme
Daha detaylı inceleme (İstisnai
durumlar, Sınır koşulları)
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
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?
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ı)
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
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
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ı
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.
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ı
Ö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.
Ö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.
Diğer senaryolar
Randevusuz gelen hasta
Sadece kontrol için gelen hasta
Acil hasta (Ambulans)
Ameliyat gerektiren hasta
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ı.“
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.
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
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
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)
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.
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.
[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ç
Öğrenci
KayıtOl
ÖğretimGörev lisi
DersOnay
Sınav Yap
Sınav Organizatörü
Sınav Planla
Sınav Duyur
Sınav Gözetmeni
KayıtGörev lisi
Örnek [Use Case] Modeli uc Use Case Model
Kuyruk Sistemi
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ı
TetkikRaporuKontrolEt
Tetkikİste
TetkikRaporuYayınlaTektikYap
ÖrnekAl
SonrakiHastayıVerDoktorİçinSonrakiniVer
LaboratuvarİçinSonrakiniVer
DoktorÇalışmıyor
MalzemeAl
«include» «include»
«include»
«include»
«extend»
«extend»
«include»
«include»
«include»
«include»
Kullanım senaryosu (Use Case) formatı
Adı
Katılımcı
Aktörler
Giriş Koşulu
Çıkış Koşulu
Olay Akışı
İstisnalar
Özel
Gereksinimler
Kullanım senaryosu (Use Case) formatı
Adı MuayeneTalepEt
Katılımcı
Aktörler
Görevli,Hasta
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.
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.
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.
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
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..*
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
+ AcilisTarihi: string
+ AktifDurumu: boolean
+ Numarası: int
+ MasrafHesapla() : void
KurumsalHesap
+ MasrafHesapla() : void
BireyselHesap
+ MasrafHesapla() : void
Ö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..*
Örnek Nesne Modeli class Class Model
Görünüm Sınıfları (Web Formları)
Görünüm sınıfları (Formlar) Yönetici Sınıfları(Controller)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() : voidDoktorHastaListesiForm
+ HastaGetirKomutu() : void
DoktorYöneticisi
+ SonrakiHastayıGetir() : void
+ MuayeneKaydet() : void
+ LabaratuvaraGönder() : void
+ MuayeneKaydıKapat() : void
+ ReçeteYaz() : void
MuayeneForm
+ MuayeneKaydetKomutu() : void
+ TetkikTalebiAçKomutu() : void
TetkikTalepForm
+ LaboratuvaraGönderKomutu() : void
+ TetkikRaporuAç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
+ 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
+ İşlemTarihi: date
+ Açıklama: string
Emailİşlemleri
+ Gönder() : void
TetkikRaporForm
+ RaporAçKomutu() : void
KuyrukGörünümForm
+ SonrakiniGetirKomutu() : void
1 1
11
11
1
1
1
1
1 1
1
1
1
1
11
1
1
11 1 1
1 1
1
1
1
1
11
11
1
1
11
11
Örnek Sıralı Diyagram
sd Doğrula
HesapGoruntulemeEkranı
SubeYetkil isi
HesapIslemleri Hesap
HesapGoruntuleKomutu()
HesapGetir()
:Hesap
Doğrula()
HesapDetaylarınıAl()
:Hesap
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üzlerindekinavigasyon için kullanılabilir. Durumlar, ekran isimleridir.
stm DynamicState
Basla
İlkBasv uru
Degerlendirme
Kabul Red
Son
Tum Evraklar Tamam
Olumlu Olumsuz
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 SonucuTalep iptal
edilir.
Talep
onaylanır.
İşlem
tamamlandı.
Olumsuz
Olumlu
Örnek Aktivite Diagramı
act Dynamic
MuayeneBaşlat
TalepİptalEdildi
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 ilk
sırada mı?
Hasta, kuyruğu kontrol
eder
Hasta, doktorun odasına
girer.
Doktor, hastaya, teşhis
amaçlı bazı sorular sorar
Doktor, hastayı muayene
eder
Tetkik
gerekli mi
? (Veya
yeni tetkik
gerekli mi
?
Doktor, hastayı muayene
eder
Doktor gerekli görürse,
farklı laboratuv arlardan
tetkik ister
Doktor muayene kaydını
kapatır
MuayeneTamamlandı.
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
LaboratuvardaTetkikBaşlat
TetkikLaboratuvaraGönderildi
RaporYayınlandı
RaporKontrolüBaşlat
Yes
Hayır
Evet
Hayır
Evet
[Use Case] lerüzerinde genel bir akış.
Ö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.
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