Visual Studio 2008 Test Edition Web ve Load Test İncelemesi (Bölüm 6) – Web Test

İlk 5 makalemizin ardından (Bölüm 1, Bölüm 2, Bölüm 3, Bölüm 4, Bölüm 5), web test uygulamasının oluşturulması ve yük testi adımlarına geçiyoruz. Web Test, bir web sayfasının / uygulamasının / servisinin veya bunların kombinasyonlarının işlevselliğini denemek için uygulanan, tarayıcınızdaki http isteklerini (GET/POST) kaydedip sonrasında bunları aynı sırayla çalıştıran test yöntemidir. Bu test yöntemi, uygulamanın performansını anlık ölçmek için kullanılabileceği gibi, yük testinin bir senaryosu olarak da kullanılabilir. Bu test yönteminde farklı kontrol ve değer alma kuralları mevcuttur. Kontrol yöntemleri; ekran alan isimleri, metin, etiketler, http istemleri sırasında geçen süreler için kullanılabilir. Sonuçları olmasını beklediğimiz değerlerle kıyaslayıp, sistemin kıstaslarımıza olan uygunluğunu ölçebiliriz.

Kullanılabilecek araçlar ve senaryo kayıtlarının oluşturulması

Web Test için kullanılabilecek 2 araç mevcuttur. Bunlardan biri, Microsoft Web Test Recorder, diğeri ise, ücretsiz “Web Debugger Proxy” olan “Fiddler” uygulamasıdır. Web Test Recorder sadece sayfa bazında kayıt yapılmasına ve sayfa geçişlerinde devre dışı kalmasından dolayı, karmaşık web uygulamalarının kaydedilmesi için ”Fiddler” programını kullanmanızı öneririz. Herhangi bir test yöntemini kullanmadan önce, yapılması gereken ilk iş, test projesinin oluşturulmasıdır. Bunun için, “New Project” adımından açılan ekrandan, yeni bir test projesi oluşturalım. Bu test projesini, normal proje çözümünüzle beraber veya ayrı kaydedebilirsiniz.

1. Microsoft Web Test Recorder

Eklediğimiz test projesi içerisine, yeni bir test projesi eklemek için, proje üzerinde farenin sağ tuşuna tıklayıp, “New Test” i seçip, açılan ekrandan da, “Web Test” i seçelim.

WebTest eklendikten sonra, Visual Studio, Internet Explorer tarayıcınızı otomatik çalıştırıp, adres çubuğuna kaydın oluşturulacağı adres bilgisini girmenizi bekler. Tarayıcının sol tarafında, Microsoft Web Test Recorder, kayıtlarınızı oluşturmanız için VS tarafından çalıştırılmıştır ve kayıt konumunda beklemededir.

Senaryo kayıtlarının oluşturulması

Adres çubuğuna, kaydedilmesini istediğimiz adresi girdikten sonra, açılan web sayfasında, kaydedilmesini istediğimiz işlemleri gerçekleştirip, senaryo kayıt işleminin sonlanmasını istediğimizde, recorder üzerinden “Stop” tuşuna basılır.

“Web test recorder”, tarayıcı üzerinden yapılan istemleri, sıralamada herhangi bir değişiklik yapmadan, aynen kaydeder. Kayıt işlemi tamamlanıp, webtest olarak kaydedilmesi aşamasında, istemlerin, “QueryString” değişkenlerinin web test parametreleri haline getirilmesini sağlar. Bu sayede, yazılımcı için, WebTest ortamında kullanılabilir hale gelir. Başka bir deyişle, “Visual Studio WebTest Context” içerisinde, senaryo simülasyonlarında bir istemden diğer isteme aktarılacak / geçirilecek parametrelerin değiştirilmesine olanak sağlar.

2. Fiddler2

Daha önce bahsettiğimiz gibi, “web test recorder”, otomatik açılan tarayıcı üzerinden işlem yapmaktadır. Eğer karmaşık bir web uygulamanız varsa (örnek: javascript seviyesinden farklı pencerelere geçiş yapıp, bir önceki pencereyi kapatan), bu durumda “web test recorder aracı yetersiz kalabilmektedir  çünkü otomatik açılan tarayıcı kapatıldığı anda, “recorder” için kayıt işlemi sonlandırılmış anlamına gelmektedir. Bu gibi durumlar için, yani farklı pencerelerde yapılan işlemlerin bir bütün halinde, web testi olarak kaydedilmesi isteniyorsa, Visual Studio ortamının dışında bir aracın proxy olarak kullanılması gerekmektedir. Bunun için, Microsoft tarafından geliştirilen ve ücretsiz bir yazılım olan Fiddler2 kullanılabilir. Fiddler2 kullanılarak oluşturulan istem kayıtlarından, Visual Studio içerisinden direk kullanılabilecek “webtest” dosyaları oluşturulabilir.

a. Kurulum
http://www.fiddlertool.com/Fiddler2/version.asp
Adresinden, Fiddler2 programını indirip, sisteminize kurabilirsiniz.
b. Ayarlar

Kurulum sonrasında, Visual Studio 2008 ile uyumlu çalışabilmesi ve senaryo kayıtlarının oluşturulabilmesi için bazı ayarların yapılması gerekmektedir. Fiddler.exe.config  ayarı; Kurulum dizini altında, “Fiddler.exe.config” dosyasını açıp, aşağıdaki XML içeriğini aynen yapıştırmamız gerekmektedir. Bu içerik ile Fiddler2 üzerinden kaydedilen istemlerin, VS2008 “webtest” dosya formatıyla 100% uyumlu bir biçimde kaydedilmesi sağlanır.

<configuration> <runtime> <generatePublisherEvidence enabled="false"/> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="Inspectors" /> <dependentAssembly> <assemblyIdentity name="Microsoft.VisualStudio.QualityTools.WebTestFramework" publicKeyToken="b03f5f7f11d50a3a" culture="Neutral" /> <bindingRedirect oldVersion="8.0.0.0" newVersion="9.0.0.0"/> <codeBase version="" href="C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.WebTestFramework.dll"/> </dependentAssembly> </assemblyBinding> </runtime> </configuration>

c. Tarayıcı proxy ayarları

Fiddler2 uygulamasının, tarayıcı istemlerini takip edip kaydedebilmesi için, tarayıcınızda Proxy ayarlarının düzgün yapılması gerekmektedir. Bunun için, tarayıcınızın Yerel Ağ Bağlantısı ayarlarını açıp, aşağıdaki ekran görüntülerinde gösterildiği gibi değişiklik yapılması gerekmektedir. Fiddler2 için varsayılan port 8888 dir. Eğer sisteminizde bu port kullanımda ise Fiddler içerisinden, Tools -> Fiddler Options -> Connections sekmesi altından bu port değiştirilebilir.

Örnekte de görüldüğü gibi, 8888 bağlantı noktası kullanımda olduğundan, “Fiddler” uygulamasının dinlemesi gereken bağlantı noktası 8181 olarak değiştirildi. Tarayıcı için otomatik ayar seçeneği kaldırıldı ve bağlantı için makinenin yerel IP si (127.0.0.1) verildi. 8181 bağlantı noktası, tarayıcı için belirtilen Proxy ayarlarında da yazıldı.

Bütün bu ayarlar yapıldıktan sonra, Fiddler uygulamasında, “File” menusu altındaki, “Capture Traffic” seçeneğini işaretlediğimiz anda, IE tarayıcısından yapılan bütün gezintiler, Fiddler tarafından yakalanıp listelenebiliyor olmalıdır.

d. Senaryo kayıtlarının oluşturulması

“Fiddler” için yapılan ayarlar tamamlandıktan sonra artık tek yapılması gereken, kaydedilmesini istediğimiz senaryoyu tarayıcımızda tekrarlayıp, istem listesinin Fiddler üzerinden kaydedilmesini sağlamaktır.

İstenen senaryo için istem listesi oluşturulduktan sonra, “Capture Traffic” seçeneğini devre dışı bırakalım. Sonrasında, gerekli gördüğümüz istemleri seçip, farenin sağ tuşu üzerinden;

Seçeneğine tıklayarak, VS Web senaryosu olarak kaydedelim. Fiddler.exe.Config ayarını daha önce yaptığımız için, kullanılacak eklentiler bölümündeki bütün seçeneklerin işaretli kalmasında herhangi bir sakınca yoktur.

e. Visual Studio Test Projesi İçerisine Dahil Edilmesi ve Çalıştırılması
Oluşturulan “webtest” dosyasını, Test projemiz altına kopyalayalım ve projeye dâhil edelim.

Eklenen testin üzerine çift tıkladığımızda, Visual Studio içerisinde problemsiz açılıyor olması gerekir.

Testi çalıştırdığımızda, aşağıdaki ekran görüntüsüne benzer bir görüntü elde ediyor olmalıyız. Kaydedilen istemler, kayıt sırasına göre, ardı ardına çalıştırılır. Http status olarak 200 veya 302 alındığı durumlarda, test başarılı bir şekilde tamamlanmıştır.

Web testi, sadece tek kullanıcı için gerçekleştirilir ve genel olarak, web uygulamalarında, iş akış ve/veya ara yüz testleri için kullanılabilir. Dolayısıyla, web testlerini, projeniz ile birlikte yaşatmanız durumunda, projeye yapılan güncellemelerden dolayı nerelerde problem olabileceğini öngörmeniz kolaylaşır.

Ali KALFAOĞLU

Visual Studio 2008 Test Edition Web ve Load Test İncelemesi (Bölüm 5) - Ağ Dışında (Workgroup) Agent ve Controller Servisleri için Kullanıcı ve Grupların Düzenlenmesi

Kurulum ve kullanım ile ilgili bölümlere başladığımız makale serimizde (Bölüm 1, Bölüm 2, Bölüm 3, Bölüm 4), yük testi sırasında  uzak makineler için metriklerin toplanmasında yaşayabileceğimiz olası bir probleme ve çözümüne değineceğiz. Böyle bir problem ile karşılaşıldığında, yük testi raporunda şöyle bir hata görülür;

“Exception LoadTestCounterCategoryNotFoundException-The performance counter category ‘Network Interface’ cannot be accessed on computer '….' (Access is denied) ; check that the category and computer names are correct.”

Uzak bir makinenin performans metriklerini toplayabilmek için, eğer çalıştırılan sistem bulunduğunuz ağın dışında (örn: sanal makinelerden oluşan ağ) ise, öncelikle, “controller” ve “agent” servislerinin kurulu olduğu sistemler üzerinde gerekli erişim haklarına sahip kullanıcıların yaratılması ve bu kullanıcıların, bazı özel test gruplarına dâhil edilmesi gerekmektedir. Bunun için, bu makinelerde önceden belirleyeceğimiz kullanıcı isimlerini ve şifrelerini birebir girmemiz gerekmektedir. Bunu bir tablo yapısı ile göstermek istersek eğer;

Servisin Kurulu Olduğu Makine	Kullanıcı Adı	Şifresi
ControllerService	ControllerUserName	ControllerPass
ControllerService	AgentUserName	AgentPass
AgentService1	ControllerUserName	ControllerPass
AgentService1	AgentUserName	AgentPass
AgentService2	ControllerUserName	ControllerPass
AgentService2	AgentUserName	AgentPass

Bu kullanıcıları yaratırken birkaç noktaya dikkat etmemiz gerekiyor. Öncelikle, ilgili kullanıcının “User must change password on next logon” seçeneğindeki işareti kaldırmalı ve “Password never expires” seçeneğinin işaretli olması gerekir.

Bu kullanıcılar “Administrators” grubuna dâhil edilmeli ve ilgili servisler de bu kullanıcılar ile başlatılır hale getirilmelidir. Bütün bunlara ek olarak, az önce bahsettiğimiz uzak makineden performans metriklerinin toplanması için “agent” ve “controller” servislerinin kurulu olduğu makinelerde aşağıdaki adımların da uygulanması gerekmektedir.

“Agent” servisinin kurulu olduğu makinelerde yapılması gerekenler:
1. Windows güvenlik duvarı uygulamasını açıp

• Performance Logs & Alerts servisinin
• File And Printer Sharing servisinin

Güvenlik duvarından geçmesine izin verilmelidir.

2. Lusrmgr.msc (Local Users and Groups) konsolunu açıp “agent” kullanıcısı

• Performance Log Users
• Performance Monitor Users
• Event Log Readers

Gruplarına eklenmeli. Ayrıca, yine “agent” kullanıcısının “Administrators” grubuna dahil olduğu kontrol edilmelidir.
3. Services.msc konsolunu açıp

• Performance Logs & Alerts
• Remote Registry

Servislerinin başlangıcı “Otomatik” e çekilmelidir.
4. Secpol.msc (Local Security Policy) konsolunu açıp

• Local Policies -> User Rights Assignment  altından “Log On as Batch Job” seçeneğine
  • Performance Log Users
  • Performance Monitor Users

Grupları eklenmelidir. Bütün bu işlemlerden sonra ise komut istemini açıp;
Lodctr /r
Komutu ile seçilen bu bilgiler için erişim yetkilerinin tekrar oluşturulması sağlanmalıdır.
“Controller” servisinin kurulu olduğu makinelerde yapılması gerekenler:
1. Lusrmgr.msc (Local Users and Groups) konsolunu açıp “Groups” altındaki

• TeamTestAgentService grubuna “agent” servisi için tanımlanan kullanıcı
• TeamTestControllerAdmin ve TeamTestControllerUsers gruplarına da “controller” servisi için tanımlanan kullanıcı eklenmelidir.

Bu şekilde, artık ağ dışında, “controller” ve “agent” servisleri herhangi bir engele takılmadan iletişime geçebilecek ve uzak makineden “agent” servisleri aracılığı ile istenilen metrikler toplanabilecektir. Unutmamız gereken bir nokta da, bütün bu işlemlerin yapıldığı sistemlerde, VS2008 SP1 güncellemesinin kurulu olması gerekmektedir. Aksi halde, bütün bu ayarlamalara rağmen, uzak makinedeki servisler “agent” olarak kullanılmak istendiği durumda API uyuşmazlığından dolayı hata alınabilir.

Ali KALFAOĞLU

SQL Server Tetikleyicileri Üzerine (Triggerlar)

SQL Server’da tablo veya görünümlerde(view) herhangi bir işlem çalıştırıldığında (DELETE, INSERT, UPDATE) başka işlemlerin de yapılması isteniyor ise tetikleyiciler kullanılır. Her ne kadar Univera bünyesinde geliştirilen yazılımlarda DML mantığında çalışan tetikleyicileri kullanmasak da (Entity Framework doğasına aykırdır, tartışma konusudur); loglama, veri tutarsızlığı vb. işler için yararlı olduklarını söylemek mümkündür. Tetikleyiciler SQL cümleleri ile oluşturulur. Tetikleyici oluşturmak için aşağıdaki sözdizimi kullanılır.

CREATE TRIGGER [şema adı.] triggerAdı On tablo_adı | görünüm_ adı
[WITH dml_tetikleyici_seçeneği]
{
For | AFTER | INSTEAD OF } {[INSERT], [,],[UPDATE ],[,],[DELETE] }
[WITH APPEND]
}
AS sql ifadesi | EXTERNAL NAME method adı
SQL serverda 2 tür tetikleyici bulunmaktadır. Bunlar AFTER ve INSTEAD OF tetikleyicileridir.

• AFTER (Ardı Sıra Tetikleyiciler): İşlem gerçekleştikten sonra tetiklenirler. Veritabanındaki INSERT, UPDATE, DELETE işlemlerinde kullanılır Tetikleyici sql cümlesinde FOR kelimesinin yanında AFTER yada INSTEAD OF kelimesi yoksa SQL Server’da bu tetikleyicinin AFTER tetikleyicisi olduğunu anlarız. AFTER tetikleyicileri görünümlerde (view) kullanılmaz.
• INSTEAD OF(Yerine Tetikleyiciler) : INSTEAD OF tetikleyicileri belirtilen işlem yapılırken araya girerek (önce veya sonra) içerisindeki komutları yerine getirir. INSTEAD OF tetikleyicileri işlemlerin arasına girebildiğinden kontrol amaçlı kullanılabilirler. Temel veritabanı işlemlerinde INSTEAD OF tetikleyiciler de kullanılır. AFTER tetikleyiciler tablolarda tanımlanırken INSTEAD OF tetikleyiciler hem tablolarda hem de görünümlerde(viewlerde) tanımlanır. İşlemlerin arasında girerek işlem yaptıklarından kontrol amaçlı kullanılabilirler. WITH CHECK OPTION komutu ile yaratılan görünümlerde (view) INSTEAD OF tetikleyicisi kullanılmaz, sql server hata verir. Bu görünümlerde INSTEAD OF tetikleyicisi tanımlamadan önce WITH CHECK OPTION ifadesinin kaldırılması gerekmektedir.
  

After Tetikleyici Örnekleri:

Insert: Bir tabloya kayıt eklendiğinde başka bir tabloda işlem yapmak için insert tetikleyicisi kullanılır. Tabloya eklenen kayıt bilgilerine ulaşabilmek için inserted deyimi kullanılır. Aşağıdaki örneği verilen tetikleyici müşteri ödeme yaptığında müşterinin bakiyesinden ödeme tutarının çıkarılıp TBLCARIBAKIYE tablosunun güncellemesi için kullanılmaktadır.

CREATE TRIGGER TRG_CARIGUNCELLE ON TBLTAHSILAT
FOR INSERT
AS
BEGIN
  DECLARE @TAHSILATTOPLAMI DECIMAL(28,8)
  DECLARE @MUSTERIKOD INTEGER
  SELECT @MUSTERIKOD = MUSTERIKOD, @TAHSILATTOPLAMI = TAHSILATTOPLAMI   FROM INSERTED

  UPDATE TBLCARIBAKIYE SET BAKIYE = BAKIYE - @TAHSILATTOPLAMI
  WHERE MUSTERIKOD = @MUSTERIKOD
END

Delete: Bir tablodan kayıt silindiğinde başka bir tabloda işlem yapmak için delete tetikleyicisi kullanılır. Tablodan silinen kayıt bilgilerine ulaşabilmek için deleted deyimi kullanılır. Aşağıdaki örneği verilen tetikleyici müşteri ödeme yaptığında müşterinin ödemesi TBLTAHSILAT tablosundan silindiğinde TBLCARIBAKIYE tablosunda tahsilat iptali yapılan tutarı müşteri bakiyesine eklemek gerekmektedir.

CREATE TRIGGER TRG_TAHSILATIPTAL ON TBLTAHSILAT DELETE
AS
BEGIN
  DECLARE @TAHSILATTOPLAMI DECIMAL(28,8)
  DECLARE @MUSTERIKOD INTEGER
  SELECT @MUSTERIKOD = MUSTERIKOD, @TAHSILATTOPLAMI = TAHSILATTOPLAMI 
  FROM DELETED

  UPDATE TBLCARIBAKIYE SET BAKIYE = BAKIYE + @TAHSILATTOPLAMI
  WHERE MUSTERIKOD = @MUSTERIKOD
END

Update: Bir tabloda güncelleme işlemi yapıldığında başka bir tabloda işlem yapmak gerekiyor ise update tetikleyicisi kullanmak gerekmektedir update kayıtlarına ulaşmak için updated gibi bir deyim bulunmaktadır. Update işlemi bilindiği gibi delete insert demektir. Eski kayıt bilgilerine ulaşmak için deleted, yeni kayıt bilgilerine ulaşmak için inserted deyimi kullanılmaktadır. Aşağıdaki örnekte tahsilat tablosunda müşterinin ödemesi değiştirildiğinde TBLCARIBAKIYE tablosundada bakiyenin güncellenmesi gerekmektedir.

CREATE TRIGGER TRG_BAKIYEGUNCELLE ON TBLTAHSILAT
FOR UPDATE
AS
  UPDATE TBLCARIBAKIYE
  SET BAKIYE = CB.BAKIYE + DTABLE.BAKIYE - ITABLE.BAKIYE
  FROM TBLCARIBAKIYE CB
  INNER JOIN  deleted DTABLE ON CB.BAKIYE = DTABLE.BAKIYE 
  INNER JOIN  inserted ITABLE ON CB.BAKIYE = ITABLE.BAKIYE

Instead of Tetikleyici Örnekleri:

Insert: Bir tabloda insert işlemi uygulandığında tablo üzerinde INSTEAD OF INSERT tetikleyicisi varsa bu işlem tabloda gerçekleşmez, tetikleyicide yazılı kodlar çalışır. Eğer bu trigger içinde herhangi bir kod yazılmaz ise bu durumda tabloya kayıt eklenmeyecektir.

CREATE TRIGGER TRG_CARIBAKIYEEKLE on VIEWCARIBAKIYE
INSTEAD OF INSERT
AS
BEGIN
  INSERT INTO TBLCARIBAKIYE SELECT MUSTERIKOD, BAKIYE FROM inserted
END

Delete: Bir tabloda delete işlemi uygulandığında tablo üzerinde INSTEAD OF DELETE tetikleyicisi varsa bu işlem tabloda gerçekleşmez, tetikleyicide yazılı kodlar çalışır.

CREATE TRIGGER TRG_TAHSILATSIL ON TBLTAHSILAT
INSTEAD OF DELETE
AS
  UPDATE TBLTAHSILAT SET SONISLEMTARIHI = GETDATE()
  WHERE TAHSILATID IN (SELECT TAHSILATID FROM DELETED)

Tetikleyicilerin Aktif ya da Pasif Edilmesi
Bazı durumlarda işlemlerde tetikleyicileri pasif duruma almak ya da pasif durumdaki tetikleyiciyi aktif duruma getirmek gerekebilir. Bu işlemler için aşağıdaki sözdizimleri kullanılır.
Tetikleyiciyi aktif duruma getirme

ALTER TABLE <TABLO_ADI> ENABLE TRIGGER ALL

Tetikleyiciyi pasif duruma getirme

ALTER TABLE <TABLO_ADI> DISABLE TRIGGER ALL

Neslihan ÇALIŞKANEL

Müşteri İhtiyacını Ön Analiz ile Anlamak

Yazılım yaşam döngüsündeki en önemli adımlardan biri olan analiz süreci ve rol tanımları ile ilgili bilgilendirmeleri önceki makalelerimizde yapmıştık. Bu makalemizde müşteri ihtiyaçları(gereksinimleri) ön analiz nasıl anlaşılır sorusuna cevap vermeye çalışacağız. Yazılım geliştirirken ortaya çıkacak ihtiyacın doğru olabilmesi için müşterinin beklentilerini tam olarak anlamak ve analizini yapmak gerekir.

Müşteri ile Ön Analiz Nasıl Yapılır ?

1. Proje yöneticisi ile iş analisti ve/veya analiz yazılım uzmanı müşteri ile bir toplantı düzenler.
2. Müşteri nasıl bir uygulamaya ihtiyacı olduğunu anlatır.
3. Proje yöneticisi ve analiz ekibi ne geliştirileceğini tam olarak anlamak için müşteriye ihtiyaç hakkında sorular sorar ve beklentilerini tespit ederler. (amaç, hedef, kapsam, ileriki ihtiyaçlar vb.)
4. Analiz ekibi müşterinin ihtiyaçlarını ön analiz dökümanı haline getirir (standart formatta), müşterinin anlattıklarının doğru anlaşılıp anlaşılmadığının netleşmesi için müşteriden onay alma süreci başlatılır.
5. Bu sürecin sağlıklı işlemesi yazılımın sonraki aşamalarının sağlıklı sürdürülmesini sağlar. İhtiyaç analizi ve yönetimindeki başarı, yazılım geliştirme yaşam döngüsündeki diğer süreçlerin başarısını doğrudan etkilemektedir.
   

Analiz döküman sürecinin onaylanmasının atlandığı durumlarda, yazılım kalite ve teslimat süreçleri ciddi risk altındadır. Ön analizde müşteri onayı alma süreci atlandığında aşağıdaki resimdeki durumla karşılaşmak kaçınılmazdır.

Bir sonraki makalemizde Analiz dökümanında  hangi kısımlar olmalı ve nelere dikkat edilmeli ? konusuna değineceğiz.

Neslihan ÇALIŞKANEL, Deniz KILINÇ

System Center Configuration Manager (SCCM)

SCCM kısaca; fiziksel ve sanal sunucuları, istemcileri ve hatta mobil cihazları yönetmemizi kolaylaştıran bir araçtır. İşletim sistemi ve yazılımların kurulumu, konfigürasyonu ve kaynak yönetimi gibi işleri merkezileştirerek tek bir noktadan yapmamızı sağlar.

2. Neler Yapılabilir?
a. Varlık Yönetimi

Sistem yöneticilerinin mevcut donanım ve yazılım varlıklarını izlemesini sağlar. Hangi donanımı kimin kullandığını, hangi makinede hangi yazılımın yüklü olduğunu takip etmek ve raporlamak son derece kolaydır.

b. Konfigürasyon Yönetimi

Bilgisayarların ve yazılımların istenen standartlara göre konfigüre edilip edilmediğini (antivirus, güncellemeler, çalışan servisler, kurulu yazılımlar vs) takip ederek, sistemlerin performans ve güvenliğini üst seviyede tutar, erişilebilirliği arttırır. Windows 2008 etki alanının NAP özelliği ile istenen konfigürasyonda olmayan bilgisayarların ağa girmesini engelleyebilir.

c. Güncelleme Yönetimi

Microsoft yazılımları dışında üçüncü parti ve şirket içi hazırlanan yazılımların, sürücülerin ve hatta biosların da güncellemelerini yapabilir. Güncellemenin başarılı olup olmadığının nedenleri ile beraber raporlamasını yapabilir.

d. Yazılım Dağıtımı

Şirkette kullanılan yazılımların kişi, grup veya şirket genelinde dağıtımı yapılabilir. Aynı yazılımın aynı sürümünün kullanılması sağlanır.

e. İşletim Sistemi Dağıtımı

Hazırlanan imaj dosyaları ile bilgisayarların yeniden kurulumunu kolaylaştırır.

Referanslar

• http://www.microsoft.com/systemcenter/configurationmanager/en/us/default.aspx

Necmettin TÜRER

Visual Studio 2008’de Kod Metrikleri ve Kod Analizi (Static and Dynamic Code Analyze) – Bölüm 2

İlk makalemizde genel bir giriş yapmış ve kod metriklerinden bahsetmiştik. Kod Analizi aracı yönetilebilir assemblyleri analiz ederek, assemblyler hakkında bilgileri raporlayan bir araçtır. Microsoft .Net Framework Dizayn Kurallarına göre programlama ve dizayn kuralı ihlallerini gösterir. Analiz aracı, kontrol ettiği kurallara uymayan yerleri birer uyarı olarak gösterir. Uyarı mesajları, hangi kuralın ihlal edildiğine ve mümkünse problemin nasıl çözüleceğine dair bilgileri içerir.

Kod Analizi Özelliğinin Açılması

Solution Explorer’da bir proje seçilip projenin properties’ine girilerek, Code analysis tabına gidilebilir. Şekil 1’deki gibi Enable Code Analysis on Build (defines CODE_ANALYSIS constant) seçeneği işaretlenirse, şekilde gözüken kuralların hepsi kontrol edilecektir. İstenilen kural işareti kaldırılarak devre dışı bırakılabilir.

Şekil 1. Code Analysis Tab

Kod Metriklerinin Kod Analizine Entegre Edilmesi

Maintainability Index, Class Coupling, Depth of Inheritance ve Cyclomatic Complexity metrikleri, Visual Studio’nun kod analizinde kural olarak tanımlıdır. Bu kuralları açarak kod metriklerine uygun kod yazılabilmesi sağlanabilir. Bu kurallar şekil 1’de gösterildiği gibi Code Analysis tabındaki “Maintainability Rules” penceresi altında durmaktadır. Hangi kuralın hangi kod metriğine karşılık geldiği ve hangi koşullarda uyarı verecekleri ise Tablo 1’de gösterilmiştir.

Tablo1. Kod Metrikleri ve Treshold Kuralları

Metric	Corresponding Rule	Threshold
Depth of Inheritance	CA1501 AvoidExcessiveInheritance	Warning at above 5 levels deep
Complexity	CA1502 AvoidExcessiveComplexity	Warning at above 25
Maintainability Index	CA1505 AvoidUnmaintainableCode	Warning at below 20
Class Coupling	CA1506 AvoidExcessiveClassCoupling	Warning at above 80 for class and above 30 for a method

Referanslar

• http://blogs.msdn.com/fxcop/archive/2007/10/03/new-for-visual-studio-2008-code-metrics.aspx
• http://msdn.microsoft.com/en-us/library/bb385914.aspx
• http://www.infosysblogs.com/microsoft/2008/03/calculate_code_metrics_feature.html
• http://www.geekzone.co.nz/vs2008/4773
• http://visualstudiomagazine.com/Articles/2008/10/21/Code-Metrics.aspx
• http://syndato.wordpress.com/2008/05/06/code-metrics-with-visual-studio-2008/
• http://blogs.msdn.com/fxcop/default.aspx?p=2
• http://en.wikipedia.org/wiki/Static_code_analysis

Özlem KARAGEDİK

UML ve Modelleme – Bölüm 7 (Sequence Diyagramlar)

UML ve Modelleme serisinin 7. si olan bu makalemizde, UML modellemede en önemli diyagram türlerinde biri olan Sequence (ardışık) diyagramlarından bahsedeceğiz. Öncesinde sırasıyla Use Case, Class, Object ve State diyagramlara değinmiştik. Sequence diyagramlar, sistemdeki nesneler ya da bileşenler arasındaki mesaj akışının olaylarını, hareketlerinin ardaşık şekilde modellenmesinde kullanılan diyagramlar sequence diyagramlardır. Bir sequence diyagramı nesnelerden, mesajlardan ve zaman çizelgesinden oluşmaktadır.

Sequence diyagrami iki boyutludur:

1. Dikey boyut: Mesajların/olayların sırasını oluşma zamanı sıralarına göre gösterir.
2. Yatay boyut: Mesajın gönderildiği nesne örneklerini (object instances) gösterir.

Sequence diyagramlarının akışı soldan sağa doğru olmalıdır. Sequence diyagramları oluşturmadan önce senaryo (use case) oluşturulmalıdır.

Şekil 1. Sequence Diyagram Genel Gösterimi

Sequence Diyagram Modellemesinde Kullanılan Elemanlar

Şekil 2. Sequence Diyagramlardaki Kullanılan Elemanların Gösterimi

Nesne(Object) ve Yaşam Çizgisi(Lifeline) : Sequence diyagramlarda yaşam çigisi ve nesne gösterimi aşağıdaki gibidir.

Şekil 3. Nesne ve yaşam çizgisi basit gösterimi

Modellemede nesnelerin isimlendirilmesi ve tip belirtimi aşağıda belirtilmiştir.

Şekil 4. Nesnelerin isim ve tip gösterim çeşitleri

Mesaj: Sequence diyagramda farklı nesnelerin birbirleri ile etkileşimi mesajlar ile gösterilir. Mesaj gösterimi mesajların tipine göre değişir. Sequence diyagramlarda mesajlar, basit(simple) mesajlar, nesne oluşurken ya da bellekten silinirken kullanılacak özel mesajlar ve mesaj yanıtları olarak değişik şekillerde gösterilir.
Mesaj Tipleri ve Gösterimleri

• Basit(Simple) Mesaj Tipi: Basit mesajlar nesneler arasındaki akış kontrolünün iletimini göstermek için kullanılır. Nesnelerin methodlarını doğrudan çağıramazlar. Sık kullanılan mesaj tipi değildir.
• Senkron (Syncronous)/ Çağrı yapan(Call) Mesaj Tipi: Nesne mesajı alıcı nesneye gönderir ve onun işlemini bitirmesini bekler, bu durumda senkron mesaj tipi kullanılır. Nesne tabanlı programlamada çağırılan birçok method senkron çalıştığından en çok kullanılan mesaj tipidir.
• Asenkron Mesaj Tipi: Senkron mesajların tersine, asenkron mesajlar nesneye mesaj gönderdikten sonra cevap beklemeden işleme devam etmesinin gösteriminde kullanılır. Genellikle komut zincirlerinde kullanılır.
• Dönüş(Return) Mesaj Tipi: Senkron mesajlarda alıcı nesnenin işleminin bitimini, gönderen nesneye bildirmesinde kullanılır.

Şekil 5. Mesaj gösterimleri

Bir sonraki makalemizde UML diyagramlarından Collaboration(İşbirliği) Diyagramlarını ayrıntılı inceleyeceğiz.

Referanslar

• http://www.tracemodeler.com
• http://developer.com/
• http://www.sequencediagrameditor.com

Neslihan ÇALIŞKANEL

Visual Studio 2008’de Kod Metrikleri ve Kod Analizi (Static and Dynamic Code Analyze) – Bölüm 1

Statik kod analizi, uygulama çalıştırılmadan (derleme sırasında), kaynak kodlarının incelenmesi ve analiz edilmesi anlamına gelmektedir. Visual Studio Team System 2008, statik kod analizi yapabilmek için kendi araçlarına sahiptir. En temel amaç, kod analizi araçlarını kullanarak kaynak kodların standart programlama ve dizayn kurallarına uygunluğunun gözden geçirilmesidir. Kod analizleri, “Buil Automation & Continuous Integration (Set Otomasyonu ve Sürekli Tümleştirme)” sürecinde de önemli bir yerde bulunmaktadır. Biz bu yazımızda, sadece kod metrikleri olarak adlandırılan kurallara değineceğiz. Bir sonraki makalede ise Kod Analizi kısmına bakacağız.

Kod Metrikleri (Code Metrics)

Kod metrikleri, kaynak kodları incelemek ve çeşitli ölçülere göre yazılımı derecelendirmek için kullanılan matematiksel ve istatistiksel yöntemlerdir. Kod metrikleri ile geliştiriciler hangi tiplerin veya metotların yeniden ele alınması gerektiğini, düzenlenmesi gerektiğini anlayabilirler. Kod metrikleri kullanılarak, koddaki potansiyel sorunlar erkenden ortaya çıkartılmış ve problemli alanları yeniden düzenleyebilmek için yeterince zaman kazanılmış olur. Kod metrikleri ile sadece yazılımın sağlığı incelenmiş olmaz, kod metrikleri aynı zamanda koddaki bakımı mümkün olmayan ve karmaşık noktaların da görülmesini sağlar.

Visual Studio 2008 kod metrikleri, bir projenin sınıflarını, modüllerini ve namespacelerini, çeşitli ölçülerle değerlendirerek potansiyel sorun kaynaklarını vurgular. Visual Studio 2008, 5 kod metriği ile birlikte gelmektedir. Bu kod metrikleri;

1. Class Coupling,
2. Depth of Inheritance,
3. Cyclomatic Complexity,
4. Lines of Code
5. Maintainability Index’tir.

Kod Metrikleri, Solution Explorer’da bir projeye veya solution üzerine sağ tıklayıp “Calculate Code Metrics” diyerek veya Analyze menüsünden “Calculate Code Metrics For Solution / Project” ile hesaplanabilir. Sonuçlar “Code Metric Results” penceresinde şekil 1’deki gibi gösterilecektir.

Şekil 1. Code Metric Results

1. Class Coupling

Bu metrik; sınıf seviyesinde, parametreler, yerel değişkenler, dönüş tipleri, method çağırımları, generic ilklemeler, base sınıflar, arayüz implementasyonları vb. aracılığıyla diğer sınıflarla olan bağlantı sayısını ölçer. Kısaca bu metrik bir sınıfın bağlı olduğu sınıf sayısını gösterir. Bu sayı hesaplanırken int32, object, string gibi primitive ve built-in tipler gözardı edilir. Bu sayının mümkün olduğunca az olması beklenir. Çünkü yüksek coupling değerleri, bir tasarımın diğer sınıflara bağımlılıkları yüzünden, yeniden kullanılmasının ve bakımının güç olduğu anlamına gelir.

Şekil 2’de coupling değerlerinin nasıl hesaplandığı gösterilmiştir. Buna göre Order Sınıfı, Currency ve Transaction olmak üzere iki sınıfla ilişkilidir. Product sınıfı sadece Supplier sınıfı ile ilişkilidir, ve coupling değeri 1’dir. Country sınıfı ise hiç bir sınıfa bağımlı değildir, bu yüzden coupling değeri 0’dır.

Şekil 2. Class Coupling örneği

2. Depth of Inheritance

Kalıtım derinliği, bir sınıfın, kalıtım ağacında o sınıfın üst düğümünden köke kadar olan sınıfların sayısını gösterir. Hiyerarşi ne kadar derinleşirse, hangi metodların veya alanların nerelerde tanımlandığını veya yeniden tanımlandığını takip etmek de zorlaşır. Çok derin kalıtım ağaçları, uygulamanın testinin ve bakımının karmaşıklığını arttırır. Örneğin bir sınıf direkt olarak Object’ten türemişse derinliği 1 olacaktır. Kalıtım derinliği hesaplanırken, interfaceler sayılmaz. Şekil 3 ‘de kalıtım derinliğinin hesaplanmasına örnek verilmiştir.

Şekil 3. Depth of Inheritance

3. Cyclomatic Complexity (CC)

Cyclomatic Complexity programdaki birbirinden farklı kod akışlarının sayısıdır. Daha basitçe açıklamak gerekirse, programdaki karar noktaları olan if bloklarının, do, while, foreach ve for döngülerinin ve switch case bloklarının sayısıdır. Yüksek cyclomatic completixy değerine sahip olan kodların test ve bakımı zor olmaktır. Çünkü bu kodlarda test edilebilecek çok sayıda farklı akış vardır.

Cyclomatic Complexity(CC) değerini hesaplamak için aşağıdaki gibi basit bir yol izlenebilir.

1. Metodun akışına CC= 1 değeri ile başla.
2. Her bir if,while,repeat, for, and , or anahtar kelimeleri veya eşdeğerleri için CC’ye 1 ekle
3. Switch’teki her bir case için CC’ye 1 ekle

Tablo 1’deki kod örneğinin Cyclomatic Complexity’sini hesaplayacak olursak metoda CC=1 ile başlıyoruz. For döngüsü için 1 ekliyoruz(CC=2). If bloğu için 1 ekliyoruz(CC=3).

Tablo 1. CC Örneği

public void TestCyclomaticComplexity()        {                 int x = 5;                 for (int z = 0; z < 5; z++)                     x = x + 1;                 if (x > 10 && x < 5) x = x - 3;         }

Şekil 4’te ise metodlar için cyclomatic complexity değerleri ve riskleri belirtilmiştir. Cyclomatic complexity değeri ne kadar yüksekse metodun karmaşıklığı da o kadar fazladır.

Şekil 4. CC değerleri ve Riskleri

4. Lines Of Code (LOC)

Lines of Code, bir metoddaki işletilebilir kod satır sayısını gösterir. Alfabe dışı karakterler, commentler, tip ve namespace tanımları bu hesaplamanın dışında kalır. Çok yüksek bir değer, bir tipin veya metodun çok fazla iş yaptığı, bu yüzden de bölünmesi gerektiği anlamına gelir.

5. Maintainability Index

Sınıf üyeleri veya tipler seviyesinde kod bakımının kolaylığına gösteren bu değişken 0-100 arasında bir değer alır. Bu değerin yüksek olması programın sürdürebilirlik seviyesinin yüksek olduğu anlamına gelir. Namespace veya assembly seviyesindeki maintainability index, o namespace veya assembly içerisindeki bütün tiplerin maintainability indexlerinin ortalamasıdır. Bu metrik, Halstead Volume, Cyclomatic Complexity ve Lines of Code metrikleri bir araya getirilerek oluşturulmuştur. Halstead Volume, kullanılan işlenen (operand) ve işlemcilerin (operator) sayısıyla ilgili bir metriktir. Maintainability index için kullanılan denklem aşağıda verilmiştir.

Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)

Maintainability index, kolay bir gösterimi olması için ikonlarla ifade edilmiştir. İkonlar için, değer aralıkları ve sürdürebilirlik seviyeleri şekil 5’de verilmiştir.

Şekil 5. Maintainability Index

Özlem KARAGEDİK

Test Attributes (TDD, Birim Testleri)

Bu yazımızda Test Driven Development (TDD), Unit Test ve Test Projesi Oluşturma makalelerinin ardından bazı test attribute’ların neler olduğuna değinilecektir. Test Attribute’lar test methodlarının başlarında yer alır ve ilgili metodu özelleştirmek için kullanılır. Bazı attribute’lar Test Projesinin tamamında etkili olmak üzere kullanılırlar.

Test Attributes

• AssemblyInitialize: Assembly tarafından tahsis edilen kaynakların yer aldığı metot için kullanılır. Tüm test sınıfları çalışmadan önce çalışacak olan metodun başında yer alır.
• AssemblyCleanup: Assembly tarafından tahsis edilen kaynakların serbest bırakıldığı metot için kullanılır. Tüm test sınıfları çalıştıktan sonra çalışacak olan metodun başında yer alır.
• TestClass: Test sınıfını oluşturan attribute’tur. Her test metodu için başlangıç durumuna gelir.
• ClassInitialize: Test sınıfı tarafından tahsis edilen kaynakların yer aldığı metot için kullanılır.
• ClassCleanup: Test sınıfı tarafından tahsis edilen kaynakların serbest bırakıldığı metot için kullanılır.
• TestInitialize: Test başlamadan önce yapılacak ön hazırlıkların yer aldığı metot için kullanılır.
• TestCleanUp: Tüm test boyunca kullanılan kaynakları serbest bırakmak için kullanılır.
• TestMethod: Testleri yapılacak kodların başlarına konmaktadır.
• Ignore: Tüm test metotları çalıştırılırken hesaba alınmaması istenen metot için kullanılır.
• ExpectedException: Test edilen metodun exception fırlatması bekleniliyorsa kullanılır. Metot exception fırlatıyorsa test metodu başarılı sayılır.
• Owner: Yazılan test metodun kim tarafından yazıldığını belirtmek için kullanılır.
• Description: Metodun kısa açıklamasını yapabilmek için kullanılır.
• WorkItem: Team Foundation Server (TFS) içerisinde metodu madde olarak belirlemek amaçlı kullanılır.

MS Test Attribute	NUnit Attribute
Test Method	Test
TestClass	TestFixture
ClassInitialize	TestFixtureSetUp
ClassCleanUp	TestFixtureTearDown
TestInitialize	SetUp
TestCleanUp	TearDown
AssemblyInitialize	N/A
AssemblyCleanUp	N/A

Assert Sınıfı

Birim testleri içerisinde doğru/yanlış önermeleri için kullanılan sınıftır. Türkçesi iddia etmektir.

• AreEqual: Verilen değerlerin eşitliğini doğrular. Eşit değilse exception türetir.
• AreNotEqual: Verilen değerlerin eşit olmadıklarını doğrular. Eşitlerse exception türetir.
• AreSame: Verilen oblejelerin aynı objeye ait olduğunu doğrular.
• AreNotSame : Verilen oblejelerin farklı objelere ait olduğunu doğrular.
• Fail: Herhangi bir koşulan bakmaksızın iddiayı başarısız kılar.
• Inconclusive: Assertion (iddianın) doğru/yanlış belirleyemediği uygulamadığı durumlar için kullanılmaktadır.
• IsTrue: Koşulun doğru olması durumunun kontrolüdür. Koşul yanlışsa iddia başarısız olur.
• IsFalse: Koşulun yanlış olduğunun doğrulanmasıdır. Koşul doğruysa iddia başarısız olur.
• IsInstanceOfType: Verilen objenin belirtilen tipte olmasının doğrulanmasıdır.
• IsNotInstanceOfType: Verilen objenin belirtilen tipte olmamasının doğrulanmasıdır.
• IsNull: Null olma kontrolünün yapılmasıdır.
• IsNotNull: Null olmama kontrolünün yapılmasıdır.

Ömer KİREMİTÇİ, Armağan DÖKER