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

Eğitmen Hakkında Erol Bozkurt – erol.bozkurt@xupit.com 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: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!

Analizden Ne Anlıyoruz? Bir konuyu derinlemesine inceleyerek ,[object Object]

temel parçaları ve ilişkilerini,

baz aldığı varsayımlarısaptama faaliyetlerinin tümüdür. Sherlock Holmes

Analizden Ne Anlıyoruz? Analiz esnasında dikkat edilebilecek öğeler ,[object Object]

Çö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çleriFormü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 / 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

İç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ı

KiminNeyiNe ZamanNasıl yapacağını tanımlamaktır. Yeni sistem Değişen gereksinimler Süreç Süreç Nedir?

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

Milestone(s) Ürünün sürümleri Bu fazlar kısa bir süre için örtüşebilir Fazlar Waterfall Yazılım Süreci Gereksinim Analizi Tasarım İmplementasyon Test Bakım zaman

Waterfall Neden Pratik Değildir? 1. Sahip olunması istenen bilgilerin hepsi hazır değildir Bü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 gerekir Buradan alınan sonuçlara göre gereksinimler değişebilir 3. Sık sık ara sürümler çıkarmak zorunda kalırız Paydaşların (müşteriler, yöneticiler) projeye güvenlerini tazelemek gerekir Tasarı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

M I L E S T O N E S α(prototype) X β X sürüm 1.0 1 2 3 1 2 3 1 2 3 1 2 3 2 3 1 Spiral Süreç zaman İterasyon # Gereksinim Tasarım Kodlama Test

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

RUP’un Gelişimi Rational Unified Process 5.0 İşlevsellik Testi Performans Testi Gereksinim Denet. Değişiklik Denet. İş Akışı Veri Tabanı UI 1998 Rational Objectory Process 4.1 1996-1997 UML Rational Yaklaşımı Objectory Process 1.0-3.8 1987-1995 Ericsson Yaklaşımı

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”

zaman Gereksinim Kontrolü Sistem Mimarisi Kullanılabilirlik Resmi Sürüm Proje Gelişim Süreci Inception Elaboration Construction Transition saptama tasarlama oluşturma sunma ,[object Object], berraklaştırılması ,[object Object], saptanması, Baseline ,[object Object]

Transition: Kullanıma sunulma,[object Object]

I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n T r a n s i t i o n P r e l i m i n a r y i t e r . i t e r . i t e r . i t e r . i t e r . i t e r . i t e r . I t e r a t i o n ( s ) # 1 # 2 # n # n + 1 # n + 2 # m # m + 1 İterasyonlar ve İşler Aşamalar İşler Gereksinim Analiz Tasarım Uygulanma Test İterasyon

İterasyonlar ve Risk Proje risklerinin ortaya konması ,[object Object]

EntegrasyonInception Waterfall Elaboration ,[object Object]

Müşteri memnuniyetini ölçmeRisk Construction ,[object Object]

Temel mekanizmaların tasarlanmasıTransition Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Post- deployment Zaman

Risk Azaltma Odaklı İterasyonlar İterasyon N’in Planı ,[object Object]

ZamanlamaEn önemli risklere yönelik senaryoların oluşturulması İlk Proje Riskleri İlk Proje Odağı Iteration N’in oluşması ,[object Object],Iterasyon N Iteration N’in değerlendirilmesi Yenilenen Proje Planı ,[object Object]

Odak/İçerikGiderilen Riskler Diğer Riskler ,[object Object],[object Object]

İterasyon Süreci ,[object Object]

Model, kod ve test kayıtları İterasyon Planı Gereksinimlerin Sapt. Analiz + Tasarım Uygulama Test Release Release raporu Yeni Risk Raporu Konfigürasyon Denet.

Adapte Olabilen bir Süreç: UP Rational Stratejik Hizmetler Biriminde baş danışman. Uzmanlık alanları: ,[object Object]

Sistem Mühendisliği Süreçleri

LiderlikSoftware Leadership: A Guide to Successful Software Development Murray Cantor 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ı Sözde Sonuçlar Gerçek Sonuçlar ,[object Object]

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.

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. ,[object Object]

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.

Paradoks Yapı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çerisindeeksiksizleşmesi ve detay seviyelerinin artması.

Yazılım Problemi: İki nokta arasındaki en kısa yol Buradan Buraya Nasıl gideceğiz? Düşündüğümüz Güzergah Müşteriyi Tatmin Edebilecek Alan ,[object Object]

Katmadeğer: Yazılım Geliştirici (kar, deneyim, satış, Pazar payı vs.)Projenin ilk Durumu ,[object Object]

Elemanlar, kabiliyetleri, bilgileri

Belirsizlikler,[object Object]

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. Planlanan Proje Bitişi Planlanan Güzergah Gerçek Güzergah ‘Waterfall’Yönetimi: “Planla ve Takip Et” Müşteriyi Tatmin Edebilecek Alan Projenin ilk Durumu Gerçek Proje Bitişi

İteratif Yaklaşımda Liderlik: “Manevra Yap ve Adapte Ol” Gerçek Güzergah Devamlı olarak : Resmin geneline hakim ol – Proje yönelik istek değişikliklerini değerlendir Manevra 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? Gerçek Proje Bitişi Planlanan Proje Bitişi Planlanan Güzergah Müşteriyi Tatmin Edebilecek Alan Projenin ilk Durumu

Bir iş Bir rol Activity (Faaliyet) Role (Çalışan) Artifact (Oluşanlar) Sürecin oluşturduğu, kullandığı veya değiştirdiği bir ürün Use case UP’in 3 Temel Parçası Use Case’leri tanımla Analist sorumluluğu Use case paketi

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.

Discipline ve Workflow Disiplin: Gereksinim Yönetimi Workflow: Gereksinim Yönetimine ait çalışma şekli detayları

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”

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.

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” X X X

SPEM Gösterimi“Yapılanlar”

SPEM Gösterimi“Üretilenler”

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

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

Süreç Haritası“Unified Process”

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

Mehmet = Veritabanı Tasarımcısı

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”

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

7. Bakım“Problem Türleri”

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

İlham Kaynakları Philippe Kruchten Watts Humphrey ? Murray Cantor Sizin Adınız Terry Quatrani James Bach James Rumbaugh Grady Booch Ivar Jacobson

İç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

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 Daha detaylı Müşterinin probleminin tanımı İhtiyaç İşlev Çözümün tanımı Gereksinim Çözümün gerçekleştirilmesi Gerçekleştirme

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

Altı Ekip Yeteneği Problem analizi Müşteri ihtiyaçlarını anlama Sistemi tanımlama Sistem kapsamını yönetme Sistem tanımının revize edilmesi 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?

Problemler ve Fırsatlar Sistemlerin en önemli iki nedeni: Problem çözmek; mevcut sistem müşteri ihtiyaçlarını karşılamıyor demek 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: Problem tanımı üzerinde anlaşmak Problemin temel nedenlerini anlamak Paydaş ve kullanıcıları tespit etmek Sistemin sınırlarını tespit etmek Çö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?

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 2Probleminnedenlerinianlamak

2Probleminnedenlerinianlamak ‘Akıl haritası’ (mindmap) çizebiliriz 12 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

4-5Sistemin sınırlarını tespit 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

4-5Sistemin sınırlarını tespit 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

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”

VizyonDokümanı GelenekselSRS EkGereksinimler Use-Case Modeli Senaryo Odaklı Gereksinim Yönetimi İhtiyaçlar İşlevler Senaryo Odaklı Yol Geleneksel Yol Gereksinimler = + Geleneksel Software Requirements Specification (SRS) dokümanı Use Case Modeli ve Ek Gereksinimler Dokümanına (Supplementary Requirements) karşılık gelmektedir.

Ek Gereksinimler (Supplementary Specification) Proje Sözlüğü (Glossary) Gereksinim Ürünleri (Artifact) Use Case Modeli Aktörler Use Case’ler ... Use-Case Dokümanları

İ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ı

Gereksinim Ürünleri (Artifact) Use Case Şemaları

Gereksinim Ürünleri (Artifact)

[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

[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ışı ,[object Object]

Birden fazla Alternatif Akış:

Başarılı alternatif akışlar

Başarısız Akışlarhata 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ı TemelAkışı’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)

5. Alternatif Akışlar 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

5. Alternatif Akışlar 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ı – Geriye Kalan

[3]Ek Gereksinimler: FURPS+ Modeli Ek Gereksinimlerin kapsamı: ,[object Object]

Kullanılabilirlik (Usability)

+ = geriye kalan herşey,[object Object]

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ı)

[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

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ı Configuration Management Plan Requirements Management Plan

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

2. İterasyonların Belirlenmesi

3. İterasyonların Belirlenmesi Sistem Mimarisini Etkileyen UC’ler İterasyon 1 İterasyon 2 İterasyon 2

İlham Kaynakları James Bielak Ellen Gottesdiener Alistair Cockburn ? Sizin Adınız

Analistler için Modelleme Bölüm 1 / 6

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.

İç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 (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 (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 (Ç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

Kullanıcı Her abstraction bir hiyerarşi oluşturur. 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

Class’lar ve Nesneler ali meltem özellikler/benzerlikler?

Class’lar ve Nesneler ali meltem yaş cinsiyet ad soyad

Class’lar ve Nesneler iki FARKLI kişi ali meltem yaş : 25 cinsiyet : erkek ad : ali soyad : turalı yaş : 23 cinsiyet : kadın ad : meltem soyad : manisalı

Class’lar ve Nesneler yaş cinsiyet ad soyad Değişkenler/ özellikler nesne ali meltem yaş : 25 cinsiyet : erkek ad : ali soyad : turalı yaş : 23 cinsiyet : kadın ad : meltem soyad : manisalı

Class’lar ve Nesneler Değişkenler/ özellikler ??? Diğer nesneler:

Class’lar ve Nesneler isim başkent nüfus paraBirimi Değişkenler/ özellikler Diğer nesneler: Avustralya İngiltere İtalya

Class’lar ve Nesneler Tüm nesneler Bu nesneleri birbirlerinden nasıl ayıracağız?

Class’lar ve Nesneler yaş cinsiyet ad soyad isim başkent nüfus paraBirimi Kişi Ülke Ortak değişkenler

“yenibirkişi” ? “hangideğişkenler?” Class’lar ve Nesneler yaş cinsiyet ad soyad Değişkenler/ özellikler Kişi(ler) ali meltem yaş : 23 cinsiyet : kadın ad : meltem soyad : manisalı yaş : 25 cinsiyet : erkek ad : ali soyad : turalı

“yenibirkişi” Class’lar ve Nesneler yaş cinsiyet ad soyad Değişkenler/ özellikler Kişi(ler) ali meltem yaş : 23 cinsiyet : kadın ad : meltem soyad : manisalı yaş : 25 cinsiyet : erkek ad : ali soyad : turalı yaş cinsiyet ad soyad

Class’lar ve Nesneler Kişi yaş cinsiyet ad soyad Nesne tabanlı terminoloji class (instance)variables attributes fields

Class’lar ve Nesneler yaş cinsiyet ad soyad Kişi instances ali meltem yaş : 23 cinsiyet : kadın ad : meltem soyad : manisalı yaş : 25 cinsiyet : erkek ad : ali soyad : turalı Nesneler

Class’lar ve Nesneler İngiltere Nesneler ali Bir nesnenin özellikleri nelerdir? isim : ingiltere Başkent : Londra Nüfus: 3,534,209 paraBirimi : Pound } yaş : 25 cinsiyet : erkek ad : ali soyad : turalı ? } ? yaş : 23 cinsiyet : kadın ad : meltem soyad : manisalı } ? meltem

Class’lar ve Nesneler kimliği kimliği İngiltere Nesneler ali Bir nesnenin özelliklerini ne belirler? isim : ingiltere Başkent : Londra Nüfus: 3,534,209 paraBirimi : Pound } yaş : 25 cinsiyet : erkek ad : ali soyad : turalı state } state yaş : 23 cinsiyet : kadın ad : meltem soyad : manisalı } state kimliği meltem

Class’lar ve Nesneler Nesne Nesnenin sahip olduğu özellikler State: Durum Identity: Kimlik

Class’lar ve Nesneler Nesneler Değişebilir Benzersiz State / Durum Identity / Kimlik

Class’lar ve Nesneler {Orta Yaş} {Yetişkin} Benzersiz Identity / Kimlik yaş : 25 cinsiyet : erkek ad : ali soyad : turalı yaş : 45 cinsiyet : erkek ad : veli soyad : kara State / Durum aynı da olabilir farklı da

İç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 “Bir Model bir Sistemin vazgeçilmez özelliklerini gösterir.” Dr. James Rumbaugh Sipariş Ürün Kargo İş Akışı Görsel Tasarım standartlaşmış sembolleri kullanarak tasarım yapmaktır

Görsel tasarımın faydaları ,[object Object]

TekrarKullanabilmek,[object Object]

İletişimi Kolaylaştırmak Birlikteçalışmasıgerekenbuikitakımçoğuzamanfarklıkelimehazneleriyüzündenanlaşamıyor. GörselTasarımdaUMLkullanımımüşterinindünyasıylasistemindünyasınıbirbirinebağlar Programcılar bu gereksinimlere dayanarak sistemi oluştururlar İş Analistleri sistemin gereksinimlerini belirlerler

Proje Kontrolünü Artırmak Sistemleryüzlercehattabinlerceclass’danoluşabiliyor. Buclassgruplarısistemebakankişininihtiyacınagöreorganizeedilebilmeli. GörselTasarımsistemefarklıyönlerdenbakabilmeyisağlar.

Sistem Mimarisi Oluşturmak GörselTasarımoluşançözümükullanılanprogramlamadilindenbağımsızhalegetirir. Programlamadilibelirlenincetasarımfizikiortamataşınır.

Tekrar Kullanabilmek Farklı Sistemler Tasarımınızıbileşenlerebölerekçözümünüzünparçalarınıtekrarkullanabilirsiniz. Bileşenler

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

Modeller ve Şemalar Bir model bir sistemin Belli bir açıdan eksiksiz olarak Ifade edilebilmesini sağlar State Diagrams State Diagrams Class Şeması Use Case Diagrams Use Case Diagrams State Diagrams Use Case Şeması State Diagrams Use Case Diagrams Object Şeması Use Case Diagrams Sequence Şeması Scenario Diagrams State Diagrams Scenario Diagrams State Diagrams Component Şeması Collaboration / Communication Şeması Model Component Diagrams Scenario Diagrams Component Diagrams Scenario Diagrams Deployment Şeması Statechart / State Machine Şeması Activity Şeması

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ğinbasitleştirilmişbirifadesi, SisteminveyaSürecinkavramsaldüzeydeanlaşılmasıdır

Model Kullanımı Gereksiz Zaruri F-15 Kağıttan Uçak

Model Kullanımı BilişimTakımlarıF-15’lerikağıttanuçakyaklaşımıylaoluşturabileceklerinizannedebiliyor. GereksinimlerdenKodlamayageçiş Dahauzunçalışmak,sistemmimarisiodaklıolmayankodyazmak EsnekbirSistemMimarisiolmaması 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ı Modelprobleminasılçözeceğinizibelirler. Hermodelfarklıdetayseviyelerindekullanılabilir. Modelçözümünkullanılacağıdünyadankopmamalıdır. Çözümeyöneliktekbirmodelyetersizdir

4 Model Kuralı Modelprobleminasılçözeceğinizibelirler. Oluşturacağınızmodelproblemeveçözümeyaklaşımınızıbelirler. Seçilenmodelbiranlamdünyasıoluşturur Heranlamdünyasısizibaşkabirçözümeyöneltir

4 Model Kuralı Hermodelfarklıdetayseviyelerindekullanılabilir 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.

4 Model Kuralı Modelçözümünkullanılacağıdünyadankopmamalı Modelgerçekçiolmalı Gerçekyerinegörebirkullanımsenaryosu,yerinegörebirsistemkısıtlamasıolabilir.Dolayısıylamodelfarklıreferanslarıbarındırabilmelidir. Gerçeğibasitleştirmeli Riskliunsurlarıişaretetmeli

4 Model Kuralı Çözümeyöneliktekbirmodelyetersizdir Sistemlerbirbirlerikötüolaraketkilemeyenfarklımodellerleincelenmeli. Birbirlerindenbağımsızolarakoluşturulabilen,incelenebilenfakatbirbirleriylealakalıolanmodelleroluşturulmalıdır Modellerinfarklıreferansları,oluşturulmanedenlerivekullanıcılarıolmalıdır.

Kullanıcı İşlevsellik SistemMimarı Performans Sisteme4+1Bakışı Logical View Implementation View Analiz /Tasarım Kod Versiyonlar Use-Case View Process View Deployment View Topoloji kurulum, kullanım

Fallingwater: http://www.casas.com/architect/franklloydwright/fallingwater000.html UML Sonrası Frank Lloyd Wright

UML’in Sınırları Takım Üyeleri Dil Kullanılan Süreç

UML’in Yarattığı İş Fırsatları Ken Ishiwata 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

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ı Max Goff Eğitimimizin sonunda açık kaynak kodlu bir projeyi UML modelinize çekin ve inceleyin: www.sourceforge.net “Zero Dollar Bill”

İç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.

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ı ,[object Object]

Yeni özellikler (property) tanımlayabilmek,

Yeni semantik yapılar oluşturabilmek için kullanılır.Genişletme mekanizmaları dörde ayrılır: ,[object Object],[object Object]

Stereotype «button» CancelButton Stereotype ikon gösterimi Stereotype etiket gösterimi  CancelButton state Stereotype kullanım şekli: ,[object Object],Stereotype adını «» işaretleri arasına koyunuz: (Örneğin, «node») ,[object Object],[object Object]

Size Ait İşaretler“UML in Color” Peter Coad (TogetherSoft) entity class’larının da kendi aralarında gruplara ayrılması gerektiğini söyler: <<Thing>> <<Description>> <<Role>> <<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 ,[object Object]

Sahiplik (telif hakkı kanıtı)

vs. vs.,[object Object],[object Object]

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}

Notlar Abstraction-occurrence pattern 1..* Title Copy Oluşturulan modellere eklenen daha detaylı açıklamalardır ,[object Object],Not ikonu içine yazılan yazılardır

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

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ırUML Metamodel

UML Profilleri UML Profilleri özel konulara yönelik UML modelleri geliştirebilmemizi sağlarla ,[object Object],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: ,[object Object]

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

Mevcut kurallara yeni ekler tanımlanır

Yeni bir semantik yapı tanımlanır ,[object Object]

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

GUI Profili GUI Profili Class Association <<stereotype>> Form <<stereotype>> Button <<stereotype>> Contains <<stereotype>> Invokes <<stereotype>> DialogBox Class ve Association UML metamodelinden gelmektedir

GUI Profili Uygulaması <<Form>> MainView 1 1 <<Invokes>> <<DialogBox>> OpenDialogBox 1 1 <<Contains>> <<Contains>> 1 1 <<Button>> OkButton <<Button>> CancelButton

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

Use Case Bulma Teknikleri 2 Event Table Çalışması:

Use Case Bulma Teknikleri 3 Aktörler Adaylarını Bulun Event Table Çalışmasını Yapın Aktör ve Use Case’leri Belirleyin Aktörleri Çizin ve İlişkilerini Düşünün Use Case’leri Çizin ve Aktörlere Bağlayın 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.)

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ızgerekmektedir. 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 Şema İçeriği Şemayla Aktarılan Bilgiler Tasarım Teknikleri Forward ve Reverse Engineering

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

Activity Şeması Sembolleri 4 Sembol Tanımı Syntax Object ‘Elle tutulabilir’ nesnelerdir. OrderItem ObjectFlow Object’i girdi ve çıktı olarak faaliyet ve komutlara bağlamaya yarar.

Activity Şeması Örnekleri 2

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 Şema İçeriği Şemayla Aktarılan Bilgiler Tasarım Teknikleri Forward ve Reverse Engineering

Temel Kavramlar 3 Action ve Output:

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

Temel Kavramlar 5 Bir 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.

Yapısal Şemalar class şeması* package şeması* composite structure şeması object şeması component şeması deployment şeması

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

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.

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.

Temel Kavramlar Generalization: Farklı ‘abstraction’ seviyeleri arasında ırsiyet ilişkileri kurmak için kullanılır.

Temel Kavramlar Polymorphism: implementasyonun detaylarını gizleyerek kolay kullanımı sağlar. Aynı isme sahip fakat farklı çalışan fonksiyonları ifade eder.

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.

İlgili Roller Şemayı Hazırlayanlar: Tasarımcı Programcı Şemayı Kullananlar: Tasarımcı Programcı

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 Şema İçeriği Şemayla Aktarılan Bilgiler Tasarım Teknikleri Forward ve Reverse Engineering

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.

İlgili Roller Şemayı Hazırlayanlar: Herkes Şemayı Kullananlar: Herkes

Paket Şeması Örnekleri Müşteri Sipariş Yer CD Sipariş Stok Satış Depo

Ş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.

İç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 Tanım elemanları Gerçekleştirme elemanları Bir modül bir sistemin hem tanımlanma hem de gerçekleştirilme aşaması çalışmalarını içerir.

Modülün Gerçekleştirilmesi Tanım elemanları Gerçekleştirme elemanları ? Gerçekleştirme elemanları subsytem’in içeriğini gösterir. Modül gerçekleştirilmesi genellikle class’lar ve ilişkilerini içerir.

Modül Tanımlanması Tanım elemanları Gerçekleştirme elemanları ? Modül tanımı modülün dışarıdan nasıl görüldüğü belirtir

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ı

Gerçekleştirme elemanları Tanım elemanları 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ı Realization elements Change Digit Analysis Information Operator Initiate Call Trunk Receive Digit and Connect Hook Signal and Disconnect Subscription Çağrı Kontrol Tanım elamanları

Stopped Running Maintenance Exhausted Error 2. State Machine Yaklaşımı Çağrı Kontrol Tanım elemanları 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

Number Dictionary Analyzer Network Manager 3. Mantıksal Class Yaklaşımı Çağrı Kontrol Tanım elemanları Modülün kullanımı nesnelerin manipülasyonu olarak görülüyorsa Gereksinimler belli bir standarda uyum zorunluluğundan kaynaklanıyorsa

initiateConnection (…) dialledDigit (…) throughConnect (…) bAnswer (…) bOnHook (…) aOnHook (…) 4. Metod Yaklaşımı Çağrı Kontrol Metodlar Basit (atomic) hizmetler veren modüller için Metodlar birbirlerinden bağımsız olarak çağrılıyorlarsa

Tekniklerin Kombinasyonları Initiate Call Trunk Receive Digit and Connect Hook Signal and Disconnect Subscription Çağrı Kontrol Specification elements Metodlar changeDigitAnalysisInformation (...) Tanım elemanları

Operations Gerçekleştirme elemanları Metodlar Tanım elemanları Eksiksiz Modül Notasyonu Üç tanımlı parçadan oluşur Bu parçalar isteğe bağlı olarak kullanılmayabilir

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)

«realize» Metodlar Gerçekleştirme elemanları operation1( ) : Type1 operation1( ) operation2( ) : Type2 operation3( ) : Type3 operation4( ) : Type4 operation5( ) : Type5 Gerçekleştirme İlişkisi Gerçekleştirme (Realization) özellikle tek seviyeli ilişkileri göstermekte faydalı

Gerçekleştirme İlişkisi «realize» Trafik Kontrol Gerçekleştirme elemanları Metodlar changeDigitAnalysisInformation ( ) Tanım elemanları Initiate Call changeDigitAnalysisInformation ( ) : : Trunk Receive Digit and Connect Hook Signal and Disconnect Subscription

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 Sequence Şeması Collaboration Şeması 2: dialledDigit :Trunk :Subscription :Traffic Control :Traffic Control markBusy dialledDigit 4: throughConnect dialledDigit :Trunk throughConnect markBusy :Subscription bAnswer 1: markBusy Bir ‘collaboration’ bir iş yerine getirilirken gereken rolleri tanımlar Bu roller birbirleriyle etkileşen nesneler aracılığıyla canlandırılır 3: dialledDigit 6: bAnswer 5: markBusy

Collaboration Notasyonu Collaboration Rol adı Rol adı Rol Rol adı Rol adı Class Bir birliktelik (collaboration) ve katılımcıları

Tanım elemanları Gerçekleştirme elemanları Initiate Call Network Interface Receive Digit and Connect Coordinator Analysis Database Hook Signal and Disconnect Collaboration Collaboration genellikle daha karmaşık durumlarda faydalıdır

Collaboration Çeşitleri Rol modeli bir özel durumu ifade ederken Class modeli daha genele yönelik. Dolayısıyla her Class modeline karşılık birden fazla Rol modeli olacaktır.

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

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)

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

Model Use Case Modeli Tasarım Modeli

Model Sembolleri Sistemi belli muhataplara onlara özel detay seviyesiyle sistemin ilgili yönlerinin gösterilmesidir. İsim 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» Sembol Tanım Syntax Model Trace

Trace Analiz Tasarım «trace»

Model / Şema Şemalar modeli dokümante eder Use Case Modeli 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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

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

Similar to Analist Eğitimi - Tüm Bölümler - [535 Slides] (20)

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