MaxiASP.Net [beta]

Brain Harry dün akşam saatlerinde blogundan yayınladığı detaylı bir yazı ile Visual Studio 2010 ve TFS 2010 için SP1 Beta'ların hazır olduğunu duyurdu.

Müşterilerden gelen ve kendilerinin buldukları 900 ile 1000 arasında bug'ın çözüldü, yeni bazı özelliklerin geldiği SP1'in de yakında yayınlanması bekleniyor. Ancak SP1, "Go Live" lisansı ile geliyor, yani üretim (canlı) ortamına yüklenebilir ve SP1'in nihai sürümü çıktığı zaman da kolayca nihai sürüme yükseltilebilir demek.

İlk aşamada MSDN abonelerine açılan indirme bağlantıları, Perşembe günü de diğer müşterilere açılacak.

MSDN üyesiyseniz buraya tıklayarak ilgili indirmelere ulaşabilirsiniz.

MSDN üyesi değilseniz aşağıdaki linkler Perşembe günü aktif olacak.

• .NET Framework 4 Update Beta
• VS 2010 SP1 Beta (.Net Framework 4.0 Güncellemesini İçeriyor)
• TFS 2010 SP1 Beta (.Net Framework 4.0 Güncellemesini İçeriyor)

TFS, TFS, Visual Studio, Visual Studio, Duyurular, Duyurular visual studio, visual studio, tfs, tfs, team foundation server, team foundation server, sp, sp, service pack, service pack

Layer (Katman) Diyagramları

Visual Studio 2010 Architecture Tools ile gelen diyagramların sonuncusu Layer (Katman) Diyagramlarıdır.

Yazılım ile belli bir süreden fazla uğraşan herkes katmanlı mimarileri duymuştur, özellikle üç katmanlı mimari son derece popülerdir. Mimarisel anlamda katmanlar, bir arada uygulamanın sağlıklı bir şekilde çalışmasını sağlayan; ancak birbirinden görev (genelde göreve göre ayrılırlar) bakımdan ayrılarak özelleşen yapılardır. En bilinen katmanlar, UI (User Interface - Kullanıcı Arayüzü), Business Layer (İş Katmanı), DAL (Data Acess Layer - Veri Erişim Katmanı). Bu katmanlar isimlerinden de anlaşıldığı işler için özelleşmiş durumdalar ve aralarında belli bir ilişki bulunuyor. Örneğin kullanıcı arayüzü katmanının amacı sadece kullanıcıya bilgileri göstermek ve kullanıcıdan gelen bilgileri diğer katmanlara iletmek ya da iş katmanının amacı veri erişim katmanından aldığı verileri işleyip kullanıcıya göstermek için kullanıcı arayüzü katmanına iletmek veya tam tersi bir işlemi yürütmek. Bu tür katmanların oluşmasının temel bir sebebi vardır, her bir katman kendine ait görevi yürütürken, aralarında kurulan ilişkinin dışına çıkmaz. Örneğin kullanıcı arayüzü katmanı kesinlikle, doğrudan veritabanına ulaşmaz; çünkü bu iş veri erişim katmanının görevidir.

Katmanlı mimari basitçe yukarıda anlatılan gibidir; ama çok daha detaylıdır. Bu konuda Cenk Çağlar'ın Katmanlı Mimari Nedir? yazısına veya Wikipedia'daki Multitier Architecture maddesine bakabilirsiniz.

Katman diyagramları da Visual Studio 2010 ile geliştirdiğiniz uygulamaların katmanlarını tasarlamanızı ve en önemlisi oluşturduğunuz mimarinin doğru şekilde uygulandığını kontrol etmekte kullanılır.

Katman Diyagramları Oluşturmak

Katman diyagramlarını tam manası ile kullanabilmek için kod projeleriniz ile aynı solution içinde bulunan bir Modelling Project içinde bulunmalıdır.Önceki yazılarımızda tasarladığımız HERA IK sistemi örneğinden devam edecek olursak, artık tasarımlarımızı koda dönüştürmek için HERA isimli bir solution oluşturuyoruz. Daha sonra bu Visual Studio'nun Architecture menüsünde bulunan New Diagram'a tıklayınız. Açılan ekrandan Layer Diagram'ı seçiniz ve bir isim veriniz.

İsim verdikten sonra "OK" düğmesine basarak devam ediniz. Yeni bir proje oluşturma penceresi açılacak ve sizden Modelling Project için bir isim girmenizi isteyecek. İsim girip OK düğmesine basınız. Böylece hem katman diyagramınız oluşacak hem de solution'ınız için bir tane Modelling Project oluşacak.

Katman Diyagramına Katman Tanımlamak

Bir katman diyagramında katmanlar, yukarıdaki ekran görüntüsünden de görülebileceği üzere mavi dikdörtgenler şeklinde ifade edilir. Bizim sistemimizde temelde üç tane katman olmasını planladığımız için üç tane mavi dikdörtgen görülüyor. Henüz bu katmanlar ile herhangi bir kod ilişkilendirilmediği için bunlar "unlinked" durumundalar.

Katman diyagramına artifact (artifact kelimesi benim bir türlü tam manasıyla tercüme edemediğim bir kelime. sözlük anlamıyla "insan eliyle yapılmış şey" olsa da, burada ifade edilen anlamı yazılan kod, sınıf, kütüphane, kontrol vs..) eklemenin birden fazla yolu vardır.

• Solution Explorer: Solution explorer'dan sürükleyip katman diyagramına bırakacağınız bir kod veya proje kendine ait bir katman içerisinde görünür. Ayrıca tıklandğında ilgili koda gidilmesi için aralarında bağlantı olur.
• Architecture Explorer: Architecture Explorer'da bulunan elemanlardan namespace gibi katman diyagramına konabilecek nesneleri, sürükle bırak yöntemi ile katman diyagramına ekleyebilirsiniz.
• Dependency Graphs: Dependency Graphs'te bulunan elemanlardan da sürükle bırakla katman diyagramına eleman ekleyebilirsiniz.

Katman diyagramına tek tek artifact'lar ekleyebileceğiniz gibi, birden fazla elemanı da topluca seçip ekleyebilirsiniz. Böyle bir durumda tüm artifact'lar tek bir katman içerisinde gruplanacaktır.Eğer yine de tüm artifact'ların her biri için ayrı gruplar oluşması isteniyorsa SHIFT tuşuna basılması gerekiyor.

Katman diyagramına önceden katmanları çizip, sonradan artifact'ları içine sürükleyip bırakabilirsiniz. Sürükleyip bıraktığınız zaman artifact ile katman arasında bir bağlantı oluşur.

Diyagramınızdaki katmanalara, artifact'lar eklediğiniz zaman sağ üst köşelerinde sayılar göreceksiniz. Bu sayılar o katmana bağlanmış olan artifactların sayısını gösterir. Örneğin yukarıdaki örnek için hazırladığım HERA isimli web uygulamasını HERAUI katmanına, HeraBusinnessServices WCF servisini HeraBusinnessSerives katmanınına ve HeraDAL kütüphanesini ise HeraDAL katmanına sürükleyip bıraktığım zaman hepsinde aşağıdaki gibi 1 sayısı görünecektir.

Peki katmanların içine sürükleyip bıraktığımız yani ilişkilendirdiğimiz artifactları nasıl görebiliriz? Bu özelliği bize Layer Explorer sağlayacak.

Layer Explorer

Layer Explorer katmanlarla ilişkilendirilmiş olan artifactların gösterilmesini sağlar. Layer Explorer'ı açmak için herhangi bir katmana sağ tıklayıp açılan menüden "View Links" seçeneğine tıklayarak Layer Explorer'ı açabilirsiniz.

Eğer katman diyagramında boş bir yere tıklarsanız yani hiç bir katman seçili olmazsa, Layer Explorer katman diyagramındaki tüm katmanları ve bu katmanlara bağlı artifact'ları listeler. Ayrıca Layer Explorer, katmanlarla ilişkilendirilmiş artifactların düzenlenmesini de sağlar. Yani bir katmandan artifact silebilir, artifact'ı taşıyabilir ya da bir artifact'ı birden fazla katmana ekleyebilirsiniz.

Katmanlar Arası Bağımlılıklar

Katman diyagramının amacı tabi ki sadece artifact'ları gruplamak değildir; temel amaç bu katmanlar arasında bağımlıklar tanımlamak ve bunları kontrol altında tutmaktır. Burada bağımlıklıktan kasıt, katmanların birbirleri arasındaki ilişkidir, örneğin kullanıcı arayüzü katmanının iş katmanında bulunan bir sınıfı kullanması gibi.

Katman diyagramı, katmanlar arasındaki ilişkiyi proje referanslarından bulabileceği gibi, siz de elle bu ilişkiyi tanımlayabilirsiniz. Normal şartlarda Solution Explorer'dan artifact eklerken, referansları doğru şekilde tanımlanmış ise katman diyagramı bağımlılıkları otomatikman oluşturur.

Katmanlar arasında elle ilişki oluşturmak için Toolbox'ta bulunan Dependency nesnesini kullanabilirsiniz. Dependency nesnesini seçtikten sonra, öncelikle referansı kullanan katmana sonra da referans edilen katmana tıklarsanız, iki katman arasında bir bağlantı oluşur. Bu bağlantı tek taraflı bir ilişki ya da bağımlılıktır.Bu tür ilişkide katmanlardan sadece biri, diğer katmandaki bir veya daha fazla sınıfı kullanır. Bazı durumlarda her iki katmanda birbirine bağımlı olabilir. Bu durumu da Bidirectional Dependency kullanarak tanımlayabilirsiniz.

Katmanlar Arası Bağımlılıkları Doğrulamak

Yazımızın biraz üst tarafında katman diyagramlarının bir amacı da tanımladığımız bağımlılıkları kontrol altında tutmaktır dedik. Bunun anlamı bizim tanımladığımız veya otomatik olarak oluşan bağımlılıkların bozulup bozulmadığını kontrol etmektir.

Yazılım süreci, özellikle kalabalık ve dağıtık ekiplerde, çok dinamik bir süreçtir. Aynı anda birçok yazılımcı koda müdahele ederler. Bazı durumlarda da bu müdahaleler sırasında başta tasarlanmış olan mimariyi bozabilecek kodlar sisteme eklenebilir. Katman diyagramı, sağladığı doğrulama imkanı ile sisteme eklenen ve mimariye ters düşen bu tür kodların tespit edilmesini ve derlemenin (build) bozulmasını sağlar. İstenirse bu doğrulama, Team Foundation Server Build sistemine bağlanarak alınan her build ile çalışması sağlanabilir.

Katman diyagramını doğrulamak için katman diyagramında boş bir yere sağ tıklayıp "Validate Architecture" komutunu seçin. Komut verildikten sonra Visual Studio katmanlardaki kodları derleyerek, tanımlanan bağımlılıklara aykırı bir durum olup olmadığını tespit eder.

Bizim bu örnekte kurduğumuz sistemde web uygulaması, WCF servislerine, WCF servisleri de sınıf kütüphanesine bağımlı.Bunların tam tersi ise Visual Studio açısından hata olarak kabul edilecek. Yani WCF servisinden, HeraDAL sınıf kütüphanesindeki sınıflara ulaşabilirken tam tersi hatalıdır.Bu durumu test etmek için web uygulamasından doğrudan HeraDAL'daki bir sınıfa ulaşarak diyagramı doğrulayalım.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using HeraDAL;
namespace HERA
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            BaseClass baseClass = new BaseClass();
        }
    }
}

Yukarıdaki kod web uygulamasının ana sayfasını oluşturan default.aspx'e ait code-behind dosyası. Görüldüğü üzere burada öncelikle HeraDAL namespace'ine doğrudan ulaşılıyor ve BaseClass isimli sınıfın bir örneği oluşturuluyor. Bu durum bizim yukarıdaki tasarımımıza aykırı, kodu bu şekilde kaydedip katman diyagramına sağ tıklayıp "Validate Architecture" komutunu seçtiğimiz zaman aşağıdaki hatayı görebiliriz.

Visual Studio'nun Error List ekranında aşağıdaki hatalar görünür.

Error 2 AV0001 : Invalid Dependency : HERA(Assembly) --> HeraDAL(Assembly)
Layers: HERAUI, HeraDAL | Dependencies: References D:\ALM\HERA\HeraModels\HeraKatmanlar.layerdiagram 0 0 HeraModels
Error 1 AV0001 : Invalid Dependency : HERA._Default.Page_Load(Method) --> HeraDAL.BaseClass.BaseClass(Method)
Layers: HERAUI, HeraDAL | Dependencies: Calls D:\ALM\HERA\HeraModels\HeraKatmanlar.layerdiagram 0 0 HeraModels

Hata doğrudan bize HERA uygulamasından HeraDAL uygulamasına geçersiz bir bağımlılık kurulduğunu gösteriyor. Hataya çift tıkladığımız zaman da doğrudan hatalı koda ulaşıyoruz.

Gerçek hayatın her noktasında olduğu gibi, yazlımda ve katman diyagramlarının doğrulanmasında da bir workaround (etrafından dolaşma) yöntemi bulunuyor. Yani bu durumu biliyor; ancak bu şekilde kalması gerektiğini düşünüyorsanız hatayı görmezden gelmek istiyorsanız hataya sağ tıklayarak açılan menüden Manage Validation Errors -> Suppress Errors komutunu seçerseniz Visual Studio artık bu kodun bir hata olduğunu size bildirmeyecek ve hata listesinde hatayı üstü çizili olarak gösterecektir. İsterseniz aynı yolu izleyerek ancak bu sefer "Hide Suppress Errors" komutunu seçerek hataların görünmesini engelleyebilirsiniz.

Suppress Errors dedikten sonra diyagramı tekrar doğruladığınız zaman aşağıdaki resimde olduğu gibi doğrulamayı geçecektir.

Bir hatayı görmezden gelmek için komut verdiğiniz zaman, Visual Studio bu hataları .suppressions uzantılı bir dosyada saklar. Herhangi bir zamanda hataları tekrar açmak için, bu dosyadan ilgili yerleri silebilir ya da tamamen dosyayı silerek tüm hataları geri getirebilirsiniz.

Katman diyagramınızdaki doğrulamayı yerel makinenizdeki her derleme işlemi sırasında da yapabilirsiniz. Bunun için izlemeniz gereken iki adım bulunuyor.

1. Solution Explorer'dan modelleme projesini açın ve katman diyagramı seçin. Diyagramın özelliklerini açıp, Build Action özelliğinin Validate olarak seçildiğine emin olun.
2. Solution Explorer'dan modelleme projesinin özelliklerini açın. Validate Architecture özelliğini True yapın.

Yukarıdaki adımları tamamladıktan sonra solution'ı derlediğiniz zaman otomatikman doğrulama yapılacak ve başarısız olursa, derleme topluca başarısız olacaktır.

Katman diyagramının en iyi yanlarından biri daha önce söylediğimiz gibi bu doğrulama işlemini TFS 2010 Build'ine bağlayabilmektir. Böylece aldığınız gecelik build'ler veya gated check-in'lerde bu doğrulama çalışacak ve bir hata olması durumunda build başarısız olacak ve bug kaydı açılacaktır.

Bu yazımızda Visual Studio 2010 Architecture Tools'un en güzel diyagramlarından biri olan katman diyagramını inceledik. Bu diyagram ile oluşturduğumuz mimariyi ve katmanları nasıl tasarlayabileceğimizi ve bu tasarımın ihlal edilmediğini kontrol altında tutabileceğimizi gördük. Bu diyagramı büyük bir projeye başlarken genel yapıyı çıkarmak için çizebileceğimiz gibi projenin ilerleyen safhalarında mevcut yapıyı görselleştirmek için de kullanabilirsiniz.

Bundan sonraki yazımızda Visual Studio 2010 Architecture Tools ile ilgili son yazımızda Architecture Explorer ve Dependency Graphs konularına bakacağız.

Visual Studio alm, application lifecycle management, architecture tools, layer diagram, katman diyagramları

Sınıf (Class) Diyagramları

Visual Studio 2010 Architecture Tools ile gelen diyagramları incelediğimiz yazı dizimizin sonuna doğru yaklaşırken sırada Sınıf (Class) Diyagramları bulunuyor. Sınıf diyagramları, önceki diyagramlara nazaran daha çok kullanabileceğiniz ve (açıkçası) onlara göre daha somut görünen bir diyagram.

Bu zamana kadar diyagramlarla, akışlarımızı, işlerimizi, sequence'lerimizi ve bileşenlerimizi tasarladık; ama .Net gibi OOP tabanlı bir yapıda sınıfların aslında herşey olduğunu takdir ediyorsunuzdur. Dolayısı ile en önemli kısımlarından biri de bu sınıfların tasarımını yapmak. Bu noktada hatırlatmam gerekir ki, bu yazı da konu aldığımız sınıf diyagramları, UML Sınıf Diyagramı olarak geçmektedir, bunun dışında .Net Sınıf Diyagramları diye ayrı diyagram Visual Studio'nun içinde bulunuyordu. Bu ikisini birbirinden ayırmamız lazım, bizim biraz sonra bakacağımız diyagram mantık ve tasarım temeline göre yapılıyor, .Net Sınıf Diyagramları ise kod tabanlı diyagramlardır.

Bir sınıf diyagramında temelde üç şey bulunabilir, Sınıf (class), Arayüz (Inteface) ve Enumeration. Tahmin edeceğiniz gibi sınıf ve arayüzler  attribute (öznitelik) ve operasyon (işlem) içerebilirler. Buradaki özniteliği C# veya VB.Net teki sınıf veya özelliklere metadata bilgisi olarak verilen attribute'lerle karıştırmayınız, bu diyagramdaki öznitelikler aslında bizim bildiğimiz sınıflar üzerindeki field (alan) kavramına karşılık geliyor. Operasyon (işlem) ise yine bizim sınıflardan bildiğimiz metotlarımza denk geliyor.Enumertion'lar ise yine OOP'den bildiğimiz enumertion'lara denk geliyor ve içerisinde belli sayıda eleman değeri tutan tiplerdir.

Sınıf diyagramlarında, sınıflar, arayüzler ve enumeration'lar arasında ilişkiler kurulabilir. Bu ilişkiler farklı sınıflar ve arayüzlerdeki özniteliklerin birbirlerine bağlanmasını sağlar. Örneğin benim Calisan isimli bir sınıfım varsa ve içinde Cinsiyet isimli bir öznitelik varsa; ben bunu öznitelik ile Cinsiyetler  enumeration'ı arasında ilişki kurabilirim.

Şimdi örnek bir sınıf diyagramına bakarak konuyu daha iyi anlamaya çalışalım.

Yukarıdaki örnek diyagram HERA IK sistemimize ait bir sınıf diyagram kesidi. Bu diyagramda ilk bakacağımız Calisan isimli sınıf. Sınıfımız şirketteki çalışanların bilgilerini tutacak. Çok karışık görünmemesi için biraz sade tuttum sınıfı. Bir insanın sahip olacağı temel özellikleri öznitelik (attribute) olarak ekledim ki; bunlar Ad, Soyad, Cinsiyet gibi. Bir de çalışan olarak sahip olunan özellikler var, SicilNo, YoneticiSicilNo, Mail gibi. Çalışan sınıfının bazı operasyonları var, BilgiGuncelle(this). Operasyondaki this parametresi kendi örneğini temsil ediyor.

Sınfın sol üst tarafında Calisan - Yonetici yazan bir ok göreceksiniz. Bu çalışanlar ve yöneticiler arasındaki ilişkileri temsil eden bir ilişki (association). Bir çaşışanın üstünde bir yönetici, bir yöneticinin altında birden fazla çalışan olduğu için ilişkinin bir tarafında 1, diğer tarafında * bulunuyor.

Çalışan sınıfımızda Cinsiyet isimli bir öznitelik bulunuyor. Bu özniteliğin tipini bir enumeration'dan alıyoruz. Bu enumeration'da Calisan sınıfımızın altında kahvrengi rengi ve Cinsiyet adı ile bulunuyor. Cinsiyet enumeration'ı ve Calisan sınıfı arasında da bir ilişki bulunuyor.

Çalışan sınıfımızın yanında IzinTalep isimli bir sınıf bulunuyor, bu sınıf çalışanların izin taleplerini tutacak. Çalışanlar ve izin talepleri arasında ilişki olduğu için yine bir ilişki (association) bulunuyor. Bir çalışan için birden fazla izin talebi olabileceği için 1-* şeklinde bir ilişki var. İzin Talep sınıfında ise izin ile ilgili bazı öznitelikler (attribute) bulunuyor. Bunlar izin başlangıç tarihi, bitiş tarihi, vs., ayrıca TalepNo, TalepDurum, TalepTarihi gibi taleplerle ilgili bazı öznitelikler bulunuyor. Ayrıca bu sınıfımızda TalepEkle(this) isimli bir operasyon var. Bu operasyonda, girilen talebin kaydedilmesini sağlıyor.

Sistemimizde IzinTalep gibi farklı talepler olabileceğini düşünüyoruz, örneğin MasrafTalep, AvansTalep gibi; bu yüzden tüm taleplerin standardını sağlamak için bir interface (arayüz) tanımlıyoruz (şekilde en sağda ve yeşil renk ile görülen dikdörtgen). Bu arayüz daha sonra bütün talep sınıflarımıza temel teşkil edecek.

Bir arayüz ile sınıf arasındaki bağlantı, ilişki (association) ile değil dependency ile ifade edilir.Bu yüzden aralarında kesikli çizgilere sahip bir ok ile ifade edilen dependency görülüyor.

Sınıf Diyagramlarındaki Özellikler

Sınıf diyagramlarındaki tüm nesnelerin birçok özelliği bulunuyor. Bu özellikler bazen ilişkinin şeklini, bazen sınıfın yapısını değiştirmek için kullanılıyor.

Tip Özellikleri

Sınıf diyagramlarında tip olarak ifade edilenler class (sınıf), enumeration ve interface'tir (arayüz). Başlıca özellikleri aşağıdaki gibidir.

Öznitelik (Attribute) Özellikleri

Sınıf ve arayüzlerde bulunan özniteliklerin özelliklerini belirler. Başlıcaları aşağıdaki gibidir.

Operasyon Özellikleri

Sınıf ve arayüzlerin sahip olduğu operasyonların özelliklerini düzenler. Başlıcaları aşağıdaki gibidir.

Bu yazımızda Visual Studio 2010 Architecture Tools ile gelen Sınıf (Class) Diyagramlarını inceledik. Sınıf diyagramları artık son aşamalara gelen tasarımımızda önemli bir yere sahiptir. Artık oluşturduğumuz sistemin yapısı genel olarak ortaya çıkmaya başlamıştır. Bu yüzden tasarımın bu aşamasına gereken önemi göstermeniz sizleri daha sonraki aşamalarda rahatlatacaktır.

Bir sonraki yazımızda Layer Diyagram'ları inceleyeceğiz.

Application Lifecycle Management, Visual Studio alm, application lifecycle management, class diagrams, sınıf diyagramları

Microsoft, Visual Studio 2003 , Visual Studio 2005 ve Visual Studio 2008 kullanan ve bu ürünlerden yeni Visual Studio 2010'a geçiş yapmayı planlayan kullanıcılar için ücretsiz bir ebook hazırlamış. Patrice Pelland, Pascal Paré ve Ken Haines tarafından kaleme alınan kitap, üç bölüm halinde mevcut Visual Studio versiyonundan Visual Studio 2010'a geçiş adımlarını ve önerilerini içeriyor.

Kitabı e-book olarak indirmek için | Kitabı XPS olarak indirmek için | Kitabın içinde yer alan kodları indirmek için

Visual Studio, Duyurular microsoft, ebook, visual studio, 2010, 2005, 2008, 2003

Daha önce ki yazılarımızda Use Case, Aktivite ve Sequence diyagramlarından bahsetmiş ve oluşturduğumuz mimarinin genel yapısını ortaya koymaya başlamıştık. Bu yazımızda da daha önce oluşturduğumuz diyagramlarda şematize ettiğimiz sistemi oluşturan bileşenleri şematize etmeye çalışacağız.

Bileşen diyagramları, sistemimizi meydana getiren bileşenlerin (web uygulamaları, windows uygulamaları, harici bileşenler, dış sistemler, COM nesneleri, vb..) birbirleri ile olan bağlantılarını göstermek için kullanılır.

Neredeyse ufak çaplı uygulamaların hepsi tek ortamdan oluşur, yani sadece web ortamı veya windows veya mobil. Oysa ki büyük sistemler, otomasyon uygulamaları gibi uygulamalar birçok dış sistemle etkileşim halindedir. Bir hastane otomasyon sistemi, hastanedeki çalışan bilgilerini tutan IK sistemi ile, faturalama için Muhasebe sistemi ile etkileşim halinde olabilir. Bazen de dış sistemlerden ziyade bizim uygulamamız, bizim yazmadığımız bileşenlerle çalışabilir. Örneğin bir donanımı kontrol etmek için donanım üreticisi tarafından sağlanan bir COM bileşeni gibi.

Uygulamamızın etkileşim içinde olduğu bileşenler ne kadar fazla ise bunların idaresi ve yönetimi zorlaşır. Bileşen diyagramları ise bu bağımlılıkların açıkça görülmesi, haberleşme arayüzlerinin (interface'ler) ifade edilmesinde çok işe yarar. Çünkü oluşturduğumuz veya oluşturacağımız sistemi bu şekilde diyagramlarla planlamak, bize sistemin durumunu daha açık görme şansını verirken, yapılabilecek iyileştirmeler veya yapılması planlanan değişikliklerin etkileri gibi konularda daha gerçekçi fikir sahibi olmamızı sağlar.

Diyagramımızın amacını anlattıktan sonra, "bileşen" kavramına dönelim. Bileşen bizim için, uygulamamızın etkileşim içinde bulunduğu, nasıl çalıştığını, işini nasıl yapıtğını bilmediğimiz (bizim için kara kutu) yapılardır. Bizler sadece bu yapı ile nasıl iletişim kuracağımızı, yani ona nasıl bilgi göndereceğimizi ve ondan nasıl bilgi alacağımızı biliriz. Bize bu bilgiyi sağlayanlarda aslında arayüzlerdir (interface).

Bileşen diyagramında arayüzler ikiye ayrılır; required interfaces (ihtiyaç arayüzleri) ve provided interfaces (sunulan arayüzler). Provided interface'ler bir bileşenin, başka bileşenlerin kullanımına sunduğu hizmetlerini belirler, Required Interfaces ise, bir bileşenin başka bir bileşenden beklediği hizmetleri belirler. Bileşen diyagramlarında her bir required interface, bir provided interface'a bağlanır.

Bu tür diyagramların başka bir avantajı da, ekibe yeni katılan ya da uygulamaya yabancı birinin uygulamanın mevcut tasarımını daha iyi ve hızlı anlamasını sağlamasıdır.

Yukarıdaki resimde örnek bir bileşen diyagramı görülmektedir. Bu diyagram, bugüne kadar makalelerimizde örnek olarak işlediğimiz HERA Insan Kaynakları sisteminin genel yapısıdır. Şekilde görülen bir dikdörtgen yapı bir bileşeni temsil etmektedir. Bu diyagramda, Web Browser, Web Uygulaması, Veritabanı, PDKS ve Muhasebe Bordro Uygulaması bileşenleri görülmektedir.

Bileşenler üzerinde yarım çember (hook) ve daire biçimlerinde (lolipop) görülen şekiller bulunuyor. Bunlardan yarım çember olarak görülen şekil required interface'i, daire olarak görülen şekil ise provided interface'i temsil eder. Biraz önce her required interface'in bir provided interface'e bağlanması koşulu gereği, burada da kesikli çizgilere sahip bir ok işareti ile arayüzler birbirine bağlanmıştır. Şekilden de açıkça görülebileceği üzere, bu interfaceler bileşenler arasındaki haberleşme noktalarıdır. Üzerlerinde yazan isimler ise arayüz isimlerini temsil etmekte olup, teamüller gereği "I" harfi ile başlamaktadır. Arayüzler arasında, bağlantıyı sağlayan kesikli çizgili ok ise Dependency nesnesidir.

Yukarıdaki diyagram bize, HERA Web Uygulaması'nın PDKS, Muhasebe ve HERA Veritabanı ile ilişki içerisinde olduğunu, PDKS'den verileri IPDKSProcesses arayüzüyle aldığını, Muhasebe Bordro Uygulamasından verileri IMuhasebeBordro arayüzü ile aldığını, Veritbabanı ile ise doğrudan bağlı olduğunu gösterir.Ayrıca HERA Web Uygulaması görüntülenebilmesi için bir Web Browser'a ihtiyaç duymaktadır ki "uygulama" ile "browser" arasındaki iletişimi "HERA Web Sitesi" sağlamaktadır.

Bileşen Diyagramları Oluşturmak

Bileşen diyagramı çizmek için modelleme projesinde bulunmanız gerekmektedir. Eğer henüz böyle bir projeniz yok ise öncelikle bir "Modelling Project" oluşturunuz. Ardından oluşturduğunuz projenin adına "Solution Explorer"da sağ tıklayınız ve Add -> New Item yolunu takip ediniz. Açılacak menüden UML Component Diagram'ı seçerek bir isim veriniz. Ardından "Add" düğmesine basarak diyagramı oluşturunuz.

Açılan boş diyagrama ToolBox'ı kullanarak 5 adet Component nesnesi koyunuz. Nesneleri, ya üzerlerinde yazan "Component#" yazılarına çift tıklayarak ya da "Properties" ekranındaki "Name" alanlarını değiştirerek aşağıdaki şekilde düzenleyiniz.

Bileşenlerimiz diyagramımızdaki yerlerini aldıklarına göre artık, bilgiyi sunan veya bilgiyi tüketen bileşenlere göre "Provided Interface" ve "Required Interface" lerimizi yerleştirebiliriz. Bu örnekte PDKS, Muhasebe Bordro Uygulaması ve HERA Web Uygulaması bilgiyi sundukları için onlara araç kutusundan birer tane "Provided Interface" nesnesi koyuyoruz. Web Browser ve HERA Web Uygulaması bilgiyi tüketen, kullanan bileşenler olduğu için de onlara Required Interface nesnesi koyuyoruz. HERA Web Uygulaması'na iki tane Required Interface koyuyoruz ki, tüm Provided Interface'lerin birer tane Required Interface karşılığı olsun.

Arayüzlerimizi koyduktan sonra bu arayüzleri aşağıdaki gibi isimlendiriyoruz.

Artık genel yapı ortaya çıktı sayılır; ancak hala arayüzlerimiz arasında bağlantı yok. Bu bağlantıyı da araç kutusunda bulunan "Dependency" nesnesi ile sağlıyoruz. Dependency nesnesine çift tıklayınız (çift tıklama, tek seferde birden fazla nesneyi ekleyebilmeyi sağlar)  ve önce Required Inteface'lere (çengel, yarım çember) ardında da Provided Inteface'lere (daire, lolipop) tıklayınız. Her seferinde aralarında kesikli çizgilerden oluşan bir bağlantı oluşacaktır.

Diyagram çizmemizin son adımında ise HERA Web Uygulaması ile Veritabanı arasındaki bağlantıyı göstermemiz gerekiyor. Bu bağlantıyı da Dependency nesnesi ile belirtiyoruz, bunun için yine araç kutusundan Dependency nesnesini seçiniz ve önce HERA Web Uygulamasına ardından da HERA Veritabanına tıklayınız. Orada kesikli çizgilere sahip bir ok oluşacaktır.

Bileşenleri Detaylandırmak

Bileşen diyagramları genel yapıyı gösterebildiği gibi herhangi bir bileşenin daha detaylı halini de gösterebilir. Örneğin bizim burada HERA Web Uygulaması dediğimiz bileşen, kendi içinde başka küçük bileşenlerle haberleşiyor olabilir. Bunları da detaylandırarak çizmek tasarımınızın gücünü arttıracaktır.

Konuyu bir örnek ile açıklayalım. Şimdi az önce olduğu gibi yeni bileşen diyagramı oluşturun ve HERAWebUygulamasi.componentdiagram şeklinde isimlendirin.

Açılan diyagrama önce bir tane Component nesnesi ekleyin, ardından bu nesnenin boyutlarını büyütün ve içine iki tane daha Component nesnesi koyun. Ardından aşağıdaki şekilde isimlendirin.

Yukarıdaki diyagramda HERA Web Uygulamasının iç bileşenleri görünüyor ve bu iç bileşenlerden her birine "part" adı veriliyor. Her part'ın kendine ait Provided ve Required Inteface'leri olabilir. Aynen az önce yaptığımız şekilde KutlamaMailServisi ve SGKServisi'ne birer tane Provided Interface koyunuz. Eklediğimiz bu iki arayüze karşılık iki tane de Required Interface eklememiz gerekiyor, ama nereye? Bu iç bileşenleri dahili parçalar olduğunu hatırlarsak, bunların karşılığının dışarıda olduğunu görebiliriz. Ancak bu detay aşamasında biz bunları bilmiyoruz, sadece dışarıya bu bilgileri sağladığımızı iletiyoruz. Bunu da HERA Web Uygulaması'na da iki tane Provided Interface koyarak, bir nevi onlara kapı açarak, yapıyoruz.

Artık diyagramımız son aşamaya geçmeye hazır. İçeride bulunan Provided Interface'leri, dışarı onları temsil edenlerle bağlamamız gerekiyor, bunu da araç kutusundaki "Delegation" nesnesini kullanarak yapıyoruz. Delegation nesnesi ile önce dışarıdaki Provided Inteface'e, sonra içeridekine tıklıyoruz ve aralarında düz bir çizgiye sahip ok oluşarak bu bağlantıyı temsil ediyor.

Bu yazımızda bileşen diyagramı konusunu ele aldık. Bileşen diyagramları artık nasıl bir yapının olacağı konusunun belirlendiği aşamalarda çizilen bir diyagramdır. Bu diyagram ile sistemi oluşturan en ufak bileşenden, en büyük sisteme kadar dahili ve harici parçaları görebilirsiniz. Bu da diyagramı karşınıza aldığınız zaman, size bir binanın teknik tasarımına bakıyormuş hissi verir; çünkü karşınıza gördüğünüz şey kodlar veya görsel arayüz değil; tamamen yapıyı oluşturan elemanlar ve aralarındaki bağlantılardır.

Bu zamana kadar hiç bahsetmediğimizi fark ettiğim için şunu da söylemek istiyorum. Architecture Tools'un Team Foundation Server ile sağlam bir bağlantısı vardır. Tüm diyagramlardaki her nesne birer Work Item ile eşlenebilir, ataması ve takibi daha sistematik olarak sağanabilir. Bu konuyu da ilerleyen yazılarımızda daha detaylı inceyeceğiz.

Bir sonraki yazımızda Class Diyagramlarına bakacağız.

Application Lifecycle Management, Visual Studio alm, application lifecycle management, architecture tools, component diagram, bileşen diyagramları

Sequence (Ardışıklık) Diyagramları

Sequence diyagramları, bir sistemde bulunan sınıflar, bileşenler, alt sistemler ve aktörler arasındaki etkileşiminin sıralamasını ve akışını göstermek için kullanılan diyagramlardır. Ne yazık ki "sequence" kelimesine daha iyi bir Türkçe karşılık bulamadığım için, bu yazıda orjinal ismini kullanmaya devam edeceğim. Ancak merak edenler için; sequence kelimesi ardıllık, ardışıklık, sıralama, vb. anlamlara gelmektedir.

Örnek bir sequence diyagramı aşağıdaki gibidir.

Sequence diyagramları soldan sağa bir elemandan bir elemana olan akışı gösterirken, yukarıdan aşağıda doğru bu akışın zaman bakımından sıralamasını gösterir. Yukarıdaki örneğimiz üzerinden devam edecek olursak, bu diyagram daha önceki yazılarımızda kurmaya başladığımız HERA IK sisteminin Çalışan İzin Talebi ile ilgili olan kısmını ifade ediyor. Bir önceki yazımızda bu işlemin akışını çıkartmıştık, burada da elemanlar arasındaki akışın hangi sırayla olacağını ifade ediyoruz.

Diyagram üzerinde ilk bakılacak şey, dikey çizgiler halinde görülen elemanlardır. Lifeline ismindeki bu elemanlar diyagramımızda konu alacağımız aktörler, sistemler, sınıflar, alt sistemler, bileşenler gibi yapıların hayatlarını ifade ederler. Bizim örneğimizde ki hayat çizgileri aşağıdaki elemanları temsil etmektedir,

• Çalışan - aktör
• "HERA IK sistemi - sistem
• 1. Yönetici - aktör
•  IK Yöneticisi - aktör
• PDKS - dış sistem

Diyagrama tekrar bakacak olursak, aktör olarak görülen elemanların üstlerinde bir "insan" figürü bulunmaktadır. Bu figür diyagram okunurken, kolayca sistemler ve aktörleri ayırmakta kullanılır. Herhangi bir hayat çizgisinin, bir insanı temsil ettiğini göstermek için lifeline nesnesinin özelliklerinden "Actor" özelliği "True" olarak ayarlanmalıdır. Her bir hayat çizgisinin üstünde bir kutu bulunuyor. Bu kutu genel olarak hayat çizgisinin ismini gösterir; ancak yukarıdaki örnekte de dikkat edeceğiniz gibi ilk iki kutuda bir ok simgesi "kısayol işareti" varken, diğerlerinde bulunmuyor. Bunun anlamı, bu kutular daha önceden sistemde var olan bazı diyagram öğelerine bağlı olmasıdır; ok simgesi olmayanlar ise elle araç kutusundan çizilmiş demektir. Ayrıca bu kutunun kenarlarının yuvarlatılmış hali de görülebilir. Bu da bu nesnenin, bir program kodunu temsil ettiğini ve o koddan oluştuğunu gösterirken, bizim örneğimizde olduğu gibi düzgün köşeli bir kutu ise bunların elle çizildiğini ifade eder.

Daha önceki diyagramlarımızda olduğu gibi bu diyagramda da, siyah bir nokta bize belirsiz bir kaynaktan gelen başlangıç sinyalini temsil ediyor. Başlangıç sinyalinin okunun ucunda bulunan gri dikey dikdörtgen kutu ise ilgili eleman tarafından yapılan "işi" temsil ediyor. Diyagramımızda çalışan bir izin talebi oluşturmak istiyor ve diyagramımıza bu bir başlangıç sinyali olarak geliyor. Çalışan HERA IK sistemine bağlanınca, bu bağlantı HERA IK sistemine bir "create message" olarak gidiyor. Sequence diyagramlarında genelde ilk olarak bir "create message" gönderilerek işlemin başlaması temsil edilir.

Çalışanımız sisteme bağlandıktan sonra izin talebi giriyor. Bu talep de bir "asenkron mesaj" olarak HERA IK'ya iletiliyor. Bu noktadan sonra eş zamanlı işlemler yürütülüyor. Bir taraftan istek yönetici onayına gönderilirken bir taraftanda PDKS'e kayıt atılması için gönderiliyor. HERA IK sisteminin hayat çizgisinin sağında bulunan "1. Yönetici" aktörüne giden senkron mesaj onay akışını tetiklerken, en sağda bulunan "PDKS"'e giden asenkron mesaj da kayıt işlemini başlatıyor. 1. Yöneticinin onayından sonra ise "IK Yöneticisi"ne senkron bir mesaj gönderilerek "IK Yöneticisi" onayı talep ediliyor. Yönetici onay işlemleri, bellir bir sırayla gitmesi gerektiğinde cevabı beklenecek şekilde tasarlanıyor ve senkron mesajlar ile ifade ediliyor.

Diyagramımızda asenkron mesajlar tek tarafa doğru giden oklar ile gösterilirken, senkron mesajlar cevabı beklenen ve cevabı gelmeden akışa devam edilemeyen mesajlar olduğu için iki tarafa doğru çizilen iki oka sahip olan şekillerle ifade edilir.

Yöneticilerden onaylar geldikten sonra çalışanımızın isteğinin sonucu yine belirsiz bir sisteme mesaj olarak gönderiliyor ve bu da HERA IK Sistemi hayat çizgisinden çıkan ve siyah bir nokta ile diyagramın sağ tarafında son bulan bir şekil ile ifade ediliyor.

Sequence Diyagramının Çizilmesi

Sequence diyagramı oluşturmak için öncelikle modelleme projemize eklememiz gerekir, bunun için Solution Explorer penceresinden projenin üstüne sağ tıklayarak Add -> New Item yolunu takip ediyoruz. Açılan diyalogtan UML Sequence Diagram'ı seçip, ismini veriyoruz ve Add tuşuna basıyoruz.

Diyagramımız oluşturulduktan sonra boş şekilde açılıyor. Diyagramımıza eleman eklemek için iki yolumuz bulunmaktadır. İlki Toolbox içerisindeki elemanları kullanmak, diğeri de UML Model Explorer penceresini kullanarak daha önce çizmiş olduğumuz diyagramlardaki nesneleri kullanmak. Tabi UML Model Explorer'dan eklenebilecek olanlar sadece sistemler ve aktörlerdir; bunlarla da sadece hayat çizgisi (lifeline) oluşturulabilir. Aradaki mesajlaşmayı göstermek için ise yine Toolbox ta bulunan kontroller kullanılmalıdır.

Diyagram oluşturmaya ilk olarak hayat çizgilerini eklemekten başlanır. Çizilecek sistemde kaç tane hayat çizgisi olacaksa (iletişim içinde olacak kaç sistem, aktör, vb. olacaksa o kadar hayat çizgisi eklenir). Eklenen hayat çizgilerinin isimleri özelliklerinden "Name" özelliği değiştirilerek düzenlenebilirken, aktör olarak ifade edilecek olanlar da "Actor" özelliği "True" değerine getirilerek ifade edilebilir.

Hayat çizgilerini oluşturduktan sonra, başlangıç sinyali eklenir. Bunun için araç kutusundan asenkron mesaj seçilir ve öncelikle boş bir yere, ardından da ilk hayat çizgisine (başlangıç sinyalini alan) tıklanır.

Başlangıç sinyalinden sonra, "create message" oluşturulur. Bunun için araç kutusundan "Create message" kontrolü seçilir ve kaynaktaki gri kutuya (işe) tıklanır; ardından hedef hayat çizgisine tıklanır. Bir hayat çizgisine create message gönderilecek ise bu, o, hayat çizgisinin aldığı ilk mesaj olmalıdır.

Hayat çizgileri arasında asenkron mesajlar göndermek için araç kutusundan "asynchronous message" kontrolü seçilir ve önce kaynak hayat çizgisindeki gri kutuya ardından da hedef hayat çizgisine tıklanır.

Senkron mesaj oluşturmak için ise araç kutusundan "synchronous message" kontrolü seçilir ve  önce kaynak hayat çizgisindeki gri kutuya ardından da hedef hayat çizgisine tıklanır.

Çizilen diyagramdaki herhangi bir hayat çizgisinden belirsiz bir kaynağa sinyal gidecekse yine araç kutusundan "asynchronous message" kontrolü seçilir ve önce kaynak hayat çizgisine ardından da boşluğa tıklanır.

Bu yazımızda sequence diyagramlarını ele aldık. Toplayacak olursak sequence diyagramları, oluşturduğunuz mimari içerisindeki bir aktivitenin hangi sistemler veya aktörler tarafından nasıl bir sıralama ile yürütüleceğini şematize etmenizi sağlayan diyagramlardır. Diyagramları detaylandırmak veya basitçe çizmek sizin kararınıza kalmış olmakla birlikte, detaylı diyagramlar okuyanlar için daha iyi anlaşılabilirlik sunar.

Bu tür diyagramları zaman kaybı olarak gören varsa şöyle bir şey söylemek istiyorum. Benim bu makalelerde çizdiğim diyagramların hepsi hayal ürünü; ancak hayal ürünü bu diyagramları çizerken bile birçok şeyi düşünüp planlamış oluyorum. Şayet gerçek bir proje olsa çok daha detaylı ve özenli olacaktır; ancak bukadarı ile sizi birçok detayı düşünmeye itiyor. Düşündüğünüz bu detaylarda, yazılımı geliştirme aşamasında yaşamanız olası sorunları daha tasarım aşamasında çözümlemenizi sağlıyor.

Bir sonraki yazımızda Bileşen Diyagramlarına bakacağız.

Application Lifecycle Management, Visual Studio alm, application lifecycle management, architecture tools, sequence diagram, sequence, ardışıklık diyagramları, ardışıklık

1- Foundation of Programming: Karl Seguin tarafından yazılan kitap, genel olarak programlama yöntemleri hakkında faydalı ama gereksiz uzunlukta bilgilerden kaçınarak okuyuculara programlama ile ilgili birçok bilgi vermeyi amaçlıyor. ALT.Net felsefesi, Domain Driver Development ya da Test Driven Development konularına da kitapta değinilmiş durumda. [indir]

2- Microsoft Application Architecture Guide, 2nd Edition: Microsoft tarafından yayınlanan bu kitap Microsoft ekosisteminde yazılım geliştiren yazılımcılara mimari tasarım desenleri ve tasarım prensipleri hakkında yol gösteriyor. Özellikle büyük çaplı uygulama geliştirirken ciddi bir sorun olan alt yapı problemlerini aşmak için iyi bir kitap. [indir]

3- Rob Miles C# Yellow Book 2010: C# dili ve .Net kütüphanelerini anlatan kitap, süreçler ve "best practice"ler ile de okuyuculara yol gösteriyor. [indir]

4- Threading in C#: Thread kavramı asenkron yazılım geliştirme için çok önemli bir konudur. Genelde basit birkaç kod ile yapılabiliyor gibi dursa da iyi planlanmayan bir yapı size zaman içerisinde çok ciddi problemler getirebilir. Kitabımız ise bu konuda size threading ile ilgili birçok konuda yol gösterecek nitelikte.

5- Improving .Net Application Performance and Scalability: Belki bir yıldır üzerinde çalıştığınız projenizi, sonunda canlı hayata alıyorsunuz. İşlevsel olarak hiç bir problem yok, müşteri istekleri de karşılanmış; dolayısı ile rahat rahat canlıya alıyorsunuz; ancak acı gerçeği kısa zaman sonra öğreneceksiniz. Uygulamanız yavaş, hem de çok. Ne yazık ki o kadar çok yaşanıyor ki bu durum, gerçek kullanımda birçok uygulama test ortamından çok daha yavaş çalışıyor ve genelde sebep yanlış alt yapı oluyor. Bu kitapta size performans ve ölçekleme ile ilgili size birçok yol gösterecek. [indir]

6- Applying Design Patterns: Yazılım dünyası geliştikçe "tasarım desenleri" de o kadar gelişti. Artık o kadar farklı desenler var ki, hangisi ne zaman uygulanmalı ve nasıl uygulanmalı çok karıştı. Bu kitap size basitçe tasarım desenlerinin nasıl uygulanacağını gösteriyor. [indir]

.Net Framework, Application Lifecycle Management, Visual Studio design patterns, threading, ebook, c#, architecture, alt.net, performance, scalability

Application Lfiecycle Management konusunda ki yazılarımıza Visual Studio 2010'un ALM alanında getirdiği yenilikler ile devam ediyoruz. İlk yazımızda Use Case Diyagramlarından bahsetmiştik. Bu yazımızda da Aktivite Diyagramlarından bahsedeceğiz.

Aktivite Diyagramları

Aktivite diyagramları, bizim gerçek hayatta iş akış diyagramları olarak tabir ettiğimiz diyagramlara denk gelmektedir. Temelde bir işin veya sürecin hangi adımlardan veya nasıl bir akış içerisinde medyana geldiğini göstermek için kullanılır. Genelde onay mekanizmaları ve sıralı işlerin gösterilmesinde sık sık faydalanılan bir diyagramdır.

Aktivite diyagramları bize uygulamanın şematize edilen bölümünün nasıl bir işleyişe sahip olacağını söyler, gerek kullanıcı etkileşimleri gerekse dış sistem bağlantıları açıkça görüleceği için mimari tasarım ve kodlama aşamasında bize kolaylıklar sağlayacağı da kesindir. Gerçek hayattan bir örnek verecek olursak, örneğin çalıştığımız bir firmada bulunan izin talebi iş akışı ile yürüyen bir süreçtir. Biz ya matbu evrak doldurarak ya da elektronik form doldurarak süreci başlatırız, sonra birinci yöneticimizin, varsa ikinci yöneticimizin onayına gider. Bu onaylardan sonra IK yöneticisi onaylar;şayet tüm aşamaları başarılı şekilde geçerse PDKS (Personel Devam Kontrol Sistemi) kayıtları oluşturulur. Bizim ilk yazımızdaki örneğimiz de bir IK sistemi olduğu için bizim de buna benzer diyagramlar çizmemiz gerekecek.

Öncelikle basit bir Aktivite Diyagramını ele alarak yapısını inceleyelim.

Yukarıdaki aktivite diyagramı, çalışanın bilgi güncellemesinin akışını şematize etmektedir. Bu basit diyagram, temel elemanları görmek için iyi olacaktır.

İlk bakmamız gereken, sol üst tarafta bulunan siyah dairedir. Bu daire bizim başlangıç noktamızdır, yani akış buradan başlamaktadır. Sol altta bulunan yuvarlak şekil ise bizim bitiş noktamızdır. Yani bu akivite iki şekil arasındaki adımlardan meydana gelmektedir.

Mavi renkle şematize edilen kenarlı yuvarlanmış olan dikdörtgenler ise bizim aktivitelerimizdir. Bunlar yapılacak işleri, atkviteleri ifade ederler. Görüldüğü üzere burada üç adet aktivite bulunuyor. "HERA'ya Bağlan", "Giriş Yap" ve "Bilgi Güncelleme".

Mavi kare şeklinde görülen ve İngilizce de "Diamond (elmas)" kelimesi ile ifade edilen şekil ise bizim karar düğümümüzdür. Bu şekil akışın belli şartlar altında farklı davranışlar gösterilebileceğini ifade etmektedir. Örneğin giriş işlemi başarısız olursa tekrar "Giriş Yap" düğümüne, başarılı olursa "Bilgi Güncelleme" düğümüne geçileceği ifade edilir. Her bir karar düğümünün bir girişi ve iki ya da daha fazla çıkışı olabilir, bu çıkışların sayısı işleme göre değişebilir.

Tüm şekiller arasında bulunan tek taraflı oklar ise bize akış yönünü gösteren "Connector" isimli elemanlardır. Bunlar diyagram içerisindeki şekilleri birbirine bağlarlar.

Şekil her ne kadar açık olsa da, sözle ifade etmemiz gerekirse bilgilerini güncellemek isteyen bir kullanıcı öncelikle HERA isimli IK sistemine "Bağlan"acak, ardından kendisine verilen bilgiler ile "Giriş Yapacak"; şayet girişi başarılı ise "Bilgi Güncelleme" işlemini yapacak, girişi başarısız oldu ise tekrar "Giriş Yap" işlemine dönecek. Bilgi Güncelleme işi bitince de bizim için akış bitmiş olacak.

Bu basit diyagramda çok fazla eleman yok, tek düzen bir akış söz konusu; lakin gerçek hayatta çok karmaşık akışlarla karşılaşılabilmektedir. Örneğin, eş zamanlı akışlar, sonuç bekleyen aktiviteler gibi durumlar olabilir. Biraz daha karmaşık bir akışa bakacak olursak.

Yukarıdaki akış çalışanın HERA üzerinden izin talebi yapmasını gösteriyor. Yine ilk olarak HERA sistemine bağlanılması şematize ediliyor, ardından da "İzin Talep" işlemine geçiliyor. İzin Talep işlemi siyah bir dikdörtgene bağlı görünüyor, bu şekle "Fork Node" adı verilir ve akıştaki çatallanmayı ifade eder. HERA sisteminde kullanıcı talep yaptıktan sonra eş zamanlı olarak iki iş yürüyor, bi taraftan yönetici onayları alınırken, diğer taraftan kullanıcının bu talebi PDKS'e kayıt ediliyor.

Çatalın sol tarafına bakacak olursak, "1. Yönetici Onayı" yazan mavi şekil, "Send Signal Action" olarak isimlendirilen elemandır. Bu işlemin başka bir aktiviteye sinyal gönderdiğini ifade eder; nitekim yöneticiden onay beklendiği sinyali gönderiliyor. Altındaki şekil ise bu onayın yani gönderilen sinyalin cevabının beklendiğini ifade etmektedir. Akışımız bu noktada onay gelene kadar duracaktır.  Aynı şekilde IK yöneticisi onayı ve onayın beklenmesi işlemleri de yürütülüyor. Tüm bu işlemere eş zamanlı olarak "PDKS'e kayıt" işlemi yürütülerek talep ve sonuçları kayıt altına alınıyor.

Çatalın iki kolunun birleştiği siyah dikdörtgen şekil ise "Join Node" olarak isimlendirilen ve bu şekilde çatallanan akışların birleştiği düğümdür. Bu noktadan sonra işlem "İzin Talep Bitisi" aktivitesi ile bitmekte ve bitiş noktasına ulaşmaktadır.

Takdir edersiniz ki, bu şekil çok daha karışık olabilir,örneğin her bir onaydan sonra karar düğümleri konabilir, çalışanın izin bakiyesi kontrol edilebilir, ona göre akış değişebilir; ama bizim amacımız diyagramı anlatmak olduğu için bu yapı şimdilik kafi görünmekte.

Veri Akışı

Aktivite diyagramları iş akışlarını ifade ettiği gibi, veri akışlarını da ifade edebilir. Veri akışlarını göstermek için iki yöntem kullanılır, ilk yöntem ve en çok tercih edileni "Object Node" isimli eleman kullanmaktır. İkinci yöntem ise "Input Pin" ve "Output Pin" elemanlarını kullanmaktadır. Öncelikle ilk yönteme bakalım.

Yukarıdaki diyagram, kullanıcının HERA'ya giriş yapması sırasında sağladığı verilerin akışını ifade ediyor. Bu diyagramda önemli olan beyaz, dikdörtgen şekildir. Bu şekil object node (nesne düğümü) olarak isimlendirilir. Bu düğümde taşınmak istenen veriler belirtilir. Ben iki tane verim olduğu için ve ikisi de "string" olduğu için tek bir düğüm kullandım; ama daha karmaşık veriler için birden fazla kullanılabilir. Her bir nesne düğümünün opsiyonel bir Type özelliği bulunur. İstenirse bu özelliğe aşağıdaki pirimitif veri tipleri atanabilir.

• Boolean
• Integer
• String
• Unlimited Natural

Boolean, Integer ve String verilerini biliyorsunuzdur; burada Unlimited Natural veri tipinden kasıt, kendi sınıflarınızı ya da yapılarınızı (struct) ya da her türlü nesnenizi tanımlayabileceğinizdir. Veri akışlarını göstermek için kullanılabilecek ikinci yöntem de aşağıda şematize edilmiştir.

Yukarıdaki diyagramımız ise, aynı veri akışını farklı şekilde ifade etmektedir. Üst tarafaki aktivitenin altına iliştirilmiş gibi duran beyaz, küçük kare "Output pin" elemanıdır. Bu eleman, bu aktiviteden veri çıkışı olduğunu ifade eder, aşağıdaki aktivitenin üstüne iliştirilmiş gibi duran küçük beyaz kare ise "Input pin" elemanıdır. Bu elemanda bu aktiviteye veri girişi olacağını ifade eder. Object node elemanında olduğu gibi, "Input Pin" elemanında da verilerin tipleri Type özelliklerinden tanımlanabilmektedir.

Use Case Diyagramında Aktivite Diyagramını'na Bağlantı

Visual Studio 2010 Architecture Tools'un getirdiği güzel bir özellikte çizilen diyagramların birbirine bağlanabilmesi. Örneğin bir Use Case diyagramını, bir aktivite diyagramına bağlayabilir ve bu bağlantıyı kullarak diyagramı incelerken kolaylıkla detaylara bakılabilir. İlk yazımızda "Kişisel Bilgi Güncelleme" işlemini detaylandırdığımız Use Case diyagramına ilk çizdiğimiz Aktivite Diyagramını bağlayarak bu durumu özetleyelim. Hatırlarsanız, Use Case Diyagramı üzerine bir "artifact" nesnesi eklemiştik. Bu nesne başka diyagramlara bağlantı amacı ile kullanılır.

Diyagramdan artifact nesnemizi seçip özelliklerinden "Hyperlink" özelliğine tıklayınız. Üç nokta ile ifade edilen "Link to URL or File" penceresini açınız. Buradan projemiz de oluşturduğumuz "KisiselBilgiGuncelleme.activitydiagram" dosyasını seçiniz. Tamam dedikten sonra artifact nesnesine çift tıkladığınız zaman, KisiselBilgiGuncelleme isimli aktivite diyagramına geçeceksiniz.

Bu yazımızda iş süreçleri ve adımlarını ifade etmek için kullanılan Aktivite Diyagramları üzerinde durduk. Bu diyagramlar, geliştirdiğimiz çözümün daha doğru olmasını sağlayacağı gibi, dışarıdan bakan kişiler (ekibe yeni katılanlar) için de daha anlaşılır olmasını sağlayacaktır. Bundan sonraki yazımızda "Sequence Diyagram" ile devam edeceğiz.

Application Lifecycle Management, Visual Studio alm, application lifecycle management, architecture tools, activity diagram, aktivite diyagramı, work flow diagram, iş akış diyagramı

Application Lifecycle Management konusundaki yazı dizimizde önce Application Lifecycle Management'ın tanımını yaptık, sonra da yazılım metodolojilerini dört ayrı yazıda (I, II, III, IV) inceledik. Bundan sonra ki yazılarımızda Visual Studio 2010 ailesinin ALM araçlarını inceleyeceğiz. İlk sırada ise Visual Studio 2010 Architecture Tools var.

İlk yazımızda standart yazılım süreçlerinin Müşteri İhtiyaçlarına Çözüm Olacak Yazılım Teknik Çözümünün ve Tasarımının Oluşturulması adımında ihtiyaca yönelik sunulması planlanan çözümünün teknik çözüm tasarımının ve modellemesinin yapıldığına değinmiştik.Bu adımda oluşturulacak çözüm için, toplanan gereksinimler ışığında, yazılımın yapısı tasarlanır. Yazılım içerisinde veri akışı nasıl olacak, kullanıcılar hangi adımları gerçekleştirecek, yazılım hangi katmanlardan oluşacak, hangi sınıflar yer alacak ve bu sınıfların ilişkileri nasıl olacak gibi detaylı bir tasarım yapılır.

Bu adımda iyi düşünülmüş ve detaylı bir tasarım yapılmasının aşağıdaki faydaları vardır

1. Yazılım süreci daha kolay yürütülür
2. Müşteriden gelecek değişikliklerin nelere etki edebileceği ve nasıl uygulanması gerektiği daha kolay görülür
3. Yazılımcılar neyi nasıl yapacaklarını daha kolay görür

Teknik çözüm ve tasarım adımının ne kadar detaylı yapılacağı aslında projeye göre de farklılık göstermektedir. Şayet Notepad gibi basit bir uygulama geliştiriyorsanız çok detaylı bir tasarıma ihtiyacınız olmayacaktır; ancak liman otomasyonu gibi onlarca kullanıcıya hizmet verecek bir çözüm geliştiriyorsanız herşey en detaylı şekilde planlanmalı.

Konuya bir örnek ile devam edelim. Yazılım değilde bir bina inşa ediyor olsaydık, inşaata başlamadan önce kağıt üzerinde ne yapacağımızı tasarlardık. Daha sonra bu bina tasarımını bilgisayar destekli olarak modellerdik, son olarakta fiziksel olarak maket haline getirirdik. İnşaat aşamasında ise her adım başta hazırlanan tasarıma göre devam ederdi. Peki yazılım projelerinin ne farkı? İçinde insan yaşamıyor olmasından dolayı mı? Unutmayalım ki öyle yazılım projeleri var ki bir bina inşaatından daha maliyetli.

Teknik çözüm ve tasarım adımının önemini anlattıktan sonra Visual Studio 2010 Architecture Tools'un bu konuda bize ne sağladığına bakalım. Visual Studio 2010 ile aşağıdaki modelleri hazırlayabiliriz:

1. Use Case Diyagramları
2. Aktivite Diyagramları
3. Sequence (Ardışıklık) Diyagramları
4. Bileşen Diyagramları
5. Sınıf Diyagramları
6. Katman Diyagramları

Bu noktada küçük bir hatırlatma yapmak istiyorum, Architecture Tools sadece Visual Studio 2010 Ultimate versiyonunda bulunan bir özelliktir.

Use Case Diyagramları

Use Case diyagramları modelleme için kullanılan en alt seviye diyagramlardır.Grafiksel olarak sistemin fonksiyonalitesini gösterirler, kim sistemi kullanıyor ve onla ne yapabilir. Son derece basit olan Use Case Diyagramları, neredeyse hiç detay göstermezler; özet olarak sadece kullanıcıları ve fonksiyonları gösterirler. Bu fonksiyonların detayları ise başka diyagramlarda ve dökümanlarda gösterilip Use Case diyagramlarına atıfta bulunurlar.

Örnek bir Use Case diyagramı aşağıdaki gibidir

Yukarıdaki örnek model, HERA isimli bir insan kaynakları sistemine aittir. Burada çalışanın kişisel bilgileri güncellemesi ve IK Çalışanının da çalışan sicil bilgileri güncellemesi durumu anlatılmaktadır. Şekil üzerinden anlatmaya devam edersek, insan şeklindeki figürler kullanıcıları temsil etmektedir. Bu örnekte iki tane kullanıcı gözüküyor normal çalışan ve IK çalışanı. Normal bir çalışanın kendi kişisel bilgilerini güncelleyebileceği "Kişisel Bilgi Güncelleme" işlemini (bu diyagramda işlemlere use case adı verilmektedir) yapabildiği görünmektedir. IK çalışanı ise çalışanların sicil bilgilerini güncelleyebileceği "Çalışan Sicil Biglileri Güncelleme" işlemini yapabildiği görülüyor. Ayrıca IK çalışanı "Bordro Hesaplama" işlemini de yapabiliyor.

Bu diyagramda kullanıcıyı temsil eden figürler istenirse "Image Path" özelliği kullanılarak değiştirilebiliyor. Kullanıcılar ve işlemler arasındaki oklar ise aralarındaki ilişkiyi temsil etmektedir. Bu basit diyagram üzerinde temel kavramları inceledikten sonra "Kişisel Bilgi Güncelleme" işlemini biraz daha detaylandıralım.

Yukarıdaki şekilde "Kisisel Bilgi Guncelleme" işleminin detaylı Use Case diyagramı görülüyor. Bu diyagramda çalışanımızı temsil eden figur yine görünüyor ve "Kisisel Bilgi Guncelleme" işlemi ile ilişkilendirilmiş. Ancak bu use case'in yanında iki yeni use case görünüyor; biri "Iletisim Bilgileri Guncelleme" use case'i, diğeri de "Egitim Bilgileri Guncelleme" use case'i. Her iki use case'de "Kisisel Bilgi Guncelleme" use case'ine bağlı ama aralarındaki ok üzerinde "<<include>>" ifadesi bulunuyor. Bu ifade bize "Kisisel Bilgi Guncelleme" işleminin bu iki use case'i içerdiğini ifade ediyor. Aşağıda mavi bir kutu halinde görülen ise "Calisan Bilgi Guncelleme" artifactıdır (artifact kelimesine henüz düzgün bir çeviri bulamadım, bulursanız lütfen iletin). Bu artifact bize diyagramımıza bir döküman ekleme şansı sağlar. Örneğin bu işlemin nasıl yapıldığını anlatan detaylı bir bilgi ya da analiz sırasında alınan ses kaydı. Dikkat ederseniz articact nesnemiz Kisisel Bilgi Guncelleme use case'i ile kesikli çizgilerden oluşan bir ok ile bağlanır; ki bu kesikli çizgili oka Dependency adı verilmektedir. Bu diyagram ile ilgili son söyleyebileceğimiz, "Bordo Hesaplama" işlemidir. Görüldüğü üzere bu işlem diğer use case'lerden ayrı duruyor; çünkü "Bordo Hesaplama" işlemi HERA IK Sistemine ait bir işlem değil, muhasebe entegrasyonu işlemidir, dolayısı ile sistemin dışında temsil edilmiştir.

Use Case Diyagram Nesneleri

Use Case diyagramları çizerken aşağıdaki nesneleri kullanabilirsiniz.

	Kullanıcı (Aktör)	Bir use case'i başlatan veya kullanan kullanıcıyı veya dış sistemi temsil eder
	İşlem (Use Case)	Kullanıcı tarafından etkileşim içinde olunan işlem
	Yorum  (Comment)	Herhangi bir nesne için daha detaylı açıklama yapmak amacıyla kullanılır
	Alt sistem (Subsystem)	Sistemin bir parçasını temsil eder
	Artifact (???)	Detaylı açıklama için atıfta bulunulan döküman veya diyagramı temsil eder
	İlişki (Association)	Kullanıcı ve işlemi birbirine bağlayan ok.
	Bağımlılık (Dependency)	Bir use case'in başka bir use case'e bağımlı olduğunu gösterir.
	Include	Bir use case'in başka bir use case'i tekrar kullanmasını gösterir.
	Genişletme (Extend)	Bir use case'in sadece başka bir use case'in gerçekleşmesi ile gerçekleşebileceğini ifade eder.
	Genelleme (Generalization)	Bir use case'in daha genel başka bir use case'in daha özelleşmiş hali olduğunu ifade eder.
	Yorum Bağlantısı (Comment Link)	Bir yorum ile diyagram nesnesini birbirine bağlar.

Use Case Diyagramı Oluşturmak

Tüm modelleme diyagramları Visual Studio 2010 Ultimate versiyonunda bulunan Modelling Project içinde tanımlanır. Dolayısı ile ilk önce bir Modelling Project projesi oluşturmak gerekiyor. Projeyi oluşturduktan sonra projeye Solution Explorer'da sağ tıkla tıklayıp "Add -> New Item" yolunu izleyerek, açılan "Add New Item" penceresinden "UML Use Case Diagram" seçeneğini seçilerek Use Case diagramı eklenebilir.

Diyagram oluştuktan sonra, Toolbox (araç kutusu) içinde bu diyagram için kullanılabilecek ve yukarıda anlattığımız nesneler görülebilir. Şimdi ilk diyagramımızı tekrar beraber oluşturalım.

1. İlk önce kullanıcıları diyagrama ekleyelim, toolbox'tan actor'u seçip diyagramda istediğimiz yere tıklıyoruz. Daha sonra F2'ye tıklayarak ya da Properties ekranından Name özelliğini değiştirerek adını Calisan yapıyoruz. Aynı şekilde bir tane daha ekleyerek ona da IKCalisan adini veriyoruz.
2. Toolbox'tan bir tane subsystem ekliyoruz. Bu nesne bizim sistemimizi temsil ediyor. Yine aynı şekilde adını değiştirip HERAIkSistemi yapıyoruz.
3. Toolbox'tan üç tane use case ekliyoruz. Bu nesneler bizim işlemlerimizi temsil edecek. İşlemlerden subsystem'in içine koyacağımız iki tanesinden birinin adını "Kisisel Bilgi Güncelleme" diğerinin adını da "Calisan Sicil Bilgisi Güncelleme" olarak değiştiriyoruz. Bir tane use case'i de dışarıya koyuyoruz ve adını "Bordro Hesaplama" olarak değiştiriyoruz.
4. Eklediğimiz kullanıcılar ve use case'leri birbirine bağlamak için Toolbox'tan Association nesnesini seçiyoruz ve önce kullanıcımıza sonra da use case'e tıklayarak aralarında ilişki oluşmasını sağlıyoruz. Bu işlemi Calisan - Kisisel Bilgi Guncelleme, IKCalisani - Calisan Sicil Bilgisi Guncelleme ve IKCalisani - Bordo Hesaplama için tekrarlıyoruz.

Görüldüğü gibi Use Case diyagramları oluşturmak son derece basittir. Temel de hangi kullanıcının hangi iş ve işleri yapabileceğinin tasarlandığı Use Case diyagramı, modelleme işine başlangıç noktasıdır. Bizim yaptığımız çok basit Use Case diyagramlarından, dış sistem bağlantıları, use case bağımlılıkları gibi ekstra tanımlamalar ile daha detaylı haller hazırlanabilirler.

Bir sonraki yazımızda Aktivite Diyagramlarını inceleyeceğiz.

Application Lifecycle Management, Visual Studio alm, application lifecycle management, architecture tools, use case, use case diyagramı

İngiltere Visual Studio ekibi 19 Ekim günü, Visual Studio 2010 ve ALM hakkında üç tane online etkinlik düzenliyor. Live Meeting üzerinden gerçekleştirilecek etkinlikler aşağıdaki gibi.

Visual Studio 2010 Test Features

19 Ekim 2010   10.00 - 11.00

Visual Studio 2010 has introduced new test tools in addition to the existing web and load tests in order to  drive closer integration between testers and developers. Test Manager is a new  environment specifically for testers, providing support for test plans, test suites, test case management and test execution.  There is also a new automated functional testing tool, support for virtualised test environments and more. This LiveMeeting will provide an overview of these new capabilities

Kayıt Maili

Visual Studio Team Explorer Everywhere               

19 Ekim 2010    11.30 - 12.30

This LiveMeeting will provide an overview of Team Explorer Everywhere 2010 (TEE). The new tool enables diverse platform development teams, such as Java developers using Eclipse-based IDEs, non-Microsoft operating systems such as Linux, Unix and Mac OS X, to build applications in Visual Studio 2010 and collaborate using Microsoft Visual Studio 2010 Team Foundation Server.  This will provide an overview of those capabilities.

Kayıt Maili

Visual Studio 2010 Ultimate

19 Ekim 2010    13.00 - 14.00

Join us for an overview of Visual Studio 2010 Ultimate. This session will provide an overview of the new Visual Studio 2010 edition and product family, and a deeper dive into the core features of the new Ultimate edition. The first area to be covered are the architectural tools, including code visualisation, architectural validation and UML modelling. The next key capability is IntelliTrace, which provides the greatly enhanced debugging, followed by an overview of the new testing tools that Ultimate provides.

Kayıt Maili

Application Lifecycle Management, Visual Studio application lifecycle management, visual studio, live meeting