Yazılım Tasarımı - Software design

Yazılım geliştirme
Yazılım mühendisliğinin temel faaliyetleri
Paradigmalar ve modeller
Metodolojiler ve çerçeveler
Destekleyici disiplinler
Uygulamalar
Aletler
Standartlar ve Bilgi Organları
sözlükler
Anahatlar

Yazılım tasarımı , bir aracının , bir dizi ilkel bileşen kullanarak ve kısıtlamalara tabi olarak, hedeflere ulaşmak için tasarlanmış bir yazılım eserinin belirtimini oluşturma sürecidir . Yazılım tasarımı, "karmaşık sistemleri kavramsallaştırma, çerçeveleme, uygulama, işletmeye alma ve nihai olarak değiştirme ile ilgili tüm faaliyetler" veya " gereksinimler belirtimini izleyen ve programlamadan önceki faaliyet , stilize bir yazılım mühendisliği sürecinde ... [olarak] anlamına gelebilir. "

Yazılım tasarımı genellikle problem çözmeyi ve bir yazılım çözümü planlamayı içerir . Bu, hem düşük seviyeli bir bileşen ve algoritma tasarımını hem de yüksek seviyeli bir mimari tasarımı içerir.

genel bakış

Yazılım tasarımı, bir veya daha fazla problem grubuna yazılım çözümleri tasarlama ve tanımlama sürecidir. Yazılım tasarımının ana bileşenlerinden biri yazılım gereksinimleri analizidir (SRA). SRA, yazılım mühendisliğinde kullanılan özellikleri listeleyen yazılım geliştirme sürecinin bir parçasıdır . Yazılım "yarı otomatik" veya kullanıcı merkezliyse , yazılım tasarımı, bu özelliklerin belirlenmesine yardımcı olmak için bir storyboard sağlayan kullanıcı deneyimi tasarımını içerebilir . Yazılım tamamen otomatikse (yani kullanıcı veya kullanıcı arayüzü yok ), bir yazılım tasarımı, planlanmış bir olay dizisini açıklayan bir akış şeması veya metin kadar basit olabilir . Birleşik Modelleme Dili ve Temel modelleme kavramları gibi yarı standart yöntemler de vardır . Her iki durumda da, planın bazı belgeleri genellikle tasarımın ürünüdür. Ayrıca, bir yazılım tasarımı , tasarım için kullanılan teknolojinin mevcudiyetine bağlı olarak platformdan bağımsız veya platforma özel olabilir.

Yazılım analizi ve tasarım arasındaki temel fark, bir yazılım analizinin çıktısının çözülmesi gereken daha küçük problemlerden oluşmasıdır. Ek olarak, analiz farklı ekip üyeleri veya gruplar arasında çok farklı şekilde tasarlanmamalıdır. Buna karşılık, tasarım yeteneklere odaklanır ve bu nedenle aynı problem için birden fazla tasarım olabilir ve olacaktır. Çevreye bağlı olarak, tasarım, ister güvenilir çerçevelerden oluşturulsun, ister uygun tasarım desenleriyle uygulansın , genellikle değişir . Tasarım örnekleri, işletim sistemlerini, web sayfalarını, mobil cihazları ve hatta yeni bulut bilişim paradigmasını içerir.

Yazılım tasarımı hem bir süreç hem de bir modeldir. Tasarım süreci, tasarımcının inşa için yazılımın tüm yönlerini tanımlamasını sağlayan bir dizi adımdır. Yaratıcı beceri, geçmiş deneyim, "iyi" yazılımın ne olduğu duygusu ve kaliteye genel bağlılık, yetkin bir tasarım için kritik başarı faktörlerinin örnekleridir. Bununla birlikte, tasarım sürecinin her zaman basit bir prosedür olmadığını belirtmek önemlidir; tasarım modeli, bir mimarın bir ev için yaptığı planlarla karşılaştırılabilir. İnşa edilecek şeyin bütününü temsil ederek başlar (örneğin, evin üç boyutlu bir görüntüsü); yavaş yavaş, her ayrıntıyı (örneğin, sıhhi tesisat döşemesini) oluşturmak için rehberlik sağlamak üzere incelenir. Benzer şekilde, yazılım için oluşturulan tasarım modeli, bilgisayar yazılımının çeşitli farklı görünümlerini sağlar. Temel tasarım ilkeleri, yazılım mühendisinin tasarım sürecinde gezinmesini sağlar. Davis, aşağıdaki listede uyarlanmış ve genişletilmiş yazılım tasarımı için bir dizi ilke önermektedir:

  • Tasarım süreci "tünel görüşünden" etkilenmemelidir. İyi bir tasarımcı, her birini problemin gereksinimlerine ve işi yapmak için mevcut kaynaklara göre değerlendirerek alternatif yaklaşımları düşünmelidir.
  • Tasarım, analiz modeline göre izlenebilir olmalıdır. Tasarım modelinin tek bir öğesi çoğu zaman birden fazla gereksinime kadar izlenebildiğinden, gereksinimlerin tasarım modeli tarafından nasıl karşılandığını izlemek için bir araca sahip olmak gerekir.
  • Tasarım, tekerleği yeniden icat etmemelidir. Sistemler, çoğu muhtemelen daha önce karşılaşılmış olan bir dizi tasarım deseni kullanılarak oluşturulur. Bu modeller her zaman yeniden icat etmeye alternatif olarak seçilmelidir. Zaman kısa ve kaynaklar sınırlı; tasarım zamanı (gerçekten yeni) fikirleri temsil etmeye, halihazırda var olan kalıpları (uygulanabilir olduğunda) entegre ederek yatırım yapılmalıdır.
  • Tasarım, gerçek dünyada olduğu gibi, yazılım ile problem arasındaki "entelektüel mesafeyi en aza indirmelidir". Diğer bir deyişle, yazılım tasarımının yapısı, mümkün olduğunda, problem alanının yapısını taklit etmelidir.
  • Tasarım tekdüzelik ve entegrasyon sergilemelidir. Bir tasarım, tamamen tutarlı görünüyorsa tek tiptir. Bu sonuca ulaşmak için tasarım ekibine tasarım çalışmalarına başlamadan önce üslup ve format kuralları tanımlanmalıdır. Tasarım bileşenleri arasındaki arayüzlerin tanımlanmasına özen gösterilirse bir tasarım entegre edilir.
  • Tasarım, değişime uyum sağlayacak şekilde yapılandırılmalıdır. Bir sonraki bölümde tartışılan tasarım kavramları, bir tasarımın bu ilkeye ulaşmasını sağlar.
  • Tasarım, anormal veriler, olaylar veya çalışma koşullarıyla karşılaşıldığında bile yavaşça bozulacak şekilde yapılandırılmalıdır. İyi tasarlanmış bir yazılım asla "bombalamamalı"; olağandışı durumları barındıracak şekilde tasarlanmalı ve işlemeyi sonlandırması gerekiyorsa, bunu zarif bir şekilde yapmalıdır.
  • Tasarım kodlama değildir, kodlama tasarım değildir. Program bileşenleri için ayrıntılı prosedürel tasarımlar oluşturulduğunda bile tasarım modelinin soyutlama düzeyi kaynak kodundan daha yüksektir. Kodlama düzeyinde verilen tek tasarım kararları, prosedürel tasarımın kodlanmasını sağlayan küçük uygulama ayrıntılarını ele almalıdır.
  • Tasarım, oluşturulduktan sonra değil, oluşturulurken kalite açısından değerlendirilmelidir. Tasarımcıya geliştirme süreci boyunca kaliteyi değerlendirmede yardımcı olmak için çeşitli tasarım konseptleri ve tasarım önlemleri mevcuttur.
  • Kavramsal (anlamsal) hataları en aza indirmek için tasarım gözden geçirilmelidir. Bazen tasarım gözden geçirilirken küçük ayrıntılara odaklanma, ağaçlar için ormanı gözden kaçırma eğilimi vardır. Bir tasarım ekibi, tasarım modelinin sözdizimi hakkında endişelenmeden önce tasarımın ana kavramsal öğelerinin (ihmaller, belirsizlik, tutarsızlık) ele alındığından emin olmalıdır.

Tasarım konseptleri

Tasarım konseptleri, yazılım tasarımcısına daha karmaşık yöntemlerin uygulanabileceği bir temel sağlar. Bir dizi temel tasarım konsepti gelişti. Bunlar aşağıdaki gibidir:

  1. Soyutlama - Soyutlama, bir kavramın veya gözlemlenebilir bir olgunun bilgi içeriğini azaltarak, tipik olarak yalnızca belirli bir amaç için ilgili bilgileri tutmak için genelleştirme süreci veya sonucudur. Arka plan ayrıntılarını veya açıklamaları dahil etmeden temel özellikleri temsil etme eylemidir.
  2. Arıtma - Detaylandırma sürecidir. Programlama dili ifadelerine ulaşılana kadar makroskobik bir fonksiyon ifadesini adım adım ayrıştırarak bir hiyerarşi geliştirilir. Her adımda, belirli bir programın bir veya birkaç talimatı daha ayrıntılı talimatlara ayrıştırılır. Soyutlama ve İyileştirme birbirini tamamlayan kavramlardır.
  3. Modülerlik - Yazılım mimarisi, modül adı verilen bileşenlere ayrılmıştır.
  4. Yazılım Mimarisi - Yazılımın genel yapısını ve bu yapının bir sistem için kavramsal bütünlük sağlama yollarını ifade eder. İyi bir yazılım mimarisi, örneğin performans, kalite, zamanlama ve maliyet açısından projenin istenen sonucuyla ilgili olarak iyi bir yatırım getirisi sağlayacaktır.
  5. Kontrol Hiyerarşisi - Bir program bileşeninin organizasyonunu temsil eden ve bir kontrol hiyerarşisini ifade eden bir program yapısı.
  6. Yapısal Bölümleme - Program yapısı hem yatay hem de dikey olarak bölünebilir. Yatay bölümler, her bir ana program işlevi için modüler hiyerarşinin ayrı dallarını tanımlar. Dikey bölümleme, kontrol ve işin program yapısında yukarıdan aşağıya dağıtılması gerektiğini önerir.
  7. Veri Yapısı - Verilerin tek tek öğeleri arasındaki mantıksal ilişkinin bir temsilidir.
  8. Yazılım Prosedürü - Her modülün ayrı ayrı işlenmesine odaklanır.
  9. Bilgi Gizleme - Modüller, bir modülün içerdiği bilgilere, bu bilgilere ihtiyaç duymayan diğer modüllerin erişemeyeceği şekilde belirlenmeli ve tasarlanmalıdır.

Grady Booch , nesne modelinde, temel yazılım tasarım ilkeleri olarak Soyutlama, Kapsülleme, Modülerleştirme ve Hiyerarşiden bahseder. PHAME (Hiyerarşi, Soyutlama, Modülerleştirme ve Kapsülleme İlkeleri) kısaltması bazen bu dört temel ilkeye atıfta bulunmak için kullanılır.

Tasarım konuları

Bir yazılım parçasının tasarımında dikkate alınması gereken birçok husus vardır. Her değerlendirmenin önemi, yazılımın karşılamak için oluşturulduğu hedefleri ve beklentileri yansıtmalıdır. Bu yönlerden bazıları şunlardır:

  • Uyumluluk - Yazılım, başka bir ürünle birlikte çalışabilirlik için tasarlanmış diğer ürünlerle çalışabilir. Örneğin, bir yazılım parçası kendisinin daha eski bir sürümüyle geriye dönük uyumlu olabilir.
  • Genişletilebilirlik - Temel mimaride büyük değişiklikler yapılmadan yazılıma yeni yetenekler eklenebilir.
  • Modülerlik - sonuçta ortaya çıkan yazılım, daha iyi bakım kolaylığı sağlayan iyi tanımlanmış, bağımsız bileşenler içerir. Bileşenler daha sonra, istenen bir yazılım sistemini oluşturmak için entegre edilmeden önce ayrı ayrı uygulanabilir ve test edilebilir. Bu, bir yazılım geliştirme projesinde iş bölümü yapılmasına izin verir.
  • Hata toleransı - Yazılım, bileşen arızasına karşı dirençlidir ve bundan kurtulabilir.
  • Sürdürülebilirlik - Hata düzeltmelerinin veya işlevsel değişikliklerin ne kadar kolay gerçekleştirilebileceğinin bir ölçüsü. Yüksek sürdürülebilirlik, modülerlik ve genişletilebilirliğin ürünü olabilir.
  • Güvenilirlik ( Yazılım dayanıklılığı ) - Yazılım, belirtilen koşullar altında belirli bir süre boyunca gerekli bir işlevi yerine getirebilmektedir.
  • Yeniden Kullanılabilirlik - Önceden var olan yazılımın bazı veya tüm yönlerini çok az değişiklikle veya hiç değişiklik yapmadan başka projelerde kullanma yeteneği.
  • Sağlamlık - Yazılım, stres altında çalışabilir veya öngörülemeyen veya geçersiz girdileri tolere edebilir. Örneğin, düşük bellek koşullarına dayanıklı olarak tasarlanabilir.
  • Güvenlik - Yazılım, düşmanca eylemlere ve etkilere dayanabilir ve direnebilir.
  • Kullanılabilirlik - Yazılım kullanıcı arayüzü , hedef kullanıcı/kitle için kullanılabilir olmalıdır. Parametrelerin varsayılan değerleri, kullanıcıların çoğunluğu için iyi bir seçim olacak şekilde seçilmelidir.
  • Performans - Yazılım, görevlerini kullanıcı için kabul edilebilir bir zaman çerçevesi içinde gerçekleştirir ve çok fazla bellek gerektirmez.
  • Taşınabilirlik - Yazılım, bir dizi farklı koşul ve ortamda kullanılabilir olmalıdır.
  • Ölçeklenebilirlik - Yazılım, artan verilere veya eklenen özelliklere veya kullanıcı sayısına iyi uyum sağlar.

modelleme dili

Bir modelleme dili kurallarının tutarlı bir kümesi tarafından tanımlanan bir yapıda bilgi, bilgi veya sistemlerini ifade etmek için kullanılabilir herhangi yapay bir dildir. Bu kurallar, yapı içindeki bileşenlerin yorumlanması için kullanılır. Bir modelleme dili grafiksel veya metinsel olabilir. Yazılım tasarımı için grafik modelleme dillerine örnekler:

Tasarım desenleri

Bir yazılım tasarımcısı veya mimarı, geçmişte başkaları tarafından ziyaret edilen ve hatta belki de çözülen bir tasarım problemini belirleyebilir. Yaygın bir sorunun çözümünü açıklayan bir şablon veya desen, tasarım deseni olarak bilinir . Bu tür kalıpların yeniden kullanılması, yazılım geliştirme sürecini hızlandırmaya yardımcı olabilir.

teknik

Yazılımın ilgili olarak terimini "tasarım" uygulanmasındaki güçlükler bazı duyuları, bir programın kaynak kodu olmasıdır olduğunu ürettiği o programın tasarımı. Bunun doğru olduğu ölçüde, "yazılım tasarımı", tasarımın tasarımını ifade eder. Edsger W. Dijkstra , semantik seviyelerin bu katmanlaşmasına bilgisayar programlamanın "radikal yeniliği" olarak atıfta bulundu ve Donald Knuth , TeX yazma deneyimini , bir programı uygulamadan önce tasarlamaya çalışmanın yararsızlığını açıklamak için kullandı:

Sadece belirtmiş olsaydım ve ilk uygulamasına tam olarak katılmamış olsaydım, T E X tam bir başarısızlık olurdu. Uygulama süreci beni sürekli olarak beklenmedik sorulara ve orijinal özelliklerin nasıl geliştirilebileceğine dair yeni anlayışlara götürdü.

kullanım

Yazılım tasarım belgeleri , bilgisayar programlamadan önce kısıtlamaların, spesifikasyonların ve hatta gereksinimlerin ayarlanmasına izin vermek için gözden geçirilebilir veya sunulabilir . Yeniden tasarım, programlanmış bir simülasyonun veya prototipin gözden geçirilmesinden sonra gerçekleşebilir . Bir plan veya gereksinim analizi olmaksızın programlama sürecinde yazılım tasarlamak mümkündür, ancak daha karmaşık projeler için bu mümkün görülmeyecektir. Programlamadan önce ayrı bir tasarım, çok disiplinli tasarımcıların ve konu uzmanlarının (KOBİ'ler) hem kullanışlı hem de teknik olarak sağlam yazılımlar için son derece yetenekli programcılarla işbirliği yapmasına olanak tanır .

Ayrıca bakınız

Referanslar

^ Roger S. Pressman (2001). Yazılım mühendisliği: bir uygulayıcının yaklaşımı . McGraw-Hill. ISBN'si 0-07-365578-3.