- “İnsanlara ne istediklerini sorsaydım, daha hızlı giden at üretirdim.” Henry FORD

yarışır…

“One lesson I was thought from a team lead was that great teams are grown, not hired. You hire someone with a potential maybe but not necessarily with the knowledge. Your main job as a team leader is to create that great team from the people you have. Don’t look outside. Because if you’re looking outside you’ve already failed.”

“Takım liderliğinden öğrendiğim bir şey var ki müthiş takımlar yetiştirilir, işe alınmaz. Belki potansiyeli olan birini işe alırsınız ama illa ki bilgili olması gerekmez. Takım lideri olarak sizin asıl işiniz elinizdeki insanlarla o müthiş takımı yaratmaktır. Kaynağı dışarıda aramayın. Çünkü arıyorsanız zaten başaramamışsınızdır.”

Roy OSHEROVE

Ancak, günlük RSS’lerimi okurken InfoQ’da yayınlanan bir makale (Software Quality – You Know It When You See It) oldukça ilgimi çekti. Takım Liderliği sürecinde birlikte çalıştığım çoğu yeni mezun arkadaşlara da sürekli empoze etmeye çalıştığım kod kalitesi üzerine oldukça faydalı bir içerik sunmakta. En temel unsurlardan başlayarak temel terimleri açıklıyor, ondan sonra da adım adım ilerleyerek “Kaliteli bir kod nasıl yazılır?” sorusundan ziyade “Bir kodun kaliteli yazılıp yazılmadığını anlamanın / denetlemenin yollar ve bu esnada değerlendirilmesi gereken kriterler nelerdir?” sorusuna yanıt veriyor. Adım adım ilerleyen sunum basit ancak açıklayıcı görsellerle desteklenmiş ve video ile birlikte anlatmak istediklerini basit ve kolay anlaşılır bir şekilde sunabiliyor.

Sunumu izlememin ardından, sunumu yapan Erik Dörnenburg‘un sitesini ziyaret ettim. Blog’unda sunumuna temel teşkil eden pek çok noktaya ayrı ayrı yazılarda değinmiş ve ThoughtWorks‘te çalışırken kullandığı çözümler ve yaptıklarına değinmiş. Blog’una çok sık yazmasa da takip etmenin faydalı olduğuna inandığım bir kişi. Özellikle şirketin özelleştirilmiş çözümler sunmasının da katkısıyla çözüm getirme konusunda güzel ve faydalı yaklaşımları mevcut. Özellikle Blog’unun Talks kısmında yaptığı konuşmalardaki kaynaklarına da erişim veriyor.

WordPress ile hazırlanmış olan sitenin tek kötü yanı Erik‘in RSS bağlantısı sağlamamak olmuş. Ancak kendisini Twitter sayfasından takip etmek mümkün.

Martin FOWLER’ın

Web sitesi: http://martinfowler.com/

Twitter’ı: http://twitter.com/martinfowler

Etkinlik diyagramları nasıl çizilir

Etkinlik diyagramları sistem içerisindeki eylemlerin akışını gösterir. Diyagram yukarıdan aşağıya doğru okunur ve dallanmalar paralel eylemleri ve durumları belirtir. Dallanma, aynı anda birden fazla sürecin işlediğini gösterir. Aşağıdaki diyagramda 1.Aktivite’den sonra bir çatal yer almakta ve dallanma meydana gelmektedir. Bu, 2.Aktivite ve 3. Aktivite’nin aynı anda gerçekleştiğini göstermektedir. 2.Aktivite’den sonra da bir dallanma vardır. Dallanma belirli koşullar altında hangi eylemlerin gerçekleşeceğini gösterir. Tüm dallar bir noktada koşullu durumda işletilecek eylemlerin sonunu belirtmek üzere birleşirler. Tüm paralel aktiviteler sonuca ulaşmadan önce birleşmek zorundadır.

Aşağıda, sipariş işleminin olası bir etkinlik diyagramı görülmektedir. Diyagram, sistem akışı içerisinde eylemlerin akışını göstermektedir. Sipariş alındıktan sonra eylemler iki farklı eylem kümesine ayrılmaktadır. Bir yönde sipariş hazırlanmakta ve gönderilmekte, diğerinde ise faturalandırma işlemi yerine getirilmektedir. Sipariş hazırlama dalında teslim metodu duruma göre tespit edilmektedir. Duruma göre Acil teslimat ya da Normal teslimat işlemi gerçekleştirilir. Son olarak paralel yürüyen aktiviteler siparişi kapatmak üzere birleşirler.

Durum makinesi (State machine): Bir nesnenin bütün durumlarını bir şema halinde gösteren yapıdır.
Durum (State): Tek bir nesnenin herhangi bir durumuna verilen addır.
Olay (Event): Nesnenin durumları arasında geçişini sağlayan yordama olay denir.
Eylem (Action): Nesnenin bir durumdan diğer bir duruma geçtiğinde yaptığı işlere eylem denir. Eylem, çalışıtırılabilir herhangi bir durum olabilir.
Geçiş (Transition): Nesnenin durumları arasındaki, geçişin gösterilmesine geçiş denir. Bir nesnenin her durumu arasında bir ilişki olmayabileceğinden dolayı iki durum arasında bir geçiş olmak zorunda değildir. Bir geçişte 4 yapı vardır. Bu yapılardan ikisi hedef (target) ve kaynak (source)’tır. Geçişler daima kaynak durumdan hedefv duruma doğru yapılır. Üçüncü yapı, kaynak durumdan hedef duruma geçişi sağlayan olay ateşleyicisi (event trigger)’dir. Son yapı da nesnenin geçiş sonrası ne şekilde davranacağını belirleyen eylem (action)’dir.
Özgeçiş (Self transaction): Bazen bir nesnenin gçişleri iki farklı durum arasında olmayıp, kendi üzerine döner. Daha net söylersek; geçişin kaynak ve hedef durumu aynı olur. Bu durum özgeçiş olarak adlandırılır.
İlk durum (Initial state): Programtaik olarak bir koda karşılık geşmese de ilk durum bir nesnenin ilk geçişinden hemen önceki durumunu temsil eder ve geçeceği ilk duruma geçişi sağlamak için bir ilk nokta teşkil eder ve durum kutusunda farklı olarak içi dolu daire olarak gösterilir.
Son durum (Final state): Nesnenin ömrü bittiğinde aldığı son durumu ifade etmek için kullanılan semboldür. Bir nesne birden fazla son duruma sahip olabilir.
Durum diyagramları nasıl çizilir
Durum diyagramları çok az sayıda eleman içerir. Temel elemanlar, nesnenin durumunu temsil eden kutular ve bir sonraki duruma geçişi temsil eden oklardır. Durum sembolünün eylem kısmı nesnenin o durumda ne yapacağını betimler.

Tüm durum diyagramları, nesnenin ilk durumu ile başlar. Bu durum nesnenin ilk yaratıldığı andaki durumudur. İlk durumu takiben nesne durum değiştirmeye başlar. Eylemlerin koşuluna göre nesnenin geçeceği bir sonraki durum çeşitlenir.

Aşağıda sipariş örneğine uygun bir durum diyagramı görülmektedir. Nesne “Denetleniyor” durumuna geçtiğinde “ürün denetle” eylemini gerçekleştirir. Eylem tamamlandıktan sonra bir sonraki geçilecek durum “ürün mevcut” ve “ürün yok” koşullarına göre belirlenir. Eğer ürün mevcut değilse sipariş iptal edilir. Eğer ürün stoklarda mevcut ise ürün gönderilir. Nesne “Gönderiliyor” durumuna geçtiğinde ise “göndermeyi başlat” eylemi gerçekleşir ve nesne “Gönderildi” durumuna geçer.

Durum diyagramları aynı zamanda bir nesnenin üst durumunu da gösterebilir. Üst durum, pek çok geçişin belirli bir duruma gittiği zamanlarda kullanılır. Son duruma kadar olan ara geçişleri göstermek yerine tek bir üst durum içerisinde durumlar tanımlanıp, son duruma geçiş üst durum üzerinden gösterilebilir. Bu, durum diyagramını okumayı kolaylaştırır.
Aşağıdaki diyagramda bir üst durum görülmektedir. “Denetleniyor” ve “Gönderiliyor” durumları “İptal edildi” durumuna geçebileceğinden geçiş sadece bir üst durum olan “Aktif” durumundan “İptal edildi” durumuna gösterilmiştir. Bunun tam tersine “Gönderildi” durumuna sadece “Gönderiliyor” durumundan geçilebileceği için “Gönderildi” durumuna gelen ok sadece “Gönderiliyor” durumundan çıkarılır.

Aşağıdaki örnekte ise sipariş verme use case’i ile ilgili basit bir işbirliği diyagramını göstermektedir.. Bu sefer iki noktadan sonra sınıf isimleri yer almaktadır. Bunun nedeni ise bu sınıftan türetilen tüm nesnelerin aynı şekilde davranacağındandır.

İşbirliği diyagramlarında nesneler iki türde yer alır. Tedarikçi (supplier) ve istemci (client). Bu iki kavram işbirliği diyagramlarında parametreler gösterilirken karşımıza çıkar. Temel olarak tedarikçi nesneler çağrılan metodu sunan nesnelerdir. Bir dizge diyagramında aradaki bağlantıyı gösteren okun ucundaki nesne, mesajı alan ve çağrılan metodu sunan tedarikçi nesnedir. İstemci nesneler tedarikçi nesne üzerindeki metodları çağırır.
İşbirliği diyagramında kullanılan nesneleri daha detaylı incelersek:

Nesne: Yukarıdaki işbirliği diyagramında bize dizge diyagramlarından da tanıdık geleceği üzere nesne aynı şekilde gösterilmektedir. Nesne kutusunun içerisinde yer alan “a” harfi nesneyi, “A” harfi ise sınıfı temsil etmektedir.

Senkron mesaj: Gönderildiği nesneden yanıt bekleyen mesajlardır ve belirli bir süre sonra, işlem tamamlandığında aynı bağlantı üzerinden yanıt alınmaktadır. Bir senkron mesaj

ile gösterilirken geri dönen yanıt da

işaretiyle gösterilir.
Asenkron mesaj: Senkron mesajların aksine cevap beklemeyen mesajlardır. Bir işbirliği diyagramında asenkron mesaj aşağıdaki simge ile gösterilir.

Prosedür çağrısı: Yukarıdaki diyagramda “b” nesnesi “c” nesnesi üzerinden bir prosedürü çağırmaktadır.

Sıra numarası: İşbirliği diyagramlarında zaman bilgisi bulunmadığından mesajlaşmalarda sıra numarası kullanılır. Dizge diyagramlarında zaten bir zaman ekseni mevcut olduğundan sıra bilgisini yazmak seçime bağlıdır. Fakat işbirliği diyagramlarında zamanı ekseni olmadığından mesaj numarası kullanmak zorunludur.

Belirsiz nesne (Anonymous object): Bir sınıftan türeyen her nesnenin aynı şekilde davranacağının düşünüldüğü tasarımlarda sınıftan türeyen nesne için isim kullanılmayabilir. Bu durumda nesne adı belirtilmez ve belirsiz nesne “:A” şeklinde sadece sınıf adı ile nitelenir.

Kendine referans (Self-reference): Kendi üzerindeki bir metodu çağıran nesnedir. Çoğu durumda nesne, kontrol amaçlı olarak sahip olduğu metodları kullanabilir.

Zaman aşımı (Timeout): Belirli bir zaman cevap gelmeyince çağrılan mesaj tipidir. Aşağıdaki gibi gösterilir.

Çoklu nesne (Multi object): Bir nesne kendi içerisinde birden fazla nesne içeriyorsa bu nesne çoklu nesne olarak tanımlanır ve aşağıdaki gibi gösterilir.

Yorum: Diyagramın kim tarafından, ne zaman oluşturulduğunu ve kapsamını tutan bileşendir. Bilgi amaçlı olarak sağ üst köşeye konulabilir.

Karmaşık sistemler, tasarlanan görevlerine yerine getirmek için ortaklaşa çalışan bir çok nesne içermektedir. UML içindeki işbirliği diyagramları temel olarak bu nesneler arasındaki ilişkiye yoğunlaşırken dizge diyagramları mesaj sırası ile ilgilenmektedir. Her iki diyagram da pek çok noktada ortaklık gösterir. Aralarındaki farklara bir göz atmek istersek:

• Dizge diyagramları, zamana bağımlı olarak nesneler arasındaki mesajlaşmayı gösterir. İşbirliği diyagramları ise zamandan bağımsızdır.
• İşbirliği diyagramları ile tek bir diyagram üzerinde dinamik yapıyı ve nesnelerin statik ilişkisini göstermek mümkündür. Dizge diyagramları ise sadece dinamik yapıyı temsil eder.
• Dizge diyagramları ilk analiz safhasında oluşturulurken işbirliği diyagramları daha çok tasarım aşamasında oluşturulur.
• Dizge diyagramlarından mesajlaşma sıraları, işbirliği diyagramlarında ise ilişkiler daha kolay gözlemlenir. Büyük diyagramlar için işbirliği diyagramlarını takip etmek zorken dizge diyagramlarında bu iş daha kolaydır. Ancak işbirliği diyagramları daha az alanda daha çok bilgiyi gösterebilir.
• Belirli bir amacı yerine getirmek üzere bir araya gelen nesneler arasındaki ilişkiler işbirliği diyagramları ile daha rahat görülür. Yine genel resmi görmek işbirliği diyagramları ile daha kolay olmaktadır.
• Dizge diyagramlarındaki bir bağlantı bir nesneden diğer bir nesneye giden mesajı gösterirken işbirliği diyagramlarındaki bir bağlantı nesneler arasındaki bir ya da daha fazla mesajı gösterebilir.
• Dizge diyagramlarında nesnelerin yaratılışı ve sonlandırışı daha kolay görülür. İşbirliği diyagramında ise aynı iş bu kadar kolay gerçekleştirilemez.
• İşbirliği diyagramlarında zaman kavramı olmadığı için bir nesnenin ne zaman aktif ne zaman pasif olduğunu anlamak zordur. Bunu anlamak içn mesaj tiplerini incelemek gerekmektedir. Fakat dizge diyagramlarında bunu kavramak çok kolaydır.
• İşbirliği diyagramları daha karışık dallanmalara (branching) ve eş zamanlı akış denetimine (concurrent flow of control) izin verirken dizge diyagramları doğası gereği çok daha basit dallanmalara müsaade etmektedir. Bu yönüyle işbirliği diyagramları daha karışık sistemleri modelleyebilmektedir.

Nesneler, diğer UML diyagramlarında olduğu gibi belirli görevleri gerçekleştirmek üzere tanımlı yapı bloklarıdır. Dizge diyagramında nesneler, diyagramında fiziksel olarak en üstten alta ve soldan sağa okunur. Her bir nesnenin altından çıkan kesikli çizgi zaman çizgisini (timeline) göstermektedir. Kesikli çizgi zaman akışını gösterirken üzerinde bulunan ince uzun dikdörtgenler o nesnenin zaman içerisinde meydana getirdiği aktivitelerdir. Her ne kadar teorik olarak dikdörtgenin uzunluğu aktivitenin uzunluğu ile doğru orantılı olsa ve da genellikle bu kurala pek uyulmaz.

Mesajlar bir nesnenin zaman çizgisinden diğer bir nesnenin zaman çizgisine doğru çizilen ok şekillerinden oluşmaktadır. Nesnelerin birbirleri ile haberleşmesi, birbirlerine gönderdikleri komutları temsil eden bu oklarla gösterilir. Bir nesne başka bir nesnenin dışında kendine de mesaj gönderebilir (öz yineleme – recursion). Bunun yanında, Actor gibi nesne olmayan UML bileşeni de nesnelere meaj gönderebilir.

Dizge diyagramlarında 3 çeşit mesaj tip kullanılmaktadır.

Basit (Simple) mesaj: Bu mesaj tipi bir nesnenin akış kontrolünü diğer bir nesneye verdiği durumlarda kullanılır. Sık kullanılan bir mesaj tipi değildir. Gösterimi aşağıdaki gibi olmaktadır:

Senkron (Synchronous) mesaj:Bir nesnenin mesajı gönderdikten sonra, zaman çizelgesinde devam edebilmek için karşı nesneden cevap beklemesi gereken durumlarda kullanılır. Varsayılan mesaj tipi olduğundan sıklıkla kullanılmaktadır. Gösterimi aşağıdaki gibidir:

Asenkron (Asynchronous) mesaj:Senkron mesajların aksine bir nesnenin mesajı gönderdikten sonra, zaman çizelgesinde devam edebilmek için karşı nesneden cevap beklemesi gerekmediği durumlarda kullanılır. Sıklıkla asenkron işlemesi gereken komut zincirlerinde kullanılmaktadır. Gösterimi aşağıdaki gibidir:

Aşağıdaki örnek, Sınıf1 nesnesinin Sınıf2 nesnesine bir mesaj göndermesi ile başlamakta olup Sınıf3 son mesajı alıncaya kadar farklı nesneler arasındaki mesaj alışverişi ile devam etmektedir.

Aşağıda ise biraz daha karmaşık bir örnek görülmektedir. Açık mavi dikey kutular nesnenin aktif olduğu süreci gösterirken yeşil kesikli çizgi ise nesnenin ömrünü göstermektedir. Yeşil dikey kutular ise o anda kontrolü elinde tutan nesneyi ifade eder. Turuncu kutu ise nesnenin yok edildiğini belirtir. Bu diyagram aynı zamanda bir nesneye mesaj gönderilme koşullarını gösterir. Koşul, mesajın yanına köşeli parantez içerisinde yazılır. Örneğin aşağıdaki örnekte Sınıf2’nin Sınıf3’e mesajını gönderebilmesi için [koşul] ifadesi sağlanmalıdır.

Sonraki diyagram, bir sipariş alımı için olan dizge diyagramının başlangıç kısmını göstermektedir. “Sipariş Giriş Penceresi” adında bir nesne yaratılmakta ve siparişin hazırlanması için Sipariş nesnesine mesaj göndermektedir. Diyagramda nesne isimlerinden sonra iki nokta üst üste konulduğuna dikkat ediniz. Şekilde nesnelerin türedikleri sınıf adları belirtilmemiştir. Buna rağmen “nesneAdı : sınıfAdı” biçiminin korunması için iki nokta üst üste işaretinin kullanılması gerektiğini unutmayınız.

Daha sonra Sipariş nesnesi ürünün stokta olup olmadığına bakmakta ve eğer [StoktaVar] koşulu sağlanırsa “Sipariş Edilen Ürün” nesnesine mesaj göndermektedir.

Bir sonraki diyagramda ise Sipariş nesnesine koşullu mesaj eklenmiştir. Eğer ürün [StoktaYok] koşulunu sağlarsa “Sipariş Giriş Penceresi” nesnesine ürünün kalmadığını belirten bir mesaj gönderir.

Etkileşim diyagramları ne zaman kullanılır

Etkileşim diyagramları bir use case içerisindeki farklı nesnelerin davranışlarını modellemek istediğimizde kullanılır ve davranışı oluşturmak üzere nesnelerin ne şekilde işbirliği yaptıklarını ortaya koyar. Etkileşim diyagramları davranış ile derinlemesine bilgi vermediğinden belirli bir nesnenin farklı use case’ler için nasıl davrandığını görmek için durum diyagramlarını kullanınız.

Etkileşim diyagramları nasıl çizilir

Dizge diyagramları, Ortak çalışma diyagramları ve ikisi bir arada nesnelerin bir use case içerisindeki etkileşimlerini göstermek üzere kullanılabilir. Dizge diyagramları genel olarak oluşan olayların sırasını gösterir. Ortak çalışma diyagramları ise nesnelerin statik olarak birbirlerine bağlantılarını gösterir. Her iki diyagram da ortak elemanlar içerirler ve çizimleri kolaydır.