Aracılığıyla paylaş


Geliştirme Süreci içinde Modelleri Kullanma

Visual Studio Ultimate'da; bir sistemi, uygulamayı veya bileşeni anlamanıza ve değiştirmenize yardım edecek bir model kullanabilirsiniz. Bir model sisteminizin çalıştığı dünyayı görselleştirmenize, kullanıcının gereksinimlerini netleştirmenize, sisteminizin mimarisini tanımlamanıza, kodu çözümlemenize ve kodunuzun gereksinimleri karşıladığından emin olmanıza yardım edebilir.

Bkz: Kanal 9 Video: Mimari modelleme yoluyla geliştirmek.

Modeller nasıl kullanılır

Modeller birkaç şekilde yardımcı olabilir:

  • Modelleme diyagramları çizmek gereksinimler, mimari ve üst düzey tasarımda bulunan kavramların netleştirilmesine yardım eder. Daha fazla bilgi için bkz. Kullanıcı Gereksinimlerini Modelleme.

  • Modeller ile çalışmak gereksinimlerdeki tutarsızlıkları açığa çıkarmanıza yardımcı olabilir.

  • Modeller ile iletişim kurmak, doğal dil ile olandan daha az belirsiz olan önemli kavramlarla iletişim kurmanıza yardımcı olur. Daha fazla bilgi için bkz. Yazılım Sistem Mimarisi Modelleme.

  • Bazen kod veya veritabanı şemaları ve belgeler gibi diğer yapıları oluşturmak için modelleri kullanabilirsiniz. Örneğin, Visual Studio Ultimate'un modelleme bileşenleri bir modelden oluşturulur. Daha fazla bilgi için bkz. Uygulamanızı Modellerden Oluşturma ve Yapılandırma.

Modelleri çok çeşitli işlemlerde, extreme agile'dan (oldukça çevik) high ceremony'e (yüksek protokol), kullanabilirsiniz.

Dd409423.collapse_all(tr-tr,VS.110).gifBelirsizliği Azaltmak için Model Kullanma

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

Eğer projeniz çevik uygulamaları takip eden küçük bir ekibe sahipse, kullanıcı hikayelerini açıklığa kavuşturmanıza yardım etmesi için modeller kullanabilirsiniz. Kullanıcılarla onların gereksinimleri hakkında olan tartışmalarda bir model oluşturma, yararlı soruları daha hızlı oluşturur ve ani veya prototip kod yazmaktansa ürünün daha geniş bir alanına geçirir.

Eğer projeniz büyükse ve dünyanın farklı kısımlarında takımlar içeriyorsa, gereksinimleri ve mimariyi düz metinde olduğundan daha etkili bir şekilde konuşabilmek için modelleri kullanabilirsiniz.

Her iki durumda da bir model oluşturma, hemen hemen her zaman tutarsızlıklarda ve belirsizliklerde önemli bir azalmayla sonuçlanır. Farklı proje katılımcıları sık sık sistemin çalıştığı iş dünyası hakkında farklı şeyler anlarlar ve farklı geliştiriciler sık sık sistemin nasıl çalıştığı hakkında farklı şeyler anlarlar. Tartışmanın odağı olarak bir model kullanmak genellikle bu farklılıkları açığa çıkarır. Tutarsızlıkları azaltmak için bir modelin nasıl kullanıldığı hakkında daha fazla bilgi için bkz. Kullanıcı Gereksinimlerini Modelleme.

Dd409423.collapse_all(tr-tr,VS.110).gifModelleri Diğer Yapılar ile Kullanma

Bir model kendiliğinden bir gereksinimler belirtimi veya bir mimari değildir. Model, bu şeylerin bazı yönlerini daha net ifade etmek için kullanılan bir araçtır, ancak yazılım tasarımı sırasında gerekli tüm kavramlar ifade edilemez. Bu nedenle modeller; OneNote sayfaları ve paragrafları, Microsoft Office belgeleri, Team Foundation'daki iş öğeleri veya proje odası duvarındaki yapışkan notlar gibi diğer iletişim yolları ile birlikte kullanılmalıdır. Son öğeden ayrı olarak, bu nesne türlerinin hepsi modelin öğe bölümlerine bağlanabilir.

Belirtimin normalde modeller ile birlikte kullanılan diğer yönleri aşağıdakileri içerir. Projenizin ölçek ve stiline bağlı olarak, bu yönlerin hiçbirini veya birkaçını kullanabilirsiniz:

  • Kullanıcı hikayeleri. Bir kullanıcı hikayesi; kullanıcılarla veya diğer proje katılımcıları ile tartışılmış, projenin yinelemelerinden birinde teslim edilecek olan sistemin davranış yönünün kısa bir açıklamasıdır. Tipik bir kullanıcı hikayesi "Müşteri şunları yapabilecektir...." ile başlar. Bir kullanıcı hikayesi kullanım örnekleri grubunu tanıtabilir veya daha önceden geliştirilmiş kullanım örneği uzantılarını tanımlayabilir. Kullanım örneklerini tanımlama veya genişletme, kullanıcı hikayesinin daha anlaşılır olmasına yardım eder.

  • İstekleri Değiştirme. Daha resmi bir projedeki değiştirme isteği faal bir projedeki kullanıcı hikayesine benzer. Çevik yaklaşım tüm gereksinimlere önceki yinelemelerde geliştirilenlere olan değişiklikler gibi davranır.

  • Kullanım örneği açıklaması. Bir kullanım örneği, belirli bir hedefe ulaşmak için kullanıcının sistem ile etkileşime girdiği bir yolu gösterir. Tam bir açıklama; hedefi, ana ve alternatif olaylar dizisini ve olağandışı sonuçları içerir. Bir kullanım örneği diyagramı, kullanım örneklerine genel bakışı sağlar ve özetler.

  • Senaryolar Bir senaryo; sistemin, kullanıcıların ve diğer sistemlerin proje katılımcılarına bir değer sağlamak için nasıl birlikte çalıştığını gösteren olaylar dizisinin oldukça ayrıntılı bir açıklamasıdır. Kullanıcı arayüzünün slayt gösterisi veya kullanıcı arayüzünün prototip formunu alabilir. Bir kullanım örneği veya kullanım örnekleri dizisini açıklayabilir.

  • Sözlük. Projenin gereksinimler sözlüğü, onların dünyasını tartışan müşteriler ile kelimeleri açıklar. Ayrıca, kullanıcı arayüzü ve gereksinimler modeli de bu terimleri kullanmalıdır. Bir sınıf diyagramı, bu terimlerin birçoğu arasındaki ilişkileri açıklamanıza yardımcı olabilir. Diyagram ve sözlük oluşturma sadece kullanıcılar ve geliştiriciler arasındaki yanlış anlamaları azaltmaz, ayrıca hemen her zaman farklı iş proje hissedarları arasındaki yanlış anlamaları da açığa çıkarır.

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

  • Üst düzey tasarım. Ana kısımları ve onların birlikte nasıl uyduğunu açıklar. Bileşen, dizi ve arayüz diyagramları üst düzey tasarımın önemli bir parçasıdır.

  • Tasarım desenleri. Sistemin farklı bölümleri arasında paylaşılan tasarımın kurallarını açıklar.

  • Sınama belirtimleri. Sınama betiği ve sınama kodu için olan tasarımlar, sınama adımları dizisini açıklamak için etkinlik ve sıralı diyagramların iyi bir kullanımını yapabilir. Sistem sınamaları gereksinimler modeli açısından ifade edilmelidir böylece gereksinimler değiştiğinde kolaylıkla değiştirilebilirler.

  • Proje planı. Proje planı veya biriktirme listesi her özelliğin teslim edileceği zamanı tanımlar. Her özelliği, hangi kullanım örneklerini ve iş kurallarını uyguladığını veya genişlettiğini belirterek tanımlayabilirsiniz. Planda kullanım örneklerine ve iş kurallarına doğrudan başvurabilir ya da ayrı bi belgede özellikler kümesi tanımlayabilir ve planda özellik başlıklarını kullanabilirsiniz.

Dd409423.collapse_all(tr-tr,VS.110).gifYineleme Planlamada Model Kullanma

Tüm projelerin kendi ölçeklerinde ve organizasyonlarında farklı olmasına rağmen, tipik bir proje iki ve altı hafta arasında yinelemeler dizisi olarak planlanır. Yeteri kadar yineleme planlamak, erken yinelemelerden geribildirim almak ve sonraki yinelemelerde kapsam ve plan ayarlamaları yapmak için önemlidir.

Aşağıdaki önerileri, bir yineleme projesinde modellemenin yararlarını fark etmenize yardımcı olması açısından faydalı bulabilirsiniz.

Dd409423.collapse_all(tr-tr,VS.110).gifHer Yinemeleme Yaklaştıkça Odağı Keskinleştirme

Her yineleme yaklaşımı olarak, yinelemenin sonunda teslim edilecekleri tanımlamanıza yardım etmesi 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 çizeneği oluşturun, önemli kullanım örneklerinin ve ana bileşenlerin diyagramını çizin. Bunların hiçbirini ince ayrıntılı olarak açıklamayın çünkü projede ayrıntılar daha sonra değişecektir. Özelliklerin bir listesini veya kullanıcı hikayelerini oluşturmak için bu modelde tanımlanmış terimleri kullanın. Proje boyunca tahmin edilen iş yükünü yaklaşık olarak dengelemek için yinelemelere özellikler atayın. Projedeki bu atamalar daha sonra değişecektir.

  • Erken bir yinelemede en önemli kullanım örneklerinin basitleştirilmiş sürümlerini uygulamayı deneyin. Bu kullanım örneklerini sonraki yinelemelerde genişletin. Bu yaklaşım, gereksinimlerde bir hata bulma riskinin azalmasına veya hakkında herhangi bir şey yapmak için projede mimarinin çok geç olma riskinin azalmasına yardım eder.

  • Her yinelemenin yakınında, bir sonraki yinelemede geliştirilecek gereksinimleri veya kullanıcı hikayelerini ayrıntılı olarak tanımlamak için gereksinimler atölyesi tutun. Önceliklere karar verebilen kullanıcılarının ve iş proje katılımcılarının yanı sıra geliştiricileri ve sistem sınayıcılarını da davet edin. 2 haftalık yineleme için gereksinimleri tanımlamak üzere üç saat izin verir.

  • Herkes için atölyenin amacı ileriki yinelemenin sonunda neler gerçekleştirilmiş olacağı konusunda hem fikir olmaktır. Gereksinimleri belirlemenize yardım etmek için modelleri araçlardan biri olarak kullanın. Atölyenin çıktısı bir yineleme biriktirmedir: yani Team Foundation öğesindeki geliştirme görevleri listesi ve Microsoft Test Yöneticisi öğesindeki test paketleridir.

  • Gereksinimler atölyesinde, sadece geliştirme görevleri için tahminlere karar vermeye gereksinim duymanıza kadar tasarımı tartışın. Aksi takdirde, tartışmayı kullanıcıların doğrudan deneyebileceği sistem davranışına saklayın. Gereksinimler modelini mimari modelden ayrı tutun.

  • Teknik olmayan proje katılımcıları genellikle sizden biraz kılavuzluk ile UML diyagramlarını anlamakta hiçbir sorun yaşamaz.

Dd409423.collapse_all(tr-tr,VS.110).gifModeli İş Öğelerine Bağlama

Gereksinimler atölyesinden sonra, gereksinimler modelinin detaylarına girin ve modeli geliştirme görevlerine bağlayın. Bunu, Team Foundation'daki iş öğelerini modeldeki öğelere bağlayarak yapabilirsiniz. Bunun nasıl yapıldığını öğrenmek için bkz. Model Öğelerini ve İş Öğelerini Bağlama.

Herhangi bir öğeyi iş öğelerine bağlayabilirsiniz ancak en yararlı öğeler aşağıdaki gibidir:

  • Kullanım örnekleri. Kullanım örneğini, onu uygulayacak geliştirme görevlerine bağlayabilirsiniz.

  • Kullanım örneği uzantıları. Eğer yalnızca bir yinelemede kullanım örneğinin bir yönü uygulanacaksa, onu bir veya daha çok uzantı ile birlikte taban kullanım örneği içine ayırabilirsiniz. Uzantılar, «extend» (genişlet) ilişkisi ile taban durumuna bağlanmış kullanım örnekleridir. Kullanım örneği uzantıları hakkında daha fazla bilgi için bkz. UML Kullanım Durumu Diyagramları: Başvuru.

  • İş kurallarını veya hizmet gereksinimler kalitesini açıklayan yorumlar. Daha fazla bilgi için bkz. Kullanıcı Gereksinimlerini Modelleme.

Dd409423.collapse_all(tr-tr,VS.110).gifModeli Sınamalara Bağlama

Onay sınamalarının tasarımına yol göstermesi için gereksinimler modelini kullanın. Bu sınamaları geliştirme işi ile eşzamanlı olarak oluşturun.

Bu teknik hakkında daha fazla bilgi için bkz. Modelden Testler Geliştirme.

Dd409423.collapse_all(tr-tr,VS.110).gifKalan İşi Tahmin Etme

Gereksinimler modeli, her yinelemenin boyutuyla ilgili olarak projenin toplam boyutunu tahmin etmeye yardım edebilir. Kullanım örneklerinin ve sınıfların sayısını ve karmaşıklığını değerlendirmek, gereken geliştirme işini tahmin etmenize yardım edebilir. İlk birkaç yinelemeyi tamamladığınızda, kapsanan gereksinimler ile hala kapsanmamış olanların karşılaştırılması yaklaşık maliyet ölçüsünü ve projenin kalan kapsamını verebilir.

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

Soyutlama düzeyleri

Modeller yazılımla ilişkili olarak bir soyutlama aralığına sahiptir. En somut modeller doğrudan program kodunu gösterir ve en soyut modeller kodda gösterilebilen veya gösterilemeyecek olan iş kavramlarını gösterir.

Bir model birçok türdeki diyagram aracılığıyla görüntülenebilir. Modeller ve diyagramlar hakkında daha fazla bilgi için bkz. Yazılım Tasarımı için Modeller Geliştirme.

Farklı türlerdeki diyagram, tasarımı farklı soyutlama düzeylerinde açıklamak için yararlıdır. Diyagram türlerinin çoğu birden daha fazla düzeyde yararlıdır. Bu tablo, her diyagram türünün nasıl kullanılabileceğini gösterir.

Tasarım düzeyi

Diyagram türleri

İş İşlemi

Sisteminizin içinde kullanılacağı bağlamı anlamak kullanıcıların ondan ne istediğini anlamanıza yardımcı olur.

  • Etkinlik diyagramları, iş hedeflerine ulaşmak için insanlar ve sistemler arasındaki iş akışını açıklar.

  • Kavramsal sınıf diyagramları, iş işlemleri içinde kullanılan iş kavramlarını açıklar.

Kullanıcı gereksinimleri

Kullanıcıların sisteminizden beklediklerinin tanımı.

  • Kullanım örneği diyagramları, kullanıcılar ve diğer dış sistemlerin geliştirdiğiniz sistem ile sahip olduğu etkileşimleri özetler. Diğer belgeleri her kullanım örneğine onu ayrıntılı olarak açıklamak için iliştirebilirsiniz.

  • UML sınıf çizenekleri, kullanıcılar ve sistemin hakkında iletişim kurduğu bilgi türlerini açıklar.

  • İş kuralları ve hizmet gereksinimlerinin kalitesi ayrı belgelerde açıklanabilir.

Üst düzey tasarım.

Sistemin genel yapısı: ana bileşenler ve nasıl eşleştikleri.

  • Katman diyagramları sistemin nasıl bölümler halinde yapılandırıldığını açıklar. Program kodunu mimariye uymasını sağlamak için katman diyagramlarına karşı doğrulayabilirsiniz.

  • Bileşen diyagramları, her bir bileşen tarafından sağlanan ve gerekli olan ileti ve hizmetleri belirleyen, parçaların arabirimlerini gösterir.

  • Sıralı diyagramlar, bileşenlerin her kullanım örneğini uygulamak için nasıl iletişim kurduğunu gösterir.

  • UML sınıf çizenekleri bileşenlerin arayüzlerini ve bileşenler arasında geçen veri türlerini açıklar.

Tasarım desenleri.

Tasarım sorunlarını çözmenin onun her bölümünde kullanılan kural ve yöntemleri.

  • UML sınıf çizenekleri desenin yapılarını açıklar.

  • Sıralı veya etkinlik diyagramları etkileşimleri ve algoritmaları gösterir.

Kod analizi

Koddan diyagramın çeşitli türleri oluşturulabilir.

  • Sıralı diyagramlar kodda nesneler arasındaki etkileşimi gösterir.

  • Katman diyagramları sınıflar arasındaki bağımlılıkları gösterir. Güncelleştirilmiş kod bir katman diyagramına karşı doğrulanabilir.

  • Sınıf diyagramları kodda sınıfları gösterir.

Dış Kaynaklar

Kategori

Bağlantılar

Videolar

video bağlantısı

video bağlantısı

video bağlantısı

Forumlar

Bloglar

Team Foundation Server Blog + Visual Studio alm

Teknik Makaleler ve Belgeler

The Architecture Journal - Issue 23: Architecture Modeling and Processes

Diğer Siteler

MSDN Architecture Center

Visual Studio mimarisi zamanda alet kullanımı Kılavuzu

Ayrıca bkz.

Kavramlar

Visual Studio mimarisi zamanda alet kullanımı Kılavuzu

Kullanım modelleri hızlı geliştirme

Yazılım Tasarımı için Modeller Geliştirme

Kullanıcı Gereksinimlerini Modelleme

Yazılım Sistem Mimarisi Modelleme

Modelden Testler Geliştirme

Modelleme Çözümlerinin Yapılandırılması