İş Analisti İş Tanımı

İş ve İhtiyaç Analizi, Yazılım Mühendisliği

Bu blog isminde “Java” kelimesini barındırmasına rağmen en az Java kadar Yazılım Mühendisliği’ne de yer veren bir web kaynağı. Bu anlamda yazılım ihtiyaçları ve analizi üzerine de yazmaya çalışıyorum, eğitim ve danışmanlıklarını da veriyorum. Geçenlerde “Analist kim değildir?” diye bir yazı yazdım ama aslolan aslında analistin iş tanımını yapmaktır. Üstat Karl Wiegers‘ın müthiş kitabıyla birlikte gelen elektronik kaynaklardan olan “Business Analyst Job Description“ı Türkçe’ye çevirip yayınlamak ne zamandır aklımdaydı. Bugünlerde Belbim A. Ş.’deki iş analisti arkadaşlarla çalışma fırsatı buldum ve sağ olsunlar, ricamı geri çevirmeyip bahsettiğim metni dilimize çevirdiler. Bu çeviri için öncelikle dostum Fatih Dereli’ye ve tüm ekibiyle birlikte özellikle bu çeviriyi hızlıca yapan Osman Raif Güneş, Evren Kal, Emrah Akbıyık, Gülnur Kılıçoğlu, Mesut Kurtuluş, Yusuf Karahan ve Murat Can Arıgün’a teşekkür ederim. Her halükarda çeviri hataları bana aittir, siz daha iyi anlatım noktaları bulursanız lütfen iletin, burada düzeltelim.

İşte Karl Wiegers’ın “İş Analisti İş Tanımı”:

Tanım

İş analisti, müşteri ve son kullanıcıyı da içerecek şekilde, proje paydaşlarının gerçek ihtiyaçlarını ortaya çıkarmak, analiz etmek, doğrulamak, tanımlamak, test etmek ve yönetmekten esas sorumlu kişidir. İş analisti, aynı zamanda bir ihtiyaç (bu kelime yerine “gereksinim” de kullanılabilir) analisti, ihtiyaç mühendisi, ihtiyaç yöneticisi, sistem analisti ya da sadece analist olarak da bilinir. İş analisti müşteri tarafı ile yazılım geliştiren taraf arasında ihtiyaçların akışını sağlayan kanal olarak hizmet verir.

Bir iş analisti bir yazılım geliştirme yaşam döngüsü boyunca çeşitli seviyelerde yer alır. İş analistinin odak noktası, İhtiyaçların temellendirilmesinden sonra ihtiyaçların yönetilmesi ve doğru bir şekilde gerçekleştirilmesini sağlamaya doğru kayar.

İş analisti fonksiyonu bir pozisyon ismi olmak zorunda değildir, bir proje rolüdür. Bu rol proje için ayrılmış bir “iş analisti” tarafından ya da projedeki öncelikli işi farklı olan proje yöneticisi, ürün yöneticisi ya da yazılım geliştiricisi gibi takım üyeleri tarafından da yerine getirilebilir. İş analisti, görevlerin düzgün bir şekilde yerine getirildiğini gözlemlemekten sorumludur.

Gerekli Beceriler

  • İnsanların söylediklerini anlama ve tereddütlü oldukları kısımları keşfetmek için dinleme becerileri,
  • Karşılıklı görüşme  ve sorgulama becerileri, bireyler ve gruplarla onların ihtiyaçları hakkında konuşma ve temel ihtiyaç bilgisini ortaya çıkaracak doğru soruları sorma becerileri,
  • Çabuk düşünme, planlanan soruların ötesine geçebilme ve görüşülen kişilerden gelen herhangi bir soruya cevap verebilme becerileri,
  • Pek çok kaynaktan toplanan bilgiyi değerlendirmek, çelişenleri uzlaştırmak, yukarı seviyedeki bilgileri detaylandırmak, daha genel bir anlayış için detaylı bilgileri yukarı seviyelere soyutlamak, bahsedilen kullanıcı isteklerini altta yatan gerçek ihtiyaçlardan ve çözüm önerilerini ihtiyaçlardan ayırt etmek için analitik beceriler,
  • Bir ortamdaki insanlar, süreçler ve tekonoloji arasındaki ilişkileri ve etkileşimleri görebilmek için sistemsel düşünme becerileri,
  • Yeni bilgileri hızlıca almak için ögrenme becerileri,
  • İhtiyaçları ortaya çıkarmak amacıyla yapılan toplantı ve atölye çalışmalarını yönetmek için yönlendirme (moderasyon) becerileri,
  • İş birliği ortamı kurmak ve ortak bir hedefe doğru hareket etmek için liderlik becerileri,
  • Elde edilen veriyi farklı teknikler yoluyla doğrulamak ve yenilerini elde etmek amacıyla yeni alanlara girmek için gözlem becerileri,
  • Müşteriler, pazarlamacılar, yöneticiler ve teknik çalışanlarla etkin ve uygun yollarla bilgi alış-verişinde bulunmak için iletişim becerileri,
  • Toplantı ve analiz çalışmaları sırasında toplanan geniş kapsamlı bilgi ile çalışmak ve hızlı değişen bilgi ile baş edebilmek için organizasyonel beceriler,
  • Dilde ifade edileni daha zengin kılmak amacıyla, kurumda hali hazırda var olan modelleme dillerini de kapsayacak şekilde, bilgiyi grafik formlarda sunmak için modelleme becerileri,
  • Öncelikleri ortaya koyabilmek ve projenin (müşteri, ürün yönetimi ve mühendislik gibi) paydaşları arasındaki anlaşmazlıkları çözebilmek için kişiler arası ilişki becerileri,
  • Kimsenin hayal edemeyeceği ihtiyaçları teklif edebilmek için yaratıcılık,

Gerekli Bilgiler

  • Gereksinimleri tanıma, analiz etme, tanımlama, doğrulama ve yönetme uygulamalarıyla ilgili çağdaş uygulamaların bilgisi ve bunları pratikte uygulama yeteneği.
  • Gereksinim mühendisliğine dair güncel kitapları ve diğer kaynakları tanıma.
  • Bir ekip ortamında farklı yazılım yaşam döngülerine göre ihtiyaç mühendisliğinin nasıl uygulanacağının bilgisi.
  • Ürün yönetimi kavramlarının ve kurumsal yazılım ürünlerinin nasıl konumlandırılıp geliştirileceğinin bilgisi.
  • Bir proje ve bir ortam için en uygun araçları seçmek amacıyla ihtiyaç geliştirme ve ihtiyaç yönetimi araçlarının bilgisi.
  • Kullanıcı temsilcileri nezdinde güvenilirlik sağlaması ve onlarla etkin çalışabilmek için, zorunlu olmamakla birlikte, uygulama alanı bilgisi, bir artıdır.

Tipik Sorumluluklar 

  • Projenin iş ihtiyaçlarını dokümante etmek için Ürün Müdürü ya da Ürün Sponsoru ile çalışın.
  • Projenin paydaşlarını ve kullanıcı türlerini belirleyin. Kullanıcı türlerinin karakteristiklerini dokümante edin. Her kullanıcı turü için uygun temsilciler belirleyin ve sorumluklarını görüşün.
  • Mülakatlar, doküman analizleri, ihtiyaçlar hakkında çalışmalar, şekilli anlatımlar, keşifler, saha ziyaretleri, iş süreci analizleri, kullanıcı süreçleri (use-case) ya da kullanıcı hikâyeleri, senaryolar, olay listeleri, rakip ürün analizleri, görev ve iş akışı analizleri yaparak ihtiyaçları ortaya çıkarın.
  • İhtiyaçları, standart şablonlara uygun olacak şekilde, doğal bir dil kullanarak, basit, açık ve kısaca yazın.
  • Üst seviye kullanıcı ve iş ihtiyaçlarını, belirli uygun bir ayrıntı düzeyinde ve insanların ihtiyaçlar üzerindeki çalışmalarına temel olacak şekilde uygun formlarda fonksiyonel (işlevsel) ihtiyaçlarına ayırın.
  • Kalite ihtiyaçlarını, sistemin dış arayüzlerini ve kısıtlarını belirtin.
  • Uygun anlarda görsel analiz modelleri (diyagramlar), prototipler ya da simülasyonlar gibi değişik araçlar kullanarak ihtiyaçları yansıtın.
  • İhtiyaçların analiz ve doğrulamasını yaparken İhtiyaç Tablolarının standartları karşılayacak şekilde tam, tutarlı, özlü, anlaşılır, izlenebilir, uygulanabilir, açık ve doğrulanabilir olduklarından emin olarak yapın.
  • Müşteri ihtiyaçlarının karşılanması ve iş hedeflerine ulaşma esaslarını temel alacak şekilde bir çözümü onaylamak için ihtiyaçları doğrulama aktivitelerini sürdürün
  • Devam eden ihtiyaçların önceliklendirilmesi işini sürdürün ve çabuklaştırın.
  • Eş düzeydeki ihtiyaçlar dokümanlarının gözden geçirme ve denetlemelerine katılın.
  • İhtiyaçların doğru bir şekilde yorumlandığından emin olmak için ihtiyaçların özelliklerinden türetilmiş benzer seviyedeki iş ürünlerinin gözden geçirmelerine katılın.
  • Bir ihtiyaç yönetimi aracıyla oluşturulup, saklanmış (depolanmış) olan ihtiyaçlara giriş yapın, işleyin ve rapor edin. İhtiyaçların özelliklerini belirleyin ve proje boyunca bunları kullanın.
  • İhtiyaçların takip bilgilerinin kullanımını ve oluşturulmasını yönetin.
  • Proje boyunca ihtiyaçların durumunu izleyin.
  • Değişim kontrol süreçleri ve araçlarına ait uygun ve etkili uygulamalar vasıtasıyla ihtiyaçlardaki temel değişiklikleri yönetin.
  • Bir ihtiyaçlar sürecinin sürekli olarak iyileştirilmesi de dâhil olmak üzere, etkili ihtiyaç pratiklerini oluşturun ve uygulayın. Organizasyon ihtiyaç mühendisliği politikaları, prosedürleri ve araçlarının gelişmesine yardımcı olun.
  • Projeler boyunca ihtiyaçların tekrar kullanımı için gerekli yolları uygulayın.
  • Ürün Yönetimine, ihtiyaçların geliştirilmesi ve analiz edilmesi sürecinde ürün planlamasında yardımcı olmak için yollar belirleyin. Yeni ürün özellikleri ve güncellemeleri önerin.

Performans  Ölçütleri

  • Ürün geliştirildikten sonra ürün ve proje yönetiminin, genel ürün kalitesi ve ihtiyaçlarının pazardaki etkinliğinin değerlendirmesi,
  • İhtiyaç mühendisliğinin yürütüldüğü anahtar müşteri ve pazarlama temsilcilerinin görüşleri,
  • Müşteri memnutiyeti ölçümü,
  • İhtiyaç geliştirme planları, kaynak kısıtları ve kalite hedeflerindeki seviyeleri karşılama ya da daha da üstunde başarma,
  • Eksik ihtiyaçlar ile “gayri resmi” yollardan projeye sızan ihtiyaçların oluşturduğu kapsam problemlerini kontrol etme.

Referanslar

Ferdinandi, Patricia L. A Requirements Pattern: Succeeding in the Internet Economy. Boston, Mass.: Addison-Wesley, 2002 (8. Bölüm).

Wiegers, Karl, and Joy Beatty. Software Requirements, 3rd Edition. Redmond, Wash.: Microsoft Press, 2013 (4. Bölüm).

Kullanım İçin Notlar

  • Yapılan genel meslek tanımından faydalanırken belirli ortamlara uyarlama sürecinde terimlerin değiştirilmesi gerekecektir. Örneğin, bazı bilgi teknolojileri takımları iş analisti rolünü “ihtiyaç analisti” olarak ifade eder ve bu takımların genellikle “ürün yöneticileri” yoktur.
  • Bu tanımlamada yer almamasına rağmen iş analisti bazen kurumun iş süreçlerinin çözümlenmesinden ve geliştirilmesinden sorumlu olabilir.
  • Bu tanımlamayı kullanan her takım, çeşitli beceri ve bilgileri kendi görevlerine uygun olarak değerlendirmelidir. Adı geçen bazı beceriler bir iş analisti için gerekli iken bir diğeri için önemsiz olabilir.
  • Bir kimseyi iş analisti olarak işe alırken bu kişinin çalışma süresince sahip olduğu becerilerinin hangilerinin doğuıştan gelen (çözümleme ve çevreye uyum becerisi vb.) ve hangilerinin öğrenilebilen (basitleştirme ve dinleme becerileri vb.) beceriler olduğunun göz önünde bulundurulması gerekir.

Toplam görüntülenme sayısı: 17378

Java Kodunuzun Nesne-Merkezli Olmadığının 10 İşareti – II: Aşırı Statik Metot Kullanımı

Java

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiştik. Şimdi de bu listedeki ilk maddeyi ele alalım:

Sınıflarda aşırı miktarda statik metot kullanımı. (Excessive use of static methods in classes.)

Kodunuzdaki statik metotların sayısı, kodunuzun ne kadar nesne-merkezli olduğunun göstergesidir. Hiç statik metota sahip olmayan bir yazılım düşünmek pek de mümkün değildir ama statik metotların kullanımının istisnai durumlardan çıkarak genel bir hal kazanması, yaklaşımınızın nesne-merkezli olmaktan çıktığının kanıtıdır.

Nesne-merkezli programlamada esas olan, nesne kullanmaktır; statik metotlar ise nesne oluşturmadan, sınıf üzerinden programlama yapmanın yoludur ve bu yüzden de nesne-merkezli programlamanın varlık sebebine karşı bir durum oluşturmaktadırlar. Dolayısıyla aslolan, nesne metotlarının (instance methods) kullanılması, statik metotların ise tamamen istisnai sebeplere bağlı olarak yazılmasıdır. Ne kadar çok statik metot kullanırsanız nesne-merkezli programlamadan o kadar çok uzaklaşıp prosedürel programlamaya o kadar yaklaşmış olursunuz.

Statik metot kullanıp nesne metotu kullanmamak, yazılımı geliştirirken nesneye ihtiyaç duymamak demektir. Bunun birkaç sebebi olabilir:

İlk sebep, nesne-merkezli bir yaklaşıma sahip olmayıp, bundan dolayı nesne üretmemektir. Bu durumda nesne-merkezli bir dil kullanılsa bile yaklaşım nesne-merkezli değildir, daha çok prosedüreldir.

Konu ister iş alanı nesneleri, isterse de algoritmik yapıdaki davranışları içeren servis nesneleri olsun, temelde sadece statik metotlar tercih etmek nesne oluşturmadan nesne-merkezli programlama yapmak anlamına gelmektedir ki bu durum eğer çok özel bir sebepten kaynaklanmıyorsa nesne kavramını ve nesne-merkezli programlamayı bilmemek demektir. Programlamada yeni olan ya da tamamen prosedürel dünyaya alışkın programcıların Java (ya da nesne-merkezli herhangi bir başka dil kullanarak) kodu yazmaya başladıklarında sıklıkla karşılaştıkları bir durumdur. Problemli olan şey, statik kullanımının bulaşıcı ve yayılma eğiliminde olduğu gerçeğidir. Bir sınıf oluşturup üzerine statik metotlar ve alanlar koymaya başladığınızda kısa sürede kendinizi sadece statik metot yazarken bulacaksınız.

İkinci sebebi ki bu çok daha meşru bir hali ifade eder, çünkü bu durumda metot hakikatten de nesnenin kendisine özel olan durumunu değil, nesnelerin ortak değerlerde barınan durumuna bağımlıdır. Bu durumda nesnelerin ortak durumu, statik değişkenlerle ifade edilir ve bu ortak duruma erişen metotların da statik olmaları normaldir. Bu anlamda statik metot kullanımı, olmadığında sıkıntılı ve verimsiz olacak halin sağlıklı bir şekilde çözülmesinde ibarettir. Örneğin Singleton tasarım şablonunda bir tane yaratılmış olan nesnenin “static” olması ve o nesneye ancak yine “static” olan bir metottan ulaşılması bir zorunluluktur:


public class Singleton {

	private static Singleton singleton = new Singleton();

	private static int count;
	private String name;

	private Singleton() {
		count++;
		name = "Singleton" + count;
	}

	public static Singleton getInstance() {
		return singleton;
	}

	public void printName() {
		System.out.println(name);
	}
}

Nesnesiz programlama yapmanın uçüncü sebebi ise nesne oluşturmanın anlamsız olduğu durumlardır. Bu gibi hallerde durum da vardır ve bu durum üzerinde çalışan metotlar da vardır ama durum ve metotların üzerinde tanımlandığı yapının nesne olması konusunda çok da açıklık yoktur. Böyle hallerde sınıfın kendisinin nesne olarak davranmasını bekleriz. Örneğin “Tanrı” diye bir sınıfımız olsa bu sınıftan kaç tane nesne üretmeyi düşünürdünüz? Eğer çok tanrılı bir dine inanmıyorsak, olsa olsa bir tane Tanrı nesnesi üretmek yeterli olurdu. Bu durumda hiç nesne oluşturmadan Tanrı sınıfını nesne gibi kullanmak dolayısıyla da bu sınıfın üzerindeki her türlü durumu ve davranışı statik yapmak son derece anlamlı olur.

Dolayısıyla bazen ya kavram o kadar soyuttur ki gerçekte bir nesne ile ifade etmezsiniz ve sınıfı nesne olarak kullanırsınız ya da kavramınızın verdiği hizmetler hiç bir şekilde o sınıftan üretilecek nesnelerin farklı olacak durunmlarına bağlı değildir. Java APIsindeki java.lang.Math sınıfı buna çok güzel bir örnektir. Math sınıfının nesnesini oluşturmanın anlamı yoktur, çünkü onun sınıfını yukarıdaki Tanrı sınıfında olduğu gibi olsa olsa ancak bir tane nesneye sahip olabilir (eğer tek bir evrenimiz varsa ve evrenin her yerinde aynı Matematik geçerliyse 🙂 )bu yüzden sınıfını nesne olarak kullanabiliriz. Ayrıca Math sınıfının metotlarının davranışı bu sınıftan oluşturulacak nesnelerin durumuna bağlı değildir. Dolayısıyla Math sınıfından nesne oluşturmadan üzerindeki statik metotlar sayesinde ondan hizmet alabiliriz.

Math sınıfına benzer tabiatta olan, yani nesne modelinin bir parçası olmayan, araçsal (utility) metotlar da genelde statik olurlar çünkü ya nesnelerin durumlarına göre değişen davranışa sahip değildirler, tüm durum bilgisi zaten statik olan sınıfın durum bilgisinden ibarettir ya da gerekli bilgiyi zaten çağrılırlarken dışarıdan argüman olarak alırlar. Bu gibi metotların bulunduğu sınıflardan nesne oluşturmak, çoğunlukla iş alanını modelemeye bir katkıda bulunmadığı gibi, kod kalabalığı yapıp, belleği de şişirirler. Örneğin loglama vb. işleri yapan bu tip metotlar da genel olarak statik metotlar olarak ifade edilirler. Dolayısıyla statik metotların bu gibi durumlarda özenle ama doğru bir şekilde kullanılması şarttır.

Bazen, gereksiz nesne oluşturmama gibi masum bir amacın, bol statik metot kullanımına yol açtığı görülmektedir. Gereksiz nesne oluşturma, belleğin gereksiz kullanımına dolayısıyla da, bellek kaçağı (memory leak), performans ve ölçeklenirlik (scalability) problemlerine yol açar. Ama bu durumun tedavisi “hiç nesne oluşturmamak” değildir. Yani “nesneler belleği şişiriyor dolayısıyla nesne oluşturmayıp statik metotlarla çalışıyoruz” demek daha büyük sorunlara yol açacaktır. Eğer hakikatten bellek kullanımı bu kadar önemli ve kritik ise, bunun mimari bir ihtiyaç olarak ortaya konması ve bu seviyede çözümünün aranması daha doğru bir yaklaşım olur. Böyle bir çalışma, nesne merkezli bir dil kullanmak yerine bellek konusunda daha cimri olan prosedürel bir dil kullanmak gibi bir karar ile de sonlanabilir. Ya da Java kullanarak ve bellek konusunda daha tedbirli davranarak da bu sorunu çözebilirsiniz. Nesne oluşturmaktan kaçınmanın ana sebebi nesnenin “gereksiz” değil olsa olsa “anlamsız” olmasıdır. Yukarıda bahsedilen Tanrı ya da java.lang.Math sınıfı gibi, modellenen işin bir parçası olmayan, dolayısıyla işle ilgili nesneden nesneye değişen bir duruma sahip olmayan, araçsal sınıflar ve genelde onların statik olan metotları olmasaydı (ve dolayısıyla da biz bu sınıfların metotlarını ancak nesneleri üzerinden kullanabilir olsaydık,) bellek probleminden çok daha önce kod yapımızla ilgili problemler yaşardık. Çünkü bu gibi sınıfların nesnelerini yaratmak çoğu zaman çok fazla bilgi gerektirir ve bu durumu aşmak için nesne üretici (factory) yapılar gibi başka tasarım desenlerine ihtiyaç duyardık.

Uzun lafın kısası, statik metot kullanımını şu durumlarla sınırlı kılmak, bu durumlar dışında daima nesne oluşturup, nesne metotlarını kullanmak gereklidir:

  • Nesne yaratmanın anlamsız olduğu durumlar. Bu durumlarda sınıfı, nesne olarak kullanabilirsiniz. Nesne yaratılsa bile sadece bir nesneye ihtiyaç varsa ki bu durum Singleton tasarım şablonuna karşılık gelir, sınıfın kendisini o tek nesne yerine, sanki nesneymiş gibi kullanılabilir. Böyle durumlarda hala nesne kullanımını tercih etmek burada açıkladığımız sebeplerden dolayı daha uygun olabilir.
  • Metodunuz, üzerinde çağrılacağı nesnenin hiç bir nesne değişkenini (instance variable) kullanmıyorsa, yani nesnenin durumuna ulaşmıyorsa, statik metot kullanabilirsiniz. Çünkü statik metotlar statik olmayan değişkenlere ulaşamazlar.
  • Metodun çağrılması için bir nesneye ihtiyacınız yoksa statik metot kullanabilirsiniz. Özellikle aynı nesnenin pek çok farklı bağlama geçilip, hepsinde kullanılması gibi durumlarda, farklı bağlama nesne geçmek yerine orada doğrudan sınıf üzerindeki statik metotları çağırmak son derece kolaylıktır. Özellikle araçsal davranışlara sahip (utility) sınıfları bu şekilde yazılımın her bölgesinde kullanmak anlamlıdır.
  • Birden fazla nesne metodu tarafından ortak kullanılacak, nesnenin değişkenlerine ulaşmayan ve muhtemelen dışarıya da açılmayacak kodlar statik metotlarda tutulabilir.

Statik kullanırken iki kere düşünün 🙂

Toplam görüntülenme sayısı: 2072

Java Kodunuzun Nesne-Merkezli Olmadığının 10 İşareti – I

Java, Yazılım Mühendisliği

Nesne-merkezli programlamanın “ne”liği konusu pek çok kişi için halen muğlaktır. C++, Java, Python ya da C# gibi nesne-merkezli bir dil kullanıyor olmanın yazdığımız programları doğrudan nesne-merkezli yapmayacağı çok açık. Çünkü bu dillerde hem prosedürel/yordamsal program yazmak için yeterince imkan vardır hem de programcılar daha az nesne-merkezli kod yazmanın yollarını rahatlıkla bulmakta ya da bu yollara düşmektedirler. Java gibi nesne-merkezli diller bize nesne-merkezli kod yazmak için imkanlar sunmaktadır ama örneğin en azından nelerin nesne olacağı ve nesnelerin  aralarındaki ilişkilerin nasıl olacağı gibi kararlar tamamen biz geliştiricilerin/tasarımcıların sorumluluğundadır. Bu sorumluluğu yerine getirmede sıkıntılar yaşadığımız müddetçe Java’nın bize sağlıklı bir nesne-merkezli yapı oluşturmak için yardım etmesi mümkün değildir.

Ben Java ilk çıktığı zamandan bu yana Java’yı kullanmaktayım. Ve hayatımı, son 10 senede zaman zaman, son 6 senede ise tamamen Java ve Yazılım Mühendisliği eğitimleri vererek ve danışmanlıkları yaparak kazanmaktayım. Bu süre zarfında çok farklı tür ve yaklaşımla yazılmış pek çok Java kodu gördüm. Bu Java kodlarının pek çoğu emin olun, Java ile kod geliştirdiği için kodunun doğrudan nesne-merkezli olduğunu düşünen geliştiriciler tarafından yazılmıştı. Halbuki bu hiç bir şekilde doğru değildir. Yani Java’yı kullanarak bir sınıf oluşturup, içine üç-beş tane private nesne değişkeni (instance variables) tanımlayıp, sonra da bu sınıfa set/get metotlarını koymak, kesinlikle kodunuzu nesne-merkezli yapmaz. Nesne-görünümlü yapabilir ama nesne-merkezli programlamanın, bundan daha fazla olduğunu söylememiz gereklidir.

Nesne-merkezli kod yazmak, sınıflar tanımlayıp onlardan nesne oluşturmaktan çok daha fazlasıdır. En önemlisi örneğin, yukarıda da bahsettiğimiz gibi nelerin nesne olacağı ve nesnelerin aralarındaki ilişkiler gibi kararlar tamamen biz geliştiricilerin/tasarımcıların sorumluluğundadır. Doğru nesneleri bulmak ve aralarındaki ilişkileri sağlıklı bir şekilde oluşturmak çoğu zaman bulunan nesneleri Java’da tanımlamaktan çok daha zordur. Gang of Four yani GoF (ya da dörtlü çete) yazdıkları Design Patterns kitabında şöyle demektedirler:

“The hard part about object-oriented design is decomposing a system into objects. The task is difficult because many factors come into play: encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, and on and on. They all influence the decomposition, often in conflicting ways.”

Türkçe olarak bu alıntıyı şöyle kurgulayabiliriz:

“Nesne-merkezli tasarımın zor tarafı sistemi nesnelere parçalamaktır. Bu iş zordur çünkü bunu yaparken pek çok faktör işin içine girer: kapsülleme, nesnenin boyutları (büyüklüğü), bağımlılık, esneklik, performans, gelişim, tekrar kullanım vb. Bütün bu faktörler, çoğu zaman birbirlerine ters düşecek şekilde bu parçalamayı etkilerler. ”

Doğru nesneleri bulmak yeterli değildir. Aslolan doğru nesneleri bulup, onları ve aralarındaki ilişkileri doğru bir şekilde kurgulayabilmektir öyle ki daha az karmaşık ve daha kolay değişebilen yazılımlara sahip olalım.

GoF’un tasarım şablonları bu zor işte bize yardımcı olurlar. Kitaplarındaki şablonlar, doğru nesneleri bulup doğru bir şekilde kurgulamak için farklı tasarım seçenekleri sunar. Bunu da geliştirdiğimiz yazılımın daha rahat değişebilmesi için yaparlar. “Design for change” (degişiklik için tasarla), GoF’un kitabının ilk bölümündeki üç temel prensiptenn birisidir. “Program to an interface, not an implementation” (arayüze program yaz, gerçekleştirmeye değil) ve “favor object composition over class inheritance” (nesne bileşimini sınıf kalıtımına tercih et) kitabın ilk bölümünde savunulan diğer iki prensiptir.

Nesne-merkezli tasarım ve programlama üzerine çalışan bilge kişiler yukarıdaki gibi pek çok prensip ortaya koymuşlardır. “Single responsibility principle” (tek sorumluluk prensibi) ya da “dependency inversion principle” (bağımlılığin ters çevrilmesi prensibi) senelerdir bu konuda duyduklarımız arasındadır. Bu anlamda SOLID kısaltması en temel 5 prensibi anlatmaktadır.

Ben bu yazı dizisinde bu tip prensipleri açıklamak yerine, sıklıkla karşılaştığım ve kodumuzu az ya da çok nesne-merkezli olmaktan çıkaran işaretlere ya da kötü alışkanlıklara değinmek istedim ve bu amaçla bir liste yaptım:  Java Kodunuzun Nesne-Merkezli Olmadığının 10 İşareti (ya da Ingilizce olarak Top Ten Signs That Your Java Code Is not Object-Oriented).

Bu listedeki yanlış uygulamalar (ya da anti-patterns), yazdığımız Java kodunu hem daha karmaşık hem de daha az değişebilir yapmaktadır. Listedeki her maddeyi örneklerle açıklayacağım gibi, nesne-merkezli paradigmanın hangi en temel prensiplerini bozduğunu da ifade edeceğim. Dolayısıyla her madde içın ayrı bir yazı olacak. Sizden de hem bu liste için hem de listede olmayan ama sizin sıklıkla gördüğünüz bu tür yanlış uygulamalar için bana yardım etmenizi rica ediyorum.

İşte liste:

  1. Sınıflarda aşırı miktarda statik metot kullanımı (Excessive use of static methods in classes.)
  2. Yüksek içerik bağımlılığı (high content coupling). Bir başka sınıfın nesne değişkenlerine doğrudan erişim ya da aşırı set ve get metodu çağrısı. (Direct access to the instance variables or excessive number of calls to setters and getters of another class.)
  3. Kodunuzda hiç alan nesnesinin olmaması ya da olsa bile yetersiz olmaları. (No or very thin domain objects in the code.)
  4. Kodunuzda hiç ya da çok az sayıda arayüz olması. (No or very few interfaces in the code.)
  5. Aralarında benzerlik ilişkisi olan nesneleri modellemek için kalıtım kullanmamak. (No inheritance hierarchy to model is-a relationships between objects.)
  6. Çok sayıda metoda sahip olan sınıflar. (Classes with lots of methods.)
  7. Karmaşık metotlar. (Complex methods.)
  8. Demeter prensibini ihlal eden metotlar. (Methods that break the Demeter law.)
  9. Aşırı miktarda karar ifadelerine sahip olan metotlar. (Methods that include excessive number of decision statements.)
  10. Sıra dışı durumları ifade etmek için Exception nesneleri oluşturmamak. (No Exception objects to represent exceptional situations.)

Yanlış uygulamalardan kaçındığımız şiir gibi kodlar yazmak amacıyla…

Toplam görüntülenme sayısı: 2586

UML’i Nasıl Kullanabiliriz? – II: Use-case ve Activity Diyagramları

İş ve İhtiyaç Analizi, Yazılım Modelleme, Yazılım Mühendisliği

Daha önceki aynı başlıklı yazımızda UML’in kullanımıyla ilgili bir giriş yapmış ve genel prensiplerden ve UML ile ilgili bazı yanlış algılardan bahsetmiştik. Bu yazıda ise daha  UML’in bir yazılım geliştirme sürecinde nasıl kullanılabileceğini daha detaylı ve teknik olarak ele alalım. UML, yazılım modellemenin pek çok farklı safhasına hitap ettiğinden, makul olan yazılım geliştirme süreci içinde çıkan modelleme ihtiyaçlarına göre UML’i kullanmaktır. Bu arada UML’i kullanmaktan temelde onun diyagramlarını kullanmayı kastediyoruz. Ama işin açıkçası bu diyagramları çizebilmek için bazı faaliyetlerde bulunmak gerekir. UML bu faaliyetler hakkında daha ınce de belirttiğim gibi size yol göstermez, bu faaliyetler olsa olsa sizin seçtiğiniz bir yazılım geliştirme metodolojisinin parçası olabilir. Bu anlamda UML diyagramları birer sonuçtur, kendi başına bir amaç değildir. DolayIısıyla bir önceki yazıda da belirtmeye çalıştığım gibi aslında UML diyagramları, buz dağının sadece görünen kısmıdır. Bu konuda şu yazıya bakmanız faydalı olabilir. Peki şimdi artık sadede gelelim ve tek tek diyagramların üzerinden geçelim. Aşağıdaki şekilde UML’in son şu anki halinde var olan 14 diyagram gösterilmiş durumda.

UML 2.4’ün diyagramları.

UML’in behavioral ya da davranışsal diyagramlarda, adından da anlaşılacağı üzere bir davranış vardır. Halbuki structural ya da yapısal diyagramlarda durağanlık söz konusudur. Davranışsal diyagramlar da bir akış dolayısıyla da ya öncelik-sonralık ya da zamansallık sıklıkla vardır. Ama yapısal diyagramlarda bir oluşdan ziyade bir olmuşluk vardır. Bu yüzden yapısal diyagramlar bir fotoğraf gibidir, yani bir futbol takımının maça başlamadan verdiği hatıra pozu gibi. Ama davranışsal diyagramlar, örneğin aynı takımın hücum ederken ya da kalesini savunurkenki sahadaki görünüşünü yansıtır diyebiliriz.

Use-case (UC) diyagramı: UC diyagramları, sistemin dışarıdan gözlemlenebilen en temel özelliği olan davranışlarını ya da fonksiyonlarını, sistem ile davranışları üzerinden etkileşimde bulunan aktörleriyle birlikte kavramsal olarak ifade eder. Bir UC, bu anlamda sistemin bir aktörüne bir değer üretecek şekilde, aktörüyle etkileşimli bir şekilde yerine getirdiği davranışlar bütünüdür öyle ki biz bu bütüne zaman zaman süreç de deriz. (Bu anlamda süreci “kullanıcı süreci” olarak algılamakta fayda vardır.)

Aşağıdaki UC diyagramı, bir açık arttırma işinin UC modelini göstermektedir.

Açık arttırma işinin use case diyagramı.

Bir UC diyagramında UC elips, aktörler ise “Cin Ali” şeklinde gösterilir. UC diyagramlarında ayrıca “include”, “extend” ya da “generalize” gibi yukarıdaki diyagramda bulunumayan, aktörler ve UCler kendi aralarında bulunan farklı ilişkiler de gösterilebilir.

UC diyagramları bir yazılım sisteminin ya da modülünün tüm davranışlarını ve etkileşimde olduğu insan olan ya da olmayan aktörlerini bir arada göstermesi açısından önemlidir. Lakin UC diyagramları görsel olarak anlamlı olsa bile UClerin esas katkısı, düzgün bir şekilde ifade edilmiş ve ana, alternatif, sıra dışı akışlarla, ön ve son şartları ve iş kuralları gibi diğer tür ihtiyaçları içeren dokümanlarındadır. Dolayısıyla UC diyagramı çizmek anlamlıdır, gereklidir ve kolaydır ama kendi başına yeterli olamaz çünkü UC diyagramı, UC modellemenin sadece suyun üstündeki kısmıdır.

Aktivite (activity) diyagramı: Aktivite diyagramı, UCin aktör ve sistem etkileşimini betimler. Veri akış (data flow) diyagramlarına benzer bir yapıya sahip olan aktivite diyagramları, özellikle karmaşık akışlara sahip UCler için biçilmiş kaftandır.

Her aktivite diyagramı sadece bir UCi modeller. UClerin görsel modeli olarak özellikle developerlara hitap eder.

Örnek bir activity diyagramı.

Yukarıdaki aktivite diyagramı, aktiviteleri, aktiviteler arasındaki geçişleri, dallanan ve sonra tekrar birleşen paralel işlemleri ve UCin başlangıç ve sonunu göstermektedir. Diyagramda ayrıca Ingilizce’de “swim lane” olarak adlandırılan ve farklı aktörlerin aktivitelerini gösteren kanallar da vardır.

Benim tecrübem, karmaşık UCler için aktivite diyagramlarını çizmenin katkısı olduğu yönündedir. Aktivite diyagramlarını okumayı müşterilerinize de kolayca ögretebilirsiniz. Bu durumda müşterileriniz aktivite diyagramları ile UC dokümanlarınızı doğrulama ve test etme imkanı bulacaktır. Aktivite diyagramlarını çizdiğinizde developerlarınız size minnettar olacaklardır.

UC diyagramları ile aktivite diyagramları, temel olarak analiz safhasında çizilen ve sistemin davranışsal özelliklerini vetimleyen diyagramlardır. Bu diyagramlar SRS olarak kısalttığımız (Software Requirements Specification ya da dilimizde Yazılım Ihtiyaç Belgesi, YİB) nihai ihtiyaç dokümanın içinde bulunur.

Bir sonraki yazıda devam etmek üzere.

 

Toplam görüntülenme sayısı: 5398

«< 45 46 47 48 49 >»