Analist Eğitimi - Tüm Bölümler - [535 Slides]

Analize Giriş

Bölüm 1/4

İçerik

Eğitmen Hakkında

Erol Bozkurt – [email protected]şim Teknolojileri DanışmanıUniversity of Houston, Computer Science.

Uzmanlıklar:Real Time Simülasyon Sistemleri Tasarımı ve

Programcılığı,Sistem Analizi, UML ve Yazılım Süreçleri Danışmanlığı.

Eğitim Planı

• 9:30 – 12:30 (3 Ders)

Öğle arası (12:30 – 13:30)

• 13:30-16:30 (3 Ders)

İhtiyacınıza göre düzenlemeler yapılabilir.

Tipik Katılımcı Profili

• Nesne Tabanlı Yazılım Deneyimi Olanlar• Nesne Tabanlı Yaklaşımı Öğrenmek İsteyenler• Analistler, Tasarımcılar, Programcılar, …• Süreç Mühendisleri• Kalite Sorumluları• Proje Yöneticileri• Konu Uzmanları (Domain Expert)• Müşteriler

Katılımcılar Hakkında

• Şirketiniz ve faaliyet alanı• Sizin rolünüz• Eğitim almanızdaki nedenler• Eğitime yönelik beklentileriniz

Eğitim Materyalleri

• Eğitim Kitabı.• Çalışmalarımızda kullanacağımız ürünlerin

demolarını ve egzersiz dokümanları içeren CD-ROM.

Bizi Seçtiğiniz İçin Teşekkür Ederiz!

Analize Giriş

Bölüm 2 / 4

İçerik

Analizden Ne Anlıyoruz?

Bir konuyu derinlemesine inceleyerek onun iç mekanizmasını, temel parçaları ve ilişkilerini, işleyiş mantığını ve baz aldığı varsayımlarısaptama faaliyetlerinin tümüdür.

Sherlock Holmes

Analizden Ne Anlıyoruz?

Analiz esnasında dikkat edilebilecek öğeler Çözümü kullanacak kişilerin özellikleri Çözümü geliştiren kişilerin özellikleri Çözümü kullanacak kişilerin iş süreçleri Çözümü geliştirecek kişilerin yazılım geliştirme

süreçleri

Formül: Roller – İş Ürünleri – İş Adımları

Analizden Ne Anlıyoruz

Farklı bir şekilde söylersek analiz çalışması insan ilişkilerinin yeniden tanımlanması ve düzenlenmesi işidir.

Dolayısıyla müşteriler ve tasarımcılar / programcılar arasında yer alarak tartışmaların tam merkezine düşer!

Analist Kimdir?

• Duyduğunu gerçek ve eksiksiz bilgi olarak algılayan,

• Algıladıklarını onaylattığında onlara bir kesinlik kazandırdığını zanneden birisi değildir.

• Aksine, duyduklarını sorgulayan ve söylenmeyenleri su yüzüne çıkaran,

• Kronik sorunları dokümante etmenin ötesinde problemin çözülmesine yardımcı olan birisidir.

Analist Kimdir?

• Terapisttir• Toplantı yöneticisidir• Değişiklik mühendisidir

Analist Kimdir?

• Dokümanla ifade edilen bilgileri kolay ayrıştıran ve alakalandıran

• Pek çok konuya yönelik yazılım geliştirmiş• Hataları ve nedenlerini tanımlayan• Gereksinimleri derleyerek geliştirilecek ürünleri

tanımlayan• Derlediği bilgileri etkili bir kullanımı sağlayacak

şekilde dokümante eden• Kalite ve performansa yönelik olarak ürünleri,

hizmetleri ve süreçleri değerlendiren ...

Analist Kimdir?

• İnsanların gerçek ihtiyaçlarını saptamak için gerekli sabra ve yeteneğe sahip

• Alternatif yaklaşımları güçlü ve zayıf yanlarına göre karşılaştırabilen

• Yüz yüze iletişim tekniklerinde bilgili ve becerili• Karmaşık sorunları kavramsal olarak

inceleyebilen ve seçenekleri belirleyerek, çözümler üretebilen birisidir.

Analist Kimdir?

• Bilgisayar donanımı, elektronik cihazlar ve yazılımlar

• Türkçe ve kullanılan diğer dillerde dilbilgisi, imla ve kompozisyon yazma

• Müfredat belirleme, eğitim içerik geliştirme, eğitmenlik ve eğitim değerlendirmeleri hakkında deneyim sahibi birisidir.

Analist Kimdir?

• Temel matematik, cebir, geometri, calculus,istatistik ve uygulanma şekilleri

• Hizmet sağlama ilkeleri ve süreçleri (İhtiyaç belirleme, hizmet kalite standartları, müşteri memnuniyeti ölçmeyi de içerir) hakkında deneyim sahibi birisidir.

Analist Türleri

Analist Türleri / Farklı Tanımlar

• İş Analisti• Sistem Analisti• Analist / Programcı• Veri / Veritabanı ‘Analisti’

Alakalı Meslekler

• Değişiklik Mühendisi• Süreç Mühendisi• İş Geliştirme Yöneticisi• Proje Yöneticisi

İlgili Standartlar

• RUP, XP, MIL-STD, IEEE vs.• CMMI• CobiT, ITIL

Olası Bir Kariyer Planı

İş Analisti

İş Analisti

Sistem Analisti

Sistem Analisti

Analize Giriş

Bölüm 3 / 4

İçerik

İçerik

• Yaygın Yazılım Süreçleri• İteratif Yazılım Geliştirme• Unified Process (UP) Yapısı• SPEM Gösterimi ile Yazılım Süreci Tanımlama• Pratik bir UP Yaklaşımı• Yazılım Rolleri ve Kaynak Yönetimi• Proje Hazırlık Çalışmaları

Değişen

gereksinimler

Yeni

sistem

Süreç

Süreç Nedir?

• Kimin Neyi Ne Zaman Nasıl yapacağını tanımlamaktır.

1. Gereksinim Yönetimi (Ne?)

Ürünün yerine getirmesi gerekenler

2. Analiz (Nasıl?)

Sistemin parçalarının ve birbirleriyle alakalarının kavramsal seviyede belirlenmesi

3. Tasarım (Nasıl?)

Sistemin parçalarının ve birbirleriyle alakalarının bir teknolojiye has olarak (J2EE, C++) belirlenmesi

4. İmplementasyon (Kodlamak)

Sistemin kaynak kodunun geliştirilmesi

5. Test (Verifikasyon: Fonksiyonel Test)

Test verileriyle uygulamayı çalıştırmak

6. Bakım (Hata Düzeltme ve Geliştirme)

Ürünün hatalarını giderme ve yeni özellikler ekleme

Yazılım Süreci Aşamaları

1. Gereksinim Yönetimi:

Uygulama kullanıcının bakiyesini göstermelidir.

2. Analiz ve Tasarım:

Tasarım VadesizHesap ve VadeliHesap class’larına sahip olmalıdır.

3. İmplementasyon:

class VadesizHesap{

double bakiye;

getBakiye{}; setBakiye{}} …

4. Test:

yatırılan $44.92 / yatırılan $32.00 /

çekilen $101.45 / …

bakiye $2938.22, testi geçti.

5. Bakım:

Hata düzeltme: Bakiye sıfır olunca ve para çekme işlemi yapılmak istenince sistem göçüyor.

Ek Özellik Geliştirme: Euro para birimini destekleme.

Süreç Örneği: Bireysel Finans

Waterfall Yazılım Süreci

zaman

GereksinimAnalizi

Tasarım

Milestone(s)

Fazlar

İmplementasyon

Test

Bakım

Ürünün sürümleri

Bu fazlar kısa bir süre için örtüşebilir

Waterfall Neden Pratik Değildir?

1. Sahip olunması istenen bilgilerin hepsi hazır değildirBütün detayları işin başında görmek zordur

2. Gereksinimlerin implementasyon maliyetlerini sadece tahmin edebiliriz Tahminin isabetliliğini anlamak için en riskli olanlarının tasarlanıp,

implemente edilmeleri gerekirBuradan alınan sonuçlara göre gereksinimler değişebilir

3. Sık sık ara sürümler çıkarmak zorunda kalırızPaydaşların (müşteriler, yöneticiler) projeye güvenlerini tazelemek gerekirTasarımcılar ve programcılar geliştirdikleri sistemin istenen sistem

olduğunun konfirmasyonunu beklerler (Bunun yegane yolu: kademe kademe parçaları birleştirerek (iterative ve incremental) yazılım geliştirme ve testtir)

4. Tipik olarak yazılım ekibinin elemanları farklı fazlarda da görev alırlar

Spiral Süreç

Spiral Süreç

zaman

1 Gereksinim

Tasarım

Kodlama

Test

1İterasyon #

1

1

2

2

2

3

3

3

X sürüm 1.0

M I L E S T O N E S

2 3

2 3 1

α(prototype) X

β

Örtüşen Süreç Aşamaları: UP

RUP’un Gelişimi

İşlevsellik TestiPerformans TestiGereksinim Denet.Değişiklik Denet.İş AkışıVeri TabanıUI

Rational Unified Process 5.01998

Rational Objectory Process 4.11996-1997

Objectory Process 1.0-3.81987-1995

Ericsson Yaklaşımı

Rational Yaklaşımı UML

Süreç Seçim Yaklaşımı Olarak MPP

• Method over Tool:“Herhangi bir yazılım mühendisliği ürününden ziyade

yönteme odaklanmak”• Project over Method:“Herhangi bir yazılım sürecinden ziyade projeye/ürüne

odaklanmak”• People over All:“Herşeyden çok ürünün kullanıcıları ve onu geliştirenler

dahil olmak üzere paydaşlara odaklanmak”

İçerik


Proje Gelişim Süreci

zaman

Inception Elaboration Construction Transition

• Inception: Projenin sınırlarının belirlenmesi, Verilecek hizmetin berraklaştırılması• Elaboration: Proje planının oluşturulması, ürün özelliklerinin

saptanması, Baseline• Construction: Ürünün oluşturulması• Transition: Kullanıma sunulma

saptama tasarlama oluşturma sunma

GereksinimKontrolü

SistemMimarisi

Kullanılabilirlik ResmiSürüm

Aşamalar ve İterasyonlar

Bir iterasyon planlı olarak gerçekleştirilmiş faaliyetler bütünüdür. Sonucunda başarısı ölçülebilen çalıştırılabilir bir bilgisayar programı oluşur.

ArchIteration

... Dev Iteration

Dev Iteration

... TransIteration

...

Release Release Release Release Release Release Release Release

PrelimIteration

...


İterasyonlar ve İşler

P re lim in a ry

Ite ra tio n (s )ite r.

# 1

ite r.

# 2

ite r.

# n

ite r.

#n + 1

ite r.

# n +2

ite r.

# m

ite r.

# m +1


Gereksinim

Tasarım

Uygulanma

Test

Analiz

Aşamalar

İşler

İterasyon

İterasyonlar ve Risk

Risk

Transition

Inception

Elaboration

Construction

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Post-deployment

Waterfall

Zaman

Proje risklerinin ortaya konması

• Mimarinin revizyonu• Risk-bazlı iterasyonlar• Entegrasyon

• Kullanıma sunma

• Müşteri memnuniyetini ölçme

• Senaryolarla sistemin yapısının ve davranışının oluşturulması

• Sistem Mimarisinin oluşması• Temel mekanizmaların tasarlanması

Risk Azaltma Odaklı İterasyonlar

İlk Proje Riskleriİlk Proje Odağı

Yenilenen Proje Planı• Maliyet• Zamanlama• Odak/İçerik

İterasyon N’in Planı• Maliyet• Zamanlama

Iteration N’in değerlendirilmesi

Giderilen RisklerDiğer Riskler• Yeni öncelikler

Iteration N’in oluşması• Maliyet ve Kalite

ölçümleri

En önemli risklere yönelik senaryoların oluşturulması

Iterasyon N

Use Case Odaklı İterasyonlar


İterasyon1İterasyon2 İterasyon3

İterasyon PlanıGereksinimler

Analiz + TasarımUygulama

Test Release

“Mini-Waterfall” Süreci

İterasyon Süreci

• Önceki iterasyonların sonuçları

• Güncel Risk Raporu• Model, kod ve test kayıtları

Release raporuYeni Risk RaporuKonfigürasyon Denet.

İterasyon Planı

Gereksinimlerin Sapt.

Analiz + Tasarım

Uygulama

Test

Release

Adapte Olabilen bir Süreç: UP

Murray CantorMurray Cantor

Rational Stratejik Hizmetler Biriminde baş danışman.

Uzmanlık alanları:

• Yazılım Mühendisliği Süreçleri• Sistem Mühendisliği Süreçleri• Yazılım Proje Yönetimi• Liderlik

Software Leadership: A Guide to Successful Software Development

Rational Stratejik Hizmetler Biriminde baş danışman.

Uzmanlık alanları:

• Yazılım Mühendisliği Süreçleri• Sistem Mühendisliği Süreçleri• Yazılım Proje Yönetimi• Liderlik

Software Leadership: A Guide to Successful Software Development

Slaytlar 20 - 28

Eski Müşteri/Yazılım Ekibi İlişkisi

• Gereksinimleri ‘bitir’ kaynak değerlendirmesi yap proje planı yaz taahhüt ver planı uygula proje başarısızlığını gör suçluyu ara sonunda kabul edilebilecek bir çözüm sun (belki)

• Varsayımlar – Gereksinimlerin, proje içeriğinin, kullanılacak teknolojinin

eksiksiz ve gereken detay seviyesinde anlaşıldığını ... – Çok isabetli tahminlerde bulunmanın mümkün olduğunu ...– Detaylı bir planın yapılabileceği ve uygulanabileceği ...

‘Waterfall’ Yaklaşımının SonuçlarıDetaylı toplantılar yapılıyor /Toplantı

notları yazılıyor

Tasarım uygun gözüküyor.

Detaylı bir spesifikasyon hazırlanıyor.

Gereksinim kapsama yüzdesi (% 100) yüksek.

• Tasarım “suçu ispatlanana kadar

masum.”

Þ Toplantılar ve dokümanlar karmaşık bir yazılım sisteminin gerçek risklerinin çok azına değiniyor.

Þ Elle tutulur bir delil yok.

Þ Yanıltıcı bir güvenlik hissi var.

Þ Pek azı n*(% 10) tasarımı yönlendiriyor.

Þ Gereksinimlerin hepsine nüfuz etme çabası kritik noktaları gözden kaçırıyor.

Þ Her zaman suçlu. Tasarım hatası ileride istemediğimiz bir zamanda ortaya çıkacak.

Sözde Sonuçlar Gerçek Sonuçlar

Pareto KanunuFa

yd

aFa

yd

a

EmekEmek20%20%

80%80%

%20’lik emek faydanın %80’ini sağlar.%20’lik emek faydanın %80’ini sağlar.

Hata Payını En Aza İndirmek Çok Emek İster

• Gereksinimler karmaşıktır– Fonksiyon/Davranış– Sistem tarafı ayrıca karmaşıktır.

• Tam anlamıyla anlamak analiz, deneyler ve neticelerin değerlendirilmesiyle mümkündür.

• Gereksinimlerle Sistem Mimarisinin ilişkilerinin belirlenmesi gerekir.

• Tüm bu emek bahsettiğimiz 80/20 kuralına tabiidir. – Eksiksiz bir bilgiye erişim en iyimser yaklaşımla ekonomik

değildir. Gerçekçi olursak mümkün değildir. – Bilgi proje süresince eksiksizleşir.

ParadoksYapılacak işi yönetebilmek içim yazılım taahhütlerinin olması gerekli

Taahhütlerin çok detaylı bir şekilde tarif edilmeleri mümkün değil

Çözüm:– Açık bir şekilde ortaklaşa çalışma, müşteriye sonuç göstererek

yönetim ve programcı arasında ahenk oluşturarak çalışmak– İteratif yazılım geliştirme– Elde edilen bilgilerin kademeli olarak zaman içerisinde

eksiksizleşmesi ve detay seviyelerinin artması.

Yazılım Problemi: İki nokta arasındaki en kısa yol

Buradan Buraya

Nasıl gideceğiz?

Buradan Buraya

Nasıl gideceğiz?

Düşündüğümüz GüzergahDüşündüğümüz Güzergah

Projenin ilk Durumu Mevcut ‘malzemeler’, teknolojiler Elemanlar, kabiliyetleri, bilgileri Kaynak eksiklikleri Belirsizlikler

Projenin ilk Durumu Mevcut ‘malzemeler’, teknolojiler Elemanlar, kabiliyetleri, bilgileri Kaynak eksiklikleri Belirsizlikler

Müşteriyi Tatmin Edebilecek Alan Katmadeğer: Kullanıcıya (kullanılabilirlik,

performans, kalite) Maliyet (zaman ve para) Katmadeğer: Yazılım Geliştirici (kar, deneyim,

satış, Pazar payı vs.)

Müşteriyi Tatmin Edebilecek Alan Katmadeğer: Kullanıcıya (kullanılabilirlik,

performans, kalite) Maliyet (zaman ve para) Katmadeğer: Yazılım Geliştirici (kar, deneyim,

satış, Pazar payı vs.)

Gerçek Güzergah

İterasyonlar ve Projenin İlerlemesinin Gözlenebilmesi

Müşteriyi Tatmin Edebilecek Alandaki BelirsizlikMüşteriyi Tatmin Edebilecek Alandaki Belirsizlik

Planlanan İçerik

Planlanan Güzergah

Projenin ilk Durumu

Planlanan GüzergahPlanlanan Güzergah

Gerçek GüzergahGerçek Güzergah

‘Waterfall’ Yönetimi: “Planla ve Takip Et”

Planlanan Proje BitişiPlanlanan Proje Bitişi

Gerçek Proje BitişiGerçek Proje Bitişi

Müşteriyi Tatmin Edebilecek AlanMüşteriyi Tatmin Edebilecek AlanProjenin ilk DurumuProjenin ilk Durumu

Planla ve Takip Et: Projenin tüm aşamalarındaki tüm faaliyetlerin zamanlamasını tahmin et ve bu tahminleri takip et. Gerçek ve Hayal: Bu durum iki farklı planın takip edilmesini gerektiriyor.

Planla ve Takip Et: Projenin tüm aşamalarındaki tüm faaliyetlerin zamanlamasını tahmin et ve bu tahminleri takip et. Gerçek ve Hayal: Bu durum iki farklı planın takip edilmesini gerektiriyor.

Müşteriyi Tatmin Edebilecek AlanMüşteriyi Tatmin Edebilecek AlanProjenin ilk DurumuProjenin ilk Durumu

Planlanan GüzergahPlanlanan Güzergah

İteratif Yaklaşımda Liderlik: “Manevra Yap ve Adapte Ol”

Planlanan Proje BitişiPlanlanan Proje Bitişi

Gerçek GüzergahGerçek Güzergah

Gerçek Proje BitişiGerçek Proje Bitişi

Devamlı olarak :Resmin geneline hakim ol – Proje yönelik istek değişikliklerini değerlendirManevra yap ve adapte ol – İterasyonlar bir dizi ufak sonuç sağladığından projenin tüm istekleri yerine getirmesini sağlamak için kullanılabilir: Hangi yönde manevra yapacağız?

Devamlı olarak :Resmin geneline hakim ol – Proje yönelik istek değişikliklerini değerlendirManevra yap ve adapte ol – İterasyonlar bir dizi ufak sonuç sağladığından projenin tüm istekleri yerine getirmesini sağlamak için kullanılabilir: Hangi yönde manevra yapacağız?

İçerik


UP’in 3 Temel Parçası

Use Case’leri tanımla

Use case paketi

Use case

sorumluluğu

Analist

Artifact(Oluşanlar)

Sürecin oluşturduğu, kullandığı veya değiştirdiği bir ürün

Role (Çalışan)

Bir rol Activity (Faaliyet)

Bir iş

Role

• Analistler: İş Analisti, Sistem Analisti, vs.• Yazılım Geliştirenler: Tasarımcı, Programcı,

Kullanıcı Arayüzü Tasarımcısı, vs.• Yöneticiler: Proje Yöneticisi, Süreç Uzmanı, vs.• Diğer: Konu Uzmanları, Denetçiler (Reviewer),

vs.

Activity

Artifact

Unified Process Yapısı

Discipline ve Workflow

Disiplin: Gereksinim Yönetimi

Workflow: Gereksinim Yönetimine ait çalışma şekli detayları

Workflow Details

Daha Fazla Detay “Rol Üzerinden”

Daha Fazla Detay“Yapılacak İş Üzerinden”

Daha Fazla Detay“Üretilenler Üzerinden”

Daha Fazla Detay“Bir Adım Daha İleriye: Şablonlar”

İş Akışları Modelleri Oluşturur

“Ürünler ve Kullanım Teknikleri”

Özetlersek

Sorulamayan Soruyu Bulmak“Sorulamayan soruyu bulmak gerçekle hayali birbirinden ayırmamızı sağlar.”

John M. Berry (A.B.D.’li Filozof)

• UP diğer süreç tanımları gibi ‘geleneksel bir model’ değildir.– Varsayımları (Neden’i) açık ve belli.– Çalışma şekillerinin girdisi, çıktısı, kimlerin ne işine yaradığı ve kimler

tarafından oluşturuldukları belli.• Yapılacakları dikte etmez: Ne’nin yanında Nasıl’da vardır.• Ne’lerin neler olacağına UP’un kullanıcısı karar verebilir.• Ne mevcut değilse onu ekleyebilir: UP plug-in’leri.• Ne’sini, Nasıl’ını ve Neden’ini (en küçük yapı taşına kadar) açıkça ortaya koyan

bir sistem soyut ve anlamsız (süreç için süreç) bir kavrama dönüşmez.• UP’u çok ciddi bir hedef olan CMM-I için de daha çok programcı odaklı Extreme

Programming için de kullanabiliriz.

İçerik


SPEM“Software Process Engineering Metamodel”

• UML gibi OMG tarafından onaylanmaktadır. Açık bir standarttır.

• Bitmiş bir standart değildir. Ufak değişmeler (gelişmeler) söz konusu olacaktır.

• Tamamıyla Unified Process üzerine oturur.• Biz, örneklerimizde, kabaca kullanacağız.

SPEM Gösterimi“Disiplinler”

XXX

SPEM Gösterimi“Roller”

SPEM Gösterimi“Yapılanlar”

SPEM Gösterimi“Üretilenler”

SPEM Gösterimi“Roller, Yapılanlar ve Üretilenler”

İçerik


Süreç Haritası

Süreç Haritası“Çevik Süreç Tanımları”

Süreç Haritası“CMMI”

Süreç Haritası“Unified Process”

UP Uyarlamaları

Gereksinim Yönetimi“Standart UP”

Analiz ve Tasarım “Standart UP”

İmplementasyon “Standart UP”

Bizim UP Sürecine Yaklaşımız

Proje Süresince Roller• Bir kişi birden fazla rolü canlandırabilir.• Aynı kişinin canlandırdığı rollerin çıkarları bir çelişki

oluşturmamalıdır.• Bütçe ve Eleman sayımızı gözeterek ve en verimli

süreç tanımını hedefleyerek,• Aşağıdaki gibi bir kadroyla yola çıkarsak,

– Ahmet Bey: Birincil görevi Sistem Analizi– Leyla Hanım: Birincil görevi Tasarım– Mehmet Bey: Birincil görevi Veritabanı Tasarımı – Hülya Hanım: Birincil görevi Proje Yönetimi

1. Gereksinimler

2. Analiz

ve Tasarım

3. İmplementasyon

4. Test

Proje Yönetimi

Süreç Mühendisliği

İçerik


İdeal Proje Ekibi

BizimProje

Ekibimiz

BizimProje

Ekibimiz

Ahmet = Sistem Analisti

Ahmet = UI Tasarımcısı

Ahmet = Testçi

Leyla = Sistem Mimarı

Leyla = Tasarımcı

Leyla = Programcı

Mehmet = Veritabanı Tasarımcısı

Hülya = Proje Yöneticisi

Hülya = Süreç Uzmanı

İçerik


Proje Hazırlık Çalışmaları“Tanımlamalar”

• Paydaş Türleri• Gereksinim Türleri• Gereksinim Değişkenleri• Kısıtlama Türleri• Risk Türleri• Metrik Türleri• Emek Türleri• Bakım Türleri• Test Türleri• UML Standardına Ekleriniz, vs. vs.

1a. Paydaşlar“Kullanıcılar”

1b. Paydaşlar“Proje Ekibi Adayları”

1c. Paydaşlar“Proje Ekibi”

2a. Gereksinim Türleri

2b. Gereksinim Türleri

2c. Gereksinim DeğişkenleriÖrnek: “Statü”

3. Kısıtlama Türleri

4. Risk Türleri

5. Metrik Türleri

6. Emek Türleri

7. Bakım“Problem Türleri”

8. Test

9. UML Kapsamına Ekler“Size Özel Stereotype”

İlham Kaynakları

James Bach

Watts Humphrey

Philippe Kruchten

Murray Cantor

James Rumbaugh Grady Booch

Terry Quatrani

Ivar Jacobson

Sizin Adınız

?

Analize Giriş

Bölüm 4 / 4

Neredeyiz?

İçerik

İçerik

• Proje Başarısızlığı Nedenleri• Gereksinim Yönetimi Kavramları• Gereksinim Yönetimi Teknikleri• Problem Analizi Teknikleri• Gereksinim Türleri• Gereksinim Dokümanları• Önceliklendirme ve Takip Edilebilirlik

Proje Başarısızlığı Nedenleri

• En yaygın nedenler:– Kullanıcı fikirlerinin alınmaması (% 13)– Eksik gereksinimler (% 12)– Değişen gereksinimler (% 12)

• Dolayısıyla projelerin üçte biri gereksinimlerle ilgili nedenlerden başarısız oluyor

Proje Başarısı Nedenleri

• En yaygın nedenler :– Kullanıcı fikirlerinin alınması (% 16)– Üst yönetim desteği (% 14)– Gereksinimlerin açık olması (% 12)

Gereksinim Hataları

• Müşteriye taşınan hataların yaklaşık olarak üçte biri gereksinim hatalarıdır

• Gereksinim hataları bulundukları anda giderilmezlerse ilerideki düzeltilme maliyetleri 10 ila 100 katına çıkabilir

• İyi proje takımları hataları tespit edildikleri anda tahlil ederler

Gereksinim Yönetimi

• Öyleyse gereksinimleri denetlemeye ihtiyacımız var: – Gereksinimleri bulmak, organize etmek ve

dokümante etmek için bir sistem gerekli – Gereksinim değişikliklerini yöneterek müşteri ve

proje ekibinin anlaşmalarını sağlayabilmek için bir süreç gerekli

• Bu kavramlara Gereksinim Yönetimi diyoruz

İçerik


Gereksinim Nedir?

• Gereksinimleri tanımlayabilmek için onları gereksinim gibi algılanabilecek diğer bilgi türlerin ayrıştırabilmemiz gerekir

• Bir ihtiyaç (need) bir sistemi kullanan müşterinin işini yapabilmesi için gereken, sistemin sahip olmak zorunda olduğu bir özelliktir

Gereksinim Nedir?

• İşlev (feature) sistemin yerine getirmeyi taahhüt ettiği bir hizmettir

• Gereksinim (requirement) sistemin karakteristik bir özelliğidir

• Gerçekleştirme (realization) gereksinimlerin uygulanma şeklidir

Bir işlevden bir veya daha fazla gereksinim türetilebilir

Detay Seviyeleri

İhtiyaç

İşlev

Gereksinim

Gerçekleştirme

Müşterinin probleminin tanımı

Çözümün tanımı

Daha detaylı

Çözümün gerçekleştirilmesi

Gereksinim Nedir?

• Fırsat (opportunity) yeni bir işlev, yeni bir müşteri tipi veya ürüne eklenen yeni bir özellik olabilir

• Problem müşterinin işini yaparken karşılaştığı bir zorluktur

• Kısıtlama (constraint) oluşturulacak sistemin uymak zorunda olduğu bazı sınırlardır

Acaba Bu Bir Gereksinim Mi?

• Yoksa eksik bilgiyle tasarımıma mı başladık?• Gerçekte ihtiyaç duyulmayan gereksinimlere

ve aslında mevcut olmayan kısıtlara dikkat ediniz

• Yoksa birisi problemden ziyade çözümü mü tanımlamaya başladı?

• Bir gereksinim olmak için çok mu genel?

Öncelik• Gereksinimin önceliği veya aciliyeti nedir?

– Yüksek, Orta, Düşük– Zaruri, İstenen, Seçeneğe Tabii – Mutlaka olmalı, Olması arzulanan, Olsa iyi olacak olan– Gündelik terminolojide ‘olacak’, ‘olsa iyi olur’, ‘olmayabilir’

• Gereksinimlerin önem nedenleri nedir?– Sistem Mimarisine etki,– Teknolojik yenilik nedeniyle bir risk,– Zorluk nedeniyle bir risk,– Vs. vs.

Paydaş (Stakeholder)

• Müşteriden fikri değerli yegane grupmuş gibi bahsedebiliyoruz ama projeye yönelik çelişen düşüncelere sahip pek çok grup insan olabilir (paydaş)

Paydaş Türü Örnekleri

• Sponsor• İş Analisti, Sistem analisti, Tasarımcı, Programcı,

Veritabanı Analisti, vs.• Konu Uzmanları• Kullanıcı• Yöneticiler• Admin.’ler• Süreç Uzmanları, Kalite Sorumluları, vs.• 3rd Party

Paydaşların Çelişen İstekleri

• Bu paydaşların hepsinin farklı ve birbirleriyle çelişen istekleri olabilir

• Başarılı bir projenin sağlaması gereken en önemli şeylerden biri bu isteklerin sahipleri arasında bir mutabakat sağlamaktır

• Mutabakat farklı çıkarlara sahip rollerin çıkarlarını olabildiğince korumalarıyla mümkündür

Yazılım Ekibi

• Yazılım geliştirme sürecine iştirak eden herkes gereksinim yönetimi çalışmalarından farklı şekillerde etkilenirler

• Problem çoğu yazılımcının teknik odaklarından dolayı insan ilişkilerinde çok başarılı olmayışlarıdır

• Öte yandan modern sistemlerin karmaşıklıkları insan ilişkisini zaruri kılmaktadır

İçerik


Altı Ekip Yeteneği

1. Problem analizi2. Müşteri ihtiyaçlarını anlama3. Sistemi tanımlama4. Sistem kapsamını yönetme5. Sistem tanımının revize edilmesi6. Doğru sistemin geliştirilmesi

1. Problemi analizi

Bu konuya ileride, daha sonra değineceğiz.

2. Müşteri ihtiyaçlarını anlama

• En üst seviyedeki gereksinimler olası çözümün tanımlanmasından çıkar

• Müşteriden bu gereksinimleri alabilmek için hangi teknikleri kullanacağımıza nasıl karar vereceğiz?

• Tıpkı bir marangoz gibi iş için gereken alet edavatı kolayca tespit edebilmek

3. Sistemi tanımlama

• Bir dizi gereksinimi nasıl organize edecek ve oluşturulacak sistemin açık bir resmini görebileceğiz?

• Alakalı ürünler arasındaki ortak gereksinimler nasıl ilişkilendirilecekler?

• Ürünün vizyonunun dejenere olmaması için onu detay gereksinimlerden nasıl ayrıştıracağız?

4. Sistem kapsamını yönetme

• Gereksinimler nadiren statiktir. Üç yaşındaki çocukların ilgi alanı gibi her an değişirler

• Ürünün kapsamının kontrolden çıkmasını nasıl sağlayacağız?

• Yapılması gerekenleri geciktirirsek kapsamı nasıl kontrol edebiliriz?

5. Sistemin tanımının revizyonu

• Yazılım ekibinin işini yapmaya kalkışmadan onlar için gerekli detay seviyesindeki gereksinimleri nasıl oluşturabiliriz?

• Detaylı gereksinimler vizyondan kopmamalı ve sadece her küçük problem parçasının çözülebilir olmasını sağlamalı

6. Doğru sistemin geliştirilmesi

• Tasarımın gereksinimleri yerine getirdiğini nasıl anlayacağız?

• Tasarımın müşteri isteklerine uygunluğundan nasıl emin olacağız?

• Gereksinim değişikliklerini nasıl kontrol altına alacağız?

İçerik


Problemler ve Fırsatlar

• Sistemlerin en önemli iki nedeni:1. Problem çözmek; mevcut sistem müşteri

ihtiyaçlarını karşılamıyor demek 2. Fırsatları değerlendirmek; yeni ürün düşünceleri,

yeni işlevler, yeni pazarlar vs. • Biz problem çözmeye odaklanacağız

Problem Analizi Aşamaları

• Problem beş aşamada tahlil edilebilir:1. Problem tanımı üzerinde anlaşmak2. Problemin temel nedenlerini anlamak3. Paydaş ve kullanıcıları tespit etmek 4. Sistemin sınırlarını tespit etmek5. Çözümü sınırlandıracak olan kısıtları bulmak

1Problem tanımı üzerinde anlaşmak

• Problem tanımı içeriği: – Problemi tarif ediniz – Etkilenen paydaşları belirtiniz – Problemin paydaşlar ve yaptıkları işler üzerindeki

etkilerini belirtiniz – Önerilen çözümü ve sağlayacağı faydaları ifade

ediniz • Kısaca, neden bu problemi çözmek için

vaktimizi harcamalıyız?

2Problemin nedenlerini anlamak

• Problemin mevcudiyetinden emin olunca bir çözüm oluşturmamız gerekiyor:

• Bir yol “temel neden” veya “nedensellik analizi”dir. Böylece problemin mevcudiyet nedenini anlayabiliriz

• Bunun için ‘kılçık şeması’ (fishbone) çizebiliriz– Düz bir çizgi çekerek problemi yazınız– Sonra problem nedenlerini yazınız– Daha sonra problem nedenlerinin nedenlerini yazınız– Tekrar ediniz

2Problemin nedenlerini anlamak

• ‘Akıl haritası’ (mindmap) çizebiliriz12 m.

Boeing Uçak A.H.

3Paydaşları ve kullanıcıları tespit

• Sistemi kullanacak ve mevcudiyetinden etkilenecek kişileri tespit edin

• Çoğu paydaş kullanıcıdır ama diğerleri değillerdir

4-5Sistemin sınırlarını tespit

• En basit tanımıyla her sistem bazı girdiler alır ve bazı çıktılar üretir

• Püf noktası bu girdi ve çıktıları kimin veya neyin üretip tükettiğidir

SystemInputs Outputs


• Neler sistemin kapsamındadır?– Paydaşların yerine kendimizi koyarsak,– Kullanıcıların yerine kendimizi koyarsak,– Yazılım ekibinin yerine kendimizi koyarsak,

• Dış sistemler hangileridir?– Bağımlı olduklarımız,– Bizim sistemimize bağımlı olanlar


• Sistem üzerine adı yazılı bir kutu ile gösterilir• Aktörler çöpten adamlardır• Dış sistemler ya adı üzerine yazılı bir kutu ya da daha yaygın olarak birer

aktör olarak gösterilirler• İlişki çizgilerinin yönü veri akış yönünü gösterir

StockTrackingSystemEnd User

StockExchanges

İçerik


Paydaş ve Kullanıcı İhtiyaçları“Stakeholder Requests”

• Gereksinimlerin bulunabilmeleri için yazılım ekibi dikkatli olmalıdır– Gereksinimleri açığa çıkarabilecek kavramları

değerlendiriniz – “Bunu bir gereksinim olarak eklemek ister misiniz”

diye sorunuz ve bahsedilen düşüncenin önemini saptayınız

• Çalışmalarınıza müşteri ihtiyaçlarını tespit ederek başlayınız

Paydaş ve Kullanıcı İhtiyaçları“Stakeholder Requests”

• En üst seviyedeki bilgi türümüz olan ihtiyaçlarla problem tahliline başlayabiliriz

• Genellikle ihtiyaçlar sistemin çözmesi beklenen temel bir problemle ifade edilirler (bu problemi nelerin ortadan kaldıracağıyla)

• Bazı kullanıcılar işlevlere değinebilirler – ihtiyaçların nasıl yerine getirilebilecekleri

İşlevler“Features”

• İşlevler müşteri ihtiyaçlarının hangi ürün kabiliyetlerine karşılık geleceğini ifade ederler – İşlev sistemin bir ihtiyacı gidermek için sunduğu bir

hizmettir• İşlevin faydası onun altında yatan ihtiyaçlara bakıldığında

kendisini gösterir • Bir ihtiyaç sisteme değinmez; bunu bir işlev yapar

Örneğin, Evden okula kayıt olabilmek istiyorum (ihtiyaç) -> Sistemin

internet erişimi olmalıdır (işlev)

Hangisi Hangisi?

• Kullanıcı görüşmesinde ihtiyaç ve işlev ayrımını hemen yapmak gerekmez

• Daha sonra edinilen bilgilerin düzenlenmesinde yardımcı olur (brainstorming)

• İşlev örneği arıyorsanız, yazılım ürünü reklamlarına bakınız!

İhtiyaç ve İşlev Sayıları

• İhtiyaçlar genellikle azdır – 10 veya daha az• İşlevler sistemin büyüklüğüne göre genellikle

25-100 arasında değişirler • Sistem kapsamı toplantıları için işlevler

kullanılırlar

İşlevler ve Gereksinimler

• İşlevlerin (feature) detayları ortaya dökülmeye başlandığında gereksinimler (requirement) ortaya çıkmaya başlarlar

• İşlev aşamasında geçici öncelikler verilebilir• İşlevleri ileride kolayca yönetebilmek için

açıklamalarını yazınız

İşlev/Gereksinim Değişkenleri (Attribute)

• İşlevleri yönetebilmek için kullanılan tipik değişkenler:– Statü, {önerildi, onaylandı, reddedildi}– Öncelik, {yüksek, orta, düşük}– Emek, {yüksek, orta, düşük}– Risk, {yüksek, orta, düşük}

İşlev/Gereksinim Değişkenleri (Attribute)

– Değişebilirlik (Stability), işlevin ve ileride implementasyonunun değişme olasılığı / derecesi

– Hedeflenen sürüm, Bu işlev hangi sürümde hazır olacak?

– Görevli, Bu işlevle ilgili atama kime yapıldı? Aşamasına göre farklı kişiler olabilir (gereksinim, analiz vs.)

– Neden veya Kaynak – Bu işlevin kaynağı nedir?

İşlevler ve Gereksinimler

Üst seviye gereksinimler: İşlevler“features”

Fonksiyonel gereksinimler“functional requirements”

Fonksiyonel olmayan gereksinimler“supplementary requirements”

Gereksinim Grupları

İçerik


Senaryo Odaklı Gereksinim YönetimiSenaryo Odaklı Gereksinim Yönetimi

Use-Case Modeli Ek GereksinimlerEk Gereksinimler

İşlevler

Gereksinimler

Vizyon DokümanıVizyon Dokümanı

İhtiyaçlar

GelenekselSRS

GelenekselSRS

=

Senaryo Odaklı Yol Geleneksel Yol

Geleneksel Software Requirements Specification (SRS) dokümanı Use Case Modeli ve Ek Gereksinimler Dokümanına (Supplementary Requirements) karşılık gelmektedir.

+

Gereksinim Ürünleri (Artifact)

Ek Gereksinimler(SupplementarySpecification)

Proje Sözlüğü(Glossary)

Use-Case Dokümanları

...

Use Case Modeli

AktörlerUse Case’ler

İlgili Roller

• Hazırlayan: İş Analisti, Sistem Analisti• Faydalanan: Tasarımcı, Kullanıcı Arayüzü

Tasarımcısı, Ürün Kullanım Kılavuzu Yazarı, Veritabanı Tasarımcısı

• Yardımcı: Müşteri, Müşteri Temsilcisi, Konu Uzmanı


Use Case Şemaları


[1]Vizyon

• Ürününüzün ilgili olduğu işi aklayan ve gerekli kabiliyetlerini ortaya koyan genel bir dokümandır

• Ne yapmak istiyorsunuz ve o iş neden yapılmaya değer?

• Vizyon dokümanı içeriği: – Giriş: ürününüzün karşılık olduğu temel ihtiyaçlara

değininiz

Vizyon

– Konumlandırma (Positioning): hitap ettiğiniz pazarın sizin açınızdan problemli yanlarını,

hedef kitlenizi ve rakiplerinizin ürünlerinin kabiliyetlerini (ne yapıp ne yapamadıkları) yazınız.

– Paydaş Tanımları: paydaşların demografik yapısını, ürününüzü kullanmak için

gereken kabiliyet seviyesini, paydaşlarınızın hedefleri ve yaşadıkları sorunları belirtiniz. Her paydaş türüne bir temsilci atayarak irtibat bilgilerini sağlayınız.

Vizyon

– Ürün işlevleri listesi: ürünün sağlaması gereken temel işlevleri ve

bunların paydaşlara ne fayda sağlayacağını birer ikişer cümle ile yazınız

Vizyon - Amaç

Vizyon – İş Fırsatı

Vizyon – Problem Tanımı

Vizyon - Paydaşlar

Paydaş Detayları

İşlevler


[2]Use Case Dokümantasyonu

• Monolog değil Dialog olmalı.• Aktörleri ile Use Case arasındaki etkileşimleri

içermeli.• Müşteri ile Tasarımcılar, Veritabanı

Tasarımcıları ve Arayüz Tasarımcıları arasındaki köprü olmalı.

Use Case: Olayların Akışı• Bir tane olağan, en tipik akış: Temel Akış (“Happy

Path”)

• Birden fazla Alternatif Akış:– Başarılı alternatif akışlar– Başarısız Akışlar hata durumlarını tolere etmeye

yarar

“Happy Path”

Senaryo Nedir?Bir senaryo use case’in içerdiği akışların bir kombinasyonunun başlayıp

bitişidir: Use Case Instance.

Senaryolar

• Use Case akışlarının bir kombinasyonudur (use case instance)

• Bir senaryonun beklenen (başarılı) bir neticesi olabilir– Müşteri kitaplarını satın aldı

• Veya başarısız bir neticesi olabilir– Müşterinin kredi kartı kabul edilmedi

Senaryolar

• Her use case’in odağı başarılı Temel Akışı’dır• Ancak pek çok başarılı ve başarısız Alternatif

Akış olabilir– Alternatif senaryolar akış esnasında neler

olabileceğini tespit yollarıdır. Örneğin, farklı şekillerde ödeme, bir transaction’ın bitirilememesi gibi

Use Case Dokümanı Formatı

• Tek-sütun formatında her paragraf aktör veya sistemin bir faaliyetini anlatır. Daha yaygın bir kullanımdır.

• İki-sütun formatında sol sütun aktöre sağ sütun sisteme aittir ve faaliyetleri ona göre yer alırlar. Faydası dialoğun zigzag yapısını daha iyi göstermesidir.

Use Case DokümanıGelişim Süreci

Bulunma Tanımlanma

Konu Başlıkları + Kısa Tanımlar

Temel Akış Detaylanır Tüm Akışlar Detaylanır

Use Case Dokümanı İçeriği

• Dokümanın mutlaka içermesi gerekenler ‘*’ işaretlenmiştir.– Temel Aktör*– Paydaşlar ve UC’le ilgileri– Precondition*– Postcondition*– Temel Akış*– Alternatif Akışlar*

1. Use Case Tanımı

– İlişkili Use Case’ler– Ek Gereksinimler– İş Kuralları– Kullanım Yoğunluğu– Açık Konular

2. Temel Aktör

• Bir use case için temel aktör o UC’i kendine bir fayda sağlamak için çalıştıran aktördür.

• Dolayısıyla bu aktör UC’i için bir tetik mekanizmasıdır.

• Temel Aktör genellikle insandır. Ancak bazen sistemler otomatik olarak dış sistemlere erişirler.

3. Paydaşlar ve UC ile İlgileri

• Bu bölümde use case’in akışında bir parçası olan tüm aktörler ve kendilerine sağladıkları faydalar belirtilmelidir

• Genellikle aktör başına bir iki cümle kafidir

4. Temel Akış• Herşeyin yolunda gittiği varsayılarak use case akışının adım

adım ve aktörle sistem arasındaki dialoğu işaret edecek şekilde yazılmasıdır.

• Bu akış iş kurallarını, üretilecek ve tüketilecek veri yapılarını ve yapılacak kontrolleri içerir.

• Bu akış use case’in beklenen kullanım şeklini ifade eder.• Bütün adımlar aktör’ün perspektifiyle yazılır. Yalnızca onun

gördükleri ve yaptıkları ile sistemin bu davranışlara reaksiyonlarını içerir.

5. Alternatif Akışlar

• Temel akışın izlediği yolu değiştirebilecek koşulları ve bu durumlarda kullanılacak yeni akışları ifade eder

• Bu başarısızlık durumlarını içerdiği gibi (kredi kartının reddedilmesi), farklı seçeneklerin izlediği yolları da içerir (çekle, kredi kartıyla veya paypal’le ödeme)


• Alternatif akışlar geçerli oldukları temel akış adımında yanlarına harf konarak işaretlenirler

• Temel Akış 3. Kasiyer ürün numarasını girer

• Alternatif Akış 3a. Geçersiz numara

• Daha sonra da alternatif akış adımları yazılır


• Dolayısıyla alternatif akışların iki parçası olur:• Nedeni: Başlığı • Akışı: Kendine özel akışı• Nedeni: 3a. Geçersiz ürün numarası

Akışı: 1. Sistem bir hata mesajı vererek ürünün

girilmesini engeller.

6. Precondition

• Use Case’in çalışabilmesi için sistemin sahip olması gereken durumu ifade ederler

• Bu liste temel aktörün o ana kadar yaptıklarını ve yapmadıklarını, şu andaki use case’e yönelmesine yol açan eylemleri içerebilir

7. Postcondition

• Use case’in akışının tamamlanmasının sonucunda sahip olunması gereken durumları ifade eder

• Bu da precondition gibi temel akış referanslı bir listedir. Herşey yolunda giderse use case akışı sonunda elimize ne geçecek?

8. Ek Gereksinimler

• Fonksiyonel olmayan gereksinimler veya use case’e özel kısıtlamalar olabilir– Performans, Güvenilirlik, Kullanılabilirlik ve

Tasarım Kısıtlamaları bu bölümde belirtilebilir• Use Case’e özel olmayan bu tür gereksinimler

Ek Gereksinimler (Supplementary Specification) dokümanında yer alır

9. İş Kuralları

• Use Case akışı esnasında uyulması gereken işe özel kuralları ve yapılması gereken kontrolleri gösterir.

• Genellikle use case’e özel değil, proje genelinde bir doküman olarak oluşturulur.

10. Kullanım Yoğunluğu

• Use Case’in kullanım yoğunluğunun belirtildiği bölümdür:– Günde 1000 defa mı?– Ayda 1 defa mı?

• Use Case öncelikleri hakkında fikir verdiğinden tasarıma yardımcı olur

11. Açık Konular

• Bu kısımda emin olmadığımız varsayımları, muhtemel teknoloji değişikliklerini ve bunlar gibi kesinleşmemiş konuların unutulmamalarını sağlayabiliriz.

• Kesinleşmemiş hukuki, iş akışı ve interface konularını da burada belirtebiliriz.

Bid on Item - Use Case Dokümanı

İnternette Açık Artırma

UC Dokümanı - Tanım

UC Dokümanı - Akış

UC Dokümanı – Geriye Kalan


[3]Ek Gereksinimler: FURPS+ Modeli

• Ek Gereksinimlerin kapsamı:• Fonksiyonel (Functional)• Kullanılabilirlik (Usability)• Güvenilirlik (Reliability)• Performans • Bakım (Supportability)• + = geriye kalan herşey

Fonksiyonel

• Tüm sisteme yönelik fonksiyonel gereksinimler. • UC odaklı olmayan yazılım geliştirme

yöntemlerini kullananlar için.• Fonksiyonel gereksinimlerin tamamı aslında

UML yaklaşımında UC Modeliyle kapsanıyor.

Kullanılabilirlik (Usability)

• Kullanılabilirlik:– İnsan faktörü; sisteminizi kullanmak nasıl

hoşnutluk verici olabilir? – Help; Kullanıcıya hangi help imkanı sağlanacaktır?

F1? Context sensitive? Online kullanım kılavuzu?– Dokümantasyon; Kullanıcıları eğitmek için ne tür

dokümantasyon üretilecektir?

Güvenilirlik (Reliability)

• Güvenilirlik ölçüm şekilleri: – Mean Time Between Failures (MTBF); İki sistem

göçmesi arasında geçen zaman – Mean Time To Repair (MTTR); Sistem göçtüğünde

çalışır hale getirilmesi için gereken zaman (Bu ‘bakım’ başlığı altında da olabilir)

– Sistemin kullanılabilir durumunu koruması (Availability) ‘performans’ başlığı altında yer alır

Performans

• Çoğu performans kriteri gereksinime dönüşür– Sorgu cevaplama süresi (ortalama, maksimum)– Throughput (Saat veya gün başına işlenen kayıt

sayısı, transactions per second (TPS))– Accuracy (scan veya veri giriş doğrululuğu)– Kaynak kullanımı (CPU, HDD kullanımı, network

trafiği)

Bakım (Supportability)

• İçeriği:– Bakım prosedürünü içerir. Sorunlar için kılavuz mu

sunacaksınız? – Sistemin bakımını yapmak ne kadar kolay? Yazılımı

ve Donanımı birlikte düşününüz. – Internationalization; sisteminiz farklı dillerde

kullanılabilecek mi?– Sisteminizin konfigürasyonu kolayca değiştirilebilir

mi?

“+”

• İçeriği:– İmplementasyon – Interface– Operasyonel– Paketleme– Kanuni konular– Ve aklınıza ne gelirse!

“+” - İmplementasyon

• İmplementasyon üzerindeki sınırlamaları ifade eder:– Kaynak sınırlamaları (maliyet, zamanlama,

eleman)– Dil ve ürünler (kullanılacak programlama ortamı)– Donanım (Dell)– Yazılım (MySQL)– Kullanıcı PC özellikleri (PIII 1000 MHz, 128 MB

RAM, Windows ME)

“+” - Interface

• Interface gereksinimleri dış sistemlerle haberleşme amaçlıdır: – Kurumuzdaki eski sistemler– Bileşenlerini satan şirketler– Başka proje ekipleri– Dış kurumlar (İMKB vs.)

“+” - Operasyonel

• Sisteminiz kullanım halindeyken yönetilebilmelidir

• Yöneticilere gereken kabiliyetler?– Kullanıcı ekleme– Kullanıcı erişim haklarını değiştirme– Kaynak kullanımını izleme (CPU, disk, network)– Fiziki ortamı izleme (ısı, nemlilik)

“+” - Paketleme

• Ürününüz nasıl paketlenecek?– Medya? CD-ROM? DVD?– Hangi dokümanlar basılacak? Hangileri elektronik

ortamdan sağlanacak?– Kullanıcılar için help desk kimlerden oluşacak?– Farklı ülkelere özel çalışmalar yapılacak mı?

“+” - Kanuni

• Ürününüz nasıl lisanslanacak?– Kullanıcı başına? Şirket başına?– PC başına?– CPU başına?

• Ürününüzün farklı versiyonları var mı? (akademik, profesyonel)

• Ürününüzün satılamayacağı yerler var mı? (ihracat kısıtlamaları)

FURPS + ve UML


[4]Sözlük (Glossary)

• Proje terimlerini içerir:– Terim 1, Terim 2, … Terim N

• Kısaltmaları ve use case dokümanlarında ifade edilseler çok yer kaplayarak okunmayı zorlaştıracak veri yapısı tanımlarını içerir

• Tanımlar dokümanda olabilir veya başka bir dokümanı refere edebilir

• Sözlük hyperlink’ler içerebilir

İçerik


Gereksinimleri Önceliklendirme

• Tüm gereksinimler (özellikle use case modelindeki fonksiyonel gereksinimler) için öncelikler belirlemeli ve ona göre zaman planı yapmalıyız.

• Önceliklendirme gereksinim değişkenleri kullanılarak yapılmalıdır:– {Tür: Zaruri, İstenen, Seçeneğe Tabii}– {Sistem Mimarisine Etki: Var, Yok}– {Emek: Zor, Orta, Kolay}– Vs. vs.

Gereksinimlerin Takip Edilebilirliği

Önceliklendirme ve Takip Edilebilirlik Kriterleri

Önceliklendirme ve Takip Edilebilirlik Kriterleri

veya

Gereksinim Yönetimi Planı 1“Vizyon Kapsamında”




Gereksinim Yönetimi PlanıRequirements Management Plan Configuration Management Plan

1. İterasyonların Belirlenmesiİnternet’te Açık Artırma Sistemi

2. İterasyonların Belirlenmesi

3. İterasyonların BelirlenmesiSistem Mimarisini Etkileyen UC’ler

İterasyon 1

İterasyon 2

İterasyon 2

İlham Kaynakları

Ellen Gottesdiener Alistair Cockburn

Sizin Adınız

?

James Bielak

Pratik Çalışma

Analistler için Modelleme

Bölüm 1 / 6

İçerik

Eğitmen Hakkında

Erol Bozkurt Bilişim Teknolojileri DanışmanıUniversity of Houston, Computer Science.

Uzmanlıklar:Real Time Simülasyon Sistemleri Tasarımı ve

Programcılığı,Sistem Analizi, UML ve Yazılım Süreçleri Danışmanlığı.

Eğitim Planı

• 9:00 – 12:30 (3 Ders)

Öğle arası (12:30 – 13:30)

• 13:30-18:00 (4 Ders)

60 dakikada bir ara: 10 dk.

İhtiyacınıza göre düzenlemeler yapılabilir.

Tipik Katılımcı Profili

• Nesne Tabanlı Yazılım Deneyimi Olanlar• Nesne Tabanlı Yaklaşımı Öğrenmek İsteyenler• Analistler, Tasarımcılar, Programcılar, …• Süreç Mühendisleri• Kalite Sorumluları• Proje Yöneticileri• Konu Uzmanları (Domain Expert)• Müşteriler

Katılımcılar Hakkında

• Şirketiniz ve faaliyet alanı• Sizin rolünüz• Eğitim almanızdaki nedenler• Eğitime yönelik beklentileriniz

Eğitim Materyalleri

• Eğitim Kitabı.• Çalışmalarımızda kullanacağımız ürünlerin

demolarını ve egzersiz dokümanları içeren CD-ROM.

Bizi Seçtiğiniz İçin Teşekkür Ederiz!


Bölüm 2 / 6

İçerik

İçerik

• Nesne Tabanlı Yaklaşımın Temelleri• Class’lar ve Nesneler

Nesne Tabanlı Yaklaşım:

• Esnek bir Referans Mekanizması: Abstraction• Etkili bir Gizleme Mekanizması: Encapsulation• Sistemi Hazmedilebilir Parçalara Ayırabilmek:

Modularity• Sistemin Parçalarının Alakalandırılabilmesi:

Hierarchy

Abstraction Abstraction

Abstraction (Soyutlama)• Sisteme değişik referanslara göre bakmak• Kullanıcı bazında geçerli hizmetleri

saptamak• Bir kullanıcıya yönelik olmayan sistem

hizmetlerini ondan gizlemek

Encapsulation

Encapsulation (Gizleme)– Kullanıcıya bir basitlik illüzyonu verebilmek– Kullanıcıyı gereksiz sistem detaylarıyla

uğraşmaktan kurtarmak– Sistemin parçalarının kolayca tekrar kullanımına

imkan vermek

Modularity

Modularity (Çok Parçalılık)– Tekrar kullanımı kolaylaştırmak– Testi ve Bakımı kolaylaştırmak– Bir projeye yönelik parçaların entegrasyonunu

kolaylaştırmak

Her abstraction

bir hiyerarşi oluşturur.

Kullanıcı

Sistem

Hierarchy (Hiyerarşi)– Class’ların sağladıkları fonksiyonellik bazında

uzmanlaşmalarına imkan vermek– Genel kullanıma açık metodları belirli paketler

halinde toplayabilmek– Sistemin yapısının takibini kolaylaştırmak

İçerik

• Nesne Tabanlı Yaklaşımın Temelleri• Class’lar ve Nesneler

özellikler/benzerlikler

?

özellikler/benzerlikler

?

ali meltemali meltem

Class’lar ve Nesneler



yaş cinsiyet ad soyad


iki FARKLI kişi


yaş : 25cinsiyet : erkekad : alisoyad : turalı

yaş : 23cinsiyet : kadınad : meltemsoyad : manisalı

ali meltem

nesne


Değişkenler/özellikler

yaşcinsiyetadsoyad



Diğer nesneler:Diğer nesneler:


Değişkenler/özellikler???

Diğer nesneler:Diğer nesneler:

AvustralyaAvustralya İtalyaİtalya İngiltereİngiltere



isimbaşkentnüfusparaBirimi

• Bu nesneleri birbirlerinden nasıl ayıracağız?• Bu nesneleri birbirlerinden nasıl ayıracağız?

Tüm nesnelerTüm nesneler


Ortak değişkenlerOrtak değişkenler

ÜlkeÜlke KişiKişi


yaşcinsiyetadsoyad

isimbaşkentnüfusparaBirimi

“yeni bir kişi”

?“hangi değişkenler?”

ali meltem

yaşcinsiyetadsoyad

Kişi(ler)





“yeni bir kişi”

ali meltem

yaşcinsiyetadsoyad

Kişi(ler)





yaşcinsiyetadsoyad

Kişi


yaşcinsiyetadsoyad

class Nesne tabanlı terminoloji (instance)variables

attributes

fields

ali meltem

Kişi


yaşcinsiyetadsoyad



Nesneler

instances

ali

İngiltere

}

?

?

?

}

meltem


Nesneler

Bir nesnenin özellikleri nelerdir?



}isim : ingiltereBaşkent : LondraNüfus: 3,534,209paraBirimi : Pound

ali

İngiltere

}

state }

meltem


Nesneler

Bir nesnenin özelliklerini ne belirler?



}isim : ingiltereBaşkent : LondraNüfus: 3,534,209paraBirimi : Pound

kimliği

kimliği

kimliği

state

state


Nesne

Nesnenin sahip olduğu özellikler

Identity: Kimlik State: Durum


Nesneler

State / DurumIdentity / Kimlik

Benzersiz

Değişebilir


yaş : 45cinsiyet : erkekad : velisoyad : kara

Identity / Kimlik

State / Durum aynı da olabilir farklı da


{Orta Yaş} {Yetişkin}

Benzersiz


Bölüm 3 / 6

İçerik

İçerik

• Görsel Tasarım• UML Modeli• UML Sonrasında Yazılım Dünyası

Görsel Tasarım

Bir sistemin verdiği bir hizmeti

nasıl gerçekleştirdiğinin görsel olarak ifade edilmesidir.

UML Süreci Yaklaşımları

– use-case driven (kullanıcıya sağlanan fayda odaklı), – architecture centric (esnek, bakımı ve tekrar

kullanılabilirliği kolay bir sistem mimarisi oluşturmaya elverişli),

– iterative (kademeli olarak)– incremental (birbirinin üzerine inşa ederek).

Rumbaugh Tanımı

Bilgi İşlem

İş Akışı

Sipariş

Ürün

Kargo

Görsel Tasarım standartlaşmış sembolleri kullanarak tasarım yapmaktır

“Bir Model bir Sistemin vazgeçilmez özelliklerini gösterir.”

Dr. James Rumbaugh

Görsel tasarımın faydaları

İş Akışı Bilgisi Toplamak İletişimi KolaylaştırmakProje Kontrolünü ArtırmakSistem Mimarisini OluşturmakTekrar Kullanabilmek

İş Akışı Bilgisi Toplamak

Use Case’ler ile yazılımın müşteri kullanımı odaklı olması sağlanıyor.

İletişimi Kolaylaştırmak

Birlikte çalışması gereken bu iki takım çoğu zaman farklı kelime hazneleri yüzünden anlaşamıyor.

Görsel Tasarımda UML kullanımı müşterinin dünyasıyla sistemin dünyasını birbirine bağlar

İş Analistleri sistemin gereksinimlerini belirlerler

Programcılar bu gereksinimlere dayanarak sistemi oluştururlar

Proje Kontrolünü Artırmak

Sistemler yüzlerce hatta binlerce class’dan oluşabiliyor.

Bu class grupları sisteme bakan kişinin ihtiyacına göre organize edilebilmeli.

Görsel Tasarım sisteme farklı yönlerden bakabilmeyi sağlar.

Sistem Mimarisi Oluşturmak

Görsel Tasarım oluşan çözümü kullanılan programlama dilinden bağımsız hale getirir.

Programlama dili belirlenince tasarım fiziki ortama taşınır.

Tekrar Kullanabilmek

Bileşenler

Farklı Sistemler

Tasarımınızı bileşenlere bölerek çözümünüzün parçalarını tekrar kullanabilirsiniz.

UML Öncesi

• 1960 - 70– COBOL, FORTRAN, C– Yapısal analiz ve tasarım teknikleri

• 1980 – 1990 başları– Smalltalk, Ada, C++, Visual Basic– İlk NT yöntemlerin ortaya çıkması

• 1990’ların geriye kalanında– Java– UML– Unified Process

Tijuana “shantytown”: http://www.macalester.edu/~jschatz/residential.html

UML Öncesi

İçerik


Modeller ve Şemalar

Use CaseDiagramsUse Case

DiagramsUse CaseŞeması

ScenarioDiagramsScenario

DiagramsCollaboration

/ CommunicationŞeması

StateDiagramsState

DiagramsComponentŞeması

ComponentDiagramsComponent

DiagramsDeploymentŞeması

StateDiagramsState

DiagramsObjectŞeması

ScenarioDiagramsScenario

DiagramsStatechart

/ State MachineŞeması

Use CaseDiagramsUse Case

DiagramsSequenceŞeması

StateDiagramsState

DiagramsClassŞeması

ActivityŞeması

Bir model bir sisteminBelli bir açıdan eksiksiz olarakIfade edilebilmesinisağlar

Model

Modellerin Faydaları

• Problem Çözme Mekanizması• Alternatif Çözümleri Görebilme• Sistemin Karmaşıklığını Kontrol Altına Alabilme• Ürünleri Daha Hızlı Oluşturabilme• Proje Maliyetini Düşürme• Hataları Azaltabilme

Model Nedir?

• Gerçeğin basitleştirilmiş bir ifadesi,• Sistemin veya Sürecin kavramsal düzeyde

anlaşılmasıdır

Model Kullanımı

Gereksiz Zaruri

Kağıttan Uçak F-15

Model Kullanımı

• Bilişim Takımları F-15’leri kağıttan uçak yaklaşımıyla oluşturabileceklerini zannedebiliyor.– Gereksinimlerden Kodlamaya geçiş– Daha uzun çalışmak, sistem mimarisi odaklı

olmayan kod yazmak– Esnek bir Sistem Mimarisi olmaması– Başarısızlık

Modelin Faydası

• Tasarladığımız çözümü anlayabilmek• Modeller ...

– Tasarlamak istediğimiz çözümü düşünebilmemize,– Sistemin yapısını ve davranışını belirleyebilmemize, – Sistemi oluşturabilmemize ve – Yaptıklarımızı dokümante edebilmemize yarıyor.

• Kapsamlı sistemleri modeller olmadan tasavvur etmek bile mümkün değil.

4 Model Kuralı

• Model problemi nasıl çözeceğinizi belirler.• Her model farklı detay seviyelerinde

kullanılabilir.• Model çözümün kullanılacağı dünyadan

kopmamalıdır.• Çözüme yönelik tek bir model yetersizdir

4 Model Kuralı

• Oluşturacağınız model probleme ve çözüme yaklaşımınızı belirler.– Seçilen model bir anlam dünyası oluşturur– Her anlam dünyası sizi başka bir çözüme yöneltir

Model problemi nasıl çözeceğinizi belirler.

4 Model Kuralı

• Her model kullanıcısına yönelik olmalıdır.– Detay seviyesi modeli kimin ve ne amaçla

kullandığına göre değişmelidir.

Her model farklı detay seviyelerinde kullanılabilir

4 Model Kuralı

• Model gerçekçi olmalı– Gerçek yerine göre bir kullanım senaryosu, yerine

göre bir sistem kısıtlaması olabilir. Dolayısıyla model farklı referansları barındırabilmelidir.

– Gerçeği basitleştirmeli– Riskli unsurları işaret etmeli

Model çözümün kullanılacağı dünyadan kopmamalı

4 Model Kuralı

• Sistemler birbirleri kötü olarak etkilemeyen farklı modellerle incelenmeli.– Birbirlerinden bağımsız olarak oluşturulabilen,

incelenebilen fakat birbirleriyle alakalı olan modeller oluşturulmalıdır

• Modellerin farklı referansları, oluşturulma nedenleri ve kullanıcıları olmalıdır.

Çözüme yönelik tek bir model yetersizdir

Process View

Deployment View

Logical View

Implementation View

KodVersiyonlar

Performans

Sistem MimarıTopoloji

kurulum, kullanım

Use-Case View

Analiz /Tasarım Kullanıcı

İşlevsellik

Sisteme 4+1 Bakışı

İçerik


Fallingwater:

http://www.casas.com/architect/franklloydwright/fallingwater000.html

UML Sonrası

Frank Lloyd Wright

http://www.casas.com/architect/franklloydwright/fallingwater000.html

Takım Üyeleri

UML’in Sınırları

Dil KullanılanSüreç

UML’in Yarattığı İş Fırsatları

• Yetenekli bilişim elemanlarının deneyimlerini aktarabilmeleri

• Yeni mezunların ustalarından örnek alabilmeleri

• Problem çözümlerinin gereksinim, analiz ve tasarım faaliyetlerinin yan ürünlere dönüşmesi

• İşverenlerin en kritik bilgilerini altyapı çalışmalarından ayırabilmeleri

• Müteşebbislerin kendilerini daha çok yeni iş fikirlerine adayabilmeleri

Ken Ishiwata

Fırsatlara örnekler

• İnfina: İş bilgisi satma,• Anadolu Hayat: Altyapı değerlendirme,• Uml öğrenen doktor,• Yazılım projesine giren haritacılar,• Alman sigorta uygulama referans modeli,• Vs. vs.

UML Kehanetleri• Teknolojik altyapı kullanımı kolaylaşacak• İşe özel nesne tabanlı yaklaşım bilgilerine erişim kolaylaşacak• İş mantığı bilgilerine erişim kolaylaşacak• Yönetsel yaklaşımların önemi artacak• İş mantığını gizleme artacak• Kod ve framework paylaşımı artacak• İş uzmanlarının yazılım alanına iştirakleri artacak• İşe özel framework pazarı kızışacak• Yazılım evleri uluslararası çalışmalara daha çok girmeye başlayacak• Az sayıda kişiden oluşan ve kısıtlı bütçe sahibi ekiplerin etkinlikleri artacak• Tasarımcı ve Sistem Analistlerinin popülerlikleri artacak• Programcıların önemleri daha çok algoritmik karmaşıklığa sahip alanlarda

korunacak• Framework bazlı kodlama hangarları oluşmaya devam edecek• Yazılım elemanlarının kişisel önemleri artacak

İlham Kaynakları• Eğitimimizin sonunda açık kaynak kodlu bir projeyi UML

modelinize çekin ve inceleyin:

www.sourceforge.net

Max Goff

“Zero Dollar Bill”

http://www.sourceforge.net/


Bölüm 4 / 6

İçerik

İçerik

• UML Modeli Kavramları• UML Tanımını Genişletme Mekanizmaları• Davranış Şemaları• Yapısal Şemalar

UML 2.0 Şema Türleri

*

*

*

*

*

Kısaca UML

UML sembolik bir dildir:Yazılım sistemlerinin oluşturulması esnasında

ortaya çıkan iş ürünlerinin– Tasavvur edilebilmesine,– İfade edilebilmesine,– Oluşturabilmesine ve – Dokümante edilebilmelerine yarar.

UML Modeli Oluşturma Nedenleri

• Oluşturulacak sistemin yapısı ve davranışı hakkındaki bilgiyi paylaşmak

• Sistem mimarisini tasavvur ve kontrol edebilmek

• Sistemi daha iyi anlayıp çözümü basitleştirmek ve tekrar kullanılabilirliği artırmak

• Riskleri yönetebilmek

4 Model Kuralı

• Oluşturduğunuz model problemi nasıl çözeceğinizi belirler.

• Her model farklı detay seviyelerinde bilgi verebilir.

• En iyi modeller gerçekle bağlarını koparmayanlardır.

• Tek bir model kesinlikle kafi değildir.

İçerik


UML Genişletme Mekanizmaları

• UML tanımı çok geniş de olsa bazen özel durumlara uyabilmesi için ‘genişletilmesi’ (extend) gerekebilir.

• UML tanım genişletme mekanizmaları- Yeni model sembolleri oluşturmak, - Yeni özellikler (property) tanımlayabilmek, - Yeni semantik yapılar oluşturabilmek için kullanılır.

• Genişletme mekanizmaları dörde ayrılır:- stereotype, tagged values, kısıtlar ve notlar

Stereotype

• Stereotype genellikle UML sembollerini yeni ortamlarda tanımlamak amacıyla kullanılır:

Örneğin Asansör Kontrol Sisteminin bir modelini oluştururken, bazı class’ları ve durumlarını (state) vurgulamak isteyebiliriz

• «hardware»• «software»

• Stereotype mutlaka tanımlandığı özel durum için ve hep aynı şekilde (mantıkla) kullanılmalıdır.

Stereotype

«button»CancelButton

Stereotypeetiket gösterimi

state

• Stereotype kullanım şekli: - Stereotype’ı UML sembolünün adının üstüne yerleştiriniz

• Stereotype adını «» işaretleri arasına koyunuz: (Örneğin, «node»)

- Yeni ikonu (resmini) tanımlayınız

CancelButton

Stereotypeikon gösterimi

Stereotype“UML Tanımıyla Gelenler”

Tanımlı Stereotype’lar:UML tanımı içinde mevcut, anlamı kesin olarak

belirlenmiş ve işarete karşılık gelen bir ikonu olan işaretlerdir.

<<Stereotype Adı>>

Tanımla Gelenler:• Boundary, Entity, Control• Aktör, vs.

cd Design Model

Class1 ud Use ...

Actor1

Size Ait İşaretler“UML in Color”

Peter Coad (TogetherSoft) entityclass’larının da kendi aralarındagruplara ayrılması gerektiğini söyler:

i. <<Thing>> ii. <<Description>> iii. <<Role>> iv. <<Moment-Interval>>

Tagged Values• Tagged values

–UML sembollerine ek özellikler atarken kullanılır–Mevcut UML sembol ve stereotype’larına eklenebilir–Bir isim-değer (özellik-değer, tag-value) ikilisi olarak

kullanılır.

• Genellikle aşağıdaki konularda kullanılır- Kod üretimi- Versiyon kontrolü- Konfigürasyon yönetimi- Sahiplik (telif hakkı kanıtı)- vs. vs.

Tagged Values

• Tagged value {} parantezi içine yazılan çok kısa bir nottur:- {tag adı, ayraç (=), bir değer}’den oluşur.

{yazan = “Ali”, Versiyon = 2.5}

Eleman

isimadres

tagged value

Tagged Values ve Kısıtlamalar

Gösterimleri aynıdır. UML ürünleri kullanıldığında NOT sembolünün içine yazılırlar. Pek çok farklı yerde belirtilebildiklerinden yaygın bir kullanımı yoktur.

{Tagged Value / Constraint}

{Vermek istediğiniz ek bilgi}

{Vurgulamak istediğiniz kısıtlama}

UML Metamodel

• Metamodel olası modellerin kullanacağı yapısal ve semantik özelliklerin tanımlandığı bir modeldir

• UML modeli, ait olduğu metamodelin bir uygulanış şeklidir

• UML metamodeli –UML sembollerini tanımlar–Tanımlamalar için UML sembollerinin bir alt kümesini

kullanır –Aralarında ilişkiler kurulan paketlerle düzenlenir

• UML metamodeli aşağıdaki konulara yanıtlar bulunarak oluşturulur:

- Syntax Yapısı (Abstract Syntax): Class Şemaları kullanılarak tanımlanır

- Net olarak tanımlanmış kurallar: Model öğelerinin uyması gereken kurallar (sınırlamalar) tanımlanır- Örneğin, bir class’ın birden fazla adı olamaz

- Semantik Yapı: Model öğelerinin ilşkilendirilme biçimleri gündelik dille tanımlanır

UML Metamodel

UML Profilleri• UML Profilleri özel konulara yönelik UML modelleri

geliştirebilmemizi sağlarla- Örneğin, süreç mühendisliği, gerçek zamanlı sistemler,

web uygulamaları vs. vs.

• Bir profil ‘paketinde’ bir veya daha çok genişletme mekanizması ürünleri bulunur (stereotype, tagged value, kısıtlamalar)

• Bunlar UML model öğelerine uygulanarak kullanılırlar

UML Profilleri• Bir UML profilinde aşağıdaki çalışmalardan gerekenler

yapılır:

- UML metamodelinin ilgili bir bölümü seçilir

- Stereotype’lar ve/veya tagged value çiftleri tanımlanır

- Mevcut kurallara yeni ekler tanımlanır

- Yeni bir semantik yapı tanımlanır

Profil Örneği• Temel GUI bileşenlerine yönelik bir profil tanımlarsak, • GUI yapımız aşağıdaki öğelere sahip olacaktır:

- Formlar- Butonlar

• Kısıtlamalar: – Bir form bir ‘dialog box’ı çalıştırabilir– Formlar ve Dialog Box’ların butonları olabilir

GUI ProfiliClass ve Association UML metamodelinden gelmektedir

GUI Profili

Class

<<stereotype>>Form

<<stereotype>>Button

Association

<<stereotype>>Contains

<<stereotype>>DialogBox

<<stereotype>>Invokes

GUI Profili Uygulaması

<<Form>>MainView

1 1

<<Button>>OkButton

<<Button>>CancelButton

<<Invokes>>

<<Contains>> <<Contains>>

<<DialogBox>>OpenDialogBox

1 1

1 1

İçerik


UML 2.0 Şemaları

Davranış Şemaları

– use case şeması*– activity şeması*– Etkileşim Şemaları

• sequence şeması• collaboration / communication şeması• interaction overview• timing şeması

– statechart / state machine şeması*

Use Case Şeması

• Temel Kavramlar• Şema İçeriği• Şemayla Aktarılan Bilgiler• Tasarım Teknikleri• Forward ve Reverse Engineering

Temel Kavramlar• Her tasarlanan sistem bir insanla veya başka bir sistemle

etkileşir• Sistemin kullanıcıları onun tahmin edilebilir bir şekilde

çalışmasını beklerler• Use Case sistemin kullanıcılarına sunacağı bir hizmetin

senaryo şeklindeki anlatımıdır. Bu yüzden bir fiil ismine sahiptir: Yap, Et gibi adlandırılır.

Örneğin, “Para Çek”, “Havale Yap”.• Aktör sistemin sunduğu hizmetleri kullanan bir kişi veya başka

bir sistemdir.• Aktörler mutlaka tasarlanan sistemin dışında olmalıdırlar.

Use Case’lerin 3 Temel İşlevi

– Sistemin Sınırlarını Çizmek: Tasarlanan sistemin dışarıdan nasıl görüleceğini programcılara da yol gösterebilecek şekilde belirlemek

– Sistemin Bütünlüğünü Görebilmek: Sunulan hizmetlerin sistem içinde nasıl gerçekleştirileceğini görebilmek

– Test için Referans Oluşturmak: Sistem oluştukça eklenen yeni unsurları kaldırıp kaldıramayacağını anlamak

‘Sihirli’ Use Case Sayısı Nedir?

Functional Decomposition!

İlgili Roller• Şemayı Hazırlayanlar:

– İş Analisti– Sistem Analisti

• Şemayı Kullananlar:– Müşteri– Proje Yöneticisi– Tasarımcı– Veri Tabanı Analisti– Kullanıcı Arayüzü Tasarımcısı– Testçi– Kullanım Kılavuzu Hazırlayanlar

Use Case Şeması Sembolleri - 1

Sembol Tanımı Syntax

use case Belli bir hedefe ulaşmak için kullanılabilecek tüm alternatif senaryolar.

aktör Sistemle etkileşen kişilerin canlandırdıkları roller ve dış sistemler.

sistem sınırı

Oluşturulan sistemle aktörleri birbirinden ayıran sınır.

UseCaseNam e

ActorNam e



association Aktörlerin veya Use Case’lerin birbirlerini kullanmaları.

generalization Aktörlerin çeşitlerini ve Use Case’lerin özel durumlarını vurgular.

extend Bir Use Case’in kullanıcısının seçimine bağlı olarak çalıştırdığı diğer bir Use Case’i vurgular.

<<extend>>



include Bir Use Case’in her zaman çalıştırdığı diğer bir Use Case’i vurgular.

Note Her şemaya dilenen bilgilerin yazılması için ve hyperlink oluşturmak amacıyla kullanılır.

note

Anchor note to item

Notu şemadaki sembollere bağlamaya yarar.

<<include>>

Şema Örneği 1

Use Case Bulma Teknikleri 1ud Use Case Model

Actor2

Actor1

Use Case1

Use Case2

Use Case3

Use Case4

Use Case5

Use Case6

Use Case 2 her zaman Use Case 1 i le birl ikte calisir.

Use Case 3 istegebagli olarak Use Case 4 i le birl ikte calisir.

Use Case 6, Use Case 5'in ozel birdurumudur. Use Case 5'in bazialternatif akislari buradadir.

Use Case 3'den Actor 2'ye birmesaj gitmektedir.

«extend»

«include»

ud Use Case Model

Actor2

Actor1

Use Case1

Use Case2

Use Case3

Use Case4

Use Case5

Use Case6

Use Case 2 her zaman Use Case 1 i le birl ikte calisir.

Use Case 3 istegebagli olarak Use Case 4 i le birl ikte calisir.

Use Case 6, Use Case 5'in ozel birdurumudur. Use Case 5'in bazialternatif akislari buradadir.

Use Case 3'den Actor 2'ye birmesaj gitmektedir.

«extend»

«include»

Use Case Bulma Teknikleri 2

Özne Nesne Fiil Oluşturulanlar Sistemin Cevabı Aday Use Case Aday Aktör

Öğrenci derse kayıt olur Ders listesine eklenme Dersi alabilirmi bakar Kayıt Ol Öğrenci

Haftalık Ders Programı Çakışan derslere bakar

Eğitmen derse kayıt olur Ders listesine eklenme Dersi alabilirmi bakar Kayıt Ol Öğrenci

Haftalık Ders Programı Çakışan derslere bakar

Event Table Çalışması:

Use Case Bulma Teknikleri 3

1. Aktörler Adaylarını Bulun2. Event Table Çalışmasını Yapın3. Aktör ve Use Case’leri Belirleyin4. Aktörleri Çizin ve İlişkilerini Düşünün5. Use Case’leri Çizin ve Aktörlere Bağlayın6. Use Case’ler Arasındaki İlişkileri Belirleyin

Aktör Bulma Soruları• Sistemin gereksinimleri kimleri ilgilendiriyor?• Sistem organizasyonun hangi biriminde kullanılacak?• Sistemden kimler faydalanacak?• Sisteme veri sağlayacak, sistemden bilgi alacak ve sistem kayıtlarını

değiştirecek olanlar kim?• Sistemin bakımını kim yapacak?• Sistemin hizmetlerinden yararlanacağı başka sistemler var mı?• Sistemin hizmetlerini sunacağı başka sistemler var mı?• Sistemin kullanımında birden fazla rolü oynayan kişiler var mı?• Sistemin kullanımında aynı rolü oynayan birden çok kişi var mı?

Use Case Bulma Soruları• Aktörlerin yerine getirecekleri görevler nelerdir?• Aktörlerden herhangi birisi sistem kayıtlarını oluşturma, kaydetme,

değiştirme, silme ve okuma amaçlı olarak kullanacak mı?• Hangi use case’ler yukarıdaki kaydetme, değiştirme, silme ve okuma

işlemlerine yol açacak?• Herhangi bir aktörün sistemi sistem dışındaki ani değişikliklerden

haberdar etmesi gerekli mi?• Herhangi bir aktörün sistem içinde olanlardan haberdar edilmesi

gerekiyor mu?• Hangi use case’ler sistemin bakımı için kullanılacak?• Sistemin vereceği tüm hizmetler (fonksiyonel gereksinimler) bulunan

use case’ler ile yansıtılabiliyor mu?

Use Case ŞemasıEgzersiz # 1

Lütfen şemadan anladıklarınızı bir paragrafta özetleyiniz (10 dk.)

uc Use Case Modeli II

Müşteri

(from Aktörler)

Sistem Yöneticisi

(from Aktörler)

Banka

(from Aktörler)

(from Use Case'ler)

Kataloğa Bak

(from Use Case'ler)

Satın Al

(from Use Case'ler)

Kataloğu Hazırla

(from Use Case'ler)

Sisteme Bağlan

«extend»

«include»

«include»

Use Case ŞemasıEgzersiz # 2

Aşağıdaki tanıma uygun use case şemasını çiziniz (15 dk.).

“Sadece üyelerin bir satın alma yapabileceği bir cd satış portali oluşturmanız gerekmektedir. Bu portali ziyaret edenler üye olmadıkları takdirde portal kataloğuna erişemeyeceklerdir.

Üye olma işlemi sırasında başvuru yapanların: • isim ve soyadları,• e-mail adresleri• favori müzisyenleri (3 isim)• favori cd’leri (3 isim)• arayıp bulamadıkları cd’ler (3 isim)• bilgileri toplanacaktır.

Üyelerden ayrıca bir şifre tanımlamaları istenecek ve e-mail adresleri kullanıcı adları olarak kullanılacaktır.

Web sitesinde şirket kataloğuna bakarak cd satın alabilmenin dışında, üyeler birbirleri arasında cd değiş tokuşu yapabileceklerdir.

Sistem üyelerin hangi cd’leri alıp sattıklarına, hangi cd’leri arayıp bulamadıklarına bakarak, cd önerilerinde bulunacaktır.“

Activity Şeması


Temel Kavramlar

• Sistem akışı içinde önce ne sonra ne olduğunu koşullarını işaret ederek gösterebiliriz.

• Use Case akışını çizebiliriz.• Sistem genelinin işleyişini çizebiliriz.• Bir hizmete yönelik işlemleri toplu halde

inceleyebiliriz (UC Map).• Tek bir işlemin nasıl gerçekleştirildiğini

inceleyebiliriz.

İlgili Roller• Şemayı Hazırlayanlar:

– İş Analisti– Sistem Analisti– Tasarımcı– Programcı

• Şemayı Kullananlar:– Müşteri– Proje Yöneticisi– Tasarımcı– Programcı– Veri Tabanı Analisti– Kullanıcı Arayüzü Tasarımcısı

Activity Şeması Sembolleri 1


Start State Activity Şemasındaki akışın başladığı nokta.

End State Activity Şemasındaki akışın bittiği nokta.

Activity Akış esnasında gerçekleşen bir faaliyet veya bir komut.



State Transition

Activity sembollerini önce hangisinin geldiğini belirterek birbirine bağlar veya bir döngüyü ifade eder..

Decision Akışın koşullara göre dallandığı

noktalarda kullanılır.

Swimlane Faaliyet ve komutları sorumluluklarına göre gruplamaya yarar.

Activity Şeması Sembolleri 3Sembol Tanımı Syntax

Synchronization bars

Eş zamanlılık içeren faaliyetleri ‘ayrılma’ veya ‘birleşme’ noktaları oluşturarak birbirine bağlamaya yarar.

Note Her şemaya dilenen bilgilerin

yazılması için ve hyperlink oluşturmak amacıyla kullanılır.

note

Anchor note to item

Notu şemadaki sembollere bağlamaya yarar.



Object ‘Elle tutulabilir’ nesnelerdir.

OrderItem

ObjectFlow Object’i girdi ve çıktı olarak faaliyet

ve komutlara bağlamaya yarar.

Şema Örnekleri 1act Pizza Siparişi

Ahçıbaşı Garson Müşteri

ActivityInitial

Pizza hamurunu hazırla

Menüyü v erSiparişi Ver

Siparişi mutfağa ilet

Pizza malzemelerinihazırla

Pizzayı fırına v er

Garsona haber v er

Serv is yap

Afiyetle ye

Hesabı iste

Hesabı sun

Hesabı öde

v s. v s.

Activity Şeması Örnekleri 2act Telefon Satış Birimi

Müşteri Telefonla Satış Depo Muhasebe

ActivityInitial

İade isteğini ilet

Vazgeçirmeye çalış

Vazgeçti mi?

Elemana Bonus yaz

ActivityFinal

İade numarası v er

Kargoya v er

«iade edildi»Ürün

Ürünü kabul et

Ürünü tekrar satışa sun

Müşteriye ödeme yap

«satışa sunuldu»Ürün

ActivityFinal

Activity Şeması Örnekleri 3

Activity Şeması Örnekleri 4

Activity ŞemasıEgzersiz

Aşağıdaki bilgileri alternatifleri ve beklenmeyen durumları da ekleyerek activity şemasıyla anlatınız (15 dk.)

• Yemek Tarifi: Arap Usulü Ispanak– Soğanları kızgın yağda 5 dk. kavurunuz,– İsterseniz, sarmısak ve kimyon ekleyerek 1 dk. daha kızartınız.– Ispanakları tavaya yavaş yavaş ekleyiniz. Eklenen ıspanakların yapraklarını iyi

yumuşayıncaya kadar karıştırınız. Taze ıspanak büyük ölçüde pişirilirken ufalacağından, ıspakların hepsi tavaya sığacaktır.

– Daha önce yumuşamaları için gece boyunca suda beklettiğiniz nohutların suyunu süzünüz ve tavaya ekleyiniz.

– Karışıma tereyağı ve baharat (tuz, biber ve kırmızı biber) ekleyiniz.– Karışım köpürmeye başlayana dek ısıtmaya devam ediniz.– Karışımı kendi suyu içinde hafif nemli olarak sununuz.

Statechart Şeması


Temel Kavramlar 1

Temel Kavramlar 2

Temel Kavramlar 3

Action ve Output:

Temel Kavramlar 4Event ve State Machine örtüşmesi:

Temel Kavramlar 5Bir faaliyet sona erene ve state geçerliliğini yitirene dek eş zamanlıolarak sürekli çalışır:

Temel Kavramlar 6

Duruma (guard condition) göre çalıştırılan komutlar:

Temel Kavramlar 7

Hiyerarşik State Machine’ler:

İlgili Roller

• Şemayı Hazırlayanlar:– Sistem Analisti– Tasarımcı– Programcı

• Şemayı Kullananlar:– Sistem Analisti– Tasarımcı– Programcı

State Machine ŞemasıEgzersizi

Kredi Kartı borcunu zamanında ödemeyenlere tutarın % 5.5’i oranında ceza verilmektedir. Borcunu son ödeme tarihinden bir ay sonra hala ödemeyenlerin kartlarına el konulmaktadır. Diğer durumlarda kart kullanımı normal şekliyle sürmektedir.

Kredi Kartı aylık ödeme tutarı 1,000 YTL ve üzerinde olanların kart limitleri iki katına çıkarılmaktadır. 1000 YTL ve üzeri ödeme yapanlara toplam harcamalarının % 2’si oranında hediye çeki gönderilmektedir.

İçerik


UML 2.0 Şemaları

Yapısal Şemalar

– class şeması*– package şeması*– composite structure şeması– object şeması– component şeması– deployment şeması

Class Şeması


Temel Kavramlar

• Class kendisinden üretilecek nesneler için ortak değişken ve metodları içeren bir şablondur.

• Bu şablondan üretilecek her nesne sadece şablonunda belirtilen değişken tipine uygun veri yapılarını taşıyabilir.

• Her nesne şablonunda tanımlanmış metodlar aracılığıyla kullanılabilir.

Temel Kavramlar

Değişkinler:Bir tip – değer ikilisidir.Class’lar değişken tipini belirler.Nesneler değişken değerini belirler.

Değişkenler bir ilkel veri veya bir class tipinde olabilirler.İlkel veri tipi kullanılan yazılım ortamına bağlı olarak

değişen integer veya string gibi mevcut veri tipleridir.

Temel Kavramlar

Metodlar:Class’ın tüm nesnelerinin canlandırabileceği

davranışlardır.Metodlar önce birer sorumluluk olarak ortaya

çıkıp daha sonra fonksiyonlara dönüşürler.Fonksiyona dönüştüklerinde parametreleri ve

return tipleri tanımlanmış olmalıdır.

Temel Kavramlar

• Değişkinler ‘private’• Metodlar ‘public’

Hepsi küçük harfle başlar ve kelimeler bitişik yazılır.

Course

- number : Integer- name : String- classSize : Integer- active : Boolean

+ openForEnrollment ( )+ closeEnrollment ( )+ isOpenForEnrollment ( )

Temel Kavramlar

• Her eleman bulunduğu yere erişim haklarını ifade eden bir görünürlüğe sahiptir (visibility).– ‘public’ elemanlar Class dışından görülebilir ve

erişilebilirler. Sembolleri: ‘+’– ‘protected’ elemanlar sadece Class’la generalization

ilişkisine sahip Class’larca görülebilir ve erişilebilirler. Sembolleri: ‘#’

– ‘private’ elemanlar ait olduğu Class dışında görülemez ve erişilemezler. Sembolleri: ‘-’

Temel Kavramlar

Encapsulation:Değişkenlerin ‘private’ olma nedenidir.

Course


+ openForEnrollment ( )+ closeEnrollment ( )+ isOpenForEnrollment ( )+ register ( )

Temel Kavramlar

Generalization:Farklı ‘abstraction’

seviyeleri arasında ırsiyet ilişkileri kurmak için kullanılır.

Course



+ courses

*

PostGraduateCourse

- Sponsor

+ publishWork ( )+ closeEnrollment ( )+ register ( )

GraduateCourse

- thesisTopic

+ register ( )

Temel Kavramlar

Polymorphism: implementasyonun detaylarını gizleyerek kolay kullanımı sağlar.

Aynı isme sahip fakat farklı çalışan fonksiyonları ifade eder.

Course



+ courses

*

PostGraduateCourse

- Sponsor

+ publishWork ( )+ closeEnrollment ( )+ register ( )

GraduateCourse

- thesisTopic

+ register ( )

Temel Kavramlar

Inheritance: oluşmuş class’ların özelliklerinin kademeli olarak zenginleştirilebilmesine olanak verir.

Class’ları özel durumlara istinaden ayırarak farklı ‘abstraction’ seviyeleri oluşturulmasını sağlar.

Böylece katmanlı bir sistem mimarisine imkan vererek tekrar kullanımı kolaylaştırır.

Temel Kavramlar

Abstract Class:Kendisinden nesne üretilmeyen, hiyerarşik yapının en

üstünde yer alan ve kendinden özelleştirilmiş class’lar vasıtasıyla değişkenlerini sistemin kullanımına sunan class’lardır.

cd Design

Hayvanlar

Eteburlar OtoburlarOmnivorlar

Class Şeması Sembolleri 1Sembol Tanımı Syntax

association Nesneleri etkileşen Class’lar arasında çizilir.

aggregation Parça bütün ilişkisi ifade eden bir association türüdür.

generalization Aralarında tür / ırsiyet ilişkisi olan Class’ları birbirlerine bağlar.

dependency Bağımlılık ilişkisini ifade eder.

Class Şeması Sembolleri 2


class Aynı veri yapısı ve davranışı sergileyen nesnelerin kaynaklandığı kalıptır.

interface Bir öğenin davranışlarını temsil eden bir fonksiyon grubudur.

«interface»

İlgili Roller

• Şemayı Hazırlayanlar:– Tasarımcı– Programcı

• Şemayı Kullananlar:– Tasarımcı– Programcı

Class Şeması Örneğicd Design

Hayvanlar

EteburlarOtoburlar Omnivorlar

Tur

Ucanlar Surunenler

FotosentezYapanlar

Bitkiler

Class ŞemasıEgzersiz # 1

Class ŞemasıEgzersiz # 2

• “Dinozorlar Paleozoik, Mesozoik ve Senozoik zaman dilimlerinde görülmüşlerdir. Paleozoik’in sonlarına doğru memelileri andıran ilginç bir örnek Dimetrodon’dur. Dimetrodon’un sırtında yelken gibi büyük bir çıkıntı vardı. Dimetrodon yürürken dört ayağını birden kullanıyordu ve etçildi.

• Uçan dinozorlara (Pterosor) örnek olarak Pteranodon’u verebiliriz. Diğerlerinin aksine Pteranodon’un kuyruğu yoktu ve çok geniş kanatları vardı (8 m.). Yine ilginç bir özelliği diğerlerinin aksine dişlerinin olmamasıydı. Uçan dinozorlar etçillerdi.

• Etçil dinozorların en ünlüsü Tiranosorus’dur. Etçil dinazorların en önemli özelliklerinden birisi genellikle ön ayaklarının çok küçük ve kullanışsız olmasıdır. Bu tür etçil dinozorlar arka ayakları üzerinde yürür ve ön ayaklarını hareket amacıyla kullanmazlar.

• Otçul dinozorların en uzunları Diplodokus ve Brontosorus etçil dinazorların aksine dört dev ayağa sahiptiler ve hepsini kullanarak gayet hızlı yürüyebildikleri düşünülmektedir. ”

Package (Paket) Şeması


Temel Kavramlar

• Paket, Subsystem ve Model – Model içindeki elemanları belli bir referansa göre

gruplamaya yararlar. – Her grubun elemanları arasında farklı bir semantik

ilişki vardır. Farklı bir nedenden dolayı bir araya gelmişlerdir.

• Subsystem (Modül) ve Model aslında birer pakettir.

Temel Kavramlar

Paket UML modeli elemanlarından oluşan bir gruptur.

Paket Şeması Sembolleri

İlgili Roller

• Şemayı Hazırlayanlar:– Herkes

• Şemayı Kullananlar:– Herkes

Paket Şeması Örnekleri

SiparişMüşteri

Yer CD

Stok Sipariş

Depo

Satış

Şema Eksiksizliği Kontrolleri 1

• UML Şeması hazırlamak serbest resim çalışmasına dönüşmemelidir.

• Şemanın hazırlanma amacı asla mevcudiyeti olmamalıdır.

• Şemayı hazırlayan ya düşünüyordur, ya sistemi geliştiriyordur, ya birisine doküman hazırlıyordur ya da bir sistemin yapısını inceliyordur.

• Şemaların belli hazırlayıcıları ve kullanıcıları vardır.

Şema Eksiksizliği Kontrolleri 2

• Bir UML şeması çizmeye karar verdiğimizde belli bir amacımız ve açıkça ifade edilebilen sorularımız olmalıdır.

• Sorularımız yanıt bulduğunda eğer şirketimiz içinde gereken dokümantasyon seviyesine de uyuyorsak çizim çalışması biter.

• Her şemanın aynı konuda olsalar bile farklı yararlılık dereceleri vardır. Bazı şemalar zamana karşı koyar bazılarıysa giderek gözden düşer.


Bölüm 5 / 6

İçerik

İçerik

• Modüllerin Yapısı• Modül Tanımlama Teknikleri• Modül Gerçekleştirme Teknikleri• Modellerin Yapısı• Modellerin İlişkileri

Modül (Subsystem) Özellikleri

• Bir modülün iki özelliği vardır:– Dış görünümü: modülün sağladığı

hizmetleri gösterir. – İç görünümü: modülün verdiği hizmetleri

destekleyen altyapıyı gösterir. • Bu iki görünüm arasında bire bir bir ilişki

vardır.

Modül Özellikleri

Bir modül bir sistemin hem tanımlanma hem de gerçekleştirilme aşaması çalışmalarını içerir.

Gerçekleştirme elemanları

Tanım elemanları

Modülün Gerçekleştirilmesi

• Gerçekleştirme elemanları subsytem’in içeriğini gösterir.

• Modül gerçekleştirilmesi genellikle class’lar ve ilişkilerini içerir.

Gerçekleştirme elemanlarıTanım elemanları

?

Modül tanımı modülün dışarıdan nasıl görüldüğü belirtir


?

Modül Tanımlanması

İçerik


Modül Tanımlanması

• Modül tanımı– Modülün verdiği hizmetleri tanımlar– Sistemin kullanıcılarına yaşatacağı deneyimi

tanımlar – Modülün iç yapısını gözler önüne dökmez – Modülün interface’lerini tanımlar

Tanımlama Teknikleri

• Use Case yaklaşımı• State Machine yaklaşımı• Mantıksal Class yaklaşımı• Metod Yaklaşımı

… ve bunların kombinasyonları

• Modülü sunduğu hizmetlerle alakalandırabilmek için• Spesifikasyonun teknik olmayan insanlara aktarılabilmesi

için


1. Use Case Yaklaşımı

1. Use Case Yaklaşımı

Çağrı Kontrol

Tanım elamanları Realization elements

Change Digit Analysis Information

Initiate Call

Receive Digit and Connect

Hook Signal and Disconnect

Operator

Trunk

Subscription

2. State Machine Yaklaşımı

• Duruma göre davranışı değişen modüller için (Simülasyon vs.)

• Modülün yaşadığı durumlar ve bu durumlar arasındaki geçişlere odaklanır

Tanım elemanları

Stopped Running

Error

Maintenance

Exhausted

Çağrı Kontrol

Tanım elemanları

AnalyzerNumber

Dictionary

Network Manager

Çağrı Kontrol

3. Mantıksal Class Yaklaşımı

• Modülün kullanımı nesnelerin manipülasyonu olarak görülüyorsa

• Gereksinimler belli bir standarda uyum zorunluluğundan kaynaklanıyorsa

4. Metod Yaklaşımı

• Basit (atomic) hizmetler veren modüller için• Metodlar birbirlerinden bağımsız olarak çağrılıyorlarsa

MetodlarinitiateConnection (…)

dialledDigit (…)

throughConnect (…)

bAnswer (…)

bOnHook (…)

aOnHook (…)

Çağrı Kontrol

Tekniklerin KombinasyonlarıÇağrı Kontrol

changeDigitAnalysisInformation (...)

Initiate Call


Hook Signal and DisconnectSubscription

Trunk

Specification elements

Tanım elemanları

Metodlar

• Üç tanımlı parçadan oluşur• Bu parçalar isteğe bağlı olarak kullanılmayabilir


Tanım elemanları

OperationsMetodlar

Eksiksiz Modül Notasyonu

İçerik


Tanım (Specification) – Gerçekleştirme (Realization)

• Tanım ve gerçekleştirme birbirleriyle uyumlu olmalıdır

• Tanım ile gerçekleştirme arasındaki ilişki (mapping) şu şekilde ifade edilebilir:– gerçekleştirme (realization) ilişkisi– birliktelik (collaboration)

Metodlar

operation1( ) : Type1






«realize»

operation1( )

Gerçekleştirme İlişkisi

Gerçekleştirme (Realization) özellikle tek seviyeli ilişkileri göstermekte faydalı

Gerçekleştirme İlişkisi


Tanım elemanları

changeDigitAnalysisInformation ( )

Initiate Call


Hook Signal and DisconnectSubscription

Trafik Kontrol

Metodlar

Trunk

changeDigitAnalysisInformation ( )::

«realize»

Collaboration

• Collaboration (Birliktelik): Belli bir hedefe yönelik olarak nesne etkileşimlerinin resmedilmesidir. Bu bir UC senaryosu veya class ilişkileri incelemesi olabilir.

• Interaction (Etkileşim):Bir birliktelik içindeki nesnelerin arasındaki haberleşmelerdir.

Collaboration

• Bir ‘collaboration’ bir iş yerine getirilirken gereken rolleri tanımlar

• Bu roller birbirleriyle etkileşen nesneler aracılığıyla canlandırılır

Sequence Şeması

:Trunk :Traffic Control :Subscription

markBusy

dialledDigit

dialledDigit

throughConnect

bAnswer

markBusy

Collaboration Şeması

:Trunk

:Traffic Control

:Subscription

3: dialledDigit6: bAnswer

5: markBusy1: markBusy

4: throughConnect

2: dialledDigit

Collaboration Sembolleri

Collaboration Notasyonu

Bir birliktelik (collaboration) ve katılımcıları

Collaboration

Rol

Class

Rol adı

Rol adıRol adı

Rol adı

Tanım elemanları Gerçekleştirme elemanları


Hook Signal and Disconnect

Initiate Call

CoordinatorAnalysisDatabase

NetworkInterface

Collaboration

Collaboration genellikle daha karmaşık durumlarda faydalıdır

Collaboration ÇeşitleriRol modeli bir özel durumu ifade ederken Class modeli dahagenele yönelik. Dolayısıyla her Class modeline karşılık birdenfazla Rol modeli olacaktır.

Use Case RealizationCollaboration Şeması: “Sipariş Alınması”

Use Case Realization (UCR)




Model Bağımlılıkları

Üniversite Kayıt Sistemi

Modüller Ne Zaman Gerekli?

• Büyük bir sistemin hangi parçalardan oluştuğunu ve bu parçaların bağımlılıklarını göstermek gerektiğinde (Sistem Mimarisi)

• Dağıtık (distributed) yazılım geliştirme yapılıyorsa • Bir grup modülün nasıl büyük bir sisteme

dönüştürülebileceğini gözlemleyebilmek için (Sistem Mimarisi)

• Bileşen bazlı yazılım geliştirme yapabilmek için

Modül Oluşturma Teknikleri• Büyük bir sistemin her kendine haslık gösteren

parçasını bir modülle ifade edin• Tanımlama (specification) tekniğini sistem ve

modülün özelliklerine göre belirleyin• Her modülü ayrı ayrı ve tanımlama elemanlarını

(gereksinim) kullanarak gerçekleştirin (realize)

İçerik


Model

Bir model sisteme belli nedenden dolayı farklı bir bakış şeklidir. Oluşturulma amacına uygun şekilde dokümantasyona ve detay seviyesine sahiptir.

Model

Tasarım Modeli

Use Case Modeli

Model Sembolleri

Model

Trace

Sembol Tanım Syntax

Modeller arasındaki bağımlılık aynı konuların farklı bakış açıları altındaki ürünlerini temsil eder.İşaret tek veya çift yönlü olabilir.

«trace»

Sistemi belli muhataplara onlara özel detay seviyesiyle sistemin ilgili yönlerinin gösterilmesidir.

İsim

Trace

Analiz

Tasarım

«trace»

Model / Şema

Use Case Modeli

Şemalar modeli dokümante eder

Tasarım Modeli

Model Ne Zaman Gerekli?

• Farklı paydaşlara sisteme kendi ihtiyaçlarına göre bakabilmelerini sağlamak için

• Sistemi gerektiğinde sadece tek bir yönden inceleyebilmek

• Yazılım geliştirme sürecinde farklı aşamalarda üretilenleri dokümante edebilmek

Model Oluşturma Teknikleri

• Her modelin amacını tanımlayınız • Her model amacına uygun şekilde sistemin

eksiksiz bir resmini çizmelidir • Modelin amacına odaklanarak ilgisiz

bilgileri modele eklemeyiniz

İçerik


Modeller ve ModüllerModeller ve Modüller arasında hiyerarşik ilişkiler kurulabilir:

Bankacılık Sistemi

Tasarım Modeli

Analiz Modeli

UC Realization

MuhasebeModülü

MuhasebeModülü

[1] Modellerİş Modeli (Seçeneğe Bağlı)

[2] ModellerGereksinim Modeli

[3] ModellerAnaliz ve Tasarım Modelleri

[4] ModellerEk Modeller

Rational SoftwareReferans UML Modeli

PearlCircle İnternette Açık Artırma

Model ElemanlarıGereksinim, Analiz, Tasarım ve Kullanıcı Arayüzü Tasarımıçalışmalarının ilişkileri.

Tasarım

Gereksinim

Analiz

KullanıcıArayüzüTasarımı

Specification

Realization

Realization

Analiz Mdl.

UC Mdl.

Tasarım

Tasarım

User Experience

Mdl.

Gereksinim → Analiz

Etkileşim Şeması # <= Akış #

Analiz ÇalışmalarıParticipants: Kullanılan class’larınUC bazında gruplanmasıdır.

Analysis Elements: class’ların mantıkiilişkilerine göre yeniden gruplandırılmalarıdır.Bu geleneksel modüler yapıya karşılık gelir.

Analiz → Tasarım

Gereksinim → Kullanıcı Arayüzü

Bid on Item – Analiz - VOPC

Bid on Item – Analiz – Temel Akış

Bid on Item – Tasarım - VOPC

Bid on Item – TasarımTemel Akış

Bid on Item – UX - VOPC


Bölüm 6 / 6

Neredeyiz?

İçerik

İçerik

• Analiz ve Tasarım Modelleri Yapısı• Analiz Class’ları• Class Bulma Teknikleri

İlgili Roller

Analiz Modeli Girdileri

Analiz Modeli Oluşturma Aşamaları

1 < N < 5}

Analiz ve Tasarım Model Yapısı

• Analiz (veya Tasarım) Paketleri • Gerek duyulduğunda class başına ve/veya modül

genelinde State Machine şemaları• Kullanım Senaryosu Gerçekleştirilmeleri (Use Case

Realizations)• Temel Soyutlamalar (Sadece Analiz Modelinde)• Katmanlar ve Modüller (Özellikle Tasarım Modelinde)

Use Case Realizations İçeriği

Analiz veya Tasarıma aitliğine bakılmaksızın Use Case başına,

• Bir Class Şeması: VOPC (View of Participating Classes)2. Bir Class Şeması: Traceabilities3. N sayıda Etkileşim Şeması

1 < N < Akış Sayısı

1 = Temel Akış her zaman alınır.

Analiz/Tasarım ModeliÇalışmaları

Modeller ve Modüller“Analysis Elements”

Modeller ve Modüller“Design Elements”

Modeller ve Modüller“UCR – Analysis Mapping”

Modeller ve Modüller“UCR – Design Mapping”

Senaryo – Class İlişkisi

Aynı class birden fazla UCR’da,kullanılabilir. Böylece class’ların sorumlulukları bir takım çalışmasıyla senaryo ihtiyaçlarına bağlı olarak zamanla eksiksizleşir.

‘1’

‘2’

‘3’

Diğer Tasarım Seviyesi Modelleri

Tasarımcı:• Deployment Modeli• İmplementasyon Modeli (*)Veritabanı Analisti:• Veritabanı Modeli (Data Model)Kullanıcı Arayüzü Tasarımcısı:• Kullanıcı Etkilişimi Modeli (Human

Interaction / User Experience Model)

Diğer Tasarım Seviyesi Modelleri“Deployment Modeli”

Deployment ŞemasıÖrneği

Diğer Tasarım Seviyesi Modelleri“Veritabanı Modeli”

Diğer Tasarım Seviyesi Modeli“Kullanıcı Etkileşimi Modeli”

Diğer Tasarım Seviyesi Modelleri“Kullanıcı Etkileşimi Modeli”

İçerik


Analiz Class’ları Nelerdir?

• Analiz class’ları bulunurken üç farklı referans kullanılır:

• Sistem ve aktörleri birbirlerinden ayıran sınırlar• Sistemin kullandığı bilgi türleri• Sistemin akış mantığı

Analiz Class’ları Nelerdir?

<<boundary>>

<<entity>>

<<control>>

=

=

=

Stereotype aynı sembolle ifade edilen nesneleri ayrıştırmaya yarar.

Analiz Class’ı Çeşitleri

<<boundary>>

<<boundary>>

<<entity>>

<<control>>

<<entity>>

<<boundary>>

Aktör1

Aktör2

Sistemin dış dünyayla etkileşimini sağlar

Sistemdeki verileri depolar ve yönetir

Use Case davranışını koordine eder

Boundary Class

• Sistemin sağladığı işlevler ile kullanıcıları arasındaki etkileşimleri sağlar– User interface class’ları

• Kullanıcıya sağlanan bilgilere odaklanır• UI detay özellikleri bu aşamada göz önüne alınmaz• Örnek: ViolationsDialog

– System / Device interface class’ları• Hangi protokollerin tanımlanması gerektiğine odaklanır.

Protokollerin implementasyon detayları bu aşamada göz önüne alınmaz

• Örnek: OffendersDBProxy

Entity Class

• Sistemin temel kavramlarının bir modelidir• Genellikle saklanacak bilgileri ifade eder• Sistem seviyesindeki mantığı içerir• Ortamdan bağımsızdır• Birden fazla use case’de kullanılabilir

Control Class

• Use case’in davranışını kontrol ve koordine eder• Use case’in yerine getirmesi gerekenleri iş bazında

class’lara atar– Bir control class’ı diğer class’lara bir şey yapmaları isteğini

iletmeli ve kesinlikle atama haricinde bir iş yapmamalıdır

• Boundary ve entity class’larını bir araya getirir• Genellikle her use case için bir control class’ı vardır

Çok Katmanlı Mimari

Tasarımdaki karşılıkları aşağıdaki gibi olabilir (Java/J2EE):

• Arayüz Katmanı: JSP• İş Mantığı Katmanı: Session Beans + Servlets• Veri Katmanı: Entity Beans • + Veri Erişim Katmanı, vs. vs.

İçerik


Analiz Class’larını Bulma Yolları

1. Her use case için:a. Dokümanına başvurunuz. b. Entity class’larını bulunuzc. Boundary ve Control class’larını bulunuzd. Her class için:

i. Değişkenlerini bulunuzii. İlişkilerini (Mesajları da içerir) bulunuz

2. Modelin bir sağlamasını yapınız

Analiz Class’larını Bulma Yolları

//

Class’ları Bulacağımız Yerler 1

Birincil kaynağın UC Dokümanı olduğunu aklımızda tutarak,Eğer Use Case Dokümanı sorunluysa:• UC tanımı her zaman analiz class’larını bulmak için kafi

olmayabilir– Önce Entity class’ları bulunmalıdır

• Müşteriye yönelik yazılan uc tanımına gerekli sistem reaksiyonlarını ifade edecek detaylar (sistem içi davranışlar) eklenebilir

• Sistemin dışarıdan gözlenen davranışlarına sebep olan iç özelliklerine odaklanmak gerekebilir


• Class’lar aşağıdaki dokümanlarda gizlenebilirler:– Gereksinim Dokümanları– Use case modeli– Müşteri istekleri– Problem domain– Proje dokümanları


• Boundary class’ları– Her aktör / uc ikilisi için en az bir tane olmalıdır

• Control class’ları– Genellikle her uc için bir tane vardır– Benzer control class’ları varsa ait oldukları

uc’ler birleştirilebilirler• Örnek: “manage traffic report”, “edit/add/remove

traffic report” use case’lerini barındırabilir.

İsim Ayıklama Yöntemi“Noun Filtering”

Use Case Tanımı

Senaryolar

İsim Ayıklama

Use Case için ilk VOPC Şeması sürümü

Diğer Dokümanlar


• Entity Class’ları– Problem tanımı, gereksinim ve diğer mevcut

dokümanlardaki isimleri inceleyerek bulunur– Bulunan isimler:

• Nesneler• Nesnelerin değişkenleri• Aktörler• Hiçbiri olabilir


Problem metninin dikkatle okunarak, herhangi bir hatalı düşünce şeklinden kötü olarak etkilenmemek için bulunan tüm isimlerin listelenmesidir.

Daha sonra bulunan isimlerden entity class’ı olamayacaklar elenir.

İsim Eleme Nedenleri 1

• Birbirine eş class’lar– Yalnızca isimlendirme farklı

• İlgisiz class’lar– Oluşturulacak sistem için anlamsız

• Değişkenler / Metodlar– İlkel veri tipleri– Veri işleme şekilleri

İsim Eleme Nedenleri 2

• Roller– Class’dan ziyade bir class’dan türetilebilecek nesne adayları

• Örnek: “Asistan” ve “Öğrenci” “Kişi” class’ın farklı rolleridir.

• Soyut kavramlar– Fiziki olarak mevcut olmayan değerlerdir– Nadiren analiz class’ına dönüşürler. Daha çok değişken

adaylarıdır: “İstek”, “Satış”– Tasarım aşamasında class’lara dönüşebilirler.

Değişkenleri Bulma Yolları

• Saptanan class’ların özelliklerini ifade ederler– Bu class’larca taşınacak veri yapılarıdır

• Class’a dönüşmeyen isimler– Akış içinde değeri önemli olan veri yapılarıdır– Bir nesne tarafından benzersiz bir biçimde

sahiplenilecek değerlerdir

İlişkileri Bulma Yolları

• İlişki (Association) genellikle bir fiile karşılık gelir– Mekan: yanında, içinde, üstünde … – Eylem: oluşturmak, yönetmek … – Haberleşme: konuşur, dinler, onaylar, uyarır … – Sahiplik: aidiyet, parça, bütün ...– Diğer: çalışır, evlidir, okur ...

• Problem ve Çözümle ilgisiz ilişkileri göz ardı ediniz • Nesne Etkileşim Şemaları ilişkileri bulmanın en

etkili yoludur

Örnek: Trafik Denetim Sistemi

• Entity Class adayları:

Trafik Raporu

Süpervizör

Rapor Okuması

Konfirmasyon

Suçlu Detayları Formu

T. Raporuna Eklenen

Sistem

Suçlu

Police memuru

Araç no

Plaka no

Hata

Trafik polisi

Polis şefi

Suç

ID

Password

Polis merkezi

Kapanma

Tarih

Hız

Trafik hatası

Memur

Eşdeğer Class’ları Eleme

Memur ve Bilirkişi Kişi ile temsil edilecek

Trafik Raporu

Süpervizör

Rapor Okuması

Konfirmasyon


T. Raporuna Eklenen

Sistem

Suçlu

Police memuru

Araç no

Plaka no

Hata

Trafik polisi

Polis şefi

Suç

ID

Password

Polis merkezi

Kapanma

Tarih

Hız

Trafik hatası

Memur

İlgisiz Class’ları Eleme

Trafik Raporu

Kişi

Rapor Okuması

Konfirmasyon


T. Raporuna Eklenen

Suçlu

Police memuru

Araç no

Plaka no

Trafik polisi

Polis şefi

Suç

ID

Password

Polis merkezi

Kapanma

Tarih

Hız

Değişken ve Metod Eleme

Trafik Raporu

Kişi

Rapor Okuması

Konfirmasyon


T. Raporuna Eklenen

Suçlu

Police memuru

Araç no

Plaka no

Trafik polisi

Polis şefi

Suç

ID

Password

Kapanma

Tarih

Hız

Soyut Kavramları Eleme

Trafik Raporu

Kişi

Konfirmasyon


Suçlu

Police memuru

Trafik polisi

Suç


Ayıklama Öncesi:

Trafik Raporu

Süpervizör

Rapor Okuması

Konfirmasyon


T. Raporuna Eklenen

Sistem

Suçlu

Police memuru

Araç no

Plaka no

Hata

Trafik polisi

Polis şefi

Suç

ID

Password

Polis merkezi

Kapanma

Tarih

Hız

Trafik hatası

Memur


Trafik Raporu

Kişi


Suçlu

Police memuru

Trafik polisi

Suç

Ayıklama Sonrası:

• Trafik raporu• Kişi• Suçlu Detayları Formu• Suçlu• Polis memuru• Trafik polisi• Suç• …

Entity class’ları

Bazen bu listede boundary class’ları da kendilerini bariz olarak gösterirler. Ancak bu class’ları bulmanın en iyi yolu UC akışını incelemektir.

Boundary class’ları

• RaporDetaylariFormu• PolisDetaylariFormu• RaporIzlemeFormu• KonfirmasyonEkrani• SucluDBProxy• PolisDBProxy• ...

Veri Tabanına erişim katmanındaki interface’ler.

Control Class’ları

• RaporKontrol• LoginKontrol

Use Case’ler

• Rapor Et– Rapor Ekle– Rapor Sil– Rapor İzle– Rapor Güncelle

• Sisteme Bağlan

Analiz Class’ları 1

Analiz Class’ları 2

Violation

EditReportController<<control>>

Traf f icReport

Of f ender Traf f icPoliceman

Clerk

ReportDetailsForm<<boundary >>

Conf irmationDialog<<boundary >>

PolicemanDBProxy<<boundary >>

Of f endersDBProxy<<boundary >>

Of f endersDB

PolicemenDB

1

1 1

1

1

İlham Kaynakları

Christopher Alexander

Martin Fowler Peter Coad

Kelli HoustonSizin Adınız

?

Don Box

Pratik Egzersiz

Business

Analist Eğitimi - Tüm Bölümler - [535 Slides]