GELİŞİM PLATFORMU

Ertan DenizErtan.deniz70@gmail.com

Ertan.deniz@wordpress.com

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