UML Nedir?

Bir inşaat mühendisi bina inşaatına pat diye başlamaz. Belki beyninde hiç yardımsız bina inşaatı yapacak kadar bilgi vardır ama yine de bina tasarlama konusunda eğitim almış deneyimli mimarlardan yardım almak daha akıllıcadır. Mimar ile inşaat mühendisi arasında belki hiç konuşma dahi olmayacaktır ama mühendisin yaptığı bina tam olarak mimarın düşündüğü şekilde olacaktır. Aradaki iletişimi proje denilen araç sağlayacaktır. O projenin üzerine konulan her işaretin bir anlamı, her sayının açıkladığı bir bilgi vardır. Alman mühendis Japon mimarın çizdiği projeyi eksiksiz yapabilir çünkü konuştukları dil inşaatcadır. Bir inşaat projesindeki şekillerin neyi ifade ettiğini bilen bir kişi o inşaatla ilgili her detayı görebilir. Hatta bu inşaata ne kadar malzeme gideceğini dahi hesaplayabilir. İnşaatın maliyetini çıkarabilir. Bir bina tasarımını hiç şekil kullanmadan sadece yazıyla ifade etmeye çalışsak çok şey yazmak gerekir. Hatta bunu da yapmadan sadece anlatarak çözmeye çalışsak ne kadar başarılı olabiliriz? Bazen basit bir şekil sayfalarca dökümandan daha açıklayıcı olabilir.

Aslında çok eski zamanlardan beri yazılım dünyasında da birçok simgesel tasarım aracı kullanılmış ancak evrensel anlamda kabul görmüş bir standart oluşmadığı için çok yaygınlaşmamıştı. Bu ihtiyacı gören OMG konuya el attı ve varolan standartları birleştirerek UML (Birleşik Modelleme Dili) standartlarını yayınladı.

UML bir yazılım tasarımının diyagramlarla açıklanması için kullanılan bir araçtır. Kodlama yapmaya gerek kalmadan sistemin genelinin veya bir parçasının tasarımını bu yolla gösterebilmek mümkündür. Analist, tasarımcı ve programcılar arasında iletişim kurmak için kullanılabilecek iyi bir araçtır. İnşaat projelerinden farklı olarak yazılım projeleri ihtiyaçlara paralel olarak üretimi boyunca sıkça değişir. Bu nedenle yazılım üretme metodları bu sık değişikliklere cevap verecek şekilde döngüsel bir mantıkla işleyecek şekilde tasarlanmıştır. Klasik bir yazılım döngüsü kabaca gereksinim belirleme, analiz / tasarım, kodlama ve test aşamalarından oluşur. Bu döngü 1 hafta - 1 ay arasında değişen bir süreyi kapsar. Son aşama tamamlandıktan sonra tekrar başa dönülür. Bu süreç böylece devam eder. Her döngü başlı başına bir proje olarak da kabul edilebilir. UML bu aşamaların herbirine hitap eden farklı diyagram çeşitleri içerir. Örneğin gereksinim belirleme (bir diğer deyişle müşteriden istekleri alma) aşamasında Use Case (vaka veya kullanım durumu olarak çevirenler var) diyagramı veya tasarım aşamasında sınıf diyagramları ve etkileşim diyagramları kullanılır. Sınıf diyagramı bir sınıfın yapısını, etkileşim diyagramları ise sınıfların çalışma esnasında biribirleriyle olan iletişimlerini gösterir. Bir programcının modellenmiş bir gereksinimi kodlaması hem zaman kazancı sağlar hem de olası hataların önüne geçilmesine yardımcı olur. Aslında programın her parçasını UML ile modellemeye gayret etmiş firmalar da vardır ama bu kadar kapsamlı bir çalışma içine girmenin ne kadar faydalı olduğu hala günümüzde süregelen bir tartışma konusudur. UML diyagramlarını basit bir iletişim aracı olarak algılamak amaçsız bir şekilde herşeyi diyagrama çevirmeye çalışmaktan çok daha iyidir.

Programımız nesne tabanlı bir dille yazılmıyorsa da kullanabileceğimiz UML diyagramları vardır ama asıl olarak UML nesne tabanlı diller düşünülerek tasarlanmıştır. Eğer nesne tabanlı programlama konusunda yeterince bilgili değilsek önce o konuyu öğrenmemiz daha faydalı olacaktır. UML ile ilgili Martin Fowler'in UML Distilled kitabının 3. sürümünü önerebilirim. Aynı kitabın 2. sürümünün Türkçe çevirisi de var. Ancak Türkçe kaynak aranıyorsa Bora Güngören'in UML ile Nesne Tabanlı Çözümleme ve Tasarım kitabı bence daha derli toplu ve faydalı bir kitap. UML dilinin kullanımının yanı sıra yazılım mühendisliğinin önemli ve genellikle zor anlaşılan konularından da işin pratiğine yönelik eğlenceli örneklerle bahsetmiş. Ayrıca nesne yönelimli programlama (OOP) bilmeyenleri de düşünerek kitaba nesne yönelimli programlamaya giriş yaparak başlamış.

Hazır yeri gelmişken bir konuya daha değineyim. Yukarıda yazılım üretimi döngüsünü anlatırken bahsettiğim gibi, program yazma işi sırf kodlama işi değil. İşin mühendisliği ve sosyal bir boyutu da var. Kodlama aşaması, üzerinde uzmanlaşılması gereken temel aşamalardan sadece birisi. İşini ciddi yapan yazılımevlerini bir kenara ayırırsak genelde işin kodlama haricindeki kısmı önemsenmez veya çok yüzeysel uygulanır. Bunun en büyük nedeni iyi kodcunun iyi program yazmak için yeterli olacağıyla ilgili yanlış bir görüş olması ve eğitim eksikliği. Bunları kitap okumadan öğrenmek pek mümkün değil. Bu konularda Türkçe kitap pek yok. Genellikle program yazarken kullandığımız araçları öğreten kitaplar yazılmış. Bunların birçoğu da çeviri. Kodlama bilgisi elbette gerekli ancak analiz, tasarım, test, üretim metodolojileri, kalite güvence gibi konularla ilgili daha çok Türkçe kitap görmek istiyorum. Tabiiki bize düşen orjinal kitap satın alarak yazarlara destek olmak ve yenilerinin yazılması için bu potansiyele sahip kişileri teşfik etmek.

Canon EOS 400D

Canon $1000 altı SLR konseptine yeni bir ürün daha ekledi. 400D yeni birçok özellik içeriyor. 350D'den sonra 400D ile gelen önemli yenilikleri şöyle özetleyebiliriz.

• 10 Megapixel çözünürlüğe ulaşılmış.


• Ultra-Sonic titreşim özelliği marifetiyle ayna temizliği yapabiliyor ve artık toz taneciği derdinden kurtuluyoruz. Ayrıca bazı hassas parçalar antistatik malzemeyle kaplanmış.


• Otomatik fokus noktası sayısı 7'den 9'a çıkmış ve artık 30D modelindeki gibi diamond diziliminde.


• Seri çekim hızı artmış.


• Küçük LCD panel kaldırılmış ve hem bilgi alma, hem de önizleme için tek ve daha büyük bir LCD panel kullanılmış.
• Dış tasarımda ve menülerde bazı yenilikler yapılmış.

Aslında Rebel serisi kullanıcılarının ısrarla beklediği özelliklere hala yer verilmemiş ama yine de Canon iyi bir ürün çıkarmış bence. Yurtdışı fiyatı $899 gibi bir rakam. Tabii Türkiye satış fiyatı ne olur, $1000 altında kalır mı bilemiyorum. KDV vesair de ekleyince aksesuarlı paket fiyatları 2000 YTL'ye yaklaşır diye tahmin ediyorum. Belki bu ürün 350D'nin fiyatını düşürürse 350D modelini almak da iyi bir tercih olabilir.

Makinenin özellikleri ile ilgili detaylı bir inceleme http://www.dpreview.com/articles/canoneos400d/ adresinde...

Lego Mindstorms NXT

Lego'nun bildiğimiz lego parçaları ile tasarlanan ve bilgisayarla programlanabilen robot tasarım seti yeni sürümü ile piyasada. Yenilikleri şöyle kabaca bir incelediğimde eski pakete göre en büyük fark NXT adı verilen programlanabilir kontrolcüde. Eski 8 bitlik mikroişlemci 32 bite terfi etmiş ve üzerine güzel bir programlanabilir LCD Panel eklenmiş. Bluetooth iletişime izin vermesi ve hızlı USB arabirimi kullanması da artı özellikler. Eski paketteki ışık ve dokunma sensörlerine ek olarak mesafe algılayıcı bir ultrasonic sensör ve ses algılayabilen bir sensör daha eklenmiş. Bunların dışında farklı amaçlara yönelik bazı 3. parti sensörlerin de üretilebileceği söyleniyor. Servo motor sayıları 2'den 3'e çıkarılmış. Motorlar ve bazı parça tasarımlarında da görsel faklılıklar var. Yeni tasarımlı parçalar değişik robot tasarımlarına imkan vermekte. Robot kol gibi tasarımlarda ihtiyaç olabilecek bazı ek parçalara da yer verilmiş. Ayrıca eski pakette olduğu gibi robotu programlamak kontrol etmek için Microsoft'un robotics platformu ve Visual Studio 2005 kullanılabiliyor. Yani tasarladığınız robotu kontrol etmek için C# veya VB.Net ile programlar yazabiliyorsunuz. Web sitesini biraz incelediğimde yaratıcı beyinlerin yumurta yazıcısı, sms atan, tic tac toe oynayabilen robot, hatta analog saat gibi değişik tasarımlar yaptıklarını gördüm. Gerçekten bu kutuyla yapılabilecekler sadece hayalgücüyle sınırlı. Kendi tasarladığınız robotu programlayıp bir iş yaptırabildiğinizi görmek gerçekten apayrı bir zevk. Türkiye'de henüz satışa sunulmadı ama bazı yerli açık arttırma sitelerinde 800-900 YTL arasına bir fiyatla satıldığını gördüm. Ürünü incelemek ve onlarca değişik robot tasarımlarını görmek için http://mindstorms.lego.com adresini ziyaret etmeniz yeterli. Ayrıca Microsoft'un robotik sayfalarına da http://msdn.microsoft.com/robotics/ adresinden erişebilirsiniz.

Paradigma Kayması.

Eğer programımız bellirli bir işi defalarca yapıyorsa, her seferinde aynı kodları tekrar tekrar yazmak istemeyiz. Bu nedenle programımızı belli bir düzende mantıklı parçalara böleriz ve bu parçaları yine belli bir düzende biraraya getirerek programı inşa ederiz. Oluşturabileceğimiz parçalar ve bunların birarada çalışma şekilleri kullandığımız dilin yapısal özelliklerine göre farklılıklar gösterir. Kullandığımız dilin özellikleri belli bir kişisel anlayış geliştirmemize neden olur. Bu anlayışa programlama paradigması denir.

Yazılım teknolojisinde yaşanan gelişmeler neticesinde programlama dillerinde bazı yenilikler olur. Eğer değişiklikler eski yapıdan yeterince farklıysa belli bir tarzda düşünmeye alışmış programcılar bu alışkanlıklarını değiştirmek ve yeni anlayışa uyum sağlamak zorunda kalırlar. Bu değişime paradigma kayması denir.

Örneğin düz vitesli araba kullanmaya alışan bir sürücü otomatik vitesli araba kullanmaya başlarsa sürücünün yeni duruma alışabilmesi için bir uyum dönemi yaşaması gerekir. Bu dönem boyunca sürücü hayali vites atabilir, ayağı olmayan debriyaja basmaya çalışabilir. Eski alışkanlıkların tamamen ortadan kalkma süresi kişiden kişiye değişir. Yapıları farklı diller arasında geçiş yapığımızda biz programcılar da buna benzer şeyler yaşarız.

Örneğin Basic dili

• GW-Basic => Sequential Programming
• Quick Basic => Procedural Programming
• Visual Basic => Event Driven Programming
• Visual Basic.NET => Object Oriented Programming

şeklinde listeleyebileceğimiz yapısal değişiklikler yaşamıştır. Bu dillerden birini bilen ve diğer dile geçiş yapmayı düşünen programcının her ne kadar hepsi de basic temelli olsa da program yazma şeklini değiştirmesini gerekir. Prosedürel yapıdaki bir programlama dilinde programcı programı zihninde prosedürlerden oluşan bir bütün olarak hayal eder ve yaşanılan sıkıntılara bu çerçevede çözümler arar. Halbuki nesne yönelimli (Object Oriented) bir programlama dilinde program prosedürlerden değil nesnelerden oluşmaktadır. Programcının yazdığı programı artık prosedürler bütünü olarak değil nesneler bütünü olarak görmeye başlaması sürecin tamamlandığını gösterir.

Günümüzde birçok Delphi ve Visual Basic programcısı programlarını formlar, bileşenler ve tablolardan oluşan bir bütün olarak düşünürler. Delphi 2005 veya .Net dillerinden birine geçiş yaptıklarında da aynı alışkanlıklarını devam ettiririler. Şunu iyi anlamamız gerekir. Bu diller ticari ürünlerdir. Üreticileri bu ürünleri yaygınlaştırmak ve herkesin program yazabilmesini sağlamak için ürünlerine birçok kolaylık ekler. Bu kolaylıklar bizim daha hızlı program yazmamızı sağlıyor gibi görünse de Nesne Yönelimli programlamanın birçok önemli prensibine aykırı programlar yazmamıza neden olur. Kısacası önceden pratik olarak gördüğümüz bazı şeyler programımızın kapsamı büyüdükçe ayağımıza dolanmaya ve bize zaman kaybettirmeye başlar. Bir dilin nesne yönelimli olmasının bize ne artılar kazandıracağını iyi öğrenmemiz gerekir. Bunu anladığımız zaman ihtiyacımız olan Paradigma Kaymasını tam olarak yaşamışız demektir.