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
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
KISIM 1 3
İleri Düzey UML Sınıf Diyagramları
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
İç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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Genelleştirme Örneği 7
Mammal
Quadruped
Feline
Tiger
YZM211 Yazılım Tasarımı © Volkan TUNALI
Lion
Lizard
Puma
2013 Bahar
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).
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Soyut Sınıf ve Operasyonların Kullanımı ve Temsili 10
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Soyut Sınıf ve Operasyon Örnekleri 11
«abstract» Shape areaOf() : float { abstract }
Circle
YZM211 Yazılım Tasarımı © Volkan TUNALI
Document { abstract } Renderer render()
ScreenRenderer
callNumber descriptors : String[*]
Book
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Sağlanan Arabirim Notasyonları 13
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Gereksinilen Arabirim Notasyonları 14
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Modül Montaj Notasyonları 15
Timer Timer «interface» Observer update( arg : Object )
Observer
TimerObserver TimerObserver
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Ö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
YZM211 Yazılım Tasarımı © Volkan TUNALI
IntrusionAlarm
FloodAlarm
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Ö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 )
YZM211 Yazılım Tasarımı © Volkan TUNALI
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
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Agregasyon ve Kompozisyon Örnekleri 21
Human Church 0..2 Arm
0..1 Hand
YZM211 Yazılım Tasarımı © Volkan TUNALI
Family
*
0..2
1..*
Leg
0..1 Foot
1..*
Person
1..*
2013 Bahar
İ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).
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
İlişki Sınıfı Örneği 23
Medication
*
*
Patient
Prescription - date
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
İ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. YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Rol İsmi Görünürlüğü ve Ulaşılabilirlik Örn. 26
1 Referee
*
Game 0..1
- myGame
1..*
- player
Player
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Ö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 YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
KISIM 2 30
Ayrıntılı Tasarıma Giriş ve Orta-Düzey Sınıf Modelleme
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
İç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 YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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)
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Ayrıntılı Tasarım Süreci 36 Detailed Design Process SRS, SAD : Problem Design Document : Solution
SRS
Analyze SRS and SAD
SAD
Generate/Improve Detailed Design Alternatives Evaluate Detailed Design Alternatives Select Detailed Design [else] [adequate detailed design] Finalize Design
YZM211 Yazılım Tasarımı © Volkan TUNALI
Design Document
2013 Bahar
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. 2. 3. 4. 5.
Orta-Düzey Tasarım Modelleri Alt-Düzey Tasarım Modelleri Modeller Arası Eşleştirme Ayrıntılı Tasarım Gerekçesi Sözlük
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Tasarım Teması Süreci
Theme-Based Decomposition SRS : Theme Source Class Diagram : Draft Model
40
SRS
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]
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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ı
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Kalıtım Örneği 51 Graph - title - xUnits - yUnits - xLabel - yLabel - xMin - yMin - xMax - yMax
Scatterplot - title - xUnits - yUnits - xLabel - yLabel - xMin - yMin - xMax - yMax - data[*] # setUpGraph() # plotData() + draw()
# setUpGraph() # plotData() + draw()
Scatterplot - data[*] # plotData()
setUpGraph(); plotData();
BarChart - numBins - bins[*] - binWidth # plotData()
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
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
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Delegasyon Örneği 53
Scatterplot - data[*] # plotData() + draw()
axes.draw(); plotData();
BarChart - numBins - bins[*] - binWidth # plotData() + draw()
YZM211 Yazılım Tasarımı © Volkan TUNALI
Axes - axes - title - xUnits - yUnits - xLabel - yLabel - xMin - yMin - axes - xMax - yMax + draw()
2013 Bahar
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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Ö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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar
Ö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.
YZM211 Yazılım Tasarımı © Volkan TUNALI
2013 Bahar