Yazılım Sistem Mimarisi Modelleme

Yazılım sisteminizin veya uygulamanızın kullanıcılarınızın gereksinimlerini karşıladığından emin olmak için, genel yapı açıklamanızın ve sisteminizin veya uygulamanızın davranışının bir parçası olarak Visual Studio Ultimate'da modeller oluşturabilirsiniz. Modelleri kullanarak, tasarım boyunca kullandığınız desenleri de açıklayabilirsiniz. Bu modeller; varolan mimariyi anlamanıza, değişiklikleri tartışmanıza ve amaçlarınızla açıkça iletişim kurmanıza yardım eder.

Bir modelin amacı; doğal dil açıklamalarında olan belirsizlikleri azaltmak ve sizin ve çalışma arkadaşlarınızın tasarımı görselleştirmenize ve alternatif tasarımları tartışmanıza yardım etmek içindir. Bir model, diğer belgeler veya tartışmalarla birlikte kullanılmalıdır. Kendi başına bir model, mimarinin tam bir belirtimini göstermez.

Bir sistemin mimarisi iki alana ayrılabilir:

• Üst düzey Tasarım. Bu, ana bileşenleri ve her gereksinimi karşılamak için birbirleriyle nasıl etkileşim kurduklarını açıklar. Eğer sistem büyükse, her bileşenin daha küçük bileşenlerden nasıl oluştuğunu gösteren kendi üst düzey tasarımı olabilir.

• Bileşenlerin tasarımları boyunca kullanılan Tasarım Desenleri ve kuralları. Bir desen, bir programlama hedefini sağlamak için belirli bir yaklaşımı açıklar. Bir tasarım boyunca aynı desenleri kullanarak, ekibiniz değişiklikler yapmanın ve yeni bir yazılım geliştirmenin maliyetini azaltabilir.

Üst düzey Tasarım

Üst düzey tasarım, sisteminizin ana bileşenlerini ve tasarımın hedeflerine ulaşmak için birbirleriyle nasıl etkileşim kurduklarını açıklar. Belirli bir sırada olmak zorunda olmamasına rağmen, aşağıdaki listedeki etkinlikler üst düsey tasarım geliştirmeye dahildir.

Eğer varolan bir kodu güncelleştiriyorsanız, ana bileşenleri açıklayarak başlayabilirsiniz. Kullanıcı gereksinimlerine yapılan değişiklikleri anladığınızdan emin olun ve sonra bileşenler arasındaki etkileşimleri ekleyin veya değiştirin. Eğer yeni bir sistem geliştiriyorsanız, kullanıcı gereksinimlerinin ana özelliklerini anlayarak başlayın. Ana kullanım örnekleri için etkileşim dizilerini keşfedebilirsiniz ve sonra dizileri bir bileşen tasarımında birleştirebilirsiniz.

Her durumda, farklı etkinlikleri paralel olarak geliştirmek ve kodu ve sınamaları erken aşamada geliştirmek yararlıdır. Başka birine başlamadan önce bu yönlerden birini tamamlamaya çalışmayı denemekten kaçının. Genellikle, hem gereksinimler hem de sistemi tasarlamak için en iyi anlama yolunuz, kodu yazarken ve sınarken değişecektir. Bu nedenle, gereksinimlerin ve tasarımınızın ana özelliklerini anlayarak ve kodlayarak başlamalısınız. Projenin sonraki yinemelerinde ayrıntıları doldurun.

• Gereksinimleri Anlama. Herhangi bir tasarımın başlangıç noktası kullanıcı gereksinimlerinin açıkça anlaşılmasıdır.

• Mimari Desenler. Sistemin çekirdek teknolojileri ve mimari öğeleri hakkında yaptığınız seçimler.

• Bileşenler ve Bunların Arayüzleri. Sistemin ana kısımlarını ve birbiriyle etkileşen arayüzleri göstermek için bileşen diyagramları çizebilirsiniz. Her bileşenin arayüzleri, sıralı diyagramlarında belirlediğiniz tüm iletileri içerir.

• Bileşenler arasındaki Etkileşimler. Her kullanım örneği, olay veya gelen ileti için, gerekli cevabı elde etmek için sistemin ana bileşenlerinin nasıl etkileşim kurduklarını gösteren bir sıralı diyagram çizebilirsiniz.

• Bileşenlerin ve Arayüzlerin Veri Modeli. Bileşenler arasından geçirilen ve bileşenler içinde saklanadan bilgileri açıklamak için sınıf çizenekleri çizebilirsiniz.

Gereksinimleri Anlama

Tam bir uygulamanın üst düzey tasarımı en verimli şekilde bir gereksinim modeli veya kullanıcı gereksinimlerinin başka bir açıklaması ile birlikte geliştirilir. Gereksinim modeli hakkında daha fazla bilgi için bkz. Kullanıcı Gereksinimlerini Modelleme.

Geliştirdiğiniz sistem daha büyük bir sistem içinde bir bileşen ise, gereksinimlerinizin bir bölümü veya tamamı program arayüzlerinde şekillendirilebilir.

Gereksinim modeli şu önemli bilgi parçalarını sağlar:

• Sağlanan arayüzler. Sağlanan bir arayüz, sistemin veya bileşenin kullanıcılarına ister insan kullanıcı ister diğer yazılım bileşenleri olsun sağlamak zorunda olduğu hizmetleri veya işlemleri listeler.

• Gerekli arayüzler. Gerekli bir arayüz, sistemin veya bileşenin kullanabileceği hizmetleri veya işlemleri listeler. Bazı durumlarda, tüm bu hizmetleri sizin kendi sisteminizin bir parçası olarak tasarlamanız mümkün olacaktır. Diğer durumlarda, özellikle birçok yapılandırmada diğer bileşenler ile birleştirilebilir bir bileşen tasarlıyorsanız, gerekli arayüz dış etkenler tarafından ayarlanacaktır.

• Servis kalitesi gereksinimleri. Başarım, güvenlik, sağlamlık ve sistemin karşılaması gereken diğer hedefler ve kısıtlamalar.

Gereksinim modeli, ya insan ya da diğer yazılım bileşenleri olan sistem kullanıcılarınızın bakış açısından yazılır. Kullanıcılar sisteminizin iç işleyişi hakkında hiçbir şey bilmez. Bunun tersine, bir mimari modelde hedefiniz iç işleyişi açıklamak ve onların kullanıcı gereksinimlerini nasıl karşıladığını göstermektir.

Gereksinimler ve mimari modelleri ayrı tutmak yararlıdır çünkü gereksinimleri kullanıcılarla tartışmanızı kolaylaştırır. Ayrıca, gereksinimleri değişmeden tutarken tasarımı yeniden düzenlemenize ve alternatif mimarileri düşünmenize yardım eder.

Gereksinimleri ve mimari modelleri iki alternatif yolla ayırabilirsiniz:

• Onları aynı çözüm içinde ancak farklı projelerde tutun. UML Model Gezgini'nde ayrı modeller olarak görüneceklerdir. Farklı ekip üyeleri modeller üzerinde paralel çalışabilirler. Modeller arasında izlemenin sınırlı türleri oluşturulabilir.

• Onları aynı UML modele ancak farklı paketlere yerleştirin. Bu, modeller arasındaki bağımlılıkları izlemenizi kolaylaştırır, ancak model üzerinde aynı anda birden fazla kişinin çalışmasını engeller. Ayrıca, çok büyük bir modelin Visual Studio'ya yüklenmesi daha uzun sürecektir. Bu yaklaşım bu nedenle büyük projeler için daha az uygundur.

Gereksinim modeline veya mimari modele koymanız gereken ayrıntı miktarı projenin ölçeğine ve ekibin boyutu ve dağıtımına bağlıdır. Kısa bir proje üzerinde küçük bir takım başka bir sınıf diyagramı iş kavramları ve bazı tasarım desenlerini tasarlamaktan İleri'den gitmek; birden fazla bölge üzerinde dağıtılmış büyük bir proje önemli ölçüde daha fazla ayrıntıya gereksinim duyacaktır.

Mimari Desenler

Geliştirmede önce, tasarımın bağlı olacağı ana teknolojileri ve öğeleri seçmek zorundasınız. Bu seçimlerin yapılacağı alanlar şunları içerir:

• Temel teknoloji seçimleri; örneğin, veritabanı ile dosya sistemi arasındaki seçim, ağa bağlı bir uygulama ve bir Web istemcisi arasındaki seçim vb.

• Framawork seçimleri; örneğin Windows Workflow Foundation veya ADO.NET Entity Framework arasındaki seçim.

• Tümleştirme yöntemi seçimleri, örneğin kurumsal hizmet veri yolu veya noktadan noktaya kanal.

Bu seçimler sıklıkla ölçek ve esneklik gibi servis kalitesi gereksinimleri tarafından belirlenir ve ayrıntılı gereksinimler bilinmeden önce yapılabilir. Büyük bir sistemde, donanım ve yazılım yapılandırması kesinlikle birbiriyle ilişkilidir.

Yaptığınız seçimler, mimari modeli nasıl kullandığınızı ve yorumladığınızı etkiler. Örneğin, veritabanı kullanan bir sistemde, sınıf çizeneğindeki ilişkilendirmeler veritabanındaki ilişkileri ve dış anahtarları gösterebilir; oysa ki XML dosyalarına dayanan bir sistemde, ilişkilendirmeler XPath'i kullanan çapraz başvuruları gösterebilir. Dağıtılmış bir sistemde, sıralı diyagramdaki iletiler kablo üzerindeki iletileri gösterebilir; bağımsız bir uygulamada, onlar işlev çağrılarını gösterebilir.

Bileşenler ve Arayüzleri

Bu bölümün başlıca önerileri aşağıdaki gibidir:

• Sisteminizin ana kısımlarını göstermek için bileşen diyagramları oluşturun.

• Sistem yapısını göstermek için bileşenler arasındaki bağımlılıkları veya onların arayüzlerini çizin.

• Her bileşenin sağladığı veya gerektirdiği hizmetleri göstermek için bileşenler üzerindeki arayüzleri kullanın.

• Büyük bir tasarımda, her bileşeni daha küçük parçalara ayırmak için ayrı diyagramlar çizebilirsiniz.

Bu noktalar, bu bölümün kalanında ayrıntılandırılmıştır.

Bileşenler

Bir mimari modelin merkezi görünümleri, sistemin ana kısımlarını ve onların birbirine nasıl bağlı olduğunu gösteren bileşen diyagramlarıdır. Bileşen diyagramları hakkında daha fazla bilgi için, bkz. UML Bileşen Diyagramları: Başvuru.

Büyük bir sistem için tipik bir bileşen diyagramı şunlara benzeyen bileşenler içerebilir:

• Sunu. Genellikle Web tarayıcısı üzerinde çalışan, kullanıcıya erişim sağlayan bileşen.

• Web hizmeti bileşenleri. İstemciler ve sunucular arasında bağlantı sağlar.

• Kullanım örneği denetleyicileri. Her senaryonun adımları boyunca kullanıcıya yön verin.

• İş çekirdeği. Gereksinim modelindeki sınıflara dayalı sınıfları içerir, anahtar işlemleri gerçekleştirir ve iş kısıtlamalarını vurgular.

• Veritabanı. İş nesnelerini depolar.

• Kaydolma ve hata halletme bileşenleri.

Bileşenler arasındaki Bağımlılıklar

Bileşenlerin kendilerine ek olarak, aralarındaki bağımlılıkları da gösterebilirsiniz. İki bileşen arasındaki bağımlılık oku, birinin tasarımındaki değişikliğin diğerinin tasarımını etkileyebileceğini gösterir. Bu genellikle olur, çünkü bir bileşen doğrudan veya dolaylı olarak diğer bir bileşen tarafından sağlanan hizmetleri veya işlevleri kullanır.

İyi yapılandırılmış bir mimaride bağımlılıklar açık bir şekilde düzenlenmiştir, şu durumlar doğru olduğunda:

• Bağımlılık grafiğinde düngüler yoktur.

• Bileşenler katmanlar içinde düzenlenebilir öyle ki her bağımlılık bir katmandaki bileşenden bir sonraki katmandaki bileşene geçer. Herhangi iki katman arasındaki tüm bağımlılıklar aynı yönde gider.

Bileşenler arasındaki bağımlılıkları doğrudan gösterebilirsiniz veya bileşenlere iliştirilmiş gerekli ve sağlanan arayüzler arasındaki bağımlılıkları gösterebilirsiniz. Arayüzleri kullanarak, her bağımlılıkta kullanılan işlemleri tanımlayabilirsiniz. Genellikle, diyagramlar ilk çizildiği zaman bağımlılıklar bileşenler arasında gösterilir ve sonra daha fazla bilgi eklendikçe arayüzler arasındaki bağımlılıklar tarafından değiştirilir. Her iki sürümde yazılımın doğru açıklamalarıdır, ancak arayüzler ile olan sürüm önceki sürümden daha çok ayrıntı sağlar.

Bağımlılıkları yönetmek en çok sürdürülebilir yazılımın üretimi için önemlidir. Bileşen diyagramları kodunuzdaki tüm bağımlılıkları yansıtmalıdır. Eğer kod zaten varsa, tüm bağımlılıkların diyagramlarda gösterildiğinden emin olun. Eğer kod geliştiriliyorsa, bileşen diyagramda planlanmamış bağımlılıkları içermediğinden emin olun. Koddaki bağımlılıkları keşfetmenize yardım etmek için, katman diyagramları oluşturabilirsiniz. Planlanmış bağımlılık kısıtlamalarınızın karşılandığından emin olmanıza yardım etmek için, katman diyagramlarına karşı kodu doğrulayabilirsiniz. Daha fazla bilgi için bkz. Katman Diyagramları: Başvuru.

Arayüzler

Bileşenlerinizin üzerine arayüzleri yerleştirerek, her bileşen tarafından sağlanan işlemlerin ana gruplarını ayırabilir ve adlandırabilirsiniz. Örneğin, web tabanlı satış sistemindeki bileşenler; müşterilerin ürün satın aldığı bir arayüze, tedarikçilerin kataloglarnı güncellediği bir arayüze ve sistemin yönetildiği üçüncü bir arayüze sahip olabilir.

Bir bileşenin herhangi bir sayıda sağlanan ve gerekli arayüzü olabilir. Sağlanan arayüzler, bir bileşenin başka bir bileşenin kullanması için sağladığı hizmetleri gösterir. Gerekli arayüzler, bileşenin diğer bileşenlerde kullandığı hizmetleri gösterir.

Eğer hem sağlanan hem de gerekli arayüzleri tanımlarsanız bu, bileşeni tasarımın geri kalanından düzgün bir şekilde ayırmanıza yardım eder ve böylelikle şu teknikleri kullanabilirsiniz:

• Bileşeni, test bandı tarafından benzetimi yapılmış çevreleyen bileşenler içindeki test bandına yerleştirin.

• Bileşeninizi diğer bileşenlerden bağımsız olarak geliştirin.

• Diğer bağlamlardaki bileşeni, arayüzlerini farklı bileşenlere eşleyerek yeniden kullanın.

Bir arayüzde işlemlerin listesini tanımlamak istediğiniz zaman, UML sınıf çizeneğinde arayüzün başka bir görünümünü oluşturabilirsiniz. Bunu yapmak için, UML Model Gezgini'nde arayüzü bulun ve sınıf çizeneği üzerine sürükleyin. Daha sonra işlemleri arayüze ekleyebilirsiniz.

UML arayüzündeki bir işlem, bileşenin davranışının çağrılabildiği herhangi bir yolda gösterilebilir. Bir Web hizmeti isteği, sinyal veya bazı diğer türlerin etkileşimini veya normal program işlev çağrısını gösterebilir.

Hangi işlemlerin ekleneceğine karar vermek için, bileşenlerin birbirleriyle nasıl etkileşim kurduklarını göstermek için sıralı diyagramlar oluşturun. Bkz. Bileşenler arasındaki Etkileşimler. Bu sıralı diyagramların her biri, farklı kullanım örneğinde olan etkileşimleri gösterir. Bu şekilde, kullanım örneklerini keşfettikçe her bileşenin arayüzündeki işlemler listesine aşamalı olarak ekleyebilirsiniz.

Bir Bileşeni Parçalara Ayırma

Önceki bölümlerde açıklanan yöntemi her bileşene uygulayabilirsiniz.

Her bileşenin içinde, onun alt bileşenlerini Parçalar olarak gösterebilirsiniz. Bir Parça, en verimli şekilde bir sınıf türü olan üst bileşeninin bir özniteliğidir. Her Parça'nın bileşen olabilecek kendi türü vardır. Bu bileşeni, bir diyagram üzerine yerleştirebilirsiniz ve onun parçalarını gösterebilirsiniz. Daha fazla bilgi için bkz. UML Bileşen Diyagramları: Yönergeler.

Bu tekniği tüm sisteme uygulamak yararlıdır. Onu tek bir bileşen olarak çizin ve ana bileşenlerini parçalar olarak gösterin. Bu, dış dünya ile sisteminizin arayüzlerini açıkça belirlemenize yardım eder.

Bir bileşen için tasarımınız başka bir bileşeni kullandığında, genellikle onu bir parça olarak ya da Gereksinim Arayüzü ile erişebileceğiniz ayrı bir bileşen olarak göstermek için bir seçiminiz olur.

Aşağıdaki durumlarda Parçaları kullanın:

• Üst bileşenin tasarımı her zaman Parça'nın bileşen türünü kullanmalıdır. Bu nedenle, parçanın tasarımı üst bileşenin tasarımına tümleşiktir.

• Üst bileşen kendinin kesin bir varlığına sahip değildir. Örneğin, görünümleri ve kullanıcı etkileşimlerinin üstesinden gelen gerçek bileşenler topluluğunu gösteren Sunu Katmanı olarak çağrılan kavramsal bir bileşene sahip olabilirsiniz.

Şu durumlardaki gerekli arayüzler aracılığıyla erişilen ayrı bileşenleri kullanın:

• Gereksinilen bileşen, arayüzleri aracılığıyla çalıştırma esnasında farklı sağlama bileşenlerine eşleştirilebilir.

• Böyle bir tasarımda, bir sağlayıcıyı diğeri ile değiştirmenin kolay olması beklenebilir.

Gerekli arayüzlerin kullanımı genellikle parçaların kullanımına tercih edilebilir. Tasarımın daha uzun sürmesine rağmen, açığa çıkan sistem daha esnektir. Ayrıca, bileşenleri ayrı ayrı sınamak da kolay olur. Bu, geliştirme planlarında daha az eşleşmeye izin verir.

Bileşenler arasındaki Etkileşimler

Bu bölümün başlıca önerileri aşağıdaki gibidir:

• Sisteminizin kullanım örneklerini belirleyin.

• Her kullanım örneği için, sisteminizin bileşenlerinin bir diğeriyle ve kullanıcılarla işbirliği yaparak nasıl gerekli sonuca ulaştığını göstermek için bir veya daha çok diyagram çizin. Genellikle, bunlar sıralı diyagramlar veya etkinlik diyagramlarıdır.

• Her bileşen tarafından alınan iletileri belirtmek için Arayüzleri kullanın.

• Arayüzlerdeki İşlemler'in etkilerini açıklayın.

• Her bileşen için yordamı, parçalarının nasıl etkileştiğini göstererek tekrarlayın.

Örneğin, web tabanlı satış sisteminde, gereksinim modeli bir müşteri satın alımını kullanım örneği olarak tanımlayabilir. Sunu katmanındaki bileşenlerin müşteri ile olan etkileşimlerini göstermek için ve onların ambar ve hesap bileşenleri ile olan etkileşimlerini göstermek için sıralı diyagram oluşturabilirsiniz.

Başlatma olaylarını belirleme

Çoğu yazılım sistemi tarafından yapılan iş, farklı girdilere veya olaylara verdiği yanıtlar tarafından kolayca bölünebilir. Başlatma olayı aşağıdaki olaylardan biri olabilir:

• Bir kullanım örneğindeki ilk eylem. Gereksinim modelinde, kullanım örneğindeki bir adım olarak veya etkinlik diyagramındaki bir eylem olarak görünebilir. Daha fazla bilgi için, UML Kullanım Durumu Diyagramları: Yönergeler and UML Etkinlik Diyagramları: Yönergeler.

• Program niteliğindeki arayüzde bir ileti. Eğer geliştirdiğiniz sistem daha büyük bir sistemde bileşen ise, bileşen arayüzlerinin birinde bir işlem olarak açıklanmalıdır. Bkz. Bileşenler ve Bunların Arayüzleri.

• Sisteminiz tarafından izlenmiş belirli bi durum veya bir günün zamanı gibi düzenli bir olay.

Hesaplamaları açıklayın

Bileşenlerin ilk olaya nasıl yanıt verdiğini göstermek için sıralı diyagramlar çizin.

Tipik bir dizede yer alan her bileşen örneği için bir yaşam çizgisi çizin. Bazı durumlarda, her türün birden fazla örneği olabilir. Eğer sisteminizin tümünü tek bir bileşen olarak açıkladıysanız, içerdiği her Parça için bir yaşam çizgisi olmalıdır.

Daha fazla bilgi için bkz. UML Sıralı Diyagramlar: Yönergeler.

Etkinlik diyagramları da bazı durumlarda yararlıdır. Örneğin, eğer bileşenleriniz sürekli bir veri akışına sahipse, onu nesne akışı olarak açıklayabilirsiniz. Eğer bileşeninizin karışık bir algoritması varsa, onu denetim akışı olarak açıklayabilirsiniz. Örneğin açıklamaları kullanarak, hangi bileşenin her eylemi gerçekleştirdiğinin açık olduğundan emin olun. Daha fazla bilgi için bkz. UML Etkinlik Diyagramları: Yönergeler.

İşlemleri belirtin

Diyagramlar, her bileşen tarafından gerçekleştirilen, ya sıralı diyagramlarda iletiler olarak ya da etkinlik diyagramında eylemler olarak gösterilen işlemleri gösterir.

Bu işlemleri her bileşen için birlikte toplayın. Bileşen üzerinde Sağlanan Arayüzler oluşturun ve işlemleri arayüzlere ekleyin. Genellikle, ayrı bir arayüz her istemci türü için kullanılır. İşlemler en kolay UML Model Explorer (UML Model Gezgini)'nde arayüzlere eklenir. Aynı şekilde, her bileşenin başka bir bileşenden kullandığı işlemleri toplayın ve onları bileşene iliştirilmiş Gerekli Arayüzler'e yerleştirin.

Etkinlik veya sıralı diyagramlara açıklama eklemek, her işlemden sonra neye ulaşıldığını not etmek yararlıdır. Ayrıca, her işlemin etkisini onun Local Postcondition (Yerel Sonkoşul) özelliği içinde yazabilirsiniz.

Bileşenlerin ve Arayüzlerin Veri Modeli

Parametreleri tanımlar ve bileşen arayüzlerinde her işlemin değerini döndürür. İşlemlerin Web hizmet istekleri gibi çağrıları gösterdiği yerde, parametreler isteğin bir parçası olarak gönderilen bilgi parçalarıdır. Birçok değerin bir işlemden döndüğü yerde, parametreleri Yön özelliğinin Çıkış'a ayarlanmasıyla kullanabilirsiniz.

Her parametre ve dönüş değerinin bir türü vardır. Bu türleri UML Sınıf Çizenekleri'ni kullanarak tanımlayabilirsiniz. Bu diyagramlarda uygulama ayrıntılarını göstermek zorunda değilsiniz. Örneğin, eğer XML olarak geçirilen veriyi açıklıyorsanız, bir ilişkilendirmeyi XML'in düğümleri arasındaki herhangi türdeki çapraz başvuruları göstermek için kullanabilirsiniz ve düğümleri göstermek için sınıfları kullanabilirsiniz.

İlişkilendirmeler ve öznitelikler üzerinde iş kısıtlamalarını tanımlamak için açıklamaları kullanabilirsiniz. Örneğin, eğer müşterinin bir siparişi üzerindeki tüm öğeler aynı tedarikçiden gelmek zorundaysa, bunu sipariş öğeleri ve ürün kataloğundaki öğeler arasındaki ilişkilendirmelere ve katalog öğesi ile onun tedarikçisi arasındaki ilişkilendirmelere başvurarak açıklayabilirsiniz.

Tasarım Desenleri

Bir tasarım deseni, yazılımın özellikle sistemin farklı parçalarında tekrar eden belirli bir yönünün nasıl tasarlandığının bir taslağıdır. Proje boyunca tek bir yaklaşımı kabul ederek, tasarımın maliyetini azaltabilir, kullanıcı arayüzünde tutarlılığı sağlayabilir ve kodu anlamanın ve değiştirmenin maliyetini azaltabilirsiniz.

Observer gibi bazı genel tasarım desenleri tanınmış ve geniş bir alanda uygulanabilir. Ayrıca, sadece sizin projenize uygulanabilen desenler de vardır. Örneğin, bir Web satış sisteminde, kodda bir müşterinin siparişine değişikliklerin yapıldığı yerde çeşitli işlemler olacaktır. Sipariş durumunun her aşamada tam olarak gösterilmesini sağlamak için, tüm bu işlemler veritabanını güncellemek için belirli bir protokolü izlemelidir.

Yazılım mimarisi çalışmasının bir kısmı tasarım boyunca hangi desenlerin benimsenmesi gerektiğine karar vermektir. Bu genellike sürekli devam eden bir görevdir, çünkü yeni desenler ve varolan desenlerde yapılan geliştirmeler proje ilerledikçe keşfedilecektir. Gelişme planını düzenlemek yararlıdır, böylelikle ana tasarım desenlerinizin herbirini erken aşamada deneyebilirsiniz.

Tasarım desenlerinin çoğu kısmen framework kodunda gerçekleştirilebilir. Desenin bir parçası, geliştiriciden belirli sınıfları ve bileşenleri kullanmasını isteyerek azaltılabilir, örneğin veritabanın doğru bir şekilde işlemesini sağlayan bir veritabanı erişim katmanı gibi.

Tasarım deseni bir belgede açıklanır ve genellikle şu parçaları içerir:

• Ad.

• Uygulanabilir olduğu bağlamın açıklaması. Bir geliştirici bu deseni uygularken hangi kriterleri düşünmelidir?

• Çözdüğü problemin kısa bir açıklaması.

• Ana parçaların ve onların ilişkilerinin modeli. Bunlar, sınıflar veya bileşenler ve arayüzler ile onlar arasındaki ilişkilendirmeler ve bağımlılıklar. Öğeler genellikle iki kategoriye ayrılır:

  • Geliştiricinin desenin kullanıldığı kodun her parçasında çoğaltılması gereken öğeler. Bunları açıklamak için şablon türlerini kullanabilirsiniz. Daha fazla bilgi için bkz. UML Kullanım Durumu Diyagramları: Başvuru.

  • Geliştiricinin kullanması gereken framework sınıflarını açıklayan öğeler.

• Sıralı veya etkinlik diyagramlarını kullanarak parçalar arasındaki etkileşimlerin modeli.

• Kuralları adlandırma.

• Desenin problemi nasıl çözdüğünün açıklaması.

• Geliştiricilerin benimseyebileceği değişikliklerin açıklaması.

Ayrıca bkz.

Kavramlar

Nasıl Yapılır: UML Modellerini ve Diyagramlarını Düzenleme

Kodu Görselleştirme ve Anlama

Kullanıcı Gereksinimlerini Modelleme

Modelden Testler Geliştirme

Geliştirme Süreci içinde Modelleri Kullanma