Bir yazılım projesinde herşeyden önce o proje ile ilgili yol haritası olan proje taslağı oluşturulmalıdır. Proje taslağı onun başarısıyla doğru orantılı olup projenin zaman ve iş gücü açısından verimli sonuçlanmasını sağlar. Bu yöntem aynı bir inşaat projesinde olduğu gibi bir yazılım projesinde de başarı faktörü olarak karşımıza çıkar. Proje/iş tasarlamanın ilk adımı proje içerisindeki aktif oyuncuların anlayabileceği standart bir modelleme yapmaktır. Bir mühendislik yaklaşımı olan modelleme, karmaşık bir sistemin şekil ve metinlerle basit bir dil ile ifade edilmesidir.
Yazılım mühendisliğinde modelleme için çeşitli çalışmalar yapılmış olsa da bunlardan en önemlisi ve geçerli olanı ilk olarak 1998 yılında OMG (Object Management Group) tarafından kabul gören UML 1.1 (The Unified Modeling Language / Birleşik Modelleme Dili) standardıdır. [Aytaç-2006]
UML, bir programlama dili olmayıp karmaşık yazılım projelerinin programlama dillerinden bağımsız, daha basit bir şekilde ifade eden görsel modelleme dilidir. Yazılım mühendisleri UML yöntemini geliştirme sürecinin ilk iki basamağı olan analiz/çözümleme ve tasarım süreçlerinde kullanırlar. UML, projedeki teknik ve teknik olmayan kişiler arasındaki iletişimi kolaylaştırır. UML aynı zamanda gerçek sistemin resmini gösterdiği için hem sistemin özellikleri ve eksikliklerini gösterir hem de bakım sürecini kolaylaştırır; yazılım projelerinin, özellikle nesneye yönelik programlama dili kullanılıyorsa, daha sağlıklı bir süreç içerisinde geliştirilmesine yardımcı olur. Ayrıca, projenin davranışını da açıkça gösterir.
Geniş bir kullanım alanına sahip olan UML yalnızca yazılım geliştirme alanında değil iş süreçleri, ağ yapıları ve veri sistemlerini modellemek için de kullanılır. Bu modelde standart işaret ve metinler kullanıldığı için ortaya çıkan tasarım, uzmanlığı ve dili farklı olsa da birçok kişi tarafından kolayca anlaşılabilir.
UML tasarımı, elemanlar ve bunların oluşturduğu diyagramlardan oluşur. Elemanlar, nesnelere ait özellikleri, işlevleri ve nesneler arasındaki yapısal ilişkiyi temsil eder. Diyagramlar ise, sistemin farklı süreçlerdeki yapısını ve davranışını temsil eder. UML tasarımında 9 temel diyagram kullanılır.

Bir sistem gereksinimlerinin modellenmesi < ı>kullanıcı senaryosu diyagramı ve < ı>etkinlik diyagramı aracılığıyla gerçekleştirilir.
Sistemin tanımı ve yüzeysel içeriği < ı>bileşen diyagramı ile < ı>nesne diyagramı aracılığıyla gerçekleştirilir.
Sistemin tasarımı ve ayrıntılı içeriği < ı>sınıf diyagramı, ardışıl (etkileşim) diyagramı, işbirliği diyagramı ve durum şeması diyagramı aracılığıyla gerçekleştirilir.
UML tasarımı için birçok araç bulunmaktadır; araç seçiminde dikkat edilmesi gereken unsur onun VS.NET ile bütünleşik çalışıyor olmasıdır; kod üretimine sahip olması ve mümkünse .NET Framework dillerine destek vermesidir. Ayrıca kullanıcı dostu ekranlara da sahip olması tercih nedeni olabilir. Bu amaçla < ı>MS Visio, Rational Rose, SmartDraw, Metamill veya Visual Paradigm araçları kullanılabilir. Kitabımızdaki UML tasarımları için “MS Visio” tercih edilmiştir. Aynı şekilde bu dillerdeki bir koda ait analiz ve tasarım modeli de oluşturulabilir. Ancak konumuz .NET olduğu için UML elementlerinin .NET Framework’teki hangi yapılara denk geldiğinin verilmesi yararlı olacaktır.
.NET Framework ve karşılık düşen UML elementleri:
İsim-uzayı (Namespace): İsim-uzayının UML tarafındaki karşılığı package elementidir.
Sınıf (Class): Sınıfın UML tarafındaki karşılığı class elementidir; new, internal gibi sınıfı yapıcıları UML tarafında desteklenmez.
Arabirim (Interface): Arabirimin UML tarafındaki karşılığı interface elementidir.
Numaralandırma türü (Enumerated type): Numaralandırma türünün UML karşılığı > şablonunu (stereotype) kullanan data type elementidir. Stereotype ifadeleri mevcut UML modelini genişletmek amacıyla modele yeni özellik ve element eklemek için kullanılır.
Yapı (Struct): Yapının UML karşılığı > şablonunu kullanan data type elementidir.
Özellik (Property) ve Yordam (Method): Özellik ve yordamların UML dilindeki karşılığı operation kavramıdır. Yordam parametreleri UML parameter kavramıyla karşılanır.
Delege/Temsilce (Delegate): Temsilcinin UML karşılığı > şablonunu kullanan data type elementidir.
Sabit (Constant) ve Değişken (Variable): Sabit ve değişkenlerin UML dilindeki karşılığı attribute kavramıdır.
Kullanıcı Senaryosu Diyagramları (Use Case Diagrams)
Yazılım geliştirme sürecinde az kullanılan bu diyagram/çizelge, sistem üzerindeki muhtemel kullanıcı senaryolarını modellemek için tercih edilir. Belirlenen senaryolarda sistemin ne yaptığı yüzeysel olarak aktarılır; sistemin amacını ve ayrıntılarını vermez. Bu modelde aktör olarak tanımlanan kullanıcı bir senaryoyu başlatır ve varsa oluşan sonucu başka bir kullanıcıya aktarır. Diyagram üzerinde senaryolar elips şeklinde çizilir. Kullanıcı ile senaryo arasındaki ilişki düz bir çizgiyle belirtilir. Bu modelde senaryolar arasında içerme (inclusion) ve genişleme (extension) olmak üzere iki tür ilişki kurulabilir. İçerme ilişkisi bir ana senaryonun bir alt senaryo içerdiğini belirtir. Söz konusu alt senaryo birden fazla senaryo tarafından kullanılır. Bu senaryolar arasında noktalı bir çizgi çizilir ve üzerine > (Visio’da >) ifadesi yazılır. Genişleme ilişkisi mevcut senaryoya yeni bir senaryo eklemek için kullanılır. Bu ilişkiyi belirtmek için noktalı çizginin üzerinde > ifadesi yazılır.

Kullanıcının sipariş oluşturması için öncelikle sisteme giriş yapması ve sözleşmeyi kabul etmesi gerekir. Müşteri siparişini iptal ettikten sonra sistemin log dosyasına not düşmesi de ek bir adım olarak eklenmiştir.
Sonuç olarak kullanıcı senaryosu (use case) diyagramı aracılığıyla bu modele bakan birisi sistemin ne yaptığının kabaca anlayabilir, görebilir.
Sınıf Diyagramları (Class Diagrams)
Projenin durağan yapısının modellenmesi için kullanılır. Nesne yönelimli programlama yaklaşımının temelini teşkil eden sınıflar (class) tıpkı gerçek yaşamda olduğu gibi modellenir; onlara ait özellikler ve davranışlar belirlenip diyagram üzerinde çizilir. UML dilinde sınıflar üç bölümden oluşan dikdörtgen şekliyle temsil edilir. Dikdörtgenin birinci bölümüne sınıfın adı, ikinci bölümünde sınıfa ait özellikler, üçüncü bölüme de sınıfın sahip olduğu işlevler yazılır. Her sınıfın mutlaka özelliği olmak zorunda değildir. İşlevler, sınıfın yeteneğini ifade eder. İşlevler tanımlanırken aldıklar veya geri döndürdükleri parametreler de girilir. Ayrıca sınıflar için ek notlar ve koşullar, kısıtlamalar da diyagram üzerinde tanımlanabilir. Aşağıdaki şekilde Kitap sınıfı ve ona ait karakter ve davranışlar gösterilmiştir.

Diyagram üzerinde sınıflar erişim belirleyicilerine göre işaretlenir. Örneğin özel (private) üyeler ‘-‘, herkese açık (public) üyeler ‘+’, korumalı (protected) üyeler ‘#’ ile gösterilir.
Sınıf diyagramı üzerinde aynı zamanda varsa sınıflar arasındaki ilişkiyi de görüntüleyebiliriz. UML yaklaşımında sınıflar arasında genel olarak 4 tür ilişki kurulur:

Bağıntı ilişkisi (Binary association) / İçerim (Aggregation), Oluşum (Composition)
Genelleştirme ilişkisi (Generalization)
Bağımlılık ilişkisi (Dependency)
Gerçekleştirim ilişkisi (Realization)

Bağıntı İlişkisi (Binary Association).
Bir nesnenin başka bir nesneyle olan yapısal bağını gösterir. Bu bağ diyagram üzerinde düz bir çizgiyle gösterilir. İki sınıf arasında ilişki kurulduğunda ilişki alanının üzerinde sınıfların ilişkideki görevi, ilişkinin yönü, türü ve ilişkinin çokluğu da belirtilir. Sınıflar arasında < ı>“bire-sıfır”, “bire-bir”, “bire-çok” türünde ilişkiler kurulabilir. Bu ilişkinin tanımları daha önce işlediğimiz “Entity Relationship (ER) Modeling” konusunda verildi. UML diyagramlarında bağıntının yönü ‘>’ simgesiyle gösterilir; nesnelerin bağıntıdaki rolleri kendilerinin alt tarafında, ilişki çokluğu gösterilir. İlişkinin türü < ı>“1,* – sayı/çokluk” şeklinde belirtilir. Muhtemel ilişkileri temsil eden simgeler aşağıdaki tabloda gösterilmiştir:

Aşağıda verilen şekilde bağıntı ilişkisi örneklendirilmiştir:

Müşteri-sipariş ilişkisinde bağıntının yönü müşteri nesnesinden sipariş nesnesine doğru verilmiştir. Bu gösterimi soldan sağa doğru okuduğumuzda “< ı>her müşteri 0 ya da herhangi bir sayıda siparişe sahiptir (0..*)”, “< ı>her sipariş yalnızca bir müşteri tarafından verilebilir (1..1)” sonuçları çıkar.
Aşağıdaki gösterim ise “< ı>bir şirketin en az 1 işçisi vardır” ve “< ı>bir işçi 0 veya herhangi bir sayıda şirkette çalışmış olabilir” olarak yorumlanabilir.

Bu basit bağıntı türü dışında içerim (aggregation/shared) ve oluşum (compo-sition) olmak üzere iki özel bağıntı türü daha vardır.
İçerim bağıntı türü iki sınıf arasındaki “sahiptir” veya “içerir” ilişkilerini modeller. Diyagram üzerinde bu bağıntı, içeren (sahiplenen) sınıf tarafına yerleştirilen boş bir baklava dilimi simgesiyle gösterilir. “n:m” çokluk değerine sahiptir.
Oluşum/kompozisyon bağıntı türü, içerimin daha güçlü özel bir durumu olup parça-bütün ilişkisini modellemede kullanılır. “Parça” nitelikli nesne, “bütün” nitelikli nesneyle anlam kazanır. Bu bağıntı “bütün” sınıf tarafında yerleştirilen dolu bir baklava dilimi simgesiyle gösterilir. “1:n” çokluk değerine sahiptir.

Bu iki bağıntı türü yüzeysel olarak birbirine benzese de aralarında iki önemli fark bulunmaktadır.

İçerim bağıntı türünde ikinci nesne birinci nesne dışında da sistem içinde kullanılabilir; yani aynı “parça” başka bir “bütün” tarafından da kullanılabilir. Örneğin bir öğrenci birden fazla öğretmenin öğrencisi olabilir. Oluşum bağıntı türünde ise ikinci nesne birinci nesneden bağımsız olarak kullanılamaz; yani bir “parça” aynı anda tek bir “bütün”e ait olabilir. Örneğin her motor tek bir otomobil tarafından kullanılabilir. Bu farktan dolayı bazı kaynaklarda içerim bağıntı < ı>bağımsız iyelik, oluşum bağıntı da < ı>bağımlı iyelik olarak isimlendirilir. Bununla birlikte her oluşum bağıntısı aynı zamanda bir içerim bağıntısıdır.
Oluşum türünde “parça”nın yaşam süresi doğrudan bütünün yaşam süresine bağlıdır. “Bütün” nesnesi oluşturulmadan “parça” nesnesi oluşturulamaz ve “bütün” nesnesi silindiğinde “parça” nesneler de onunla birlikte silinir. Örneğin “ürün grup” nesnesi silindiğinde o grupla ilişkili ürünün yaşamı da sonlanır. İlişkisel veritabanı sisteminde aralarında oluşum bağıntısı tanımlanmış tablolarda ana kayıt silindiğinde ayrıntı tablosundan da ilgili kayıtların silinmesi gerekir.

Son olarak, iki sınıf arasında birden fazla bağıntı çizilebilir veya bir sınıf kendisiyle ilişkilendirilebilir. Örneğin, şirket bileşeni için “işçi” diye bir nesne tanımladığımız bir müdür, hem işçi hem de yönetici rollerine sahiptir. Aşağıdaki örneği inceleyelim:

Bir futbol takımının 11 oyuncusu vardır. Bunlardan birisi kaptandır. Yani oyuncular iki gruba ayrılmıştır. Bir grup normal oyuncu diğer grup kaptan olarak görev yapar.
Bir oyuncu yalnızca bir takım için oynayabilir.
Takımın kaptanı normal oyuncuları yönetir.