3. 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ığı.
4. 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.
5. 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
19. 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!
20. 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.
22. 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 ...
23. 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.
24. 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.
25. 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.
37. İç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ı
39. 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ı
40. 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
41. 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
42. 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
46. 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ı
47. 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”
48. İç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ı
49.
50.
51. 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
64. Model, kod ve test kayıtları İterasyon Planı Gereksinimlerin Sapt. Analiz + Tasarım Uygulama Test Release Release raporu Yeni Risk Raporu Konfigürasyon Denet.
69. 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 ...
81. 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.
82. 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ı.
89. 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
90. İ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
91. İç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ı
92. 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
93. 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.
106. 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.
107. İç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ı
108. 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.
114. İç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ı
124. 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
131. İç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ı
143. İç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ı
144. 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.
162. İç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
163. 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
164. 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)
165. 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
166. 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
167. İç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
168. 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
169. 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
171. 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
172. 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?
173. Ö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.
174. 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ş)
175. 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
176. 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
177. 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
178. İç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
179. 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
181. 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
182. 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?
183. 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?
184. 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ı
185. 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?
186. İç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
187. 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
188. 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
189. 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?
190. 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
192. 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
193. 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
194. 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
195. 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
196. İç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
197. 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
198. 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
199. İş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)
200. 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!
201. İ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
202. İş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
203. İş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}
204. İş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?
205. İşlevler ve Gereksinimler Üst seviye gereksinimler: İşlevler “features” Fonksiyonel gereksinimler “functional requirements” Fonksiyonel olmayan gereksinimler “supplementary requirements”
207. İç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
208. 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.
209. Ek Gereksinimler (Supplementary Specification) Proje Sözlüğü (Glossary) Gereksinim Ürünleri (Artifact) Use Case Modeli Aktörler Use Case’ler ... Use-Case Dokümanları
210. İ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ı
213. [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
214. 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.
215. 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
224. [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ı.
229. Senaryo Nedir? Bir senaryo use case’in içerdiği akışların bir kombinasyonunun başlayıp bitişidir: Use Case Instance.
230. 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
231. 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
232. 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.
233. 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
234. 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*
235. 1. Use Case Tanımı İlişkili Use Case’ler Ek Gereksinimler İş Kuralları Kullanım Yoğunluğu Açık Konular
236. 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.
237. 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
238. 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.
239. 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)
240. 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
241. 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.
242. 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
243. 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?
244. 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
245. 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.
246. 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
247. 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.
248. Bid on Item - Use Case Dokümanı İnternette Açık Artırma
259. 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?
260. 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
261. 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)
262. 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?
264. “+” - İ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)
265. “+” - 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.)
266. “+” - 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)
267. “+” - 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ı?
268. “+” - 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ı)
271. [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
272. İç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
273. 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.
289. 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ığı.
290. 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.
291. 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
298. 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
300. 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
302. 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
304. 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
306. 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
310. 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ı
311. 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ı
315. Class’lar ve Nesneler yaş cinsiyet ad soyad isim başkent nüfus paraBirimi Kişi Ülke Ortak değişkenler
316. “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ı
317. “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
318. Class’lar ve Nesneler Kişi yaş cinsiyet ad soyad Nesne tabanlı terminoloji class (instance)variables attributes fields
319. 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
320. 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
321. 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
322. Class’lar ve Nesneler Nesne Nesnenin sahip olduğu özellikler State: Durum Identity: Kimlik
323. Class’lar ve Nesneler Nesneler Değişebilir Benzersiz State / Durum Identity / Kimlik
324. 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
328. Görsel Tasarım Bir sistemin verdiği bir hizmeti nasıl gerçekleştirdiğinin görsel olarak ifade edilmesidir.
329. 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).
330. 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
337. Proje Kontrolünü Artırmak Sistemleryüzlercehattabinlerceclass’danoluşabiliyor. Buclassgruplarısistemebakankişininihtiyacınagöreorganizeedilebilmeli. GörselTasarımsistemefarklıyönlerdenbakabilmeyisağlar.
338. Sistem Mimarisi Oluşturmak GörselTasarımoluşançözümükullanılanprogramlamadilindenbağımsızhalegetirir. Programlamadilibelirlenincetasarımfizikiortamataşınır.
339. Tekrar Kullanabilmek Farklı Sistemler Tasarımınızıbileşenlerebölerekçözümünüzünparçalarınıtekrarkullanabilirsiniz. Bileşenler
340. 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
343. 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ı
344. 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
348. 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.
349. 4 Model Kuralı Modelprobleminasılçözeceğinizibelirler. Hermodelfarklıdetayseviyelerindekullanılabilir. Modelçözümünkullanılacağıdünyadankopmamalıdır. Çözümeyöneliktekbirmodelyetersizdir
350. 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
351. 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.
352. 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
353. 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.
354. 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
358. 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
359. 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.
360. 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
361. İlham Kaynakları Max Goff Eğitimimizin sonunda açık kaynak kodlu bir projeyi UML modelinize çekin ve inceleyin: www.sourceforge.net “Zero Dollar Bill”
366. 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.
367. 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
368. 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.
374. 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>>
380. 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}
381.
382. 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
393. ButonlarKısıtlamalar: Bir form bir ‘dialog box’ı çalıştırabilir Formlar ve Dialog Box’ların butonları olabilir
394. GUI Profili GUI Profili Class Association <<stereotype>> Form <<stereotype>> Button <<stereotype>> Contains <<stereotype>> Invokes <<stereotype>> DialogBox Class ve Association UML metamodelinden gelmektedir
398. Davranış Şemaları use case şeması* activity şeması* Etkileşim Şemaları sequence şeması collaboration / communication şeması interaction overview timing şeması statechart / state machine şeması*
399. Use Case Şeması Temel Kavramlar Şema İçeriği Şemayla Aktarılan Bilgiler Tasarım Teknikleri Forward ve Reverse Engineering
400. 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.
401. 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
403. İ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
411. 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
412. 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ı?
413. 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?
414. Use Case ŞemasıEgzersiz # 1 Lütfen şemadan anladıklarınızı bir paragrafta özetleyiniz (10 dk.)
415. 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.“
416. Activity Şeması Temel Kavramlar Şema İçeriği Şemayla Aktarılan Bilgiler Tasarım Teknikleri Forward ve Reverse Engineering
417. 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.
418. İ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ı
422. 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.
427. 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.
428. Statechart Şeması Temel Kavramlar Şema İçeriği Şemayla Aktarılan Bilgiler Tasarım Teknikleri Forward ve Reverse Engineering
436. İlgili Roller Şemayı Hazırlayanlar: Sistem Analisti Tasarımcı Programcı Şemayı Kullananlar: Sistem Analisti Tasarımcı Programcı
437. 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.
441. Class Şeması Temel Kavramlar Şema İçeriği Şemayla Aktarılan Bilgiler Tasarım Teknikleri Forward ve Reverse Engineering
442. 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.
443. 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.
444. 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.
445. Temel Kavramlar Değişkinler ‘private’ Metodlar ‘public’ Hepsi küçük harfle başlar ve kelimeler bitişik yazılır.
446. 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: ‘-’
449. Temel Kavramlar Polymorphism: implementasyonun detaylarını gizleyerek kolay kullanımı sağlar. Aynı isme sahip fakat farklı çalışan fonksiyonları ifade eder.
450. 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.
451. 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.
457. 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. ”
458. Package (Paket) Şeması Temel Kavramlar Şema İçeriği Şemayla Aktarılan Bilgiler Tasarım Teknikleri Forward ve Reverse Engineering
459. 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.
464. Ş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.
465. Ş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.
468. İçerik Modüllerin Yapısı Modül Tanımlama Teknikleri Modül Gerçekleştirme Teknikleri Modellerin Yapısı Modellerin İlişkileri
469. 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.
470. 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.
471. 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.
473. İçerik Modüllerin Yapısı Modül Tanımlama Teknikleri Modül Gerçekleştirme Teknikleri Modellerin Yapısı Modellerin İlişkileri
474. 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
475. Tanımlama Teknikleri Use Case yaklaşımı State Machine yaklaşımı Mantıksal Class yaklaşımı Metod Yaklaşımı … ve bunların kombinasyonları
476. 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ı
477. 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ı
478. 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
479. 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
480. 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
481. Tekniklerin Kombinasyonları Initiate Call Trunk Receive Digit and Connect Hook Signal and Disconnect Subscription Çağrı Kontrol Specification elements Metodlar changeDigitAnalysisInformation (...) Tanım elemanları
482. 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
483. İçerik Modüllerin Yapısı Modül Tanımlama Teknikleri Modül Gerçekleştirme Teknikleri Modellerin Yapısı Modellerin İlişkileri
484. 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)
485. «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ı
486. 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
487. 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.
488. 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
491. 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
492. 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.
499. 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
500. 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)
501. İçerik Modüllerin Yapısı Modül Tanımlama Teknikleri Modül Gerçekleştirme Teknikleri Modellerin Yapısı Modellerin İlişkileri
502. Model Bir model sisteme belli nedenden dolayı farklı bir bakış şeklidir. Oluşturulma amacına uygun şekilde dokümantasyona ve detay seviyesine sahiptir.
504. 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
506. Model / Şema Şemalar modeli dokümante eder Use Case Modeli Tasarım Modeli
507. 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
508. Model Oluşturma Teknikleri Her modelin amacını tanımlayınız Her model amacına uygun şekilde sistemin eksiksiz bir resmini çizmelidir