Geliştirme sürecinizde modelleri kullanma

Visual Studio'da bir sistemi, uygulamayı veya bileşeni anlamanıza ve değiştirmenize yardımcı olması için bir model kullanabilirsiniz. Model, sisteminizin çalıştığı dünyayı görselleştirmenize, kullanıcıların ihtiyaçlarını netleştirmenize, sisteminizin mimarisini tanımlamanıza, kodu analiz etmenize ve kodunuzun gereksinimleri karşıladığından emin olmanıza yardımcı olabilir.

Hangi Visual Studio sürümlerinin her model türünü desteklediğini görmek için bkz . Mimari ve modelleme araçları için sürüm desteği.

Modeller size çeşitli yollarla yardımcı olabilir:

• Çizim modelleme diyagramları gereksinimler, mimari ve üst düzey tasarımla ilgili kavramları netleştirmenize yardımcı olur. Daha fazla bilgi için bkz . Model kullanıcı gereksinimleri.

• Modellerle çalışmak, gereksinimlerdeki tutarsızlıkları ortaya çıkarmanıza yardımcı olabilir.

• Modellerle iletişim kurmak, önemli kavramları doğal dile göre daha belirsiz bir şekilde iletmenize yardımcı olur. Daha fazla bilgi için bkz . Uygulamanızın mimarisini modelleme.

• Bazen kod veya veritabanı şemaları veya belgeleri gibi diğer yapıtları oluşturmak için modelleri kullanabilirsiniz. Örneğin, Visual Studio'nun modelleme bileşenleri bir modelden oluşturulur. Daha fazla bilgi için bkz . Modellerden uygulamanızı oluşturma ve yapılandırma.

Modelleri, aşırı çevikten yüksek törene kadar çok çeşitli işlemlerde kullanabilirsiniz.

Belirsizliği azaltmak için modelleri kullanma

Modelleme dili, doğal dilden daha az belirsizdir ve genellikle yazılım geliştirme sırasında gerekli olan fikirleri ifade etmek için tasarlanmıştır.

Projenizde çevik uygulamaları izleyen küçük bir ekip varsa, kullanıcı hikayelerini netleştirmenize yardımcı olması için modelleri kullanabilirsiniz. Müşteriyle ihtiyaçlarıyla ilgili tartışmalarda model oluşturmak, ani artış veya prototip kodu yazmaktan çok daha hızlı ve ürünün daha geniş bir alanında yararlı sorular oluşturabilir.

Projeniz büyükse ve dünyanın farklı yerlerinde ekipler içeriyorsa, gereksinimleri ve mimariyi düz metin olarak iletebileceğinizden çok daha etkili bir şekilde iletmenize yardımcı olması için modelleri kullanabilirsiniz.

Her iki durumda da model oluşturmak neredeyse her zaman tutarsızlıklarda ve belirsizliklerde önemli bir azalmaya neden olur. Farklı paydaşlar genellikle sistemin çalıştığı iş dünyası hakkında farklı bilgilere sahiptir ve farklı geliştiriciler genellikle sistemin nasıl çalıştığı hakkında farklı bilgilere sahiptir. Tartışmanın odağı olarak bir modelin kullanılması genellikle bu farklılıkları ortaya çıkarır. Tutarsızlıkları azaltmak için modeli kullanma hakkında daha fazla bilgi için bkz . Model kullanıcı gereksinimleri.

Modelleri diğer yapıtlarla kullanma

Model tek başına bir gereksinim belirtimi veya mimari değildir. Bu, bunların bazı yönlerini daha net ifade etmek için bir araçtır, ancak yazılım tasarımı sırasında gerekli olan tüm kavramlar ifade edilemez. Bu nedenle modeller OneNote sayfaları veya paragrafları, Microsoft Office belgeleri, Team Foundation'daki iş öğeleri veya proje odası duvarındaki yapışkan notlar gibi diğer iletişim araçlarıyla birlikte kullanılmalıdır. Son öğe dışında, bu nesne türlerinin tümü modelin öğe bölümlerine bağlanabilir.

Normalde modellerle birlikte kullanılan belirtimlerin diğer yönleri şunlardır. Projenizin ölçeğine ve stiline bağlı olarak, bu yönlerden birkaçını kullanabilir veya hiç kullanmayabilirsiniz:

• Kullanıcı hikayeleri. Kullanıcı hikayesi, projenin yinelemelerinden birinde teslim edilecek sistem davranışının bir yönünün kullanıcılar ve diğer paydaşlarla tartışıldığı kısa bir açıklamadır. Tipik bir kullanıcı hikayesi "Müşteri...." Kullanıcı hikayesi bir kullanım örnekleri grubuna neden olabilir veya daha önce geliştirilmiş kullanım örneklerinin uzantılarını tanımlayabilir. Kullanım örneklerinin tanımlanması veya genişletilmesi, kullanıcı hikayesinin daha anlaşılır hale getirilmesine yardımcı olur.

• değişiklik istekleri. Daha resmi bir projedeki değişiklik isteği, çevik projedeki kullanıcı hikayesine çok benzer. Çevik yaklaşım, tüm gereksinimleri önceki yinelemelerde geliştirilen değişiklikler olarak ele alır.

• Servis talebi açıklamasını kullanın. Kullanım örneği, kullanıcının belirli bir hedefe ulaşmak için sistemle etkileşim kurmasının bir yolunu temsil eder. Tam açıklama hedefi, ana ve alternatif olay dizilerini ve olağanüstü sonuçları içerir. Kullanım örneği diyagramı, kullanım örneklerini özetlemeye ve genel bir bakış sağlamaya yardımcı olur.

• Senaryolar: Senaryo, sistemin, kullanıcıların ve diğer sistemlerin paydaşlara değer sağlamak için birlikte nasıl çalıştığını gösteren olay dizisinin oldukça ayrıntılı bir açıklamasıdır. Kullanıcı arabiriminin slayt gösterisi veya kullanıcı arabiriminin prototipi biçiminde olabilir. Bir kullanım örneğini veya bir kullanım örneği dizisini açıklayabilir.

• Sözlük. Projenin gereksinimler sözlüğü, müşterilerin dünyalarını tartıştığı sözcükleri açıklar. Kullanıcı arabirimi ve gereksinim modelleri de bu terimleri kullanmalıdır. Sınıf diyagramı, bu terimlerin çoğu arasındaki ilişkilerin netleştirilmesine yardımcı olabilir. Diyagramların ve sözlüğün oluşturulması yalnızca kullanıcılar ve geliştiriciler arasındaki yanlış anlaşılmaları azaltmakla kalmaz, aynı zamanda hemen her zaman farklı iş paydaşları arasındaki yanlış anlaşılmaları ortaya çıkarır.

• İş kuralları. Birçok iş kuralı, gereksinimler sınıfı modelindeki ilişkilendirmeler ve öznitelikler üzerinde sabit kısıtlamalar olarak ve sıralı diyagramlarda kısıtlamalar olarak ifade edilebilir.

• Üst düzey tasarım. Ana bölümleri ve bunların birbirine nasıl uyum sağladığını açıklar. Bileşen, dizi ve arabirim diyagramları, üst düzey tasarımın önemli bir parçasıdır.

• Tasarım desenleri. Sistemin farklı bölümlerinde paylaşılan tasarım kurallarını açıklayın.

• Test belirtimleri. Test betikleri ve test kodu tasarımları, test adımlarının dizilerini açıklamak için etkinlik ve sıralı diyagramları iyi kullanabilir. Sistem testleri, gereksinimler değiştiğinde kolayca değiştirilebilmeleri için gereksinimler modeliyle ifade edilmelidir.

• Proje planı. Proje planı veya kapsam, her özelliğin ne zaman teslim edileceğini tanımlar. Hangi kullanım örneklerini ve iş kurallarını uyguladığını veya genişletebileceğini belirterek her özelliği tanımlayabilirsiniz. Kullanım örneklerine ve iş kurallarına doğrudan planda başvurabilir veya ayrı bir belgede bir özellik kümesi tanımlayabilir ve plandaki özellik başlıklarını kullanabilirsiniz.

Yineleme planlamasında modelleri kullanma

Tüm projeler ölçek ve kuruluş açısından farklı olsa da, tipik bir proje iki ile altı hafta arasında bir dizi yineleme olarak planlanır. Kapsamı ve sonraki yineleme planlarını ayarlamak için kullanılacak erken yinelemelerden gelen geri bildirimlere izin verecek kadar yineleme planlamak önemlidir.

Yinelemeli bir projede modellemenin avantajlarını hayata geçirmeye yardımcı olmak için aşağıdaki önerileri yararlı bulabilirsiniz.

Her yineleme yaklaştıkça odağı netleştirin

Her yineleme yaklaştıkça, yinelemenin sonunda nelerin teslim edileceklerini tanımlamaya yardımcı olması için modelleri kullanın.

• Erken yinelemelerde her şeyi ayrıntılı olarak modellemeyin. İlk yinelemede, kullanıcı sözlüğündeki ana öğeler için bir sınıf diyagramı oluşturun, ana kullanım örneklerinin bir diyagramını çizin ve ana bileşenlerin bir diyagramını çizin. Ayrıntılar projenin ilerleyen bölümlerinde değişeceği için bunların hiçbirini ayrıntılı olarak açıklamayın. Özelliklerin veya önemli kullanıcı hikayelerinin listesini oluşturmak için bu modelde tanımlanan terimleri kullanın. Proje genelinde tahmini iş yükünü yaklaşık olarak dengelemek için özellikleri yinelemelere atayın. Bu atamalar projede daha sonra değişecektir.

• Erken yinelemede en önemli kullanım örneklerinin tümünün basitleştirilmiş sürümlerini uygulamaya çalışın. Bu kullanım örneklerini daha sonraki yinelemelerde genişletin. Bu yaklaşım, projede herhangi bir şey yapmak için gereksinimlerde veya mimaride çok geç bir kusur bulma riskini azaltmaya yardımcı olur.

• Her yinelemenin sonunda, bir sonraki yinelemede geliştirilecek gereksinimleri veya kullanıcı hikayelerini ayrıntılı olarak tanımlamak için bir gereksinimler atölyesi tutun. Öncelikleri belirleyebilecek kullanıcıları ve iş paydaşlarını, geliştiricileri ve sistem test edicilerini davet edin. 2 haftalık yinelemenin gereksinimlerini tanımlamak için üç saat izin verin.

• Atölyenin amacı, herkesin bir sonraki yinelemenin sonunda nelerin gerçekleştirileceğini kabul etmektir. Gereksinimlerin netleştirilmesine yardımcı olacak araçlardan biri olarak modelleri kullanın. Atölyenin çıktısı bir yineleme kapsamıdır; yani Team Foundation'daki geliştirme görevlerinin ve Microsoft Test Manager'daki test paketlerinin listesidir.

• Gereksinimler atölyesinde tasarımı yalnızca geliştirme görevleri için tahminleri belirlemeniz gerektiği sürece tartışın. Aksi takdirde, kullanıcıların doğrudan yaşayabilecekleri sistem davranışıyla ilgili tartışmayı sürdürebilirsiniz. Gereksinimler modelini mimari modelden ayrı tutun.

• Teknik olmayan paydaşlar genellikle UML diyagramlarını anlamakta hiçbir sorun yaşamaz ve sizin de bazı rehberliğinizle.

Modeli iş öğelerine bağlama

Gereksinimler atölyesinin ardından gereksinimler modelinin ayrıntılarını ayrıntılı bir şekilde inceleyin ve modeli geliştirme görevlerine bağlayın. Team Foundation'daki iş öğelerini modeldeki öğelere bağlayarak bunu yapabilirsiniz.

Herhangi bir öğeyi iş öğelerine bağlayabilirsiniz, ancak en kullanışlı öğeler şunlardır:

• İş kurallarını veya hizmet gereksinimlerini açıklayan açıklamalar. Daha fazla bilgi için bkz . Model kullanıcı gereksinimleri.

Modeli testlere bağlama

Kabul testlerinin tasarımını yönlendirmek için gereksinimler modelini kullanın. Geliştirme çalışmaları ile bu testleri eşzamanlı olarak oluşturun.

Bu teknik hakkında daha fazla bilgi edinmek için bkz . Modelden test geliştirme.

Kalan çalışmayı tahmin et

Gereksinimler modeli, her yinelemenin boyutuna göre projenin toplam boyutunu tahmin etmeye yardımcı olabilir. Kullanım örneklerinin ve sınıfların sayısını ve karmaşıklığını değerlendirmek, gerekli geliştirme çalışmalarını tahmin etme konusunda size yardımcı olabilir. İlk birkaç yinelemeyi tamamladığınızda, kapsanan gereksinimlerin ve hala karşılanması gereken gereksinimlerin karşılaştırması, projenin geri kalanının maliyeti ve kapsamına ilişkin yaklaşık bir ölçü verebilir.

Her yinelemenin sonuna yakın bir şekilde, gelecekteki yinelemelere gereksinimlerin atamasını gözden geçirin. Her yinelemenin sonunda yazılımlarınızın durumunu bir kullanım örneği diyagramında alt sistem olarak göstermek yararlı olabilir. Tartışmalarınızda, kullanım örneklerini ve kullanım örneği uzantılarını bu alt sistemlerden birinden diğerine taşıyabilirsiniz.

Soyutlama düzeyleri

Modeller, yazılımla ilgili olarak çeşitli soyutlamalara sahiptir. En somut modeller doğrudan program kodunu, en soyut modeller ise kodda gösterilip gösterilmeyebilecek iş kavramlarını temsil eder.

Bir model çeşitli diyagram türleri aracılığıyla görüntülenebilir. Modeller ve diyagramlar hakkında bilgi için bkz . Uygulamanız için model oluşturma.

Tasarımı farklı soyutlama düzeylerinde tanımlamak için farklı diyagram türleri yararlıdır. Diyagram türlerinin çoğu birden fazla düzeyde kullanışlıdır. Bu tablo, her diyagram türünün nasıl kullanılabileceğini gösterir.

Tasarım düzeyi	Diyagram türleri
İş Süreci Sisteminizin hangi bağlam içinde kullanılacağını anlamak, kullanıcıların ondan nelere ihtiyacı olduğunu anlamanıza yardımcı olur.	- Kavramsal sınıf diyagramları, iş süreci içinde kullanılan iş kavramlarını açıklar.
Kullanıcı gereksinimleri Kullanıcıların sisteminizden nelere ihtiyaç duyduğunun tanımı.	- İş kuralları ve hizmet kalitesi gereksinimleri ayrı belgelerde açıklanabilir.
Üst düzey tasarım Sistemin genel yapısı: ana bileşenler ve bunların nasıl bir araya topladıkları.	- Bağımlılık Diyagramları, sistemin birbirine bağlı parçalara nasıl yapılandırıldığını açıklar. Mimariye uygun olduğundan emin olmak için program kodunu bağımlılık diyagramlarına karşı doğrulayabilirsiniz.
Kod analizi Diyagramlar koddan oluşturulabilir.	- Bağımlılık diyagramları sınıflar arasındaki bağımlılıkları gösterir. Güncelleştirilmiş kod bir bağımlılık diyagramında doğrulanabilir. - Sınıf diyagramları koddaki sınıfları gösterir.

Dış kaynaklar

Kategori	Bağlantılar
Videolar	MSDN Nasıl Yapılır Videoları: UML Modelleri ve Diyagramları Oluşturma ve Kullanma (Visual Studio Ultimate) MSDN Nasıl Yapılır Serisi: UML Araçları ve Genişletilebilirlik (Visual Studio Ultimate)
Forumlar	- Visual Studio Görselleştirme ve Modelleme Araçları - Visual Studio Görselleştirme ve Modelleme SDK'sı (DSL Araçları)
Bloglar	Microsoft DevOps
Teknik Makaleler ve Dergiler	MSDN Mimari Merkezi

İlgili içerik

• Çevik geliştirmede modelleri kullanma
• Uygulamanız için model oluşturma
• Kullanıcı gereksinimlerini modelleme
• Uygulama mimarinizi modelleme
• Model aracılığıyla test geliştirme
• Modelleme çözümünüzün yapısını oluşturma

Not

Metin Şablonu Dönüştürme bileşeni, Visual Studio uzantısı geliştirme iş yükünün bir parçası olarak otomatik olarak yüklenir. Ayrıca Visual Studio Yükleyicisi Tek tek bileşenler sekmesinden SDK'lar, kitaplıklar ve çerçeveler kategorisinin altından da yükleyebilirsiniz. Tek tek bileşenler sekmesinden Modelleme SDK'sı bileşenini yükleyin.