YZM211 YAZILIM TASARIMI

Transkript

1 BÖLÜM 7 STATİK ORTA-DÜZEY NESNE YÖNELİMLİ TASARIM: SINIF MODELLERİ YZM211 YAZILIM TASARIMI Yrd. Doç. Dr. Volkan TUNALI Mühendislik ve Doğa Bilimleri Fakültesi / Maltepe Üniversitesi

2 GENEL BAKIŞ 2 KISIM 1 İleri Düzey UML Sınıf Diyagramları SECTION 2 Ayrıntılı Tasarıma Giriş ve Orta-Düzey Sınıf Modelleme

3 KISIM 1 3 İleri Düzey UML Sınıf Diyagramları

4 Amaçlar 4 UML sınıf diyagramı notasyonlarında henüz değinilmemiş kısımları sunmak Yeni notasyonun kullanımıyla ilgili örnekler vermek Notasyonun iyi kullanılmasına yönelik sezgisel bazı kurallar sunmak

5 İçerik 5 Genelleştirme (Generalization) Soyut (abstract) ve somut (concrete) operasyonlar ve sınıflar Arabirimler (interface) Özellik görünürlüğü (feature visibility) Sınıf ve örnek değişkenleri ve operasyonları Agregasyon (aggregation) ve kompozisyon (composition) İlişki (association) sınıfları Sınıf diyagramları için sezgisel kurallar

6 Genelleştirme (Generalization) 6 Genelleştirme (generalization) bir model elemanıyla (ebeveyn parent) diğeri (çocuk child) arasındaki ilişkiyi belirten bir UML yapısıdır. Çocuk, özel bir ebeveyn türüdür. İçi boş üçgen ve çizgilerle temsil edilir. Üçgen ebeveyne bağlanır, çizgiler ise çocuğa. Genelleştirme UML sınıf diyagramlarında kalıtımı (inheritance) modellemek için kullanılır.

7 Genelleştirme Örneği 7 Mammal Quadruped Feline Lizard Tiger Lion Puma

8 Genelleştirme ya da İlişki (Association) 8 Genelleştirme sınıflar arasındaki bir ilişkidir. İlişki (association) ise ilişkilendirilmiş sınıfların örnekleri arasındaki ilişkiyi temsil eder. Genelleştirme bir ilişki (association) çeşidi değildir. Çoklukları yoktur, Rol isimleri yoktur, İsimleri yoktur (zaten adı genelleştirme dir).

9 Soyut (Abstract) Operasyonlar ve Sınıflar 9 Soyut operasyon (abstract operation) gövdesi/içeriği olmayan operasyondur; somut operasyon (concrete operation) ise gövdesi/içeriği olan operasyondur. Soyut sınıf (abstract class) kendisinden nesne yaratılamayan yani örneği (instance) oluşturulamayan sınıftır; somut sınıf ise örneği oluşturulabilen sınıftır. Bir sınıf Soyut bir operasyon içeriyorsa mutlaka soyut olmalıdır; Hiç soyut operasyonu olmasa bile kendisi soyut olabilir.

10 10 Soyut Sınıf ve Operasyonların Kullanımı ve Temsili Soyut sınıflar kendi alt sınıflarını belirli operasyonları implemente etmeye zorlarlar. Soyut sınıflar UML de şu şekilde gösterilir: İsimleri italik yazılarak, «abstract» ile stereotiplenerek, veya {abstract} özelliği verilerek. Soyut operasyonlar UML de şu şekilde gösterilir: Spesifikasyonları italik yazılarak, veya {abstract} özelliği verilerek.

11 Soyut Sınıf ve Operasyon Örnekleri 11 «abstract» Shape areaof() : float { abstract } Renderer render() Document { abstract } callnumber descriptors : String[*] Circle ScreenRenderer Book

12 Arabirimler (Interfaces) 12 Bir UML arabirimi (interface) public tanımlı özellik (attribute) ve soyut operasyonların bir koleksiyonudur. Sağlanan (provided) arabirim bir sınıf veya bileşen tarafından gerçeklenir Bir top veya lolipop sembolüyle temsil edilir, veya Bir gerçekleme konnektörüne (realization connector) sahip stereotipli bir sınıf sembolüyle temsil edilir Gereksinilen (required) arabirim Bir sınıf veya bileşen tarafından ihtiyaç duyulur Bir soket sembolüyle temsil edilir, veya Top sembolüne bir bağımlılık okuyla temsil edilir, veya Stereotipli sınıf sembolüne bir bağımlılık okuyla temsil edilir

13 Sağlanan Arabirim Notasyonları 13

14 Gereksinilen Arabirim Notasyonları 14

15 Modül Montaj Notasyonları 15 Timer Timer «interface» Observer update( arg : Object ) Observer TimerObserver TimerObserver

16 UML Özellik Görünürlüğü (Visibility) 16 Public İçinde yer aldığı sınıfın görünür olduğu her yerde görünürdür; + ile belirtilir. Package İçinde yer aldığı sınıfı içeren package içinde her yerde görünürdür; ~ ile belirtilir. Protected İçinde yer aldığı sınıfta ve onun tüm alt-sınıflarında görünürdür; # ile belirtilir. Private Yalnızca içinde yer aldığı sınıfta görünürdür; - ile belirtilir.

17 Özellik Görünürlüğüne Örnek 17 Alarm + identifier : String {constant} # location : String # description : String - classification : Classifier + getlocation() : String + getdescription() : String + action() ~ setclassification( c : Classifier) ~ getclassification() : Classifier # basicaction() FireAlarm IntrusionAlarm FloodAlarm

18 Sınıf ve Örnek Değişken & Operasyonları 18 Bir örnek değişkeni veya nesne değişkeni (instance variable), değeri ilgili sınıfın tüm örnekleri tarafından saklanan bir özelliktir. Bir sınıf değişkeni (class variable) yalnızca bir kez ve sınıfın kendisi tarafından saklanan ve sınıfın tüm örnekleri tarafından paylaşılan bir özelliktir. Bir örnek operasyonu veya nesne operasyonu (instance operation) yalnızca sınıfın bir örneği üzerinden çağrılabilir. Bir sınıf operasyonu (class operation) sınıf üzerinden çağrılabilir. UML de sınıf değişkenleri ve operasyonları static olarak adlandırılır. Bir özelliğin veya operasyonun spesifikasyonu altı çizili yapılarak belirtilir.

19 Özellik ve Operasyon Spesifikasyonu Örnek 19 Tokenizer - theinstance : Tokenizer + token : TokenType = NONE + tokentext : String - buffer : String - bufferposition : integer - delimiters : String + getinstance() : Tokenizer + nexttoken() + setbuffer( buffer : String ) + setdelimiter( delim : String ) TokenType + NONE : TokenType { constant } + NUMBER : TokenType { constant } + IDENTIFIER : TokenType { constant } + EQUAL : TokenType { constant } + MINUS : TokenType { constant } + PLUS : TokenType { constant } - name : String - TokenType( name : String ) + tostring() : String

20 Agregasyon ve Kompozisyon 20 Agregasyon ilişkisi (aggregation association) sınıflar arasındaki parça-bütün ilişkisini temsil eder. İçi boş elmas ve çizgiler ile gösterilir Elmas bütün e bağlanır, çizgiler ise parçalara İlişki (association) ile ilgili tüm süslemeleri içerebilir (ilişkinin yönü, ismi, çoklukları, vs.) Kompozisyon ilişkisi (composition association) ise herhangi bir anda her bir parçanın yalnızca bir tek bütün le ilişkilendirilebildiği bir agregasyondur. İçi dolu elmas ve çizgiler ile gösterilir

21 Agregasyon ve Kompozisyon Örnekleri 21 Human Church Family * 1..* Arm Leg Hand Foot 1..* Person 1..*

22 İlişki (Association) Sınıfları 22 Bir ilişki sınıfı (association class) birbirine bağladığı sınıfların örnekleri arasındaki bir ilişkiyi temsil eder, ve ayrıca ilişkiye özgü veri ve davranış barındırır. İlişki sınıfı bağlantısı kesik çizgiyle temsil edilir Sınıf bir ilişki çizgisiyle bağlanır İlişkilendirilmiş sınıflardan bir örnek çifti için yalnızca tek bir ilişki sınıfı örneği olabilir. Eğer daha fazla örnek gerekirse, aralarına yeni bir sınıf girmelidir (somutlaşan ilişki reified association).

23 İlişki Sınıfı Örneği 23 Medication * * Patient Prescription - date

24 Rol İsmi Görünürlüğü 24 İlişkiler (association) genellikle referanslar kullanılarak implemente edilir. Rol ismi bir referans özellik ismi olabilir Rol isimlerinin de görünürlük belirteçleri olabilir (+, #, ~, -). Rol isimlerinin görünürlük belirteçleri yazılmayabilir.

25 İlişki Ulaşılabilirliği (Navigability) 25 A ve B sınıfları arasındaki bir ilişkide eğer A sınıfının bir örneği B sınıfının bir örneğine erişebiliyorsa bu ilişki için A dan B ye gezilebilir/ulaşılabilir (navigable) denilir. Gezilebilirlik, ilişki çizgisine yönü A dan B ye olacak şekilde ok ucu eklenerek belirtilir. Gezilemezlik (non-navigability) ise ilişki çizgisinin diğer ucuna bir x (çarpı) konularak belirtilir. Gezilebilirlik işaretleri kullanılmayabilir; eğer hiç işaret yoksa diyagramdan gezilebilirlik hakkında bir çıkarım yapılamaz.

26 Rol İsmi Görünürlüğü ve Ulaşılabilirlik Örn. 26 Referee 1 * Game mygame 1..* - player Player

27 Sınıf Diyagramı Kuralları 1 27 Genelleştirme bağlantısı üzerine asla isim, rol ismi, veya çokluk yerleştirmeyin. Diyagramları elle çizerken soyut sınıf ve operasyonları belirtmek için «abstract» stereotipini ve {abstract} özelliğini kullanın; italik yazı tipini yalnızca bilgisayarda çizerken kullanın. Top ve soket arabirim sembollerini arabirimin ayrıntılarını soyutlamak için kullanın; stereotipli sınıf sembolünü ise arabirimin ayrıntılarını göstermek için kullanın.

28 Sınıf Diyagramı Kuralları 2 28 Arabirim veya operasyon isimlerini italik yazmayın. Sağlanan arabirimleri arabirim top sembolüyle veya stereotipli bir sınıf sembolü ve gerçekleme bağlantısıyla gösterin. Gereksinilen arabirimleri arabirim soket sembolüyle, veya stereotipli sınıf sembolüne veya arabirim top sembolüne bağlanmış bağımlılık oklarıyla gösterin. Agregasyon ve kompozisyondan uzak durun.

29 Özet 29 UML sınıf diyagramları şunların gösterimi için oldukça güçlü araçlardır: Generalization Abstract operations and classes Class and instance variables and operations Interfaces and interface assemblies Aggregation and composition associations Association classes Feature and rolename visibility Navigability

30 KISIM 2 30 Ayrıntılı Tasarıma Giriş ve Orta-Düzey Sınıf Modelleme

31 Amaçlar 31 Ayrıntılı tasarım sürecine giriş yapmak Ayrıntılı tasarım spesifikasyonlarını incelemek Orta-düzey ve alt-düzey tasarım arasındaki farkı ortaya koymak Orta-düzey sınıf tasarımları oluşturmak için kullanılabilecek teknikleri sunmak Orta-düzey tasarım için sezgisel bazı kurallar sunmak

32 İçerik 32 Ayrıntılı tasarımın kapsamı Orta- ve alt-düzey tasarım Ayrıntılı tasarım süreci ve spesifikasyonları Orta-düzey tasarım teknikleri Yaratımsal Dönüşümsel Orta-düzey tasarım kuralları Sorumluluk-güdümlü tasarım Kalıtım Delegasyon

33 Ayrıntılı Tasarımın Kapsamı 33 Mimariden kodlamaya kadar soyutlama düzeyleri Pek çok statik ve dinamik model Çok miktarda tasarım spesifikasyonu İki bölüme ayrılır: orta-düzey ve alt-düzey tasarım Ayrıntılı tasarım, mimari tasarım ve programlama arasındaki sınırlar oldukça bulanıktır

34 Orta-Düzey Tasarım 34 Orta-düzey tasarım, yazılımı derleme birimleri veya sınıflar gibi orta-boyutlu bileşenler, bunların özellikleri, ilişkileri, ve etkileşimleri düzeyinde belirleme aktivitesidir. DeSCRIPTR spesifikasyonu Tasarım kalıpları (Design patterns)

35 Alt-Düzey Tasarım 35 Alt-düzey tasarım en düşük soyutlama düzeyindeki küçük ayrıntıları tamamlama aktivitesidir. DeSCRIPTR spesifikasyonları + PAID Packaging Derleme birimleri, kütüphaneler, paketler, vb. içine kod yerleştirmek. Algorithms Bazen belirtilir. Implementation Görünürlük, erişilebilirlik, ilişkilerin gerçeklenmesi vb. Data structures and types Bazen belirtilir.

36 Ayrıntılı Tasarım Süreci 36 Detailed Design Process SRS, SAD : Problem Design Document : Solution SRS SAD Analyze SRS and SAD Generate/Improve Detailed Design Alternatives Evaluate Detailed Design Alternatives Select Detailed Design [else] [adequate detailed design] Finalize Design Design Document

37 Ayrıntılı Tasarım Dokümanı 37 Bir tasarım dokümanı (design document) bir SAD ve bir ayrıntılı tasarım dokümanından (detailed design document (DDD)) oluşur. DDD şablonu 1. Orta-Düzey Tasarım Modelleri 2. Alt-Düzey Tasarım Modelleri 3. Modeller Arası Eşleştirme 4. Ayrıntılı Tasarım Gerekçesi 5. Sözlük

38 Orta-Düzey Tasarım Oluşturma Teknikleri 38 Yaratımsal (Creational) Orta-düzey tasarım sınıf modellerinin baştan oluşturulması İşlevsel ayrıştırma (Functional decomposition) Kalite niteliğine göre ayrıştırma (Quality attribute decomposition) Tasarım temaları (Design themes) Dönüşümsel (Transformational) Başka bir modelin orta-düzey tasarım sınıf modeline dönüştürülmesi Benzer sistem Kalıplar veya mimariler Analiz modelleri

39 Tasarım Temalarından Oluşturma 39 Bir tasarım teması (design theme) tasarımda dikkate alınması ve çözümlenmesi gereken önemli bir problem, kaygı, veya konudur. Tasarım temaları bir tasarımın baştan oluşturulmasında esas teşkil edebilir.

40 40 Tasarım Teması Süreci SRS Theme-Based Decomposition SRS : Theme Source Class Diagram : Draft Model Write Design Story Design Story Identify Themes Themes Generate/Improve Candidate Classes Evaluate/Select Classes [else] [class discovery slows] Draw/Improve Class Diagram Class Diagram Evaluate Class Diagram [else] [diagram complete]

41 Tasarım Öykülerinin Analizi 41 Bir tasarım öyküsü (design story) yazarak başlayın: uygulamanın en önemli yönlerini vurgulayan kısa bir açıklama. Tasarım temalarını tespit etmek için tasarım öyküsünü çalışın. Temaları listeleyin İşlevsel temalar Kalite niteliğine bağlı temalar

42 Aday Sınıfların Oluşturulması 42 Temalardan aday sınıfları çıkartmak için beyin-fırtınası yapın; sınıfları ve sorumluluklarını listeleyin. Programın görevlerinden sorumlu varlıklar Aktörler Programın kendisiyle ilgili veri kaydettiği şeyler Yapılar ve koleksiyonlar Sınıfları rasyonelleştirin. Bulanık isimleri ve sorumlulukları olanları atın Örtüşen sorumlulukları olan sınıflar üzerinde yeniden çalışın Kapsam dışında şeyler yapan sınıfları atın

43 Taslak Sınıf Diyagramı Oluşturulması 43 Listedeki sınıfları çizin. Özellik, operasyon, ve ilişkileri ekleyin. Sınıf diyagramını rafine edin. Sınıfları tamlık (completeness) ve uyum (cohesion) açısından kontrol edin. Uygun düşen yerlerde süper-sınıflar yapın. Uygun düşen yerlerde tasarım kalıpları (design patterns) uygulayın.

44 Kavramsal Modelin Dönüştürülmesi 44 Aktörleri arabirim sınıflarına çevirin. Aktör etki alanı (domain) sınıfları ekleyin. Bir başlangıç sınıfı (startup class) ekleyin. Denetleyici ve koordinatör sınıfları dönüştürün ya da ekleyin. Veri tipleri için sınıflar ekleyin. Barındırıcı (container) sınıfları dönüştürün ya da ekleyin. Mühendislik tasarımı ilişkilerini dönüştürün ya da ekleyin.

45 Sorumluluklar 45 Bir sorumluluk bir görevi gerçekleştirme (operasyonel sorumluluk) ya da veri barındırma (veri sorumluluğu) gibi bir zorunluluktur. Operasyonel sorumluluklar genellikle operasyonlar tarafından yerine getirilir. Veri sorumlulukları genellikle özellikler (attribute) tarafından yerine getirilir. Sınıflar arası işbirliği (collaboration) de söz konusu olabilir.

46 Sorumluluk-Güdümlü Ayrıştırma 46 Sorumluluklar farklı soyutlama düzeylerinde ifade edilebilir. Sorumluluklar ayrıştırılabilir. Yüksek-düzeyli sorumluluklar üst-düzey bileşenlere atanabilir. Sorumlulukların ayrıştırılması bileşenlerin ayrıştırılmasının temel çıkış noktası olabilir. Sorumluluklar hem operasyonel hem de veri bazlı zorunluluklar olduğundan sorumluluk-güdümlü ayrıştırma işlevsel ayrıştırmadan farklı olabilir.

47 Sorumluluk Kuralları 1 47 Sorumlulukların doğru bir şekilde atanması yüksek uyum (cohesion) ve düşük bağlılık (coupling) elde edilmesine yardımcı olabilir. Hem operasyonel hem de veri bazlı sorumlulukları ifade edin. Modüllere en fazla bir operasyonel ve bir veri sorumluluğu atayın. Tamamlayıcı nitelikte veri ve operasyonel sorumluluklar atayın.

48 Sorumluluk Kuralları 2 48 Modül sorumluluklarının örtüşmediğinden emin olun. Operasyon ve verileri bir modüle yalnızca o modülün sorumluluklarının yerine getirilmesinde işe yarayacaksa ekleyin. Bir modüle sorumluluklarını yerine getirmesi için gereken tüm operasyonları ve verileri ekleyin.

49 Kalıtım (Inheritance) 49 Kalıtım (Inheritance) bir sınıf ve bir veya daha fazla süper-sınıf arasında tanımlanan bir ilişki şeklidir. Kalıtım nedeniyle alt-sınıf(lar) süper-sınıf(lar)ın tüm özellik ve operasyonlarına sahip olur. Sınıflar arasında genelleştirme (generalization) ilişkisi kalıtım ile sağlanır Süper-sınıftaki özellik ve operasyonların alt-sınıflar tarafından yeniden kullanımına olanak sağlar

50 Kalıtımın Uygun Şekilde Kullanılması 50 Kalıtımı yalnızca yeniden kullanım (reuse) için kullanmayın. Kafa karıştırıcıdır Kötü görünür Uzun dönemde problemlere neden olabilir Kalıtımı yalnızca sınıflar arasında genelleştirme (birtürü-olma) ilişkisi varsa kullanın. Yeniden kullanım genellikle sınıf yapısı üzerinde biraz daha çalışmakla elde edilebilir. Açık ve temiz Zarif Dayanıklı

51 Kalıtım Örneği 51 Scatterplot - title - xunits - yunits - xlabel - ylabel - xmin - ymin - xmax - ymax - data[*] Graph - title - xunits - yunits - xlabel - ylabel - xmin - ymin - xmax - ymax # setupgraph() # plotdata() + draw() setupgraph(); plotdata(); # setupgraph() # plotdata() + draw() Scatterplot - data[*] # plotdata() BarChart - numbins - bins[*] - binwidth # plotdata()

52 Delegasyon (Delegation) 52 Delegasyon (delegation) bir modülün (delege eden) diğer bir modüle (delege) bir sorumluluğun yerine getirilmesi konusunda güvenmesi ve görevi emanet etmesi taktiğidir. Kalıtımla ilgili kısıtları ihlal etmeden yeniden kullanıma olanak sağlar Yazılımı daha fazla yeniden kullanılabilir ve konfigüre edilebilir yapar

53 Delegasyon Örneği 53 Scatterplot - data[*] Axes axes.draw(); plotdata(); # plotdata() + draw() BarChart - numbins - bins[*] - binwidth # plotdata() + draw() - axes - axes - title - xunits - yunits - xlabel - ylabel - xmin - ymin - xmax - ymax + draw()

54 Kalıtım ve Delegasyon Kuralları 54 Kalıtımı yalnızca alt-sınıf ve üst-sınıf arasında gerçekten bir genelleştirme varsa kullanın. Benzer sınıflardaki ortak özellik ve operasyonları bir süper-sınıfta birleştirin. Yeniden kullanımı, esnekliği, ve konfigüre edilebilirliği arttırmak için delegasyon kullanın.

55 Özet 1 55 Ayrıntılı tasarım, yazılım mühendisliği tasarımının en yoğun ve büyük işlerinden oluşur. Bundan dolayı orta-düzey ve alt-düzey tasarım olarak ele almak yararlıdır. Orta-düzey tasarım DeSCRIPTR spesifikasyonlarını içeren bir DDD ile dokümante edilir. Orta-düzey sınıf tasarımları baştan oluşturulabildiği gibi başka bir modelden dönüştürülerek de oluşturulabilir.

56 Özet 2 56 Yaratımsal tasarım tekniği tasarım öykülerinden çıkartılan tasarım temalarını kullanır. Dönüşümsel tasarım tekniğinde kavramsal model bir tasarım sınıf modeline dönüştürülür. Sorumluluk-güdümlü tasarım, tasarımcıların sınıf modelleri oluştururken doğru kararlar vermelerine yardımcı olur. Kalıtım ve delegasyon doğru kullanıldığı taktirde yeniden kullanılabilirliği, esnekliği, ve konfigüre edilebilirliği yüksek, temiz ve zarif tasarımlar oluşturulmasına yardımcı olur.