1 Chapter 8 Tasarım Kavramları Modified from Software Engineering: A Practitioner’s Approach, by Roger S. Pressman For non-profit educational use only.

... konulu sunumlar: "1 Chapter 8 Tasarım Kavramları Modified from Software Engineering: A Practitioner’s Approach, by Roger S. Pressman For non-profit educational use only."— Sunum transkripti:

1 1 Chapter 8 Tasarım Kavramları Modified from Software Engineering: A Practitioner’s Approach, by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use.

2 2 Tasarım Mitch Kapor, Lotus 1-2-3’ün fikir babası, “software design manifesto” sunu Dr. Dobbs Journal’de sunmuştur. Şunları söylemiştir:  İyi bir yazılım tasarımı aşağıdakileri sergilemelidir:  Sağlamlık: Bir program, kendi fonksiyonlarını engelleyen herhangi bir bug a sahip olmamalı.  Değerli olması: Bir program icat edildiği amaca uygun olmalı.  Zevk : Programı kullanmak zevkli olmalı.

3 3 Analiz Modeli -> Tasarım Modeli

4 4 Tasarım ve Kalite tasarım analiz modelinde belirtilen bütün aşikar ihtiyaçları içermelidir, müşteri tarafından istenen bütün ihtiyaçları barındırmalıdır. tasarım, kod yazacak olanlar için, test yapacak olanlar için ve destek verecekler için okunabilir ve anlaşılabilir olmalıdır tasarım yazılımı bütünüyle kapsamalıdır, verinin işlenmesi, fonksiyonel ve davranışsal açılardan.

5 5 Kalite Rehberi Bir tasarım mimarisinin şunları içermelidir (1) bilinen mimari stil ve örüntüler kullanılarak oluşturulmuştur, (2) iyi tasarım karakteristiklerini sergileyen bileşenlerin birleşimidir ve (3) evrimsel bir şekilde uygulanabilir  Küçük sistemler için, tasarım bazen lineer olarak geliştirilebilir. Tasarım modüler olmalıdır.; yani yazılım mantıksal olarak altsistemlere ve elemanlara bölümlenmelidir. Tasarım verinin, mimarinin, arayüzlerin ve bileşenlerin gösterimi ayrı ayrı içermelidir. Tasarım uygun veri yapılarının kullanımına izin vermelidir. (uygulanacak sınıflar ve çizilecek tanınabilir veri örüntüleri için). Tasarım bağımsız fonksiyonel karakteristikler sergileyen bileşenlere yol açmalıdır.. Tasarım karmaşıklığı aza indirgeyen arayüzlere yol açmalıdır. (bileşenler arası ve dış ortamla bağlantılar) Tasarım tekrarlanabilir bir metotla üretilmelidir Tasarım yazılımın manasını ortaya çıkaran bir notasyonla gösterilmelidir.

6 6 Tasarım Prensipleri Tasarım at gözlüğü bakış açısından zarar görmemeli. Analiz modeline uygun olmalıdır. Tasarım tekerleği tekrar icat etmemeli Tasarım ile gerçek dünya problemi arasındaki intellektüel mesafeyi minimize etmeli Tasarım birlik ve bütünlük sağlamalı Tasarım değişime açık olmalı. Tasarım kodlama, kodlama tasarım değildir. Tasarım yapılırken kalite ön planda tutulmalı Tasarım mantıksal hataların oluşmaması için gözden geçirilmeli. From Davis [DAV95]

7 7 Temel Kavramlar Soyutlama (Abstraction)—veri, prosedür, kontrol Mimari (Architecture)—yazılımın bütün yapısı Örüntüler (Patterns)—kanıtlanmış tasarım çözümleri Bölümleme (Separation of concerns)—karmaşık problemler, küçük parçalara bölünerek çözülebilir. Modülerlik (Modularity)—verinin ve fonksiyonun modüler olması Gizleme (Hiding)—kontrollü arayüzler Fonksiyonel Bağımlılık (Functional independence)—tek başına fonksiyonlar ve düşük eşleştirme Düzeltme (Refinement)—bütün soyutlamalar için detayların incelenmesi Durum (Aspects)—genel ihtiyaçların tasarımı nasıl etkilediğinin anlaşılması Yeniden düzenleme (Refactoring)—tasarımı basitleştiren tekrar organizasyon tekniği N-yönelimli tasarım kavramları (OO design concepts)— Tasarım Sınıfları (Design Classes)—uygulanacak sınıfları analiz etmeyi sağlayan tasarım detaylarının sağlanması

8 8 Veri Soyutlama door implemented as a data structure manufacturer model number type swing direction inserts lights type type number number weight opening mechanism

9 9 Prosedür olarak soyutlama open implemented with a "knowledge" of the object that is associated with enter details of enter algorithm

10 10 Mimari “Yazılımın bir bütün olarak yapısıdır ve sistem için yapının sağlamış olduğu kavramsal bütünleştirme yollarıdır.” [SHA95a] Mimari tasarım gösteriminin bu özelliği bir sistemin bileşenleri tanımlar (modüller, nesneler, filtreler) ve bu bileşenlerin paketlenme birbirleriyle haberleşme mantığını kapsar. Yapısal Özellikler. Mimari tasarım gösteriminin bu özelliği bir sistemin bileşenleri tanımlar (modüller, nesneler, filtreler) ve bu bileşenlerin paketlenme birbirleriyle haberleşme mantığını kapsar. Mimari tasarım tanımı, performans, kapasite, güvenilirlik, güvenlik, sağlamlık, adapte olabilirlik ve diğer sistem karakteristiklerini nasıl karşılayacağını belirtmelidir. Ekstra-fonksiyonel Özellikler. Mimari tasarım tanımı, performans, kapasite, güvenilirlik, güvenlik, sağlamlık, adapte olabilirlik ve diğer sistem karakteristiklerini nasıl karşılayacağını belirtmelidir. Mimari tasarım, benzer sistem ailelerinde kullanılabilen ve tekrar edilebilir örüntüleri kullanabilmelidir. Tasarım tekrar kullanılabilir yapılar oluşturmalı ve/veya varolan yapıları kullanabilmelidir. İlişkili Sistem Aileleri. Mimari tasarım, benzer sistem ailelerinde kullanılabilen ve tekrar edilebilir örüntüleri kullanabilmelidir. Tasarım tekrar kullanılabilir yapılar oluşturmalı ve/veya varolan yapıları kullanabilmelidir.

11 11 Örüntüler Tasarım Örüntü Şablonu Örüntü ismi (Pattern name)— Amaç—örüntünün tanımı Eş- anlamları Motivasyon—problemin bir örneğini sağlar Uygulanabilirlik—uygulamanın yapılabilmesi içn belirli tasarım durumları var mı? Yapı—örüntüyü uygulamak için gereken sınıfları tanımlar Katılımcılar—Örüntüyü uygulamak için gereken sınıfların sorumluluklarını tanımlar İşbirliği—katılımcıların kendi sorumluluklarını icra edebilmeleri çin nasıl işbirliği yapacaklarını belirler Sonuçlar—örüntü uygulanınca hangi sonuçları ve etkileri vardır İlişkili örüntüler

12 12 Bölümleme - ayrılaştırma Küçük parçaların çözümü ile karmaşık problemler çözülebilir. Daha hızlı ve etkili çözüm.

13 13 Modülerlik “Modülerlik, bir programın zeki bir şekilde yönetilebilmesini sağlayan tek yazılım özelliğidir. " [Mye78]. Monalitik yazılım (i.e., tek bir modülden oluşan büyük bir program) bir yazılım mühendisi tarafından kolayca anlaşılamaz.  kontrol, referanslar, değişkenler, karmaşıklık …. Hemen hemen her yapıda, tasarım modüllere ayrılmalıdır. Buradaki amaç anlamayı kolaylaştırmak ve sonuç olarak yazılımı inşa etmek için gereken maliyeti en aza indirmek.

14 14 Modülerlik : Trade-offs What is the "right" number of modules for a specific software design? optimal number of modules of modules cost of cost of software software number of modules moduleintegrationcost module development cost

15 15 Bilgi Gizleme module controlled interface "secret" algorithm algorithm data structure data structure details of external interface details of external interface resource allocation policy resource allocation policy clients a specific design decision

16 16 Neden Bilgi Gizleme? yan etkilerin olmasını azaltır yerel tasarım kararlarına dışarıdan etkiyi sınırlar kontrollü arabirimler aracılığı ile iletişim düzenli olur küresel veri kullanımını teşvik etmez enkapsulationa yol açar daha kaliteli yazılımlar

17 17 Adım adım Gözden Geçirme open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

18 18 Modülleri boyutlandırma

19 19 Fonksiyonel bağımlılık fonksiyonen bağımlılık ile anlaşılan modullerin birbirleriyle etkileşimli olmasıdır. Bağlılık – Uyum içinde olma (Cohesion) bir modülün bağıl fonsiyonel güçlülüğünün belirtisidir.  A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing. Birliktelik (Coupling) modülleri arasındaki bağıl bağlılığın ifadesidir.  Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

20 20 Durum, Görünüş, Bakış Açısı (Aspects) A ve B gibi iki ihtiyaç olsun. A, B ‘yi çapraz keser denilir. Eğer A ihtiyacı giderilmeden B ihtiyacı giderilemez. Bir durum çapraz kesme meselesinin gösterimidir.

21 21 Durumlar—Örnek SafeHomeAssured.com web uygulaması için iki ihtiyaç olsun.  A ihtiyacı Access camera surveillance via the Internet kullanıcı durumu ile tanımlansın.  Bir tasarım düzenlemesı, kayıtlı kullanıcının videoya erişimine odaklansın  İhtiyaç B SafeHomeAssured.com ‘un kullanılabilmesi için kayıtlı kullanıcının geçerliliğini test eder olsun.  Bu ihtiyaç bütün SafeHome kullanıcıları için geçerlidir. Kayırlı kullanıcının SafeHomeAssured.com’u kullanmadan önce kimliğinin kontrolunun olması bir durumdur.

22 22 Yeniden Düzenleme (Refactoring) Fowler [FOW99] in tanımı  “Yeniden düzenleme, bir yazılım sisteminin iç yapısının geliştirilmek amacıyla değiştirilmesidir ve bu işlem yazılımın dış yapısını etkilemez.” Yazılım yeniden düzenlendiğinde, varolan yazılım aşağıdakiler için incelenir.  gereksizlik - redundancy  kullanılmayan tasarım elemanları  etkili olmayan veya gereksiz algoritmalar  zayıf tasarlanmış veya uygun olmayan veri yapıları  veya daha iyi bir tasarım gerektiren tasarım hataları

23 23 OO Tasarım kavramları Tasarım sınıfları  Varlık sınıfları - Entity classes  Sınır sınıfları - Boundary classes  Kontrol sınıfları - Controller classes Kalıtım - Inheritance—altsınıflar üst sınıfların bütün özelliklerini kalıtımla alır Mesajlar - Messages—alıcı nesnede olan bazı davranışların gösterilmesi Çok biçimlilik - Polymorphism—tasarımı genişletmek için gereken çabayı azaltan bir karakteristik

24 24 Tasarım Sınıfları Analiz sınıfları, tasarım esnasında varlık sınıfları olmak için yeniden düzenlendi Sınır sınıfları tasarım esnasında kullanıcının kullandığı arabirimleri geliştirmek için geliştirildi. Kontrol Sınıfları aşağıdkaileri yönetmek için tasarlandı.  varlık nesnelerini oluşturmak veya güncellemek  varlık nesnelerinden bilgi buluyorken sınır nesnelerinin oluşturulması  Nesne kümeleri arasındaki karmaşık iletişim  nesneler veya kullanıcı ve uygulama arasındaki veri iletişiminin geçerliliğinin sağlanması

25 25 Tasarım Modeli

26 26 Tasarım Model Elemanları Veri elemanları  Veri modeli --> veri yapıları  Veri modeli --> veritabanı mimarisi Mimari elemanlar  Uygulama alanı  Analiz sınıfları, ilişkileri, işbirlikleri veya tasarım için kullanılan davranışları  Örüntüler ve stiller Arabirim elemanları  kullanıcı arabirimi,  diğer aygıt, ağ veya ürünlere olan dış arabirimler  çeşitli tasarım elemanları arasındaki iç arabirimler Eleman bileşenleri Teslimat bileşenleri

27 27 Mimari Elemanlar Mimari model üç kaynaktan faydalanılarak oluşur. [Sha96] :  uygulama alanı ile ilgili bilgi geliştirilecek yazılım için gereken;  model elemanları için gereken özel ihtiyaçlar veri akış diyagramları analiz durumları, gibi  mimari örüntü ve stillerin mümkün olup olmaması

28 28 Arabirim Elemanları

29 29 Bileşen Elemanları

30 30 Dağıtım Elemanları - Deployment Elements