Kullanıcı Amaçları

Müşteriler (bir yazılım projesi sipariş eden kişiler) yazılımı belli amaçlarını gerçekleştirmek için istemişlerdir. Kullanıcılar (yazılımı kullanacak kişiler)  de yazılımı bu amaçları gerçekleştirecek şekilde kullanacaklardır. Gereksinim analizi işte bu amaçların anlaşılması aşamasıdır. Kullanım durumu şemalarında bu amaçları yazılı olarak özetler ve doğru anlaşılmış olduklarından emin olmak için kullanıcılar ve yazılım geliştiricilerle paylaşırsınız.

 Kısacası, bir UML kullanım durumu şemasıyla görselleştireceğiniz kullanım durumları kullanıcı amaçlarının yazılı özetlerini içerirler. Dikkat edin, bunlar yazılım her türlü yetenekleri ve özelliklerinin kuru birer listesi değildirler. Yazılımın kullanıcıya fayda sağlayan yeteneklerine odaklanmalısınız. Bu açıdan bakarsanız, kullanıcı gereksinimlerini bir alışveriş listesi yapar gibi yazıp geçmemeniz gerektiğini de anlarsınız. Gereksinimler analizi aslında kullanıcının ne istediğini kullanıcıdan daha iyi anlamanız gereken bir aşamadır. Nasıl ki bir ebeveyn çocuğunun her istediğini yapmak yerine onun için doğru olanı yapmalıdır, bir yazılım geliştirici de kullanıcıya fayda sağlayacak amaçları gerçekleştirmeye odaklanmalıdır.

Gereksinimlerin Türleri

Larman'ın Birleştirilmiş Süreç kapsamında listelediği gereksinim türleri aşağıdaki gibidir:

• Fonksiyonel
  Özellikler, yetenekler ve güvenlik gereksinimleri bu kategoride yer alır. Kullanım durumları şemaları genellikle bu türden gereksinimlere odaklanır ve gereksinimler analizinde ilk önce araştırılıp belirlenenler de bunlardır.
• Kullanılabilirlik
  Yazılımın kullanıcılarla etkileşimi ve onlara sağlayacağı yardımcı bilgiler bu kategori altındadır. Bu türden gereksinimler yerine getirilmemişse yazılım beklenen amaçları gerçekleştirebilecek bile olsa er veya geç kullanımdan düşecektir.
• Güvenilirlik
  Tahmin edilir şekilde davranış ve hata durumundan kurtulma konusundaki beklentiler bu kategori altındadır. Bir kullanım durumundaki aktivitenin senaryosunu oluşturup bir akış şemasıyla görselleştirdiğiniz zaman olası hata durumlarındaki alternatif adımları da gösterir ve hatadan dönebilmenin önemini daha iyi kavrarsınız.
• Performans
  Tepki süreleri, veri akış hacmi, doğruluk, bulunabilirlik ve kaynak kullanımı konulu gereksiniler  bu kategori altında yer alır. Bunlar bir sistem yazılımının amaçlara uydunluğu veya kullanılışlığını etkilemeyecek, ama kullanım maliyetini etkileyecek özellikleriyle ilgilidir.
• Desteklenebilirlik
  Ayarlabilirlik (configurability), uyarlanabilirlik (adaptability), sürdürülebilirlik (maintainability) ve yabancı dillere uyarlamakla ilgili gereksinimler de bu kategori altındadır. Bu gereksinimler de sistem yazılımının hitap ettiği çevreyi genişletecek özellikleriyle ilgilidir.

Gereksinimlerin Önemi

Gereksinimler yazılım projesini başlatan müşterilerin sistemden beklentileridir. Gereksinimler analizi de bu beklentilerin araştırılması, anlaşılması, ve yazılım geliştirici takım üyeleriyle müşterilerin açıkça anlayacakları şekilde kaydedilmesidir.

UML ile yazılım modellemede kullanılan kullanım durumu şemaları (use case diagrams) işte bu gereksnimlerin anlaşılır şekilde kaydetmenin önemli bir yoludur.

Craig Larman gereksinimler analizinin önemini vurgulamak için, yukarıda bir kopyasını sunduğumuz grafiğe işaret ederek, yazılım projelerini engelleyen sorunların dörtte birinin gereksinimlerle ilgili olduğuna dikkat çekiyor. Yazılım projeleri geliştirirken gereksinimlerin işin başında tam anlaşılmasını ve diğer işlerin kendilerine ait ayrık aşamalarla ilerlemesini öngören şelale yönteminin artık işe yaramayacağını belirtiyor ve son hedefe doğru adım adım yaklaşırken, her şey gibi gereksinimlerde de sürekli olabilecek değişiklikleri gerektikçe geri dönüp yakalayacak olan iteratif geliştirme yöntemini öneriyor. İteratif geliştirmeyi de her biri gereksinim analizi, modelleme ve uyarlama aşamaları içeren alt proje adımlarının bir dizisi olarak açıklıyor.

Nesneye Yönelik Analiz ve Tasarım

Craig Larman'a göre, nesneye yönelik düşünce tarzı edinmek UML şemalarının görselleştirme prensiplerini öğrenmekten daha önemlidir. Gerçek hayattaki nesneleri temsil edecek yazılım sınıflarına atanacak sorumlulukların ve bu sınıfların birbirleriyle olan ilişkilerinin önceden planlamak için önceden denenerek doğrulanmış belli kalıpların (patterns) uygulanmasını öneriyor.

Larman nesneye yönelik analiz (object oriented analysis) aşamasını yazılımı geliştirecek gerçek sistemi oluşturan nesne ve kavramların tanımlanması olarak görür. Nesneye yönelik tasarım aşamasında da bu nesneleri yazılımda temsil edecek sınıfların ve işbirliklerinin (collaboration) tasarlanması olarak görüyor.

Peki nesneleri tanımlamak ve yazılımı onları temsil edecek sınıflara dayalı olarak tasarlamak neden bu kadar önemlidir? Bunun nedeni açık: Tanımladığınız nesneler üzerinde yazılım geliştireceğiniz sistemi oluşturmaktadır; sistemin çalışması bu nesnelerin birbirleriyle kurdukları ilişkilerden, aralarındaki bilgi alşverişinden ibarettir. Dolayısıyla geliştireceğiniz yazılımın  çalışması da bu nesneleri temsil eden sınıflar arasındaki mesaj alışverişleri şeklinde olacaktır.

Bennet, Robb ve Farmer ise nesneye yönelik tasarımı savunurken yeniden kullanımın (reuse) önemine dikkat çekiyorlar. Nesneye yönelik yazılım geliştirmenin önde gelen prensibi ileride başka sistemler üzerinde yazılım geliştirirken de kullanabileceğiniz sınıflar tasarlamaktır. Gerçek hayattaki nesnelerin birden fazla sistemde benzer şekilde etkinlik gösterdiklerini düşünürseniz, bunları temsil eden sınıfların da birden fazla sistem yazılımlarında benzer şekilde iş görebileceğini anlarsınız.

UML Nedir?

Bu küçük not sayfasında ezberleyip tekrarlayacağınız bir kitap tanımı sunacak değiliz. UML deyince belli belli amaçlara yönelik şemalar oluşturmak için önerilmiş görselleştirme yöntemleri anlamanız gerekir. Önemli olan yöntemleri uygulamanızdır. Yöntemlerin uygulanış şekilleri hakkında teorik tartışmalara girmişseniz, dilbilgisi kurallarıyla uğraşırken temel bir ihtiyacını gidermesini sağlacayak basit bir cümle kurmayı hiç düşünmemiş bir turist gibi sokak ortasında altınıza edersiniz.

Yanlış anlamayın, uygulama şekli hiç önemli değildir, herkes istediği şemayı istediği şekilde çizsin demiyoruz. Yalnızca temel prensipleri bilip işe koyulun, ayrıntıları ilerledikçe öğrenirsiniz diyoruz. Belki mimarların ellerinden çıkmış bina planları görmüşsünüzdür; kapı, pencere, dolap ve lavabo gibi yapı öğeleri belki de tüm dünyada benzer veya aynı sembollerle temsil edilirler. O semboller orada o türden nesneler olacak demektir, ama planı hayata geçiren müteahhitler o sembollere karşılık olarak o nesnelerin son kullanıcının istediği marka veya modellerini koydurabilirler. İç mimari aşamasına geçilmişse, planlar biraz daha ayrıntılı olacaktır; mobilyaların türleri ve yerleri de planlarda gözükebilir, ama spesifik model ve görünümler yine son kullanıcının isteklerine bağlıdır.

UML de yazılım mimarları arasında kabul görmüş bir plan yapma şeklidir. Planlanan sistemin son hali son kullanıcının isteklerine bağlıdır, ama tıpkı genel ve iç mimari planlardaki gibi, sistem belli bir kaç türden şemalar oluşturarak planlanır. UML şemaları da mimari planlar gibi müşteriler, geliştiriciler, uygulayıcılar ve son kullanıcıların birlikte göz gezdirebileceği ortak bir görsel iletişim dilidir.

Giriş

Bu blog UML (United Modelling Language, Birleştirilmiş Modelleme Dili) görselleştirme yöntemleriyle yazılım modellemesiyle ilgili bilgiler sunuyor. Başlangıç aşamasında, ve sanırız epeyce uzun bir süre için de konunun özünü en iyi kapsadığını düşündüğümüz kitaplardan alıntı ve özetlerin bir derlemesinden ibaret kalacaktır. Bunda bir sakınca görmüyoruz; yazılım modelleme bir veya daha fazla kaynaktan ezberleme yoluyla kalıcı bilgiler edinerek uygulamaya geçebileceğiniz bir konu değildir. Temel prensipleri özet ölçüsünde öğrenir ve gerçek veya kağıt (üzerinde bazı yazıcı aletlerle kalıcı izler bırakabileceğiniz ince bir selüloz tabakası) üzerinde kalmış bir yazılım geliştirme ortamında uygularsınız. Bu blogun sunduğu derlemelerin, siz ara sıra göz attığınızda uygulamalarınızla ilgili yeni bakış açıları kazandırmasını umuyoruz.

Eklemeler yapıldıkça bu blogdaki derlemeler belki düzensiz bir görünüm alacaktır, ama temel amacımız aynı kalacaktır: Sistemlerin nesneye yönelik, yani gerçek hattaki nesnelerin bir birleşimi olarak analiz edilmesi ve sistemleri yönetecek yazılımların da yine nesneye yönelik, ama bu kez bu gerçek nesleri temsil edecek yazılım nesnelerinin bir birleşimi olarak tasarlanması.