*در دنیای NoSql پیاده سازیهای متفاوتی از دیتابیسها انجام شده است و هر دیتابیس، ویژگیها و مزایا و معایب خاص خودش را دارد. باید قبول کرد که همیشه و همه جا نمیتوان از یک پایگاه داده NoSql مشخص استفاده نماییم (دلایلی نظیر محدودیتهای License، هزینه پیاده سازی و...). در نتیجه بررسی یک دیتابیس دیگر با شرایط و توانمندیهای خاص آن خالی از سود نیست.
» این دیتاییس در گروه Graph databasesها قرار دارد و از زبان SPARQL (بخوانید Sparkle) برای کوئری گرفتن و کار با دادهها بهره میبرد؛
» متن باز و رایگان است
» پشتیبانی از دات نت چهار به بعد؛
» قابل استفاده در Mobile Application - Windows phone 7 , 8؛
» بدون شما (Schema Less) و با قابیلت ذخیره سازی triple و به فرمت RDF
» پشتیبانی از Linq و OData؛
» پشتیبانی از تراکنشها ؛
» پیاده سازی مدل برنامه به صورت Code First؛
» سرعت بالا جهت ذخیره سازی و لود اطلاعات؛
» نیاز به پیکربندیهای خاص جهت پیاده سازی ندارد؛
» ارائه افزونه رایگان Polaris جهت کوئری گفتن و نمایش Visual داده ها.
و غیره که در ادامه با آنها آشنا خواهید شد.
در B*Db دو روش برای ذخیره سازی اطلاعات وجود دارد:
» Append Only : در این روش تمامی تغییرات (عملیات نوشتن) در انتهای فایل index اضافه خواهد شد. این روش مزایای زیر را به دنبال خواهد داشت:
- عملیات نوشتن هیچگاه عملیات خواندن اطلاعات را block نمیکند. در
نتیجه هر تعداد عملیات خواندن فایل (منظور اجرای کوئریهای SPQRL است) میتواند به صورت موازی بر روی Storeها اجرا شود.
- به دلیل اینکه عمل ویرایش واقعی هیچ گاه انجام نمیشود (دادهها فقط اضافه خواهند شد) همیشه میتوانید وضعیت Store را به حالتهای قبلی بازگردانید.
- عملیات نوشتن اطلاعات بسیار سریع خواهد بود.
نکته ای که باید به آن دقت داشت این است که فقط در هنگام ساخت Storeها میتوانید نوع ذخیره سازی آن را تعیین نمایید، بعد از ساخت Store امکان سوئیچ بین حالات امکان پذیر نیست.
همان طور که پیشتر گفته شد B*Db برای ذخیره سازی اطلاعات از سند RDF بهره میبرد. البته با RDF Syntaxهای متفاوت :
هم چنین در B*Db چهار روش برای دست یابی با دادهها (پیاده سازی عملیات CRUD) وجود دارد از قبیل:
» B*Db EntityFramewok
» Data Object Layer
» RDF Client Api
» Dynamic API
که هر کدام در طی پستهای متفاوت بررسی خواهد شد.
بررسی یک مثال با روش B*Db EntityFramework
برای شروع ابتدا یک پروژه جدید از نوع Console Application ایجاد کنید. سپس از طریق Nuget اقدام به نصب Package زیر نمایید:
pm> install-Package BirghtStarDb
PM> Install-Package BirghtStarDbLibs
بعد از نصب پکیجهای بالا یک فایل Text Template با نام MyEntityContext.tt نیز به پروژه افزوده خواهد شد. این فایل جهت تولید خودکار مدلهای برنامه استفاده میشود. اما برای این کار لازم است به ازای هر مدل ابتدا یک اینترفیس ایجاد نمایید. برای مثال:
[Entity] public interface IBook { public int Code { get; set; } public string Title { get; set; } }
» نیاز به ایجاد یک خاصیت به عنوان Id وجود ندارد. به صورت پیش فرض خاصیت Id با نوع string برای هر مدل پیاده سازی میشود. اما اگر قصد دارید این نام خاصیت را تغییر دهید میتوانید به صورت زیر عمل کنید:
[Entity] public interface IBook { [Identifier] public string MyId { get; } public int Code { get; set; } public string Title { get; set; } }
استفاده از اینترفیس برای ساخت مدل انعطاف پذیری بالایی را در اختیار ما قرار میدهد که بعدا مفصل بحث خواهد شد. برای عملیات درج داده میتوان به صورت زیر عمل کنید:
MyEntityContext context = new MyEntityContext("type=embedded;storesdirectory=c:\brightstar;storename=test"); var book = context.Books.Create(); book.Code = 1; book.Title = "Test"; context.Books.Add(book); context.SaveChanges();
»embedded : در این حالت از طریق آدرس فیزیکی فایل مورد نظر میتوان یک Connection ایجاد کرد.
»rest : یا استفاده از HTTP یا HTTPS میتوان به سرویس B*Db دسترسی داشت.
»dotNetRdf : برای ارتباط با یک Store دیگر با استفاده از اتصال دهندههای DotNetRDf.
»sparql : اتصال به منبع داده ای دیگر با استفاده از پروتکل SPARQL
در هنگام ایجاد اتصال باید نوع مورد نظر را از حتما تعیین نمایید. با استفاده از storedirctory مکان فیزیکی فایل تعیین خواهد شد.
npm install -D jsHint jsHint-loader
module.exports = { entry:['./shared.js','./main.ts'] ,output:{ filename:'bundle.js' } ,watch :true ,module:{ preLoaders:[ { test:/\.js$/ ,exclude:/node_modules/ ,loader:'jshint-loader' } ], loaders:[ { test:/\.ts$/ ,exclude:/node_modules/ ,loader:'ts-loader' } ] } }
همچنین برای تکمیل قابل ذکر است که وبپک دارای postLoaders نیز میباشد که پس از Loaderهای اصلی اجرا میشوند.
// در حالتی که به صورت محلی وبپک نصب شده است npm run webpack -- -p // درحالتی که وبپک به صورت سراسری اجرا میشود webpack -p
npm install -D strip-loader
// webpack.prod.config.js //تنظیمات قبلی را میخوانیم var devConfig = require("./webpack.config.js"); // لودری که وظیفهی حذف کردن دارد را وارد میکنیم var stripLoader = require("strip-loader"); // مانند قبل یک آبجکت با موارد مورد نظر برای لودر میسازیم var stripLoaderConfig = { test:[/\.js$/,/\.ts$/], exclude :/node_modules/ ,loader:stripLoader.loader("console.log") } // اضافه کردن به لیست لودرهای قبلی devConfig.module.loaders.push(stripLoaderConfig); // و در آخر اکسپورت کردن تنظیمات جدید وقبلی module.exports = devConfig;
loader:stripLoader.loader("console.log")
// در حالتی که وبپک به صورت محلی نصب شده است npm run webpack -- --config webpack.prod.config.js -p // در حالتی که وبپک به صورت سراسری نصب شده باشد webpack --config webpack.prod.config.js -p
// زمانی که وبپک به صورت محلی در پروژه نصب شده است npm run webpackserver -- --config webpack.prod.config.js -p //در حالتی که وبپک به صورت گلوبال ( سراسری ) نصب میباشد webpack-dev-server --config webpack.prod.config.js -p
// new webpack.config.js file //ماژول توکار نود جی اس var path = require("path"); module.exports = { // مشخص کردن زمینه برای فایلهای ورودی context:path.resolve("js"), entry:['./shared.js','./main.ts'] ,output:{ // مشخص کردن محل قرارگیری باندل ساخته شده path:path.resolve("build/js"), // درخواست از سمت چه مسیری برای باندل خواهد آمد ؟ publicPath:"assets/js", filename:'bundle.js' } , devServer:{ //راهنمایی برای وب سرور جهت اینکه فایلها را از چه محلی سرو کند contentBase:"assets" } ,watch :true ,module:{ loaders:[ { test:/\.ts$/ ,exclude:/node_modules/ ,loader:'ts-loader' } ] } }
context:path.resolve("js")
// تغییرات در شی output // این کلید جدید مسیر قرار گیری جدید باندل را به وبپک اطلاع میدهد path:path.resolve("build/js"), // راهنما برای وب سرور وبپک جهت میزبانی مسیر زیر از کلید بالا publicPath:"assets/js",
//index.html <html> <head> first part of webpack tut! </head> <body> <h1>webpack is awesome !</h1> <script src="assets/js/bundle.js"></script> </body> </html>
حال با اجرا کردن وب سرور وبپک میتوان مشاهده کرد که مسیرهای جدید، بدون مشکل توسط وبپک پیدا شده و فایلها سرو میشوند. قابل توجه است که این نوع چینش پروژه قابل تغییر و شخصی سازی برای پروژههای گوناگون میباشد.
ساخت فایلهای سورس مپ (source map)
سادهترین راه جهت ساخت فایلهای سورس مپ با استفاده از یک پرچم در هنگام فراخوانی وبپک به صورت زیر میباشد.
// فعال کردن ساخت سورس مپها npm run webpack -- -d // یا در هنگام نصب گلوبال webpack -d // جهت استفاده به همراه وب سرور npm run webpackserver -- -d // یا به صورت نصب گلوبال webpack-dev-server -d
// webpack.config.js // کلید جدید اضافه شده در فایل پیکربندی devtool:"#source-map"
با اجرای وب سرور وبپک خواهید دید که سورس مپها در منوی توسعه دهندهی مرورگر قابل دستیابی میباشند.
ساخت چندین باندل گوناگون
قصد داریم به پروژه، دو صفحهی دیگر را نیز با نامهای aboutme و contact اضافه کنیم. هر یک از این صفحات اسکریپت مخصوص به خود را خواهد داشت و باندل نهایی نیز شامل تمامی آنها خواهد شد. در صورتی که این خروجی مطلوب ما نباشد و به طور مثال بخواهیم مکانیزمی شبیه به lazy loading اسکریپتها را داشته باشیم و فقط زمانی اسکریپتها بارگذاری شوند که به آنها احتیاج باشد، برای انجام این کار با وبپک به صورت زیر عمل خواهیم کرد.
دو صفحهی html جدید را با عناوین ذکر شدهی بالا به پوشهی assets اضافه میکنیم و برای هریک نیز اسکریپتی با همان نام خواهیم ساخت و در پوشهی js قرار میدهیم.
محتوای صفحات بدین شکل میباشد.
// index.html file <html> <head> <title> third part of webpack tut! </title> </head> <body> <nav> <a href="aboutme.html">about me</a> <a href="contact.html">contact</a> </nav> <h1>webpack is awesome !</h1> <script src="assets/js/shared.js"></script> <script src="assets/js/index.js"></script> </body> </html> // aboutme.html file <html> <head> <title> about me page ! </title> </head> <body> <nav> <a href="index.html">index</a> <a href="contact.html">contact</a> </nav> <h1>webpack is awesome !</h1> <script src="assets/js/shared.js"></script> <script src="assets/js/aboutme.js"></script> </body> </html> // contact.html file <html> <head> <title> contact me page ! </title> </head> <body> <nav> <a href="index.html">index</a> <a href="aboutme.html">about me</a> </nav> <h1>webpack is awesome !</h1> <script src="assets/js/shared.js"></script> <script src="assets/js/contact.js"></script> </body> </html>
var path = require("path"); var webpack = require("webpack"); // وارد کردن پلاگینی از وب پک برای ساخت تکههای مختلف اسکریپتها // معرفی اسکریپت shared.js var commonChunkPlugin = new webpack.optimize.CommonsChunkPlugin("shared.js"); module.exports = { context:path.resolve("js"), //entry:['./shared.js','./main.ts'] // معرفی اسکریپتهای جدید به وبپک entry:{ index:"./main.js", aboutme:"./aboutme.js", contact:"./contact.js" } ,output:{ path:path.resolve("build/js"), publicPath:"assets/js", // filename:'bundle.js' // به جای یک باندل کلی از وبپک میخاهیم برای هر ورودی باندلی جدید بسازد filename:"[name].js" } // رجیستر کردن پلاگین ,plugins:[commonChunkPlugin] , devServer:{ contentBase:"assets" } //,devtool:"#source-map" ,watch :true ,module:{... } }
حال با اجرای وبپک میتوان دید که سه باندل ساخته شده که همگی به اسکریپت shared.js وابستگی دارند و اگر این اسکریپت را از صفحات HTML حذف کنید، با خطا رو به رو خواهید شد. این پلاگین قدرت ساخت باندلهایی با خاصیت مشخص کردن وابستگیها و همچنین تو در توییها خاص را نیز دارد. برای مطالعهی بیشتر میتوانید به اینجا مراجعه کنید: پلاگین commonsChunk
در قسمت بعدی با استفاده از وبپک فایلهای css، فونتها و تصاویر را نیز باندل خواهیم کرد.
فایلهای مطلب:
سورس تا قبل از قسمت ایجاد تغییرات در ساختار فایلهای پروژه :dntwebpack-part3-beforeFileAndFolderManagment.zip
سورس برای بعد از ایجاد تغییرات در ساختار فایلهای پروژه : dntwebpack-part3AfterFileOrganization.zip
ارزیابی و تفسیر مدل در داده کاوی
دانشی که در مرحله یادگیری مدل تولید میشود، میبایست در مرحله ارزیابی مورد تحلیل قرار گیرد تا بتوان ارزش آن را تعیین نمود و در پی آن کارائی الگوریتم یادگیرنده مدل را نیز مشخص کرد. این معیارها را میتوان هم برای مجموعه دادههای آموزشی در مرحله یادگیری و هم برای مجموعه رکوردهای آزمایشی در مرحله ارزیابی محاسبه نمود. همچنین لازمه موفقیت در بهره مندی از علم داده کاوی تفسیر دانش تولید و ارزیابی شده است.
ارزیابی در الگوریتمهای دسته بندی
برای سادگی معیارهای ارزیابی الگوریتمهای دسته بندی، آنها را برای یک مسئله با دو دسته ارائه خواهیم نمود. در ابتدا با مفهوم ماتریس درهم ریختگی (Classification Matrix) آشنا میشویم. این ماتریس چگونگی عملکرد الگوریتم دسته بندی را با توجه به مجموعه داده ورودی به تفکیک انواع دستههای مساله دسته بندی، نمایش میدهد.
هر یک از عناصر ماتریس به شرح ذیل میباشد:
TN: بیانگر تعداد رکوردهایی است که دسته واقعی آنها منفی بوده و الگوریتم دسته بندی نیز دسته آنها را بدرستی منفی تشخیص داده است.
TP: بیانگر تعداد رکوردهایی است که دسته واقعی آنها مثبت بوده و الگوریتم دسته بندی نیز دسته آنها را بدرستی مثبت تشخیص داده است.
FP: بیانگر تعداد رکوردهایی است که دسته واقعی آنها منفی بوده و الگوریتم دسته بندی دسته آنها را به اشتباه مثبت تشخیص داده است.
FN: بیانگر تعداد رکوردهایی است که دسته واقعی آنها مثبت بوده و الگوریتم دسته بندی دسته آنها را به اشتباه منفی تشخیص داده است.
مهمترین معیار برای تعین کارایی یک الگوریتم دسته بندی دقت یا نرخ دسته بندی (Classification Accuracy - Rate) است که این معیار دقت کل یک دسته بند را محاسبه میکند. در واقع این معیار مشهورترین و عمومیترین معیار محاسبه کارایی الگوریتمهای دسته بندی است که نشان میدهد، دسته بند طراحی شده چند درصد از کل مجموعه رکوردهای آزمایشی را بدرستی دسته بندی کرده است.
دقت دسته بندی با استفاده از رابطه I بدست میآید که بیان میکند دو مقدار TP و TN مهمترین مقادیری هستند که در یک مسئله دودسته ای باید بیشینه شوند. (در مسائل چند دسته ای مقادیر قرار گرفته روی قطر اصلی این ماتریس - که در صورت کسر محاسبه CA قرار میگیرند - باید بیشینه باشند.)
معیار خطای دسته بندی (Error Rate) دقیقاً برعکس معیار دقت دسته بندی است که با استفاده از رابطه II بدست میآید. کمترین مقدار آن برابر صفر است زمانی که بهترین کارایی را داریم و بطور مشابه بیشترین مقدار آن برابر یک است زمانی که کمترین کارائی را داریم.
ذکر این نکته ضروری است که در مسائل واقعی، معیار دقت دسته بندی به هیچ عنوان معیار مناسبی برای ارزیابی کارایی الگوریتمهای دسته بندی نمیباشد، به این دلیل که در رابطه دقت دسته بندی، ارزش رکوردهای دستههای مختلف یکسان در نظر گرفته میشوند. بنابراین در مسائلی که با دستههای نامتعادل سروکار داریم، به بیان دیگر در مسائلی که ارزش دسته ای در مقایسه با دسته دیگر متفاوت است، از معیارهای دیگری استفاده میشود.
همچنین در مسائل واقعی معیارهای دیگری نظیر DR و FAR که به ترتیب از روابط III و IV بدست میآیند، اهمیت ویژه ای دارند. این معیارها که توجه بیشتری به دسته بند مثبت نشان میدهند، توانایی دسته بند را در تشخیص دسته مثبت و بطور مشابه تاوان این توانایی تشخیص را تبیین میکنند. معیار DR نشان میدهد که دقت تشخیص دسته مثبت چه مقدار است و معیار FAR نرخ هشدار غلط را با توجه به دسته منفی بیان میکند.
معیار مهم دیگری که برای تعیین میزان کارایی یک دسته بند استفاده میشود معیار (AUC (Area Under Curve است.
AUC نشان دهنده سطح زیر نمودار (ROC (Receiver Operating Characteristic میباشد که هر چه مقدار این عدد مربوط به یک دسته بند بزرگتر باشد کارایی نهایی دسته بند مطلوبتر ارزیابی میشود. نمودار ROC روشی برای بررسی کارایی دسته بندها میباشد. در واقع منحنیهای ROC منحنیهای دو بعدی هستند که در آنها DR یا همان نرخ تشخیص صحیح دسته مثبت (True Positive Rate - TPR) روی محور Y و بطور مشابه FAR یا همان نرخ تشخیص غلط دسته منفی (False Positive Rate - FPR) روی محور X رسم میشوند. به بیان دیگر یک منحنی ROC مصالحه نسبی میان سودها و هزینهها را نشان میدهد.
بسیاری از دسته بندها همانند روشهای مبتنی بر درخت تصمیم و یا روشهای مبتنی بر قانون، به گونه ای طراحی شده اند که تنها یک خروجی دودویی (مبنی بر تعلق ورودی به یکی از دو دسته ممکن) تولید میکنند. به این نوع دسته بندها که تنها یک خروجی مشخص برای هر ورودی تولید میکنند، دسته بندهای گسسته گفته میشود که این دسته بندها تنها یک نقطه در فضای ROC تولید میکنند.
بطور مشابه دسته بندهای دیگری نظیر دسته بندهای مبتنی بر روش بیز و یا شبکههای عصبی نیز وجود دارند که یک احتمال و یا امتیاز برای هر ورودی تولید میکنند، که این عدد بیانگر درجه تعلق ورودی به یکی از دو دسته موجود میباشد. این دسته بندها پیوسته نامیده میشوند و بدلیل خروجی خاص این دسته بندها یک آستانه جهت تعیین خروجی نهایی در نظر گرفته میشود.
یک منحنی ROC اجازه مقایسه تصویری مجموعه ای از دسته بندی کنندهها را میدهد، همچنین نقاط متعددی در فضای ROC قابل توجه است. نقطه پایین سمت چپ (0,0) استراتژی را نشان میدهد که در یک دسته بند مثبت تولید نمیشود. استراتژی مخالف، که بدون شرط دسته بندهای مثبت تولید میکند، با نقطه بالا سمت راست (1,1) مشخص میشود. نقطه (0,1) دسته بندی کامل و بی عیب را نمایش میدهد. بطور کلی یک نقطه در فضای ROC بهتر از دیگری است اگر در شمال غربیتر این فضا قرار گرفته باشد. همچنین در نظر داشته باشید منحنیهای ROC رفتار یک دسته بندی کننده را بدون توجه به توزیع دستهها یا هزینه خطا نشان میدهند، بنابراین کارایی دسته بندی را از این عوامل جدا میکنند. فقط زمانی که یک دسته بند در کل فضای کارایی به وضوح بر دسته دیگری تسلط یابد، میتوان گفت که بهتر از دیگری است. به همین دلیل معیار AUC که سطح زیر نمودار ROC را نشان میدهد میتواند نقش تعیین کننده ای در معرفی دسته بند برتر ایفا کند. برای درک بهتر نمودار ROC زیر را مشاهده کنید.
مقدار AUC برای یک دسته بند که بطور تصادفی، دسته نمونه مورد بررسی را تعیین میکند برابر 0.5 است. همچنین بیشترین مقدار این معیار برابر یک بوده و برای وضعیتی رخ میدهد که دسته بند ایده آل بوده و بتواند کلیه نمونههای مثبت را بدون هرگونه هشدار غلطی تشخیص دهد. معیار AUC برخلاف دیگر معیارهای تعیین کارایی دسته بندها مستقل از آستانه تصمیم گیری دسته بند میباشد. بنابراین این معیار نشان دهنده میزان قابل اعتماد بودن خروجی یک دسته بند مشخص به ازای مجموعه دادههای متفاوت است که این مفهوم توسط سایر معیارهای ارزیابی کارایی دسته بندها قابل محاسبه نمیباشد. در برخی از مواقع سطح زیر منحنیهای ROC مربوط به دو دسته بند با یکدیگر برابر است ولی ارزش آنها برای کاربردهای مختلف یکسان نیست که باید در نظر داشت در این گونه مسائل که ارزش دستهها با یکدیگر برابر نیست، استفاده از معیار AUC مطلوب نمیباشد. به همین دلیل در این گونه مسائل استفاده از معیار دیگری به جزء هزینه (Cost Matrix) منطقی به نظر نمیرسد. در انتها باید توجه نمود در کنار معیارهای بررسی شده که همگی به نوعی دقت دسته بند را محاسبه میکردند، در دسته بندهای قابل تفسیر نظیر دسته بندهای مبتنی بر قانون و یا درخت تصمیم، پیچیدگی نهایی و قابل تفسیر بودن مدل یاد گرفته شده نیز از اهمیت بالایی برخوردار است.
از روشهای ارزیابی الگوریتمهای دسته بندی (که در این الگوریتم روال کاری بدین صورت است که مدل دسته بندی توسط مجموعه داده آموزشی ساخته شده و بوسیله مجموعه داده آزمایشی مورد ارزیابی قرار میگیرد.) میتوان به روش Holdout اشاره کرد که در این روش چگونگی نسبت تقسیم مجموعه دادهها (به دو مجموعه داده آموزشی و مجموعه داده آزمایشی) بستگی به تشخیص تحلیگر دارد که معمولاً دو سوم برای آموزش و یک سوم برای ارزیابی در نظر گرفته میشود. مهمترین مزیت این روش سادگی و سرعت بالای عملیات ارزیابی است ولیکن روش Holdout معایب زیادی دارد از جمله اینکه مجموعه دادههای آموزشی و آزمایشی به یکدیگر وابسته خواهند شد، در واقع بخشی از مجموعه داده اولیه که برای آزمایش جدا میشود، شانسی برای حضور یافتن در مرحله آموزش ندارد و بطور مشابه در صورت انتخاب یک رکورد برای آموزش دیگر شانسی برای استفاده از این رکورد برای ارزیابی مدل ساخته شده وجود نخواهد داشت. همچنین مدل ساخته شده بستگی فراوانی به چگونگی تقسیم مجموعه داده اولیه به مجموعه دادههای آموزشی و آزمایشی دارد. چنانچه روش Holdout را چندین بار اجرا کنیم و از نتایج حاصل میانگین گیری کنیم از روشی موسوم به Random Sub-sampling استفاده نموده ایم. که مهمترین عیب این روش نیز عدم کنترل بر روی تعداد دفعاتی که یک رکورد به عنوان نمونه آموزشی و یا نمونه آزمایشی مورد استفاده قرار میگیرد، است. به بیان دیگر در این روش ممکن است برخی رکوردها بیش از سایرین برای یادگیری و یا ارزیابی مورد استفاده قرار گیرند.
چنانچه در روش Random Sub-sampling به شکل هوشمندانهتری عمل کنیم به صورتی که هر کدام از رکوردها به تعداد مساوی برای یادگیری و تنها یکبار برای ارزیابی استفاده شوند، روش مزبور در متون علمی با نام Cross Validation شناخته میشود.
همچنین در روش جامع k-Fold Cross Validation کل مجموعه دادهها به k قسمت مساوی تقسیم میشوند. از k-1 قسمت به عنوان مجموعه دادههای آموزشی استفاده میشود و براساس آن مدل ساخته میشود و با یک قسمت باقی مانده عملیات ارزیابی انجام میشود. فرآیند مزبور به تعداد k مرتبه تکرار خواهد شد، به گونه ای که از هر کدام از k قسمت تنها یکبار برای ارزیابی استفاده شده و در هر مرتبه یک دقت برای مدل ساخته شده، محاسبه میشود. در این روش ارزیابی دقت نهایی دسته بند برابر با میانگین k دقت محاسبه شده خواهد بود. معمولترین مقداری که در متون علمی برای k در نظر گرفته میشود برابر با 10 میباشد. بدیهی است هر چه مقدار k بزرگتر شود، دقت محاسبه شده برای دسته بند قابل اعتمادتر بوده و دانش حاصل شده جامعتر خواهد بود و البته افزایش زمان ارزیابی دسته بند نیز مهمترین مشکل آن میباشد. حداکثر مقدار k برابر با تعداد رکوردهای مجموعه داده اولیه است که این روش ارزیابی با نام Leaving One Out شناخته میشود.
در روش هایی که تاکنون به آن اشاره شده، فرض بر آن است که عملیات انتخاب نمونههای آموزشی بدون جایگذاری صورت میگیرد. به بیان دیگر یک رکورد تنها یکبار در یک فرآیند آموزشی مورد توجه واقع میشود. چنانچه هر رکورد در صورت انتخاب شدن برای شرکت در عملیات یادگیری مدل بتواند مجدداً برای یادگیری مورد استفاده قرار گیرد روش مزبور با نام Bootstrap و یا 0.632 Bootstrap شناخته میشود. (از آنجا که هر Bootstrap معادل 0.632 مجموعه داده اولیه است)
ارزیابی در الگوریتمهای خوشه بندی
به منظور ارزیابی الگوریتمهای خوشه بندی میتوان آنها به دو دسته تقسیم نمود:
شاخصهای ارزیابی بدون ناظر، که گاهی در متون علمی با نام معیارهای داخلی شناخته میشوند، به آن دسته از معیارهایی گفته میشود که تعیین کیفیت عملیات خوشه بندی را با توجه به اطلاعات موجود در مجموعه داده بر عهده دارند. در مقابل، معیارهای ارزیابی با ناظر با نام معیارهای خارجی نیز شناخته میشوند، که با استفاده از اطلاعاتی خارج از حیطه مجموعه دادههای مورد بررسی، عملکرد الگوریتمهای خوشه بندی را مورد ارزیابی قرار میدهند.
از آنجا که مهمترین وظیفه یک الگوریتم خوشه بندی آن است که بتواند به بهترین شکل ممکن فاصله درون خوشه ای را کمینه و فاصله بین خوشه ای را بیشینه نماید، کلیه معیارهای ارزیابی بدون ناظر سعی در سنجش کیفیت عملیات خوشه بندی با توجه به دو فاکتور تراکم خوشه ای و جدائی خوشه ای دارند. برآورده شدن هدف کمینه سازی درون خوشه ای و بیشینه سازی میان خوشه ای به ترتیب در گرو بیشینه نمودن تراکم هر خوشه و نیز بیشینه سازی جدایی میان خوشهها میباشد. طیف وسیعی از معیارهای ارزیابی بدون ناظر وجود دارد که همگی در ابتدا تعریفی برای فاکتورهای تراکم و جدائی ارائه میدهند سپس توسط تابع (F(Cohesion, Separation مرتبط با خود، به ترکیب این دو فاکتور میپردازند. ذکر این نکته ضروری است که نمیتوان هیچ کدام از معیارهای ارزیابی خوشه بندی را برای تمامی کاربردها مناسب دانست.
ارزیابی با ناظر الگوریتمهای خوشه بندی، با هدف آزمایش و مقایسه عملکرد روشهای خوشه بندی با توجه به حقایق مربوط به رکوردها صورت میپذیرد. به بیان دیگر هنگامی که اطلاعاتی از برچسب رکوردهای مجموعه داده مورد بررسی در اختیار داشته باشیم، میتوانیم از آنها در عملیات ارزیابی عملکرد الگوریتمهای خوشه بندی بهره بریم. لازم است در نظر داشته باشید در این بخش از برچسب رکوردها تنها در مرحله ارزیابی استفاده میشود و هر گونه بهره برداری از این برچسبها در مرحله یادگیری مدل، منجر به تبدیل شدن روش کاوش داده از خوشه بندی به دسته بندی خواهد شد. مشابه با روشهای بدون ناظر طیف وسیعی از معیارهای ارزیابی با ناظر نیز وجود دارد که در این قسمت با استفاده از روابط زیر به محاسبه معیارهای Rand Index و Jaccard می پردازیم به ترتیب در رابطه I و II نحوه محاسبه آنها نمایش داده شده است:
Rand Index را میتوان به عنوان تعداد تصمیمات درست در خوشه بندی در نظر گرفت.
TP: به تعداد زوج داده هایی گفته میشود که باید در یک خوشه قرار میگرفتند، و قرار گرفته اند.
TN: به تعداد زوج داده هایی گفته میشود که باید در خوشههای جداگانه قرار داده میشدند و به درستی در خوشههای جداگانه جای داده شده اند.
FN: به تعداد زوج داده هایی گفته میشود که باید در یک خوشه قرار میگرفتند ولی در خوشههای جداگانه قرار داده شده اند.
FP: به تعداد زوج داده هایی اشاره دارد که باید در خوشههای متفاوت قرار میگرفتند ولی در یک خوشه قرار گرفته اند.
ارزیابی در الگوریتمهای کشف قوانین انجمنی
به منظور ارزیابی الگوریتمهای کشف قوانین انجمنی از آنجایی که این الگوریتمها پتانسیل این را دارند که الگوها و قوانین زیادی تولید نمایند، جهت ارزیابی این قوانین به عواملی همچون شخص استفاده کننده از قوانین و نیز حوزه ای که مجموعه داده مورد بررسی به آن تعلق دارد، وابستگی زیادی پیدا میکنیم و بدین ترتیب کار پیدا کردن قوانین جذاب، به آسانی میسر نیست. فرض کنید قانونی با نام R داریم که به شکل A=>B میباشد، که در آن A و B زیر مجموعه ای از اشیاء میباشند.
پیشتر به معرفی دو معیار Support و Confidence پرداختیم. میدانیم از نسبت تعداد تراکنش هایی که در آن اشیاء A و B هر دو حضور دارند، به کل تعداد رکوردها Support بدست میآید که دارای مقداری عددی بین صفر و یک میباشد و هر چه این میزان بیشتر باشد، نشان میدهد که این دو شیء بیشتر با هم در ارتباط هستند. کاربر میتواند با مشخص کردن یک آستانه برای این معیار، تنها قوانینی را بدست آورد که Support آنها بیشتر از مقدار آستانه باشد، بدین ترتیب میتوان با کاهش فضای جستجو، زمان لازم جهت پیدا کردن قوانین انجمنی را کمینه کرد. البته باید به ضعف این روش نیز توجه داشت که ممکن است قوانین با ارزشی را بدین ترتیب از دست دهیم. در واقع استفاده از این معیار به تنهایی کافی نیست. معیار Confidence نیز مقداری عددی بین صفر و یک میباشد، که هر چه این عدد بزرگتر باشد بر کیفیت قانون افزوده خواهد شد. استفاده از این معیار به همراه Support مکمل مناسبی برای ارزیابی قوانین انجمنی خواهد بود. ولی مشکلی که همچنان وجود دارد این است که امکان دارد قانونی با Confidence بالا وجود داشته باشد ولی از نظر ما ارزشمند نباشد.
از معیارهای دیگر قوانین انجمنی میتوان به معیار Lift که با نامهای Intersect Factor یا Interestingness نیز شناخته میشود اشاره کرد، که این معیار میزان استقلال میان اشیاء A و B را نشان میدهد که میتواند مقدار عددی بین صفر تا بی نهایت باشد. در واقع Lift میزان هم اتفاقی بین ویژگیها را در نظر میگیرد و میزان رخداد تکی بخش تالی قانون (یعنی شیء B) را در محاسبات خود وارد میکند. (بر خلاف معیار Confidence)
مقادیر نزدیک به عدد یک معرف این هستند که A و B مستقل از یکدیگر میباشند، بدین ترتیب نشان دهنده قانون جذابی نمیباشند. چنانچه این معیار از عدد یک کمتر باشد، نشان دهنده این است که A و B با یکدیگر رابطه منفی دارند. هر چه مقدار این معیار بیشتر از عدد یک باشد، نشان دهنده این است که A اطلاعات بیشتری درباره B فراهم میکند که در این حالت جذابیت قانون A=>B بالاتر ارزیابی میشود. در ضمن این معیار نسبت به سمت چپ و راست قانون متقارن است در واقع اگر سمت چپ و راست قانون را با یکدیگر جابجا کنیم، مقدار این معیار تغییری نمیکند. از آنجائی که این معیار نمیتواند به تنهایی برای ارزیابی مورد استفاده قرار گیرد، و حتماً باید در کنار معیارهای دیگر باشد، باید مقادیر آن بین بازه صفر و یک نرمال شود. ترکیب این معیار به همراه Support و Confidence جزو بهترین روشهای کاوش قوانین انجمنی است. مشکل این معیار حساس بودن به تعداد نمونههای مجموعه داده، به ویژه برای مجموعه تراکنشهای کوچک میباشد. از این رو معیارهای دیگری برای جبران این نقص معرفی شده اند.
معیار Conviction برخی ضعفهای معیارهای Confidence و Lift را جبران مینماید. محدوده قابل تعریف برای این معیار در حوزه 0.5 تا بی نهایت قرار میگیرد که هر چه این مقدار بیشتر باشد، نشان دهنده این است که آن قانون جذابتر میباشد. بر خلاف Lift این معیار متقارن نمیباشد و مقدار این معیار برای دلالتهای منطقی یعنی در جایی که Confidence قانون یک میباشد برابر با بی نهایت است و چنانچه A و B مستقل از هم باشند، مقدار این معیار برابر با عدد یک خواهد بود.
معیار Leverage که در برخی متون با نام Novelty (جدید بودن) نیز شناخته میشود، دارای مقداری بین 0.25- و 0.25+ میباشد. ایده مستتر در این معیار آن است که اختلاف بین میزان هم اتفاقی سمت چپ و راست قانون با آن مقداری که مورد انتظار است به چه اندازه میباشد.
معیار Jaccard که دارای مقداری عددی بین صفر و یک است، علاوه بر اینکه نشان دهنده وجود نداشتن استقلال آماری میان A و B میباشد، درجه همپوشانی میان نمونههای پوشش داده شده توسط هر کدام از آنها را نیز اندازه گیری میکند. به بیان دیگر این معیار فاصله بین سمت چپ و راست قانون را بوسیله تقسیم تعداد نمونه هایی که توسط هر دو قسمت پوشش داده شده اند بر نمونه هایی که توسط یکی از آنها پوشش داده شده است، محاسبه میکند. مقادیر بالای این معیار نشان دهنده این است که A و B تمایل دارند، نمونههای مشابهی را پوشش دهند. لازم است به این نکته اشاره شود از این معیار برای فهمیدن میزان همبستگی میان متغیرها استفاده میشود که از آن میتوان برای یافتن قوانینی که دارای همبستگی بالا ولی Support کم هستند، استفاده نمود. برای نمونه در مجموعه داده سبد خرید، قوانین نادری که Support کمی دارند ولی همبستگی بالایی دارند، توسط این معیار میتوانند کشف شوند.
معیار (Coefficient (φ نیز به منظور اندازه گیری رابطه میان A و B مورد استفاده قرار میگیرد که محدوده این معیار بین 1- و 1+ میباشد.
از دیگر معیارهای ارزیابی کیفیت قوانین انجمنی، طول قوانین بدست آمده میباشد. به بیان دیگر با ثابت در نظر گرفتن معیارهای دیگر نظیر Support، Confidence و Lift قانونی برتر است که طول آن کوتاهتر باشد، بدلیل فهم آسانتر آن.
در نهایت با استفاده از ماتریس وابستگی (Dependency Matrix)، میتوان اقدام به تعریف معیارهای متنوع ارزیابی روشهای تولید قوانین انجمنی پرداخت. در عمل معیارهای متعددی برای ارزیابی مجموعه قوانین بدست آمده وجود دارد و لازم است با توجه به تجارب گذشته در مورد میزان مطلوب بودن آنها تصمیم گیری شود. بدین ترتیب که ابتدا معیارهای برتر در مسئله مورد کاوش پس از مشورت با خبرگان حوزه شناسائی شوند، پس از آن قوانین انجمنی بدست آمده از حوزه کاوش، مورد ارزیابی قرار گیرند.
WinJS سورس باز شد
آشنایی با NUnit
NUnit یکی از فریم ورکهای آزمایش واحد سورس باز مخصوص دات نت فریم ورک است. (کلا در دات نت هرجایی دیدید که N ، به ابتدای برنامهای یا کتابخانهای اضافه شده یعنی نمونه منتقل شده از محیط جاوا به دات نت است. برای مثال NHibernate از Hibernate جاوا گرفته شده است و الی آخر)
این برنامه با سی شارپ نوشته شده است اما تمامی زبانهای دات نتی را پشتیبانی میکند (اساسا با زبان نوشته شده کاری ندارد و فایل اسمبلی برنامه را آنالیز میکند. بنابراین فرقی نمیکند که در اینجا چه زبانی بکار گرفته شده است).
ابتدا NUnit را دریافت نمائید:
http://nunit.org/index.php?p=download
یک برنامه ساده از نوع console را در VS.net آغاز کنید.
کلاس MyList را با محتوای زیر به پروژه اضافه کنید:
using System.Collections.Generic;
namespace sample
{
public class MyList
{
public static List<int> GetListOfIntItems(int numberOfItems)
{
List<int> res = new List<int>();
for (int i = 0; i < numberOfItems; i++)
res.Add(i);
return res;
}
}
}
اکنون بر روی نام پروژه در قسمت solution explorer کلیک راست کرده و گزینه add->new project را انتخاب کنید. نوع این پروژه را که متدهای آزمایش واحد ما را تشکیل خواهد داد، class library انتخاب کنید. با نام مثلا TestLibrary (شکل زیر).
با توجه به اینکه NUnit ، اسمبلی برنامه (فایل exe یا dll آنرا) آنالیز میکند، بنابراین میتوان پروژه تست را جدای از پروژه اصلی ایجاد نمود و مورد استفاده قرار داد.
پس از ایجاد پروژه class library ، باید ارجاعی از NUnit framework را به آن اضافه کنیم. به محل نصب NUnit مراجعه کرده (پوشه bin آن) و ارجاعی به فایل nunit.framework.dll را به پروژه اضافه نمائید (شکل زیر).
سپس فضاهای نام مربوطه را به کلاس آزمایش واحد خود اضافه خواهیم کرد:
using NUnit.Framework;
using NUnit.Framework.SyntaxHelpers;
سپس باید ویژگی جدیدی به نام TestFixture را به این کلاس اضافه کرد.
[TestFixture]
public class TestClass
سپس هر متدی که به عنوان متد آزمایش واحد نوشته میشود، باید دارای ویژگی Test باشد تا توسط NUnit بررسی گردد:
[Test]
public void TestGetListOfIntItems()
اکنون برای اینکه بتوانیم متد GetListOfIntItems برنامه خود را در پروژه دیگری تست کنیم، باید ارجاعی را به اسمبلی آن اضافه کنیم. همانند قبل، از منوی project گزینه add reference ، فایل exe برنامه کنسول خود را انتخاب کرده و ارجاعی از آنرا به پروژه class library اضافه میکنیم. بدیهی است امکان اینکه کلاس تست در همان پروژه هم قرار میگرفت وجود داشت و صرفا جهت جداسازی آزمایش از برنامه اصلی اینکار صورت گرفت.
پس از این مقدمات، اکنون متد آزمایش واحد ساده زیر را در نظر بگیرید:
[Test]
public void TestGetListOfIntItems()
{
const int count = 5;
List<int> items = sample.MyList.GetListOfIntItems(count);
Assert.That(items.Count,Is.EqualTo(5));
}
اگر آن را (سطر مربوط به Assert را) کلمه به کلمه بخواهیم به فارسی ترجمه کنیم به صورت زیر خواهد بود:
میخواهیم اثبات کنیم که count مربوط به شیء items مساوی 5 است.
پس از اضافه کردن متد فوق، پروژه را کامپایل نمائید.
اکنون برنامه nunit.exe را اجرا کنید تا NUnit IDE ظاهر شود (در همان دایرکتوری bin مسیر نصب NUnit قرار دارد).
از منوی File آن یک پروژه جدید را آغاز نموده و آنرا ذخیره کنید.
سپس از منوی project آن، با استفاده از گزینه add assembly ، فایل dll کتابخانه تست خود را اضافه نمائید.
احتمالا پس از انجام این عملیات بلافاصله با خطای زیر مواجه خواهید شد:
---------------------------
Assembly Not Loaded
---------------------------
System.ApplicationException : Unable to load TestLibrary because it is not located under
the AppBase
----> System.IO.FileNotFoundException : Could not load file or assembly
'TestLibrary' or one of its dependencies. The system cannot find the file specified.
For further information, use the Exception Details menu item.
همانطور که ملاحظه میکنید، NUnit با استفاده از قابلیتهای reflection در دات نت، اسمبلی را بارگذاری میکند و تمامی کلاسهایی که دارای ویژگی TestFixture باشند در آن لیست خواهد شد.
اکنون بر روی دکمه run کلیک کنید تا اولین آزمایش ما انجام شود. (شکل زیر)
رنگ سبز در اینجا به معنای با موفقیت انجام شدن آزمایش است.
ادامه دارد...
خطا ها و مدیریت خطا (Exception Handling)
exception myError of int
ساختار کلی try catch finally در #F به صورت زیر است.(تنها تفاوت در کلمه with به جای catch است)
try // try code here with //catch statement here
try // try code here finally //finally statement here
یک مثال از try with:
exception WrongSecond of int//یک exception تعریف میکنیم let primes = [ 2; 3; 5; 7; 11; 13; 17; 19; 23; 29; 31; 37; 41; 43; 47; 53; 59 ] // یک تابع برای تست اینکه آیا ثانیه الان در لیست prime وجود دارد یا نه let testSecond() = try let currentSecond = System.DateTime.Now.Second in // شرط برای اینکه مشخص شود که ثانیه در لیست است یا خیر if List.exists (fun x -> x = currentSecond) primes then // اگر بود یک خطا تولید میشود failwith "A prime second" else // اگر نیود یک استثنا از نوع wrongSecond پرتاب میشود raise (WrongSecond currentSecond) with // catch کردن استثناها WrongSecond x -> printf "The current was %i, which is not prime" x
در کد با در هر خط توضیحات لازم داده شده است. نکته قابل ذکر این است که در #C زمانی که قصد داشته باشیم یک استثنا جدید ایجاد کنیم باید کلاسی جدیدی که از کلاس System.Exception ارث برده باشد(یا هر کلاس دیگری که خود از این System.Exception ارث برده است) ایجاد کنیم و کدهای مورد نظر رو در اون قرار بدیم. ولی در اینجا (در قسمتی که رنگ آن متفاوت است) به راحتی توانستیم یک استثنا جدید بر اساس نیاز بسازیم.
یک مثال از try finally :
// تابعی برای نوشتن فایل let writeToFile() = //ابتدا فایل به صورت متنی ساخته میشود let file = System.IO.File.CreateText("test.txt") try // متن مورد نظر در فایل نوشته میشود file.WriteLine("Hello F# users") finally //فایل مورد نظر بسته میشود.این دستور حتی اگر در هنگام نوشتن فایل استثنا هم رخ بدهد اجرا خواهد شد file.Dispose()
*توجه : برنامه نویسانی که قبلا با OCaml کدنویسی کرده اند هنگام برنامه نویسی #F از raise کردنهای زیاد و بی مورد استثناها خودداری کنند. به دلیل نوع معماری CLR پرتاب کردن استثنا و مدیریت آن کمی هزینه بر است (بیشتر از زبان Ocaml). البته این مسئله در زبانهای تحت دات نت نیز مطرح است کما اینکه در #C نیز مدیریت استثناها رو در بالاترین لایه انجام میدهیم و از catch کردن بی مورد استثنائات در لایههای زیرین خودداری میکنیم.
یک مثال از الگوی Matching در try with
let getNumber msg = printf msg; try int32(System.Console.ReadLine()) with | :? System.FormatException -> -1 | :? System.OverflowException -> System.Int32.MinValue | :? System.ArgumentNullException -> 0
1) پروژه ریشه که بسته به نامی که در ابتدای کار انتخاب میکنید، تغییر نام خواهد یافت.
برای مثال اگر نام وارد شده در ابتدای کار MyWpfFramework باشد، این پروژه ریشه نیز، MyWpfFramework نام خواهد داشت. از آن صرفا جهت افزودن Viewهای برنامه استفاده میکنیم. کلیه Viewها در پوشه View قرار خواهند گرفت و با توجه به ساختار خاصی که در اینجا انتخاب شده، این Viewها باید از نوع Page انتخاب شوند تا با سیستم راهبری فریم ورک هماهنگ کار کنند.
در داخل پوشه Views، هر بخش از برنامه را میتوان داخل یک زیر پوشه قرار داد. برای مثال قسمت Login سیستم، دارای سه صفحه ورود، نمایش پیام خوش آمد و نمایش صفحه عدم دسترسی است.
متناظر با هر Page اضافه شده، در پروژه MyWpfFramework.Infrastructure یک ViewModel در صورت نیاز اضافه خواهد شد. قرار داد ما در اینجا ترکیب نام View به علاوه کلمه ViewModel است. برای مثال اگر نام View اضافه شده به پروژه ریشه برنامه، LoginPage است، نام ViewModel متناظر با آن باید LoginPageViewModel باشد تا به صورت خودکار توسط برنامه ردیابی و وهله سازی گردد.
این پروژه از کتابخانه MahApps.Metro استفاده میکند و اگر به فایل MainWindow.xaml.cs آن مراجعه کنید، ارث بری پنجره اصلی برنامه را از کلاس MetroWindow مشاهده خواهید نمود. این فایلها نیازی به تغییر خاصی نداشته و به همین نحو در این قالب قابل استفاده هستند.
و در پوشه Resources آن یک سری قلم و آیکون را میتوانید مشاهده نمائید.
2) پروژه MyWpfFramework.Common
در این پروژه کلاسهایی قرار میگیرند که قابلیت استفاده در انواع و اقسام پروژههای WPF را دارند و الزاما وابسته به پروژه جاری نیستند. یک سری کلاسهای کمکی در این پروژه Common قرار گرفتهاند و قسمتهای مختلف سیستم را تغذیه میکنند؛ مانند خواندن اطلاعات از فایل کانفیگ، هش کردن کلمه عبور، یک سری متد عمومی برای کار با EF، کلاسهای عمومی مورد نیاز در حین استفاده از الگوی MVVM، اعتبارسنجی و امثال آن.
در این پروژه از کلاس PageAuthorizationAttribute آن جهت مشخص سازی وضعیت دسترسی به صفحات تعریف شده در پروژه ریشه استفاده خواهد شد.
نمونهای از آنرا برای مثال با مراجعه به سورس صفحه About.xaml.cs میتوانید مشاهده کنید که در آن AuthorizationType.AllowAnonymous تنظیم شده و به این ترتیب تمام کاربران اعتبارسنجی نشده میتوانند این صفحه را مشاهده کنند.
همچنین در این پروژه کلاس BaseViewModel قرار دارد که جهت مشخص سازی کلیه کلاسهای ViewModel برنامه باید مورد استفاده قرار گیرد. سیستم طراحی شده، به کمک این کلاس پایه است که میتواند به صورت خودکار ViewModelهای متناظر با Viewها را یافته و وهله سازی کند (به همراه تمام وابستگیهای تزریق شده به آنها).
به علاوه کلاس DataErrorInfoBase آن برای یکپارچه سازی اعتبارسنجی با EF طراحی شده است. اگر به کلاس BaseEntity.cs مراجعه کنید که در پروژه MyWpfFramework.DomainClasses قرار دارد، نحوه استفاده آنرا ملاحظه خواهید نمود. به این ترتیب حجم بالایی از کدهای تکرای، کپسوله شده و قابلیت استفاده مجدد را پیدا میکنند.
قسمتهای دیگر پروژه Common، برای ثبت وقایع برنامه مورد استفاده قرار میگیرند. استفاده از آنها را در فایل App.xaml.cs پروژه ریشه برنامه ملاحظه میکنید و نیاز به تنظیم خاص دیگری در اینجا وجود ندارد.
3) پروژه MyWpfFramework.DataLayer
کار تنظیمات EF در اینجا انجام میشود (و قسمت عمدهای از آن انجام شده است). تنها کاری که در آینده برای استفاده از آن نیاز است انجام شود، مراجعه به کلاس MyWpfFrameworkContext.cs و افزودن DbSetهای لازم است. همچنین اگر نیاز به تعریف نگاشتهای اضافهتری وجود داشت، میتوان از پوشه Mappings آن استفاده کرد.
در این پروژه الگوی واحد کار پیاده سازی شده است و همچنین سعی شده تمام کلاسهای آن دارای کامنتهای کافی جهت توضیح قسمتهای مختلف باشند.
کلاس MyDbContextBase به اندازه کافی غنی سازی شدهاست، تا در وقت شما، در زمینه تنظیم مباحثی مانند اعتبارسنجی و نمایش پیغامهای لازم به کاربر، یک دست سازی ی و ک ورودی در برنامه و بسیاری از نکات ریز دیگر صرفه جویی شود.
در اینجا از خاصیت ContextHasChanges جهت بررسی وضعیت Context جاری و نمایش پیغامی به کاربر در مورد اینکه آیا مایل هستید تغییرات را ذخیره کنید یا خیر استفاده میشود.
در متد auditFields آن یک سری خاصیت کلاس BaseEntity که پایه تمامی کلاسهای Domain model برنامه خواهد بود به صورت خودکار مقدار دهی میشوند. مثلا این رکورد را چه کسی ثبت کرده یا چه کسی ویرایش و در چه زمانی. به این ترتیب دیگر نیازی نیست تا در برنامه نگران تنظیم و مقدار دهی آنها بود.
کلاس MyWpfFrameworkMigrations به حالت AutomaticMigrationsEnabled تنظیم شده است و ... برای یک برنامه دسکتاپ WPF کافی و مطلوب است و ما را از عذاب به روز رسانی دستی ساختار بانک اطلاعاتی برنامه با تغییرات مدلها، رها خواهد ساخت. عموما برنامههای دسکتاپ پس از طراحی، آنچنان تغییرات گستردهای ندارند و انتخاب حالت Automatic در اینجا میتواند کار توزیع آنرا نیز بسیار ساده کند. از این جهت که بانک اطلاعاتی انتخابی از نوع SQL Server CE نیز عمدا این هدف را دنبال میکند: عدم نیاز به نگهداری و وارد شدن به جزئیات نصب یک بانک اطلاعاتی بسیار پیشرفته مانند نگارشهای کامل SQL Server. هرچند زمانیکه با EF کار میکنیم، سوئیچ به بانکهای اطلاعاتی صرفا با تغییر رشته اتصالی فایل app.config برنامه اصلی و مشخص سازی پروایدر مناسب قابل انجام خواهد بود.
در فایل MyWpfFrameworkMigrations، توسط متد addRolesAndAdmin کاربر مدیر سیستم در آغاز کار ساخت بانک اطلاعاتی به صورت خودکار افزوده خواهد شد.
4) پروژه MyWpfFramework.DomainClasses
کلیه کلاسهای متناظر با جداول بانک اطلاعاتی در پروژه MyWpfFramework.DomainClasses قرار خواهند گرفت. نکته مهمی که در اینجا باید رعایت شود، مزین کردن این کلاسها به کلاس پایه BaseEntity میباشد که نمونهای از آنرا در کلاس User پروژه میتوانید ملاحظه کنید.
BaseEntity چند کار را با هم انجام میدهد:
- اعمال خودکار DataErrorInfoBase جهت یکپارچه سازی سیستم اعتبارسنجی EF با WPF (برای مثال به این ترتیب خطاهای ذکر شده در ویژگیهای خواص کلاسها توسط WPF نیز خوانده خواهند شد)
- اعمال ImplementPropertyChanged به کلاسهای دومین برنامه. به این ترتیب برنامه کمکی Fody که کار Aspect oriented programming را انجام میدهد، اسمبلی برنامه را ویرایش کرده و متدها و تغییرات لازم جهت پیاده سازی INotifyPropertyChanged را اضافه میکند. به این ترتیب به کلاسهای دومین بسیار تمیزی خواهیم رسید با حداقل نیاز به تغییرات و نگهداری ثانویه.
- فراهم آوردن فیلدهای مورد نیاز جهت بازرسی سیستم؛ مانند اینکه چه کسی یک رکورد را ثبت کرده یا ویرایش و در چه زمانی
نقشهای سیستم در کلاس SystemRole تعریف میشوند. به ازای هر نقش جدیدی که نیاز بود، تنها کافی است یک خاصیت bool را در اینجا اضافه کنید. سپس نام این خاصیت در ویژگی PageAuthorizationAttribute به صورت خودکار قابل استفاده خواهد بود. برای مثال به پروژه ریشه مراجعه و به فایل AddNewUser.xaml.cs دقت کنید؛ چنین تعریفی را در بالای کلاس مرتبط مشاهده خواهید کرد:
[PageAuthorization(AuthorizationType.ApplyRequiredRoles, "IsAdmin, CanAddNewUser")]
/// <summary> /// وضعیت اعتبار سنجی صفحه را مشخص میکند /// </summary> public enum AuthorizationType { /// <summary> /// همه میتوانند بدون اعتبار سنجی، دسترسی به این صفحات داشته باشند /// </summary> AllowAnonymous, /// <summary> /// کاربران وارد شده به سیستم بدون محدودیت به این صفحات دسترسی خواهند داشت /// </summary> FreeForAuthenticatedUsers, /// <summary> /// بر اساس نام نقشهایی که مشخص میشوند تصمیم گیری خواهد شد /// </summary> ApplyRequiredRoles }
5) پروژه MyWpfFramework.Models
در پروژه MyWpfFramework.Models کلیه Modelهای مورد استفاده در UI که الزاما قرار نیست در بانک اطلاعاتی قرارگیرند، تعریف خواهند شد. برای نمونه مدل صفحه لاگین در آن قرار دارد و ذکر دو نکته در آن حائز اهمیت است:
[ImplementPropertyChanged] // AOP public class LoginPageModel : DataErrorInfoBase
- کلاس پایه DataErrorInfoBase سبب میشود تا مثلا در اینجا اگر از ویژگی Required استفاده کردید، اطلاعات آن توسط برنامه خوانده شود و با WPF یکپارچه گردد.
6) پروژه MyWpfFramework.Infrastructure.csproj
در پروژه MyWpfFramework.Infrastructure.csproj تعاریف ViewModelهای برنامه اضافه خواهند شد.
این پروژه دارای یک سری کلاس پایه است که تنظیمات IoC برنامه را انجام میدهد. برای مثال FrameFactory.cs آن یک کنترل Frame جدید را ایجاد کرده است که کار تزریق وابستگیها را به صورت خودکار انجام خواهد داد. فایل IocConfig آن جایی است که کار سیم کشی کلاسهای لایه سرویس و اینترفیسهای متناظر با آنها انجام میشود. البته پیش فرضهای آن را اگر رعایت کنید، نیازی به تغییری در آن نخواهید داشت. برای مثال در آن scan.TheCallingAssembly قید شده است. در این حالت اگر نام کلاس لایه سرویس شما Test و نام اینترفیس متناظر با آن ITest باشد، به صورت خودکار به هم متصل خواهند شد.
همانطور که پیشتر نیز عنوان شد، در پوشه ViewModels آن، به ازای هر View یک ViewModel خواهیم داشت که نام آن مطابق قرار داد، نام View مدنظر به همراه کلمه ViewModel باید درنظر گرفته شود تا توسط برنامه شناخته شده و مورد استفاده قرار گیرد. همچنین هر ViewModel نیز باید دارای کلاس پایه BaseViewModel باشد تا توسط IoC Container برنامه جهت تزریق وابستگیهای خودکار در سازندههای کلاسها شناسایی شده و وهله سازی گردد.
7) پروژه MyWpfFramework.ServiceLayer
کلیه کلاسهای لایه سرویس که منطق تجاری برنامه را پیاده سازی میکنند (خصوصا توسط EF) در این لایه قرار خواهند گرفت. در اینجا دو نمونه سرویس کاربران و سرویس عمومی AppContextService را ملاحظه میکنید.
سرویس AppContextService قلب سیستم اعتبارسنجی سیستم است و در IocConfig برنامه به صورت سینگلتون تعریف شده است. چون در برنامههای دسکتاپ در هر لحظه فقط یک نفر وارد سیستم میشود و نیاز است تا پایان طول عمر برنامه، اطلاعات لاگین و نقشهای او را در حافظه نگه داری کرد.
8) پروژه MyWpfFramework.Tests
یک پروژه خالی Class library هم در اینجا جهت تعریف آزمونهای واحد سیستم درنظر گرفته شده است.