yazılım mimarisi ve tasarımı · yzm 8 yazılım mimarisi ve tasarımı burada kumanda nesnesi...

YZM 2118

Yazılım Mimarisi ve Tasarımı

Yrd. Doç. Dr. Volkan TUNALI

Celal Bayar Üniversitesi

Hasan Ferdi Turgutlu Teknoloji Fakültesi

Yazılım Mühendisliği

1 YZM 2118 Yazılım Mimarisi ve Tasarımı

BÖLÜM – 9.1

Tasarım Prensipleri 1/2

2

Bu bölümde;

Tasarım Prensipleri

ile ilgili konular anlatılacaktır.

YZM 2118 Yazılım Mimarisi ve Tasarımı

1. Ayrıştırma (Decomposition)

2. Kohezyon (Cohesion)

3. Tek Sorumluluk Prensibi (Single Responsibility)

4. Zayıf Bağlaşım Prensibi (Low Coupling)

5. Yeniden Kullanılabilirlik prensibi (Reusability)

6. Açık – Kapalı Prensibi (OCP)

7. Liskov Yerine Geçme Prensibi (LSP)

8. Bağımlılığı Ters Çevirme Prensibi (DIP)

3

Tasarım Prensipleri


• Nesne yönelimli tasarımın ilk prensibi olan

ayrıştırmanın tanımı; problem alanındaki ilgili

varlıkların tespit edilip, doğru nesneler

biçiminde ifade edilmesidir.

• Bir yöntem olarak da nitelendirilebilecek

ayrıştırma, sistemdeki karmaşıklıkla

(complexity) başa çıkabilmek için yapılır.

• Buna kısaca böl ve fethet (divide and conquer)

denilmektedir.

4

1.Ayrıştırma (Decomposition)


• Yazılımcının çözümlemeyi gerçekleştirirken en

büyük yardımcısı analiz sırasında ortaya çıkan

use case tanımlarıdır.

• Use case tanımlarını isim ve fiilleri ortaya

çıkaracak şekilde okumak olası nesnelerin

tespitine yardımcı olacaktır. 5

1.Ayrıştırma (Decomposition) (devam...)


Varlıklar Nesneler

• Bu aşamada yazılımcı, "NASIL?" sorusu yerine

"NE(LER)?” sorusunun cevabına

odaklanmalıdır.

• Böylece algoritma düşünmek yerine nesneleri

düşünmeye yoğunlaşabilir.

6



NASIL? NE(LER)?

Fonksiyonel Ayrıştırma

• Büyük ve karmaşık fonksiyonlar bu yöntemle

daha küçük ve anlaşılabilir alt fonksiyonlara

ayrılırlar.

• Genellikle analiz aşamasında diagram şeklinde

üretilirler.

• İlk seviye bileşenler ve fonksiyonları ayrıştırılarak

başlanır.

• İstenilen detayda alt seviyelere inildiğinde işlem

durdurulur.

7




8




9



10

2.Kohezyon (Cohesion)


• Yazılım mühendisliğinde kohezyon; bir

sınıftaki tanımlı üyelerin birbirlerine

mantıksal ilişkilenmesi biçiminde

tanımlanabilir.

• Diğer bir deyişle kohezyon, sınıf

içerisindeki üyelerin ya da fonksiyonlar

içindeki görevlerin birbirlerine olan

mantıksal uzaklığını belirler.

11

2.Kohezyon (Yapışıklık) (devam...)


• Tasarımda kohezyon faktörünün yüksek

olması arzu edilir.

• Zira bir sınıfa ilişkin üye fonksiyonlar

aralarında mantıksal bir kopukluk olmayacak

şekilde yazılmış olmalıdır.

• Üyeler arasındaki mantıksal kopukluklar

kohezyonu azaltarak sınıfın yazılma amacını

çarpıtacağı gibi bağımlılıkların da artmasına

neden olur.

12



• Örneğin; string işlemleri için yazılmış bir sınıf,

string'in ekrana basılmasını sağlayan

fonksiyonlara sahip olmamalıdır.

• Her şeyden önce böylesi yanlış bir tercih, o sınıfı

sadece belirli GUI sistemleriyle çalışmaya

bağımlı kılacaktır.

• Öte yandan o string sınıfı içinde yazılan ve string

işlemleriyle doğrudan ilişkili fonksiyonlar ise

olması arzu edilen yüksek kohezyonu yaratacak bir

tercihtir.

13



14



• Yüksek kohezyon yazılım sisteminin

esnekliğini arttırır, bakım ve yeniden

kullanılabilirliği kolaylaştırır.

• Kohezyonun türleri:

– Rastlantısal (Coincidental) Kohezyon

– Mantıksal (Logical) Kohezyon

– Geçici (Temporal) Kohezyon

– Prosedürel Kohezyon

– Ardışıl Kohezyon

– Fonksiyonel Kohezyon

15

3.Tek Sorumluluk Prensibi (SRP)


• Tek Sorumluluk Prensibi (Single Responsibility

Principle) Kohezyon olgusuyla yakından ilişkili

olup, bir modülün (örneğin sınıfın) sadece tek bir

sorumluluğu yerine getirmek üzere tasarlanmasını

öngörmektedir.

16

3.Tek Sorumluluk Prensibi (SRP) (devam...)


• Bu prensip diğer bir bakış açısıyla

Kohezyon kavramının özgün bir tanımıdır.

• Zira gereksiz sorumluluklardan arındırılarak

sadece belirli bir görevi yerine getirmek üzere

tasarlanmış bir sınıf elde etmenin yolu; sınıfın

yazılma amacını çarpıtacak yani kohezyonunu

düşürecek fonksiyonlara yer vermemektir.

17



• Bu prensibin uygulanması teoride kolay ancak

pratikte zor olmaktadır.

• Sorumluluk ya da görevleri ayrıştırabilmek

zordur.

• Doğru bir tasarımda ileride olabilecek bir

değişiklikte sadece değişen durumun

sorumluluğunu üstlenmiş sınıf değiştirilebilir

olması öngörülür.

18



• Yani; bir sınıfı değiştirmek için sadece tek bir gerekçeniz

olmalıdır. Şayet birden fazla gerekçe söz konusuysa o

sınıfın bölünmeye ihtiyacı var demektir. Çünkü

değişiklik ihtiyacı daima bir tek nedene

dayandırılmalıdır.

19



Üye sınıfına gereğinden fazla

sorumluluk yüklenmiştir.

• GirisYap(),

• EPostaGonder(),

• SmsGonder(),

• HaberGonder()

fonksiyonları kohezyonun

düşmesine neden olmaktadır.

20



Doğru tasarım şu şekilde olmalıdır:

Kodlayalım…

21



Uye.java

22



SmsUtil.java

23



GirisServisi.java

24

4.Zayıf Bağlaşım Prensibi (LCP)


• Gerçek dünyada nesneler nadiren tek başlarına

bulunmaktadırlar.

• Çoğu zaman birbirleriyle ilişki ve iletişim

halinde olan nesneler birbirlerini içerebilir ya da

çeşitli biçimlerde kullanabilirler.

• Coupling, nesneler arasındaki ilişkilerin

nesneleri birbirlerine ne kadar bağlı kıldığının

ölçütüdür.

25

4.Zayıf Bağlaşım Prensibi (LCP) (devam...)


• Kohezyon faktörü; sınıf içerisindeki dolayısıyla nesneye

ilişkin üyelerin birbirleriyle mantıksal ilişkisi olarak

tanımlanmıştı.

• Kendi içinde kohezyonu yüksek sınıfların birbirleriyle

ilişkiler kurarken, bu ilişkide coupling faktörü

olabildiğince düşük tutulmalıdır.

Coupling

Kohezyon Kohezyon

Sınıf A Sınıf B

26



• Coupling faktörünün 5 seviyesi vardır:

1. Nil Coupling

2. Export Coupling

3. Overt Coupling

4. Covert Coupling

5. Surreptitious (Gizlice) Coupling

27



1. Nil Coupling

– Teorik olarak en düşük dolayısıyla en iyi

coupling düzeyidir.

– Zira bu seviyede bağımlılık söz konusu

olmamaktadır.

– Diğer sınıflarla hiçbir ilgisi olmayan, tek

başlarına kullanılan sınıflar bu duruma

örnek teşkil etmektedir.

28



2. Export Coupling

– Herhangi bir sınıf başka bir sınıfa ortak bir

arayüzle bağlıysa aralarında export

coupling oluşur.

– Birçok durumda ulaşılmaya çalışılan ideal

seviye export coupling seviyesidir.

– Bu seviyeden sonraki seviyeler yaratılmak

istenen low coupling ilkesine zarar vermeye

başlar.

29



3. Overt Coupling

– Bir sınıf, başka bir sınıfa ilişkin üyeleri belli bir

izin dahilinde kullanıyorsa aralarında overt

coupling söz konusudur.

4. Covert Coupling

– Bir sınıf, başka bir sınıfa herhangi bir izin

vermeden arkadaşlık kurması durumudur.

30



5. Surreptitious (Gizlice) Coupling

– Bir sınıf, başka bir sınıfın içsel detaylarının

tümünü biliyorsa ve bunları kullanarak işlem

gerçekleştiriyorsa bu sınıfların arasında

surreptitious coupling oluşur.

– Tasarım açısından tehlikelidir.

– Bağımlılık, prensip gereğince az olması

gerekirken, bu seviyedeki coupling’de çok

fazladır.

31



Aşağıdaki UML’de gösterildiği gibi bir sınıfın

içerisinde başka bir sınıftan nesne yaratmak ve o

nesnelerle bir çok işlem yaptırmak coupling’i oldukça

arttırmaktadır.

Kumanda Televizyon

32



Dikkat!!! Yanlış Tasarım!!!

33



Burada kumanda nesnesi görevini yapabilmek için

televizyon nesnesine ihtiyaç duymaktadır, yani kumanda

televizyona bağımlıdır. Tasarım kırılgan olup bu

bağımlılığım zararları aşağıdaki gibidir:

• Tv olmazsa kumanda bir işe yaramaz.

• Tv değiştiğinde kumanda bu değişimden direk etkilenir.

• Kumanda sadece televizyonu kontrol edebilir başka

aletleri kontrol edemez.

Kumanda Televizyon

34



ÇÖZÜM

• Kumanda ile Televizyonun sınıfsal ve nesnesel

bağını kopart.

• Kumanda içerisinde IKumanda interface’i ile bağ kur.

• Televizyon sınıfı da IKumanda interface’ini

implement etsin.

• Hatta Radyo sınıfını da ekle. O da IKumanda

interface’ini implement etsin.

• Tasarımı test et.

35



IKumanda.java

Televizyon.java

36



Kumanda.java

37



Radyo.java

KumandaTest.java

Yararlanılan Kaynaklar

38

• Aykut Taşdelen, C++, Java ve C# ile UML ve Dizayn

Paternleri, Pusula Yayıncılık, İstanbul, 2014

• Eric Freeman, Head First Design Patterns, O'Reilly

Media,2004

• Stephen Stelting & Olav Maassen, Applied Java™

Patterns, Prentice Hall PTR ,2001

• http://www.AlgoritmaveProgramlama.com


http://www.algoritmaveprogramlama.com/







39

İYİ ÇALIŞMALAR…

Yrd. Doç. Dr. Volkan TUNALI

[email protected]


yazılım mimarisi ve tasarımı · yzm 8 yazılım mimarisi ve tasarımı burada kumanda nesnesi...

Documents