ICONIX Nedir?
Iconix temelde UML ve Agile Metodolojilerin(XP, Crystal vs) tarif ettiği yöntemleri derleyip toparlayan bir metodolojidir. Daha ayrıntılı bilgi için buraya bakınız.
Bu sayfada Iconix'in kullanılmasını tavsiye ettiği UML digramlarını ele alıyoruz. Diğer yandan Iconix'in bir süreç olarak da yapılmasını önerdiği bazı şeyler var ki (örneğin iletişimle ilgili, testeler ile ilgili) bunları gerekirse başka bir konu altında ele almayı planlıyorum.
Kullanacağımız Diagram Tipleri
- Domain Model (static)
- Use Case Model (dynamic)
- Robustness Diagram (dynamic)
- Sequence Dİagram (veya CRC kartları) (dynamic)
- Class Model (static)
Bu digram tiplerinden static olanlar geliştirdiğimiz yazılımı oluşturacak olan parçaların (model, view ve controller olarak da ifade edebiliriz) davranışları ile ilgili herhangi bir fikir vermezler, dynamic olanlar daha çok davranış ve akışa yönelik bilgi içermektedirler.
Takip Etmemiz Gereken Adımlar
- Domain Modelin çıkarılması
- Use case diagramının oluşturulup, use case'lerin yazılması
- Robustness diagramlarının çizilmesi
- Sequence diagramlarının çizilmesi (veya alternatif olarak CRC kartlarının oluşturulması)
- Class diagramlarının çizilmesi.
Domain Model
Domain modeli ayrıntı ve davranışsal (fonksiyonel) özellikler içermeyen class diagramları olarak da düşünebiliriz. Domain model proje ile ilgili ortak bir dil geliştirebilmek açısından önemlidir. Ortak bir dil geliştirilmiş olmasına bağlı olarak projenin ilerleyen aşamalarında iletişim ile ilgili ciddi bir fayda sağlanabilmektedir. Domain model projenin başlangıcında oluşturulmalı ancak ilerleyen aşamalarda gerekirse güncellenmelidir. Domain model Class Modelinin temelini oluşturuacaktır, iyimser bir tahminle kullanacağımız class'ların 80%'i domain modelin oluşturulması sırasında kendini belli edecektir.
Domain Model proje ile ilgili elde edilmiş olan müşteri görüşmelerinin sonuçlarına ve geliştiricilerin/tasarımcıların konu ile ilgili deneyimlerinden elde edilen bilgilere dayanılarak oluşturulmaya başlanılır, ancak use case'ler yazıldıkça da güncellenebilmektedir.
Domain Model'i Oluşturmak için kullanabileceğimiz en basit yöntem elde bulunan materyal üzerinde isim/fiil analizi yapmaktır. Bu analizde
- İsimler ve isim tamlamaları class veya class attribute (property) olarak değerlendirilirken
- Fiiller de bu class'lar üzerinde birer method olmaya adaydırlar.
Örneğin: Kullanıcılar ilan veren diğer kullanıcılara mesaj atabileceklerdir.
Bu örnekte "Kullanıcı", "ilan" ve "mesaj" birer isim oldukları için class olarak değerlendirilebilirler, "göndermek" ise bir method olarak düşünülebilir. Sonuçta şöyle bir domain model ile bu materyali şu şekilde ifade edebiliriz.
Use Case Model ve Use Caseler
Sistemin işlevselliği ile ilgili en fazla 2'şer paragraflık anlatımlardır. Use Case'ler mümkünse domain kullanıcıları tarafından yazılmalıdır, eğer bu mümkün değilse tasarımı yapanlar veya geliştiriciler kullanıcılar ile yaptıkları görüşmeleri Use Case'ler şeklinde düzenlemelidirler, bu noktada belirsizlikleri en aza indirebilmek için kullanıcılarımıza mümkün oldukça fazla soru sormakta fayda vardır. Use Case'lerin tamamını bir Use Case diagramında toplayabileceğimiz gibi Use Case'leri gruplayarak da birden fazla diagram oluşturabiliriz. Use Case diagramı kuş bakışı sistemin çalışması ile ilgili fikir edinmemizi sağlarken, use case'ler robustness analizi için temel oluşturmaktadırlar.
Örnek: Ev ve oda ilan vermek için kullanılması öngörülen bir sistemin Use Case Diagramı şu şekilde ifade edilebilir.
Bu diagramdaki her oval aslında bir adet use case'i ifade etmektedi ve her biri için mümkünse en fazla 2'şer paragraflık ayrıntı yazmamız gerekiyor. Şöyle ki:
İlan Oluştur: Kullanıcıya oluşturmak istediği ilan tipi seçtirilir. İki tip ilan vardır A) Kullanıcı ev veya oda arıyordur, B) kullanıcı ev veya oda arkadaşı arıyordur. Kullanıcının seçtiği ilan tipine göre girebileceği zorunlu ve seçenekli bilgiler gösterilir. (Her iki tip ilan için zorunlu ve opsiyonel alanları belirtebiliriz) Kullanıcı zorunlu bilgileri girmediyse sistem tarafından uyarılırı ve bu bilgileri girmesi istenir. Bilgiler girildiyse ve kullanıcı ilan için yayınlama tarih aralığı belirttiyse ve sistem tarihi bu aralıkta ise ilan sisteme kaydedilir ve sistemde yayınlanmaya başlar. Bir ilanın sistemde yayınlanması bu ilanın aramalarda listelenebilmesi için gereklidir.
İlanlarımı Listele: Kullanıcı ilanlarım linkini kullanarak kendi ilanlarını listesine ulaşacaktır. İlan listesi ilan tipine göre gruplanmış iki grup şeklinde gösterilecektir, yani iki liste gösterilecektir. Listede her bir ilan için açıklama bilgisi, ne zaman yaratıldığı, yayında ise yayın tarih aralığı , şehir ve ilçe bilgisi gösterilir. Kullanıcı her bir ilanın için gösterilen Güncelle linkine basarak İlan Güncelleme sayfasına gönderilir.
Robustness Diagram
Robustness diagramının amacı Domain Modelde göz ardı ettiğimiz classlar varsa bu classların ortaya çıkarılmasını sağlamaktır. Diğer bir deyişle Robustness diagramı use case'ler vasıtasıyla Domain Modelin sağlamasını yapabilmek için kullanılır. Her bir use case için bir robustness diagram çizmemiz önerilir, ancak birbiriyle yakından ilişkili olan birden fazla use case için de tek bir diagram çizebiliriz.
Robustness diagramını çizerken bir yandan da Domain Modeli gözümüzün önünde tutmamız faydalı olacaktır, böylece anında eksik classları domain modele ekleyebiliyor olacağız. Robustness diagramı çizerken bir programcı olarak değil bir domain user olarak sisteme bakmamız gerekiyor, yani bu diagramı çizerken gözümüzün önüne programlamaya yönelik yapılar değil domainde işin nasıl yapıldığı ile ilgili fikirler canlanmalı.
Bu diagramların mümkün oldukça kolay ve hızlı çilizebiliyor olması gerekiyor. "Use case başına en fazla 2 paragraf açıklama" kuralının faydasını tam da bu noktada görebiliriz. Use caselerimiz ne kadar kısa olursa robustness diagramlarımızın çizimi de o derece kolay ve hızlı olacaktır. Dolayısıyla bu diagramlar amaçlarını yerine getirdikten sonra (domain model ve use caseler arasındaki bağlantıyı sağlamak) projenin ilerleyen aşamalarda mutlaka güncellenmesi gerekir gibi bir kaygımız olmasına gerek kalmayacaktır. Yani kısa ve öz use case = çizimi ve anlaşılması kolay robustness diagram dolayısıyla her defasında use caseler için ihtiyaç duydukça yeni robustness diagramı çizebiliyor olacağız.
Rıbustness Diagramlarının çiziminde UML Objectory Stereotype'ları arasında yer alan boundaty, entity ve control simgeleri kullanılmaktadır. Bu simgeler söyle çizilir
Boundary Objects: Kullanıcının sistemle etkileşimdebulunmak için kullanacağı objeleri ifade etmek için kullanılırlar. Örneğin arama sayfası (SearchPage), arama sonuçlarının (AdSearchResultsPage) ilan güncelleme sayfası (AdEditPage) ve ilan ayrıntı görüntüleme sayfası (AdDetailPage) birer boundary object olarak değerlendirilebilir.
Entity Objects: Domain modelde yer alan objeleri temsil etmek için kullanılır. Aslında sadece data taşıyan objeleri temsil ederler de diyebiliriz. Örneğin ilan listesi (AdCollection) veya Section Listesi (Sections) entity object olarak düşünülebilir.
Control Objects: Boundary ve entity objeleri arasındaki etkileşimi ifade etmek için kullanılırlar. Örneğin arama yapma (Find Advertise), ilanı kaydetme (Save Advertise) gibi işlemleri contro object olarak değerlendirebiliriz.
Bahsedilen stereotypelar sıkça kullanılan MVC (Model-view-controller) yaklaşımı ile yakın bir benzerliğe de sahiptir. Özellikle diagramları çizerken ve implementasyon sırasında MVC benzetmesi size çok faydalı olacaktır. Şöyle ki
Entity Objects = Model
Boundary Objects = View
Control Objects = Controller
şeklinde düşünebilirsiniz.
Örnek-1: İlan arama Use Case'i için çizilebilecek robustness diagramı şu şekilde olabilir. Bu use case başka use caselere precedes ile bağlandığı için yani başka use casler ilan aramanın yapıldığını varsaydığı için aynı zamanda bir package olarak da ifade etmemiz uygun olacaktır.
Örnek-2:İlan sahibine mesaj gönderme Use Case'i için çizilebilecek robustness diagramı şu şekilde olabilir.
Sequence Diagram
Amacı domain modelde tasarladığımız ve robustness analizi ile eksiklerini giderdiğimiz classlarımıza (objeler mi desek acaba) fonksiyonalite kazandırmak. (İngilizcesi "Allocate behaviour to our objects"). Sequence diagramlarda robustness analizinde kullandığımız boundary, entity ve control objelerine ilave olarak lifeline, activation line ve diğer bazı yeni kavramlar kullanıyoruz. Tekrar belirtmek gerekirse burdaki temel amacımız claslarımıza (objelerimize) davranış/fonksiyonalite kazandırmak. Sequence diagramları oluştururken artık programcı gibi düşünmeye başlayabiliriz, çünkü bu aşama implementasyon için ihtiyaç duyacağımız class diagramını oluşturmamız için bize önemli bilgiler sağlayacaktır.
Temel fikir use case başına bir sequence diagram çizmek olup daha önce bahsettiğimiz "Use case başına en fazla 2 paragraf" önerisine uymanın faydasını bu diagramları çizerken de göreceğiz. Kısa ve öz use case = daha kolay çizlen ve okunabilen sequence diagram.
Örnek: İlan sahibine mesaj gönderme Use Case'i için şöyle bir sequence diagram çizebiliriz.
Sequence diagramda yer alan bazı sembolleri şunlardır:
Lifeline: Bir boundary, entity veya control objesinden (genel olarak ilgili stereotype) aşağı doğru çizilen kesikli çizgidir. Lifeline, stereotypelar arası mesajlaşmaları belirtmek için bir bağlantı noktası olarak kullanılır. Örneğin bir stereotype'ın lifelineından başlatılan mesaj kuvvetle muhtemel (lost message ve found message kavramlarını işin içine katmıyoruz) ya başka bir stereotypeın lifelineında sonlanır veya kendi üzerinde sonlanır (Mesaj recursive ise)
Activation Rectangle: Bir stereotypein aktif olduğu zamanı belirtmek için kullanılan ve lifeline üzerine çizilen içi boş bir diktörgendir. Örnekte yer alan AdvertiseSearchForm'un activation rectangle'ına bakınca şöyle bir anlam çıkarabiliriz Search mesajı gönderilir gönderilmez AdvertiseSearchForm'un işi biter.
Mesajlar: Implementasyon sırasında classlar üzerinde implemente edeceğimiz methodları temsil ederler. Mesajlar için parametre ve dönüş tipi belirtebiliriz. Şöyle ki MesajAdı(param1, param2): dönüş tipi
Mesaj Çağırısının Dönüşü (Return): Mesaj çağırılarımızın dönüşünü ifade etmek için kullanılmaktadırlar ve Mesaj ile benzer özellik taşımaktadırlar. Mesajlardan farkı kesikli çizgi ile ifade edilmeleridir.
Sequence diagramlarla ilgili daha ayrıntılı bilgiyi buradan edinebilirsiniz.
CRC (Class-Responsibility-Collaborator) Kartları
Sequence diagramları UML camiasında çok formel bulundukları için ve özellikle de looplar gibi bazı durumları ifade etmek biraz karmaşık (hem çizmesi hem de anlayıp okuması) olduğu için bunların yerine daha basit bir yöntem olarak CRC (Class -responsibility-collaborator) kartlarının kullanımı pratiklik açısından önerilmektedir. CRC kartları Object Oriented konseptleri anlatmak için önerilmiş olmalarına rağmen etkin bir modelleme aracı olarak da kullanılamktadırlar.
CRC kartlarını çizmek oldukça kolay olup tüm sistem için tüm bilgileri içeren kocaman kocaman bir yığın CRC kart çizmek yerine use case'lerimizin her biri için use case'de belirtilen işlevi temsil eden daha kopmakt ve daha az sayıda CRC kartları çizebiliriz. Ancak her iki durumda da class diagramını oluştururken CRC kartlarına göz atmamız uygun olacaktır.
CRC kartları ile ilgili daha ayrıntılı bilgiye buradan ulaşabilirsiniz.
Konu ile ilgili tavsiye ettiğim kitap:
"Agile Development with ICONIX Process: People, Process, and Pragmatism" by Doug Rosenberg , Mark Collins-Cope , Matt Stephens
Daha fazla bilgi