YZM211 YAZILIM TASARIMI

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 ...
Author: Emre Çavdarlı
8 downloads 0 Views 1MB Size
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