Makale Özeti

Visual Studio Team System ile Yazılım Süreç Yönetimi makale serisinin, 3. Makalesi, Yazılım mimarları araçları hakkındadır.

Makale

 

VISUAL STUDIO TEAM SYSTEM (VSTS) İLE

YAZILIM SÜREÇ YÖNETİMİ

11.02.2007

 

Ertan Deniz

Derya Bilgi Teknolojileri

www.deryabilgi.com, Ertan.Deniz@deryabilgi.com

 

 

 

Makale özeti

 

Visual Studio Team System tanıtımı ile ilgili makale serisinin üçüncüsü, yazılım mimarları tarafından kullanılacak araçlar hakkındadır.  Araçların kullanımı daha kolay kavrayabilmek için, örnek bir proje takip edilmiştir. Bu örnek proje, makale serisinde kullanılmaya devam edilecektir.

 

Microsoft’un yeni modelleme vizyonu ve Yazılım mimarları araçlarının özellikleri hakkında bilgi sahibi olacağız. Bu araçların, Servis temelli mimaride (SOA-Service Oriented Architecture) uygulama geliştirme ihtiyaçlarımıza nasıl cevap vereceğini değerlendirme imkanı bulacağız.

 

Bu serinin ilk 2 makalesine, aşağıdaki adreslerden ulaşılabilir.

 

Visual Studio Team System - Giriş ve Bileşenler (1)

http://www.yazgelistir.com/Makaleler/1000001120.ygpx

 

Visual Studio Team System – Takım ortak bilgi yönetim sunucusu (2)

http://www.yazgelistir.com/Makaleler/1000001126.ygpx

 

 

İçindekiler

 

Microsoft’un modelleme vizyonu ve Yazılım mimarları için VSTS

Yazılım mimarları için modelleme araçları

Uygulama tasarım aracı (Application Designer)

Değerlendirme

Kaynaklar

 

Microsoft’un modelleme vizyonu ve Yazılım mimarları için VSTS

 

VSTS ile model temelli bir yaklaşım geldi. Bu yaklaşım, Microsoft’un yeni yazılım geliştirme vizyonu. Fakat  UML standartları üzerine bina edilmemiş. UML 2.0 ile gelen yenilikler incelenmiş ve dokümantasyon temelli yapısının devam ettiğine karar verilmiş. Gerekli görülen yerlerde, UML gösterim şekillerinden istifade edilmiş. UML, modelleme de önemli bir standartlaşma sağladı. UML’den önce modelleme konusunda bir çok yaklaşım vardı. UML 1.0  ile, yazılım geliştirmede modellerin kullanılması konusunda önemli bir adım atıldı. Bu yüzden de yaygın olarak kullanılmaya çalışılıyor. Microsoft kendi içinde de UML diagramlarını dokümantasyon amaçlı kullanıyor. Fakat, Microsoft UML ve UML temelli araçların, yazılım geliştirme sürecinde üretkenliği çok fazla arttırmadığı görüşünde. Visual Studio Enterprise Architect ürünü ile Visio temelli bir UML aracını kullanıma sunmuştu. Microsoft, UML araçlarının kullanımı üzerine, diğer müşterileri de kapsayan incelemeler yaptırmış.Bu incelemelerde, çok küçük bir oranda UML diagramlarının kullanıldığı, genelde sınıf diagramları seviyesinde bir yoğunlaşma olduğu tespit edilmiş. Buna, kullanıcı tarafından yapılan işlemler serisini (Use Case diagrams) gösteren diagramlarını da ekleyebiliriz. Bu durum, yeni bir modelleme yaklaşımını tetikleyen şartlardan birisi. UML standartlaşma sebebiyle, bazı .NET veri tiplerini desteklemiyor. Bu durum, kod üretimi aşamasında problemlere sebeb olabiliyor. Gereksinimlerde ortaya çıkan o iş ortamına özel bir çok modelleme ihtiyacı var. Fakat standartlaşma sebebiyle, bunlarda kapsama alınamıyor.  Modeller sadece dokümantasyon temelli düşünülmemeli.Tüm yazılım geliştirme sürecinde,bu modellere ihtiyaç var. Modeller üzerinden kod üretilmesi, modellerin yazılım geliştirme sürecinde birbiri ile ilişkili olarak kullanılması, model ve kod senkronizasyonu önemli bir ihtiyaç. Modellerin yazılım geliştirme sürecindeki bu önemli rolu sebebiyle, Microsoft  DSL (Domain Specific Languages) teknolojisini geliştirdi. UML benzeri bir gösterim şekli var. Modeller yazılım geliştirme sürecinde, aktif olarak kullanılabiliyor. VSTS ile sunulan tasarım araçları, bu alt yapı kullanılarak geliştirilmiş.Aynı zamanda, bu teknoloji, size modelleme aracı geliştirmeniz için gerekli alt yapıyı da sağlıyor. Modelleme yapısının, geliştirilebilir olması ile çok farklı tasarım araçlarını (Veritabanı diagramları, iş akış diagramları vb) görmemiz mümkün olacak.   Team system ile gelen modelleme yaklaşımı ile ilgili MSDN’de detaylı bir makale [1]  var. UML ile ilgili geniş açıklamalar yapılmış. Bu makalenin okunmasını ve bu konunun üzerinde durulmasının faydalı olacağını düşünüyorum.

 

Microsoft, UML desteğini MS Visio ile sürdürüyor. Fakat UML 1.3 standartlarında. UML ile güncel olarak çalışan kurumlar, başka bir UML aracını tercih edebilirler. Visual Studio 2005 ile bu hususta entegrasyonunu sağlamış, Enterprise Architect [2] isimli bir ürün özellik ve maliyet açısından incelemeye değer.

 

Bu sürüm ile, servis temelli yazılım uygulama geliştirme (SOA) konusunda önemli bir alt yapı sağlanmış.  Farklı cihazlardan bilgiye erişim, İnternet erişimine açık hizmetler, güvenlik, farklı uygulama entegrasyonları en  önemli gereksinimler arasında. Web servisleri ve İnternet ortamına açık sistemlerin sürekliliği, güvenliği (Özellikle İnternet hizmetleri), Bilgi teknolojisi operasyon ekipleri tarafından yönetiliyor. Bu ekiplerin, geliştirdikleri bazı gereksinimler ve kısıtlar var. Uygulamaların bu kısıtlar üzerinde test edilmesi (denenmesi) gerekmektedir. Bu yapının modellenmesi ve gerçek hayata geçiş süreci için birlikte çalışmak gerekiyor. VSTS’nin bu sürümü ile, bize bu imkanı sunan tasarım araçları geliştirilmiştir. Bu tasarım araçları 4 tanedir :

 

1.      Uygulama tasarım aracı

2.      Teknik alt yapı tasarım aracı

3.      Sistem tasarım aracı

4.      Gerçek ortama geçiş tasarım aracı

 

Bu araçlar ve sınıf tasarım aracı (Class Designer) DSL teknolojisi ile geliştirilmiş. Projelerdeki özel modelleme ihtiyaçları için, bu araçlar kullanılarak yeni tasarım araçları geliştirilebilir. Bu geliştirilebilir yapı sayesinde, çözüm ortakları tarafından bir çok yeni tasarım aracını, geliştirme ortamında görme imkanımız olacaktır. Bu araçlar ile çizilen diagramlar sadece görsel ve dokümantasyon amaçlı hazırlanmış diagramlar değil. Uygulamaların tasarlanması ve gerçek ortama geçiş sürecine kadar kod yazmadan süreç yönetimi hedeflenmiş. Mesela, yazılım mimarları tarafından uygulama ve sistem modeli tasarlanır. Teknik alt yapı mimarları uygulamanın çalışacağı sunucu ve güvenlik alt yapısını tasarlar. Daha sonra, bu tasarımların birbirine uygunluğu tespit edilir. Bu örnek, model diagramlarının süreç içinde kullanılma ihtiyacına iyi bir örnek. Aynı zamanda modellerin görsel özellikleri sebebiyle, iyi bir iletişim imkanı. Bu işlemlerin gerçekleşebilmesi için, ortak bir modelleme alt yapısı ve dili kullanılması gerekiyor. Tüm tasarım araçları, model ile ilgili bilgilerin saklandığı, XML temelli sistem tanım dosyalarını kullanır. (System Definition Model) Bu iletişim dili, sistemlerin tasarım,geliştirme ve operasyon gereksinimlerini tanıtarak, daha kolay sistem entegrasyonu açısından çok önemli. Daha geniş çapta başlayan bir vizyonun da (DSI –Dynamic System Initiative) yazılım geliştirme tarafına bakan ilk adımları atılmış. Microsoft ve iş ortakları tarafından yapılacak çok iş var. Her çeşit işletim sisteminin, Uygulama sunucularının, Web sunucularının, bazı uygulama ve web servislerinin bu şekilde tanımlandığını ve uygulamalarımızda daha kolay kullanabileceğimizi bir düşünelim. Yazılım mimarları için VSTS sürümüne, böyle bir vizyonun uygulanması ve gerçekleştirilmesi nazarıyla bakmak faydalı olacaktır.

 

Özetleyecek olursak ; Modelin hazırlanması, teknik alt yapı uzmanları ile birlikte çalışma imkanı, model dokümanının kaynak kod sisteminde saklanması,versiyon takibi, modelin sürecin hem devamında kullanılması hem de genel dokümantasyon olarak kullanılması, tasarım araçlarının önemli özellikleri olarak dikkatimizi çekmektedir.

 

Takip eden bölümde, bu sürüm ile birlikte gelen tasarım araçları hakkında bazı bilgiler verilmiştir.

 

Yazılım mimarları için modelleme araçları

 

Bu bölümde; Yazılım mimarları için sunulan tasarım araçlarını örnek bir uygulama üzerinde inceleyeceğiz.

 

Örnek uygulamamız servis temelli bir mimaride modellenecek basit bir satış sitesi. Gereksinimler şu şekilde sıralanabilir :

1.      Web uygulama arayüzü,

2.      Ürün, sipariş,ödeme ile ilgili web servisleri

3.      E-mail ve SMS uyarı hizmetleri için web servisleri,

4.      Sipariş ve uyarı sistemleri geliştirilmesi

5.      Internet ortamına açık hizmetleri (Web uygulaması) ve güvenli alan tanımlanması (Web servisleri,Veritabanı)

 

Projenin mimari modeli, VSTS ile sunulan tasarım araçları ile gerçekleştirilecektir. Takip eden bölümde, hem tasarım araçlarının özelliklerini öğrenecek hem de örnek projemizdeki gereksinimlere göre modelleme işlemini gerçekleştirmeye çalışacağız.

Uygulama tasarım aracı (Application Designer)

 

Uygulama tasarım aracı ile, projeyi oluşturan uygulamalar, servisler ve  aralarındaki iletişim modellenmektedir. Tasarım elemanları bölümünde yer alan, tanımlı şekiller ve bağlantı noktaları ile diagramlar kolaylıkla hazırlanabilmektedir. Sık kullanılan uygulama tanımları, tekrar kullanılabilmek amacıyla tasarım elemanları araç kutusuna kaydedilebilmektedir.

 

Bu tasarım aracı ile birlikte sunulan, tasarım elemanları aşağıdaki tabloda sunulmuştur:

 

Tasarım elemanları

Açıklama

Windows Uygulaması

Microsoft windows uygulaması tanımlanır.

ASP.NET Uygulaması

ASP.NET uygulaması tanımlanır.

Office Uygulaması

Microsoft Ofis uygulaması (Excel,Word)

Dışardan kullanılan Web Servisi

Uygulama tarafından kullanılan ve başka bir yerde sunulan web servisi. URL bilgisi sağlanmalı.

Veritabanı

Uygulama tarafından kullanılan veritabanı.

Bağlantı bilgisi sağlanmalı.

BizTalk Web Servisi

Web service olarak sunulan Biztalk süreci.

URL sağlanmalı.

Genel uygulama

Uygulama ile entegrasyonu sağlanması düşünülen ve tasarım elemanı olmayan genel uygulama.

Web Servis iletişim noktaları

Uygulamalar ve  Web servislerini bağlayan iletişim noktaları

Veritabanı iletişim noktası

Uygulama ve servisler ile veritabanı arasındaki  iletişim noktaları

Web içerik iletişim noktaları

(HTML,ASP) içerikleri iletişim noktaları.

ASP.NET uygulaması modele eklendiğinde, bu iletişim noktası uygulama prototipinin üzerinde bulunmaktadır.

Genel iletişim noktası

Genel uygulama (Tanımlanmamış) üzerindeki iletişim noktası.

Yorum

Model üzerine yorum eklemek için kullanılır.

Tablo1 : Uygulama tasarım aracının tasarım elemanları

 

Uygulamalar arası etkileşim için, iletişim noktaları kullanılmaktadır. Mesela, ASP.NET uygulamasından, Web servis iletişim noktası kullanılarak, Web servisine bağlantı sağlanır. Bu durumda, ASP.NET uygulaması üzerinde, servisi alan (consumer) iletişim noktası, Web servis üzerinde ise, servisi sağlayan (provider) iletişim noktası bulunmaktadır.

 

Yazılım geliştirme sürecinde, uygulama mimarisi hakkında yapılacak çalışma, kodlama aşamasından önce gelmesi gerekiyor. Bu tasarım aracı da sunuduğu hizmetler ile, bu sıraya riayet edilmesi hususunu hatırlatıyor. Uygulama mimarisinin modellenmesi ve uygulamaların çalışacağı platform üzerinde denenmesi ile, bazı problemlerin erken teşhisi ve daha kolay çözümü mümkün olacaktır.  Bu tasarım onaylandıktan sonra, tasarıma uygun bir bir çözüm yapısının (Projeler ve ilgili kod/konfigürasyon dosyaları) oluşturulmaktadır. Eğer çözüm yapısı daha önceden oluşturulmuş ise, uygulama model dokümanı eklendiğinde, kod üzerinden model diagramı hazırlanacaktır. Model veya kod üzerinde yapılan değişiklikler için, arka planda senkronizasyon sağlanmıştır. Örnek projemizdeki gereksinimlere göre, uygulama tasarım aracı ile modellediğimiz diagramımızın görüntüsü aşağıdaki şekilde olacaktır :

 

 

 

Resim1: Uygulama tasarım aracı ile çizilen uygulama mimarisi modeli

 

Bu mimari model dokümanınından, sürecin devamında istifade edeceğiz. Proje ile birlikte kaynak kod veritabanında saklandığı için, değişiklik yönetimi de gerçekleştirilecektir. Devamlı güncel kalması sağlanacak bir döküman ve proje teknik dokümantasyonumuzun uygulamalar ve servislerin ilişkilerini gösteren bölümü elimizde hazır. 

 

Bu tasarım aracı ile,  uygulamalar ile ilgili parametreler ve kısıtlar tanımlanabiliyor olması diğer önemli özellikleri arasında. Örnek olarak, Uygulama ile ilgili tanımlarda (Uygulama mimarisi modeli), ASP.NET Web servislerimizin  NET Framework 2.0 üzerinde çalışacağı tanımının yapıldığını düşünelim. Sürecin devamında, bu uygulamanın çalışacağı sunucu bu özelliği sağlaması gerekecektir.

 

Uygulama tasarım aracı ile, Web servisleri ile ilgili operasyonların tanımı da gerçekleştirilebilmektedir. Örnek bir modelde, ASP.NET uygulaması üzerinde, web servisi iletişim noktasını seçerek, web servisi ile ilgili metodlar ve parametreler tanıtılabilir.

 

Sonraki bölümde, uygulama mimarisi modeli üzerinden sistemlerin ve alt sistemlerin modellendiği sistem tasarım aracınının özelliklerini inceleyeceğiz.

 

Sistem tasarım aracı (System Designer)

 

Sistem tasarım aracı, Uygulama tasarım aracı ile geliştirilen uygulama mimarisi üzerinden, sistem model diagramları oluşturmak için kullanılmaktadır. Sistem diagramı, gerçek ortama geçiş açısından bakıldığında, birbiri ile ilişkili uygulamalardan (Uygulama tanımları) oluşmaktadır. Yani var olan bir uygulama mimarinizi, içinden bazı uygulamaları da seçerek  farklı durumlarda sistem diagramları halinde, gerçek ortama geçirebiliriz. Sistem diagramları üzerinde yer alan uygulamaların bazı özellikleri için yeniden değer (overriding) girilebilmektedir. Bu özellikler uygulama diagramı üzerinde (overridable) belirtilmelidir. 

 

Sistem diagramları, büyük uygulama mimarisini temsil eden resmin daha kolay modellenmesi imkanını da sağlamaktadır. Sistemler, sistem ve alt sistem olarakta modellenebilir. (Nested Systems)

 

Örnek projemizde yer alan bazı  uygulamaları seçerek, sipariş sistemimizi tasarlayalım. Sipariş sistemimizin model dokümanı (SDM dokümanı) görüntüsü aşağıdaki şekilde olacaktır.

Resim2: Sipariş sistemi

 

 

Aynı şekilde, uyarı servislerini içeren uyarı sistemimizi de tasarlayabiliriz. Bu durumda, aşağıdaki sistem görüntüsünü elde edeceğiz.

 

Resim3: Uyarı sistemi

 

 

Sistem dokümanları içinde yer alan uygulama ve servislere, sistem üzerindeki iletişim noktalarından erişilebilmektedir. Bu sistem modellerinin farklı sistemler içinde kullanımının mümkün olduğunu belirtmiştik. Aşağıdaki ekran görüntülerinde; Sipariş sisteminin web uygulamasından kullanıldığı örnek sistem dokümanları gösterilmektedir.

 

 

Resim4: Web uygulamasından sistemlerin kullanımı (Web System)

 

Örnek projemizde; Sipariş ve Uyarı sistemi olarak 2 sistem modelledik. Projemizin daha geniş fonksiyonları olduğunu düşündüğümüzde (Finans,Üretim,Lojistik vb) sistemler halinde modellemenin önemi ortaya çıkmaktadır. Yukarıda bahsi geçtiği gibi, projelerimizde yer alan uygulamaların, farklı ihtiyaçlara göre (Müşteri kurulumları gibi) yeni sistemlerin modellenmesi, bu sistemlerdeki uygulamaların özelliklerinin değiştirilebilmesi gerçekten çok önemli bir avantaj. Aynı çözümü veya çözümün bir kısmını çalıştıran farklı müşterilerdeki uygulamaların,  işletim ortamlarındaki farklılıklarının dokümantasyonu da sağlanmış olacaktır.

 

Sonraki bölümde, sistemlerimizin çalışacağı fiziksel ortamın, mantıksal modelleme aracı inceleyeceğiz.

 

Teknik alt yapı tasarım aracı (Logical Datacenter Designer)

 

Teknik alt yapı tasarım aracı ile, projenin çalışacağı fiziksel işletim ortamı, mantıksal olarak modellenmektedir. Tasarım ortamında; Microsoft IIS, MS SQL Server gibi uygulama sunucuları ve bunların bağlantıları modellenip, gerekli konfigürasyonlar yapılabilir. Sunucular bölgeler halinde tanımlanıp, iletişim sınırları çizilebilir. Bölgede kullanılabilecek sunucu tipleri ve  bölgeye olan iletişimin yönü belirlenebilir. Sunucular ve bölgeler ile ilgili yapılan tanımlamalar, tekrar kullanmak amacıyla araç kutusuna kaydedilebilir.

 

Bu diagram, yazılım geliştiricilere, uygulamaların çalışacağı hedef ortam ile ilgili önemli bilgiler sağlamaktadır. Fiziksel işletim ortamı, yazılım geliştiriciler için o kadar önemli değil. Yazılım geliştiriciler, uygulama çalıştırma ortamı, konfigürasyonlar,kısıtlar ve sunucuların bağlantısı gibi hususlar ile ilgileniyor. Bunları bilmesi yeterli. Diğer detaylar, teknik alt yapı uzmanlarının sorumluluğunda. Bu model dokümanı da, teknik sunucu alt yapısı ve konfigürasyon bilgilerini içeren yapısı ile, teknik dokümantasyonumuzun önemli bir parçası.

 

Bu model dokümanı mantıksal olduğu için, gerçek ortamdaki sunucular ile farklılıklar olabilir. Mesela, gerçek ortamda bir sunucu üzerinde Windows Server 2003, Internet Information Services (IIS) 6.0 ve  SQL Server kurulmuş olduğunu düşünelim. Model diagramımızda, bunların hepsi için farklı mantıksal sunucular modelleyebiliriz.

 

 

Bu tasarım aracı ile birlikte sunulan tasarım elemanları aşağıdaki tabloda gösterilmiştir :

 

Tasarım elemanları

Açıklama

Windows uygulaması

Windows uygulaması, genel windows uygulamaları ve ofis uygulamaları olarak ayarlanabilir.

IIS sunucusu

ASP.NET uygulamaları,web servisleri ve diğer genel uygulamalar olrak ayarlanabilir.

Veritabanı sunucusu

Genel bir veritabanı sunucusunu temsil eder.

Genel sunucu

Önceden tanıtılmamış uygulama sunma ortamı

Bölge (Zone)

Sunucuların gruplanması

İletişim noktaları (Endpoints)

Alanlar ve sunucular arasındaki iletişim noktalarını temsil eder. Sunucular, müşteri (Client) iletişim noktalarını ve diğer sunucular ile olan iletişim noktalarını destekler.Alan iletişim noktaları, alan içine,alan dışına ve çift yönlü izin verme şeklinde tanımlanabilir.

Yorum

Model üzerine yorum eklemek için kullanılır.

Tablo2 : Teknikalt yapı tasarım aracının tasarım elemanları

 

Örnek projemiz ile ilgili, örnek bir  mantıksal sunucu modeli aşağıda sunulmuştur. İhtiyaçlarımıza göre, farklı model diagramları da çizilebiliriz.

 

 

 

 

Resim5: Teknik alt yapı tasarım model dokümanı.

 

Sunucunun sağlayacağı özellikler verilerek, uygulamaların buna uyması istenebilir. Bu tip hususlar; uygulamaların, teknik alt yapı üzerinde denenmesi sürecinde (gerçek ortama geçiş süreci) uygunluğu araştırılacak ve uygun olmayan durumlar için hata mesajı üretilecektir. 

 

Sonraki bölümde, sistem diagramlarımızın, teknik alt yapı tasarım modeli üzerine yerleştirilmesi ve uygunluğun sınandığı, modelleme aracını inceleyeceğiz.

 

Gerçek ortama geçiş tasarım aracı (Deployment Designer)

 

Bu tasarım aracı ile, sistem modelleri (Uygulama tanımları) , teknik alt yapı diagramları üzerine yerleştirilerek, sistemlerin gerçek ortama geçiş süreci oluşturulmaktadır. Bu bir deneme sürecidir. Bu diagramın oluşturulabilmesi için, uygulama mimari diagramı ve en az bir tane teknik alt yapı diagramı tasarlanmış olmalıdır.Uygulama tanımlarının, çalışacağı sunucuları doğru olarak tespit edilmelidir. Tasarım aracı, bu işlemi gerçekleştirirken, görsel uyarılar da sunmaktadır.

 

Tüm uygulama tanımları, uygun sunucularla ilişkilendirildikten sonra, bu işlemlerin uygunluğu araştırılabilir. Bu uygunluğu araştırma işlemi ile, Visual Studio tanımlı olan tüm kısıtlar ve ayarlar üzerinden gerekli kontrolleri yapar ve problemleri tespit eder. Mesela, uygulama tanımlarında; ASP.NET Web servisleri için, NET 2.0 gereksinimi belirlediğimizi düşünelim. Bu servislerin çalışacağı, sunucuda NET 1.1 kurulu olduğuna dair tanımlama yapılmış ise, sınama işleminde bir hata ile karşılaşılacaktır. Bıu hata listesi, derleme esnasında sunulan hata listesi şeklindedir. Hataya fare ile çift tıklandığında, hatanın yeri gösterilir. Tek satır kod yazmaya başlamadan, mimari ve çalışma ortamı ile ilgili problemlere erken çözüm imkanı elde edilmiş olur.

 

Sipariş sistemimizin web uygulamasından kullanımının gösterildiği sistem diagramımızı (Resim4 : WebSystem), mantıksal sunucu modeli diagramı üzerinde gerçek hayata geçirme çalışması (Deployment) içinde, aşağıdaki örnek model diagramı hazırlanmıştır : 

 

 

Resim11: Gerçek ortama geçiş tasarım aracı örnek ekranı

 

2 tane bölge oluşturduk. DMZ (Demilitarized Zone) bölgesi ve güvenli bölge. Web uygulamamızı, DMZ bölgesine, web servilerimizi ve veritabanımızı güvenli bölgeye yerleştirdik.

 

Gerçek ortama geçiş süreci ile ilgili bir rapor üretilmektedir. Bu rapor XML formatındadır. Formatlı bir döküman olması sebebiyle, başka bir sürece girdi olarak verilebilir.  VSTS, dokümantasyon amaçlı HTML raporu da üretmektedir. Bu raporda, sistem envanteri, sistem ile ilgili dosyalar,sunucu ayarları ve seçeneğe bağlı bir şekilde diagramlar bulunmaktadır.

 

Değerlendirme

 

Yazılım mimarları için VSTS araçları, Microsoft’un yeni modelleme vizyonunu temsil etmesi ve uygulama alanındaki ilk adımları olması açısından çok önemli. Modellerin sadece dokümantasyon olması özelliğinden çıkarak, uygulama geliştirme sürecinde kullanımı bize çok önemli imkanlar sunuyor. Bu makalemizde, 4 modelleme aracını ve süreç içindeki entegrasyonlarını inceleme imkanı bulduk. Bu modelleme araçları, DSL (Domain Specific Languages) araçları ile geliştirilmiş ve hazır olarak sunulmuştur. Aynı alt yapının kullanılması ile, yeni tasarım araçları da geliştirilip, sürece entegre edilebilir.

 

Yazılım mimarları için sunulan bu modelleme araçları ile, Servis temelli mimari (SOA-Service Oriented Architecture) projeleri geliştirmek için alt yapımız da hazır. SOA, yazılım geliştirmeye bakış açımızı etkileyecek çok önemli bir gelişme. Teknoloji sağlayıcıların en çok yatırım yaptıkları alanların başında geliyor.

 

Bu modelleme araçları, aynı zamanda çoğunlukla ihmal ettiğimiz teknik dökümantasyonumuzu da önemli ölçüde karşılıyor. Hem de güncel kalmasını sağlayarak. Yazılım ekipleri ile, teknik alt yapı uzmanları arasında süreç entegrasyonu, ortak çalışma ve bilgi paylaşımı imkanları ile kaliteli uygulama geliştirme adımlarımızda bize katkı sağlayacaktır.

 

 

Kaynaklar

 

Kaynaklar, bu serinin ilk makalesinde (Bölüm1:Giriş ve bileşenler), ortak yayınlanmıştır.

 

 

VSTS Yazılım mimarları 11 02 2007