آشنایی با FileTable در SQL Server 2012 بخش 1
- به چه نحوی از SQL Server استفاده میکنید؟ آیا سرور و برنامه دسکتاپ شما روی یک کامپیوتر هستند؟ برای اینکار بهتر است از SQL CE یا SQLite استفاده کنید؛ یا حتی LocalDB. هدف از SQL Server نصب آن روی یک سرور و خدمات دهی به چندین و چند کامپیوتر تحت شبکه است. برای استفاده روی یک کامپیوتر یعنی کسب و کار کوچک و عملا نیازی به SQL Server 2012 ندارد اینکار. زندگی مصرف کننده را سخت نکنید. نصب و نگهداری یک سرور کار هر شخصی نیست و برای سازمانها طراحی شده و نه مصارف کوچک تک کاربره دسکتاپ.
- با این توضیح اگر کسی به سرور شما دسترسی دارد، آیا نمیتواند مثلا اگر فایلها در دیتابیس ذخیره میشدند، اونها رو دستی با یک کوئری حذف کند؟ امنیت کار با سرور اینجا است که مطرح میشود و همچنین اطمینان به ادمینها.
- در مورد امنیت file table مراجعه کنید به مستندات مایکروسافت. مثلا: FileTables are secured by SQL Server security only
داستانهای کاربر
توسعهدهندگان، ویژگیهای مورد نظر پروژه را با جمعآوری نیازمندیها، در قالب داستانهای کاربر احصاء میکنند و به هرکدام متناسب با پیچیدگیاش امتیازی اختصاص میدهند. با لیستی از داستانهای دارای ابعادی مشخص و بودجه و زمان مورد نیاز برای هرکدام، مشتریان قادر به این انتخابند که کدام ویژگیها در تکرار (iteration) بعدی باقی بماند. مشخصکردن بودجه و زمان، یعنی تعیین حجم کاری که تیم توسعه برای انجام آن ویژگی، نیاز میداند. برآورد بودجۀ مورد نیاز تکرار اول به صورت تجربی خواهد بود و ممکن است این تخمین در ابتدا نادرست باشد؛ اما با شروع تکرار بعدی درست خواهد شد. در پایان هر تکرار، امتیازات به دست آمده از داستانهای کامل شده را جمع کنید. مجموع این امتیازات، نشانگر سرعت شما خواهد بود. این سرعت شاخص خوبی جهت چگونگی بودجهبندی مرحلۀ بعد است. هنگامیکه امتیازات جمعآوری شده به حد مطلوبی رسید، «سرعت پیشرَوی»، شاخص مناسب دیگری برای بودجهبندی است که عبارت است از متوسط سرعت سه تکرار آخر.
با این کار شما به دیدگاه مناسبی از فاز برنامهریزی دست پیدا میکنید. حال اجاز دهید نگاه دقیقتری به شیوههای برنامهریزی داشته باشیم.
برنامهریزی (planning game) دو فاز دارد: فاز شناسایی و فاز برنامهریزی. در فاز شناسایی، توسعهدهندگان و مشتریان را دور هم جمع میکنند تا دربارۀ نیازمندیهای سیستم در حال طراحی، گفتگو کنند. به خاطر داشته باشید که این کار تا وقتی انجام میشود که به ویژگیهایی (features) کافی برای شروع انجام کار برسیم و البته واضح است که چنین لیستی از ویژگیهای احصاء شده، هرچقدر هم که تلاش شود، کامل نخواهد بود. مشتریان اغلب اوقات، خواستهی خود را یا نمیدانند یا نمیتوانند به خوبی توضیح دهند. بنابراین معمولاً این لیست به مرور تغییر میکند. در ضمن آنکه برخی ویژگیها دقیقتر میشود، مواردی نیز ممکن است به لیست افزوده شوند یا حتی میتوان برخی ویژگیهای نامربوط را از لیست حذف کرد. در مرحلۀ شناسایی، ویژگیها به داستانهای کاربر تجزیه شد و ثبت میشوند.
یک داستان کاربر عبارت است از توصیفی کوتاه از یک ویژگی که نمایانگر یک واحد ارزش کسب و کار برای مشتری است. داستانهای کاربر از زبان کاربر بیان شدهاند و قالب نوشتاری زیر را دارند:
به عنوان «نوع کاربر»، من میخواهم «یک فعل» تا «منفعتی برای کسب و کار»
یا به صورت:
به منظور «یک دلیل» به عنوان «نقش کاربر» من میخواهم «یک فعل»
داستانهای کاربر معمولاً در جلسهی گفتگو با مشتری بر روی کارتهای راهنما نوشته شده و در آن از واژگان و ادبیاتی استفاده میشود که برای مشتری قابل فهم باشد. ممکن است چنین بیاندیشید که ثبت نیازمندیها، خلاف مزیتهای چابکسازی است؛ چرا که تولید نرمافزار کارآمد و چابک مبتنی بر مستندسازی گسترده و فراگیر خواهد بود. در واقع، داستانهای کاربر به طور ساده فقط یادآورندۀ جزئیات بیشتری از گفتگوی انجام شدهاند که به عمد بهصورت کوتاه و دقیق نوشته شدهاند. فهم دقیقتر جزئیات کار، مستلزم ارتباط بیشتر میان توسعهدهندگان و مشتری است. در واقع همسو با این اصل چابک که میگوید: «مؤثرترین و کارآمدترین شیوۀ انتقال اطلاعات در میان تیم توسعه و به خارج از آن، گفتگوی چهره به چهره است.»
هنگام احصاء ویژگیهای پروژه تحت عنوان داستانهای کاربری، از اصول INVEST (که پیشتر گفته شد) جهت کنترل مناسب بودن این داستانها استفاده کنید. شکل 2-3 مثالی از یک داستان کاربر را که توصیفکنندۀ ویژگی «افزودن یک بن تخفیف به سبد خرید» است، نشان میدهد. «تخفیف گرفتن»، یک منفعت کسب و کار است برای عامل (actor) اصلی، یعنی مشتری. «یک بن تخفیف به سبد بیفزا» نام فرآیند یا «use case» مربوط است.
معیار پذیرش همچنین به تشخیص جزئیات بیشتر یا شناسایی وابستگیها کمک میکند. مثلاً در شکل 3-3 تعریف «in date» چیست و چه چیزی حدود یک بن تخفیف را مشخص میکند؟ معمولاً باید حداقل سه معیار پذیرش وجود داشته باشد. در فصل بعد در یک مطالعۀ موردی، مطالب بیشتری را دربارۀ داستانهای کاربر خواهید آموخت.
هنگامیکه تیم و مشتریان حسکنند که حدود 75 درصد از ویژگیهای اصلی احصاء شده است، توسعهدهندگان ابعاد داستانها را تخمین زده و آنها را برای اولویتبندی توسط مشتری آماده میکنند.
تخمین
شکی در آن نیست که تخمینزدن کار سختی است. تخمینزدن هم دانش است هم هنر. تخمینزدن در یک پروژۀ تازه شروع شده، بسیار سخت است زیرا مجهولات بسیاری در آن وجود دارد.
یکی از روشهای تخمین گروهی، روش «Planning Poker» نام دارد. در این روش همهی اعضای فنی تیم، متشکل از توسعهدهندگان نرمافزار، تحلیلگران، متخصصان امنیت و زیرساخت، مشارکت میکنند. نقش مشتری در این حالت پاسخگویی به سؤالات احتمالی اعضای تیم است تا ایشان بهتر بتوانند تخمین بزنند.
شیوۀ انجام کار به این صورت است که عضوی از تیم، یک داستان کاربر را برداشته و آن را برای تیم توضیح میدهد. تیم دربارۀ آن ویژگی با مشتری گفتگو کرده تا جزئیات بیشتری را دریابد. وقتی که تیم به درک خوبی از آن رسید، رأیگیری آغاز میشود. هر عضو تیم با یک کارت، از مجموعهای ازکارتهایی با شمارههای 0، 1 ، 2، 3، 5، 8، 13، 20، 40 و 100 رأی خود را اعلام میکند.
تیم باید از داستانی شروع کند که نسبتاً کوچک و ساده باشد. این داستان به عنوان مبنا انتخاب میشود. هر تخمین داستان کاربر، باید به نسبت این داستان کوچک انجام شود. اگر داستان مبنا به خوبی انتخاب نشود، بقیۀ تخمینها نادرست خواهد بود.
اگر همهی اعضای تیم به یک صورت رأی دهند، آن رأی، تخمین آن داستان خواهد شد. اگر اختلاف آراء وجود داشت، ناظر یعنی کسی که رأی نمیدهد، از افرادی که بالاترین و پایینترین امتیاز را دادهاند، میخواهد که علل خود را توضیح دهند. سپس تیم مجدداً گفتگو کرده و دوباره رأیگیری میکند. طبق تجربه، خوب است که زمان معقولی، برای هر گفتگو در نظر گرفته شود.
اگر تخمین یک داستان به دلیل فقدان دانش فنی، بسیار سخت بود، مناسب است که این داستان کنار گذاشته شود و داستان دیگری برای برطرف کردن مشکل ناآشنایی با دانش فنی مورد نظر فراهم شود. بدین ترتیب تیم توسعه در موقعیت بهتری میتواند نسبت به داستان جدید تخمین بزند.
داستانهایی که بیش از یک هفته کار نیاز داشته باشند با عنوان داستانهای حماسی (epic stories) شناخته میشوند و معمولاً برای تخمین بسیار بزرگ هستند. در واقع، این داستانها به چند داستان کوچکتر که قابل فهمتر و به آسانی قابل تخمین باشند، تجزیه میشوند. این بدان معناست که ایجاد یک داستان کاربر از تعداد انبوهی ویژگی موجب کاهش کارآیی خواهد شد.
تخمین در تیمی که افراد آن تاکنون با همدیگر سابقۀ همکاری نداشته باشند، خیلی پایین یا خیلی بالاست. اما با استمرار هر تکرار و تجربه و دانش بیشتر افراد، تخمین داستانها بهتر میشود.
استفاده از ابزار Planning Poker مزایای بسیاری دربردارد. دقت تخمین بالا میرود؛ زیرا مسأله از منظر تخصصهای گوناگون مورد بررسی قرار گرفته است. همچنین به تیم کمک میکند که هم رأی شوند و گفتگو میان اعضاء را تسهیل میکند. پس از آنکه داستانها تخمین زده شدند، مشتری و صاحب محصول با تیم توسعه در تولید چگونگی انتشار نسخهها، همکاری میکنند.
برنامه انتشار
اگرچه کدهای قابل ارسال، قابلیت انتشار در پایان هر تکرار را دارند، اما یک پروژه XP در چند سری منتشر شده است. یک نسخۀ منتشرشده، متشکل از تعداد مناسبی داستان برای عرضۀ ارزش کسب وکاری است که به کوچک نگه داشتن آن کمک میکند. بسیار مناسب است که یک موضوع یا هدف خاص را در ضمن هرنسخۀ انتشار، مد نظر قرار داد تا کمک کند که هر نسخۀ انتشار بر برخی ارزشهای کسب و کاری متمرکز شده و آن را هدایت کند. معمولاً یک نسخۀ انتشار، متشکل از چهار تکرار است؛ همانطور که در شکل 4-3 نشان داده شده است.
در برنامهریزی نسخههای انتشار، طول یک تکرار نیز تعیین میشود که معمولاً بین دو تا چهار هفته است. مطابق تجربه، اگر محیط کار شما دچار بینظمی و اختلالات دائمی است، میتوانید دورۀ تکرار را به یک هفته محدود کنید.
یکی از پروژههایی که ما بر روی آن کار میکردیم، برنامهای بود که نگهداری آن بسیار سخت و فوقالعاده ناپایدار بود. مشتری مکررا با تیم تماس گرفته و اشکالات بحرانساز و ایراداتی را که مخل برنامه بودند، گزارش میکرد. در ابتدای کار دوره، تکرار ما هفتگی بود. به همین دلیل چون حلقۀ بازخوردگیریمان کوچک بود، میتوانستیم بر پایدارسازی پروژه در هر دوره کاری تمرکز کنیم. هنگامی که محصول به پایداری مناسبتری رسید و تماسهای مشتری کم شد، قادر شدیم تا در هر دوره، دقت بیشتری بر روی مسائل به خرج دهیم.
اگر قصد دارید به صورت دقیق بر روی حلقۀ بازخورد متمرکز شوید، دورهی تکرار یک هفتهای، مدل خوبی است. اما این مدل سربار زیادی را به دلیل ضرورت تقسیم داستانهای کاربر باید به بخشهای کوچکتری تا آن اندازه که در یک دوره تکمیل شوند، بر پروژه تحمیل میکند. در ادامه خواهیم گفت که هر تکرار شامل برنامۀ ملاقات و بازبینی نیز هست.
بعد از مدتی که تیم با فرآیند کار آشناتر شد و نوبت به مشکلات با اولویت کمتر رسید، میتوان دورۀ تکرار را دو هفتهای در نظر گرفت. اما اگر پروژه به گونهای است که ویژگیهای بزرگتر را نمیتوان به موارد کوچکتری که قابل انجام در دورههای یک هفتهای باشد، تجزیه کرد و تیم هنوز در حال یادگیری است، دورههای بلندمدتتر قابل پذیرش است.
مشتری با توجه به طول دورۀ تکرار و بودجۀ داستان آغازین، انتخاب میکند که کدام داستان در هنگام انتشار نسخۀ اوّل، در تکرار اوّل کامل شود.
این مشتری است که داستانها را به گونهای اولویتبندی میکند تا مشخص شود که کدامیک بیشترین ارزش کسب و کار را فراهم میکند. از آنجایی که مشتری مسؤول داستانهای کاربر است، تیم باید به وی توضیح دهد که داستانهایی وجود دارند که صرفاً باید به جهت دلایل فنی ایجاد شوند.
معمولاً باید به داستانهای کاربریای که مستلزم ریسک بالا بوده یا دربرگیرندۀ مجهولات زیادی باشند، بیش از یک یا دو تکرار اختصاص داد.
برنامۀ تکرار
مشتری داستانهایی را که میخواهد در تکرار باشند، انتخاب میکند. برای هر داستان کاربر، مجموعهای از معیارهای پذیرش، تعریف شده است. همان طور که متوجه شدهاید ما در هر فاز، وقت بیشتر و بیشتری را صرف جمعآوری جزئیات هر داستان کاربر کرده و بصورت عمیقتری در آن غور میکنیم. این کار مفید است، زیرا اگر یک داستان کاربر ایجاد شده در ابتدای پروژه، ممکن است بعداً به عنوان داستانی کم اهمیت یا غیر مهم دیدهشود و بدون آنکه وقت خاصی برای آن صرف شده باشد، کنار گذاشته شود. اما اگر در ابتدای کار وقت زیادی صرف دقیقتر کردن داستانهای کاربر شود و بعداً بعضی از آنها کنار گذاشته شوند، در واقع وقت تلف شده است. بنابراین دقیقتر کردن یک داستان در جایی که مورد نیاز است، باید اتفاق بیفتد. در سطح برنامۀ تکرار، مجموعهای از معیارهای پذیرش را برای هر داستان کاربر تعریف میکنیم. معیار پذیرش به توسعهدهنده کمک میکند تا بداند که یک داستان کاربر به طور کامل انجام میشود. این معیارها به صورت مؤلفههایی از بافرض/هنگامی که/درنتیجه، نوشته میشود.
مثالهای زیر چگونگی انجام این کار را توصیف میکند:
عنوان ویژگی: افزودن کالایی به سبد
به عنوان یک مشتری میخواهم بتوانم کالایی را به سبدم اضافه کنم؛ به نحوی که قادر باشم به خرید خود ادامه دهم.
سناریو: سبد خالی
با فرض اینکه یک سبد خالی دارم، در نتیجه جمع تعداد کالایی که برای سفارش در سبد من وجود دارد، صفر است.
سناریو: افزودن یک کالا به سبد
با فرض اینکه یک سبد خالی دارم هنگامی که کالایی با شناسۀ 1 به سبدم اضافه میکنم، در نتیجه جمع کالاهای قابل سفارش در سبدم 1 میشود.
سناریو: افزودن کالاهایی به سبد
با فرض اینکه یک سبد خالی دارم، هنگامی که کالایی با شناسۀ 1 و کالایی با شناسۀ 2 به سبدم اضافه میکنم، در نتیجه جمع کالاهای قابل سفارش در سبدم 2 میشود.
سناریو: دو بار افزودن یک کالا
با فرض اینکه یک سبد خالی دارم هنگامی که کالایی با شناسۀ 1 به سبدم اضافه میکنم و هنگامی که کالایی با شناسۀ 1 را مجدداً به سبدم اضافه میکنم، در نتیجه تعداد کالاهای با شناسۀ 1 در سبد من باید 2 باشد.
سناریو: افزودن یک کالای تمام شده به سبد
با فرض اینکه یک سبد خالی دارم و کالایی با شناسۀ 2 در انبار وجود نداشته باشد، هنگامی که من کالایی با شناسۀ 2 را به سبد خودم اضافه میکنم، در نتیجه جمع تعداد کالای قابل سفارش در سبد من باید 0 باشد و به کاربر، موجود نبودن آن کالا را هشدار دهد.
یک آزمون پذیرش (acceptance) به زبان متعارف در قوانین کسب و کار نوشته میشود. در مثال سبد خرید، این سؤال پیش میآید که چگونه میتوان یک محصول را از سبد کالا، حذف کرد و اگر یک جنس اکنون در انبار نیست و کاربر پیام هشدار دریافت کرده است، در ادامه چه اتفاقی باید بیفتد؟ سناریوها به تیم در کشف ملزومات کسب و کار و تصریح آنها کمک میکند.
این سناریوها توسط توسعهدهنده به عنوان نقطۀ شروع آزمونهای واحد در توسعۀ آزمون محور و رفتار محور استفاده میشود. سناریوها همچنین در آزمودن معیارهای پذیرش به توسعهدهنده کمک کرده و توسعهدهنده و تستکننده را قادر میسازند که بر روی اتمام داستان اتفاق نظر داشته باشند.
بعد از آنکه سناریوهای معیار پذیرش تعیین شد، تیم توسعه، هر داستان را به تعدادی وظیفه تقسیم میکند و وظایف مرتبط به یک داستان، در تابلوی وظایف قرارگرفته و تیم توسعه تخمینهای خود را در قالب یکی از واحدهای اندازهگیری، مثلاً نفرساعت اعلام میکند. شکل 5-3 یک تابلوی وظیفه را نمایش میدهد.
به عنوان مثال وظایف میتوانند شامل ایجاد طرح یک بانک اطلاعاتی برای یک داستان یا یکپارچهسازی آن با بخشی موجود در سیستم باشند. وظایف شامل مؤلفههای فنی مانند تهیۀ گزارش از زیرسیستمها یا چارچوب مدیریت استثنائات نیز میباشد. اغلب اینگونه وظایف نادیدهگرفته میشود. یک داستان کاربر با وظایف گوناگونی گره خورده است. مثلاً:
داستان کاربر : به عنوان یک کاربر میخواهم بتوانیم یک کاربر را مدیریت کنم.
وظایف زیر از این داستان قابل استخراج است:
- طرحی برای بانک اطلاعات جهت ذخیرهسازی اطلاعات کاربر ایجاد کن.
- یک کلاس کاربر، برای مدیریت کاربر از درون برنامه ایجاد کن.
هر عضو تیم میتواند بر روی هر وظیفهای که بر روی تخته است، کار کند. هنگامیکه یک عضو گروه، وظیفهای را برمیدارد، باید نشانی از خود روی کارت آن وظیفه قراردهد ( مثلاً حروف اوّل اسمش) تا بقیۀ افراد بدانند که وی بر روی آن وظیفه، مشغول به کار است. معمولاً اما نه همیشه، یک توسعهدهنده همۀ وظایف مربوط به یک داستان را برمیدارد. این کار بدین معناست که آن توسعهدهنده با پشتیبانی تیم، مسؤول اتمام آن کار است.
در طول یک تکرار، هر روز باید گفتگوهایی سرپایی با حضور همۀ اعضای تیم انجام شود و مشکلاتی که ممکن است باعث به تأخیر افتادن ارائه کار شود، مورد بحث و بررسی قرار گیرد و همچنین تیم، لیست وظایف و تخته آن را بهروز کرده تا پیشرفت یا موانع آن به وضوح قابل رؤیت باشند.
با تشکر از آقای سید مجتبی حسینی
این مطلب به عنوان اولین بخش از این سری مطالب منتشر میشود.
هدف این نوشته بررسی جزییات برنامه نویسی در رابطه با کلاس و شیء نیست. بلکه دریافتن چگونگی شکل گرفتن ایده شیء گرایی و علت مفید بودن آن است.
مشاهده مفاهیم شیء گرایی در پیرامون خود
حتماً در دنیای برنامه نویسی شیء گرا بارها با کلمات کلاس و شیء روبرو شده اید. درک صحیح از این مفاهیم بسیار مهم و البته بسیار ساده است. کار را با یک مثال شروع میکنیم. به تصویر زیر نگاه کنید.در سمت راست بخشی از نقشه یک ساختمان و در سمت چپ ساختمان ساخته شده بر اساس این نقشه را میبینید. ساختمان همان شیء است. و نقشه ساختمان کلاس آن است چراکه امکان ایجاد اشیائی که تحت عنوان ساختمان طبقه بندی (کلاس بندی) میشوند را فراهم میکند. به همین سادگی. کلاسها طرح اولیه، نقشه یا قالبی هستند که جزییات یک شی را توصیف میکنند.
حتماً با من موافق هستید اگر بگویم:
- در نقشه ساختمان نمیتوانید زندگی کنید اما در خود ساختمان میتوانید.
- از روی یک نقشه میتوان به تعداد دلخواه ساختمان ساخت.
- هنگامی که در یک ساختمان زندگی میکنید نیازی نیست تا دقیقاً بدانید چگونه ساخته شده و مثلاً سیم کشی یا لوله کشیهای آن چگونه است! تنها کافیست بدانید برای روشن شدن لامپ باید کلید آن را بزنید.
- ساختمان دارای ویژگی هایی مانند متراژ، ضخامت دیوار، تعداد پنجره و ابعاد هر یک و ... است که در هنگام ساخت و بر اساس اطلاعات موجود در نقشه تعیین شده اند.
- ساختمان دارای کارکرد هایی است. مانند بالا و پایین رفتن آسانسور و یا باز و بسته شدن درب پارکینگ. هر یک از این کارکردها نیز بر اساس اطلاعات موجود در نقشه پیاده سازی و ساخته شده اند.
- ساختمان تمام اجزای لازم برای اینکه از آن بتوانیم استفاده کنیم و به عبارتی در آن بتوانیم زندگی کنیم را در خود دارد.
سوال: کلاس یا نقشه ایجاد گاو چیست؟ اگر از من بپرسید خواهم گفت طرح اولیه گاو هم ممکن است وجود داشته باشد البته در اختیار خداوند و با سطح دسترسی ملکوت!
اتومبیل، تلویزیون و ... همگی مثال هایی از اشیاء پیرامون ما در دنیای واقعی هستند که حتماً میتوانید کلاس یا نقشه ایجاد آنها را نیز بدست آورید و یا ویژگیها و کارکردهای آنها را برشمارید.
مفاهیم شیء گرایی در مهندسی نرم افزار
مفاهیمی که تاکنون در مورد دنیای واقعی مرور کردیم همان چیزی است که در دنیای برنامه نویسی ـ به عقیده من دنیای واقعیتر از دنیای واقعی ـ با آن سر و کار داریم. علت این امر آن است که اصولاً ایده روش برنامه نویسی شیء گرا با مشاهده محیط پیرامون ما به وجود آمده است.برای نوشتن برنامه جهت حل یک مسئله بزرگ باید بتوان آن مسئله را به بخشهای کوچکتری تقسیم نمود. در این رابطه مفهوم شیء و کلاس با همان کیفیتی که در محیط پیرامون ما وجود دارد به صورت مناسبی امکان تقسیم یه مسئله بزرگ به بخشهای کوچکتر را فراهم میکند. و سبب میشود هماهنگی و تقارن و تناظر خاصی بین اشیاء برنامه و دنیای واقعی بوجود آید که یکی از مزایای اصلی روش شیء گراست.
از آنجا که در یک برنامه اصولاً همه چیز و همه مفاهیم در قالب کدها و دستورات برنامه معنا دارد، کلاس و شیء نیز چیزی بیش از قطعاتی کد نیستند. قطعه کد هایی که بسته بندی شده اند تا تمام کار مربوط به هدفی که برای آنها در نظر گرفته شده است را انجام دهند.
همان طور که در هر زبان برنامه نویسی دستوراتی برای کارهای مختلف مانند تعریف یک متغیر یا ایجاد یک حلقه و ... در نظر گرفته شده است، در زبانهای برنامه نویسی شیء گرا نیز دستوراتی وجود دارد تا بتوان قطعه کدی را بر اساس مفهوم کلاس بسته بندی کرد.
به طور مثال قطعه کد زیر را در زبان برنامه نویسی سی شارپ در نظر بگیرید.
class Player { public string Name; public int Age; public void Walk() { // کدهای مربوط به پیاده سازی راه رفتن } public void Run() { // کدهای مربوط به پیاده سازی دویدن } }
این کلاس به چه دردی میخورد؟ کجا میتوانیم از این کلاس استفاده کنیم؟
پاسخ این است که این کلاس ممکن است برای ما هیچ سودی نداشته باشد و هیچ کجا نتوانیم از آن استفاده کنیم. اما بیایید فرض کنیم برنامه نویسی هستیم که قصد داریم یک بازی فوتبال بنویسیم. به جای آنکه قطعات کد مجزایی برای هر یک از بازیکنان و کنترل رفتار و ویژگیهای آنان بنویسیم با اندکی تفکر به این نکته پی میبریم که همه بازیکنان مشترکات بسیاری دارند و به عبارتی در یک گروه یا کلاس قابل دسته بندی هستند. پس سعی میکنیم نقشه یا قالبی برای بازیکنها ایجاد کنیم که دربردارنده ویژگیها و رفتارهای آنها باشد.
همان طور که در نقشه ساختمان نمیتوانیم زندگی کنیم این کلاس هم هنوز آماده انجام کارهای واقعی نیست. چراکه برخی مقادیر هنوز برای آن تنظیم نشده است. مانند نام بازیکن و سن و ....
و همان طور که برای سکونت لازم است ابتدا یک ساختمان از روی نقشه ساختمان بسازیم برای استفاده واقعی از کلاس یاد شده نیز باید از روی آن شیء بسازیم. به این فرآیند وهله سازی یا نمونه سازی نیز میگویند. یک زبان برنامه نویسی شیء گرا دستوراتی را برای وهله سازی نیز در نظر گرفته است. در C# کلمه کلیدی new این وظیفه را به عهده دارد.
Player objPlayer = new Player(); objPlayer.Name = “Ali Karimi”; objPlayer.Age = 30; objPlayer.Run();
تمام آنچه که بازیکن برای انجام امور مربوط به خود نیاز دارد در کلاس بازیکن کپسوله میشود. بدیهی است در یک برنامه واقعی ویژگیها و رفتارهای بسیار بیشتری باید برای کلاس بازیکن در نظر گرفته شود. مانند پاس دادن، شوت زدن و غیره.
به این ترتیب ما برای هر برنامه میتوانیم مسئله اصلی را به تعدادی مسئله کوچکتر تقسیم کنیم و وظیفه حل هر یک از مسائل کوچک را به یک شیء واگذار کنیم. و بر اساس اشیاء تشخیص داده شده کلاسهای مربوطه را بنویسیم. برنامه نویسی شیء گرا سبب میشود تا مسئله توسط تعدادی شیء که دارای نمونههای متناظری در دنیای واقعی هستند حل شود که این امر زیبایی و خوانایی و قابلیت نگهداری و توسعه برنامه را بهبود میدهد.
احتمالاً تاکنون متوجه شده اید که برای نگهداری ویژگیهای اشیاء از متغیرها و برای پیاده سازی رفتارها یا کارکردهای اشیاء از توابع استفاده میکنیم.
با توجه به این که هدف این مطلب بررسی مفهوم شیء گرائی بود و نه جزییات برنامه نویسی، بنابراین بیان برخی مفاهیم در این رابطه را که بیشتر در مهندسی نرم افزار معنا دارند تا در دنیای واقعی در مطالب بعدی بررسی میکنیم.
در مورد سطح دسترسی
"به خودمان اهمیت بدهیم"
کسانی که در حوزه توسعه نرم افزار کار میکنند عموما از سبک زندگی مناسبی برخوردار نیستند. فشار کاری زیاد، انتظارات بالای سایرین از ما، رقابت شدید، نیاز به یادگیری مداوم و به روز ماندن، ساعتها خیره شدن به مانیتور و فعالیت فیزیکی بسیار پایین، عدم تعامل موثر با سایرین و ... از ویژگیهای "حرفه" ماست. اینها در کنار مشکلات جدیتر زندگی مانند مسائل مالی، رابطه و دغدغههای زندگی بسیار سنگینتر هم خواهند شد.
اسکات هنسلمن در وبلاگ اش راهکار هایی را که خودش برای حل این مسائل به کار بسته را به اشتراک گذاشته است.
- ۳۳ راه برای خلاق ماندن (بودن)! | ootooban.com
- WebP و آینده تصاویر وب | blog.salarcode.com
- Pure Css Line Graph | cssglobe.com
- Windows 8 ROP | www.irhoneynet.org
- 5 قابلیت جالب در ASP.NET MVC | weblogs.asp.net
- مروری بر طراحی Stack Overflow | highscalability.com
public class Employee { public string EmployeeName { get; set; } public int EmployeeNo { get; set; } public void Insert(Employee e) { //Database Logic written here } public void GenerateReport(Employee e) { //Set report formatting } }
public class Employee { public string EmployeeName { get; set; } public int EmployeeNo { get; set; } } public class EmployeeDB { public void Insert(Employee e) { //Database Logic written here } public Employee Select() { //Database Logic written here } } public class EmployeeReport { public void GenerateReport(Employee e) { //Set report formatting } }
//Method with multiple responsibilities – violating SRP public void Insert(Employee e) { string StrConnectionString = ""; SqlConnection objCon = new SqlConnection(StrConnectionString); SqlParameter[] SomeParameters=null;//Create Parameter array from values SqlCommand objCommand = new SqlCommand("InertQuery", objCon); objCommand.Parameters.AddRange(SomeParameters); ObjCommand.ExecuteNonQuery(); }
//Method with single responsibility – follow SRP public void Insert(Employee e) { SqlConnection objCon = GetConnection(); SqlParameter[] SomeParameters=GetParameters(); SqlCommand ObjCommand = GetCommand(objCon,"InertQuery",SomeParameters); ObjCommand.ExecuteNonQuery(); } private SqlCommand GetCommand(SqlConnection objCon, string InsertQuery, SqlParameter[] SomeParameters) { SqlCommand objCommand = new SqlCommand(InsertQuery, objCon); objCommand.Parameters.AddRange(SomeParameters); return objCommand; } private SqlParameter[] GetParaeters() { //Create Paramter array from values } private SqlConnection GetConnection() { string StrConnectionString = ""; return new SqlConnection(StrConnectionString); }
مروری بر روش ها و رویکردهای مختلف در یادگیری مدل
همان گونه که اشاره شد در روشهای با ناظر (برای مثال الگوریتمهای دسته بندی) کل مجموعه دادهها به دو بخش مجموعه دادههای آموزشی و مجموعه دادههای آزمایشی تقسیم میشود. در مرحله یادگیری (آموزش) مدل، الگوریتم براساس مجموعه دادههای آموزشی یک مدل میسازد که شکل مدل ساخته شده به الگوریتم یادگیرنده مورد استفاده بستگی دارد. در مرحله ارزیابی براساس مجموعه دادههای آزمایشی دقت و کارائی مدل ساخته شده بررسی میشود. توجه داشته باشید که مجموعه دادههای آزمایشی برای مدل ساخته شده پیش از این ناشناخته هستند.
در مرحله یادگیری مدل؛ برای مقابله با مشکل به خاطرسپاری (Memorization) مجموعه دادههای آموزشی، در برخی موارد بخشی از مجموعه دادههای آموزشی را از آن مجموعه جدا میکنند که با عنوان مجموعه داده ارزیابی (Valid Dataset) شناسائی میشود. استفاده از مجموعه داده ارزیابی باعث میشود که مدل ساخته شده، مجموعه دادههای آموزشی را حقیقتاً یاد بگیرد و در پی به خاطرسپاری و حفظ آن نباشد. به بیان دیگر در مرحله یادگیری مدل؛ تا قبل از رسیدن به لحظه ای، مدل در حال یادگیری و کلی سازی (Generalization) است و از آن لحظه به بعد در حال به خاطرسپاری (Over Fitting) مجموعه دادههای آموزشی است. بدیهی است به خاطرسپاری باعث افزایش دقت مدل برای مجموعه دادههای آموزشی و بطور مشابه باعث کاهش دقت مدل برای مجموعه دادههای آزمایشی میشود. بدین منظور جهت جلوگیری از مشکل به خاطرسپاری از مجموعه داده ارزیابی استفاده میشود که به شکل غیر مستقیم در فرآیند یادگیری مدل، وارد عمل میشوند. بدین ترتیب مدلی که مفهومی را از دادههای آموزشی فرا گرفته، نسبت به مدلی که صرفاً دادههای آموزشی را به خوبی حفظ کرده است، برای مجموعه داده آزمایشی دقت به مراتب بالاتری دارد. این حقیقت در بیشتر فرآیندهای آموزشی که از مجموعه داده ارزیابی بهره میگیرند قابل مشاهده است.
در روشهای بدون ناظر یا روشهای توصیفی (برای مثال خوشه بندی) الگوریتمها فاقد مراحل آموزشی و آزمایشی هستند و در پایان عملیات یادگیری مدل، مدل ساخته شده به همراه کارائی آن به عنوان خروجی ارائه میشود، برای مثال در الگوریتمهای خوشه بندی خروجی همان خوشههای ایجاد شده هستند و یا خروجی در روش کشف قوانین انجمنی عبارت است از مجموعه ای از قوانین «اگر- آنگاه» که بیانگر ارتباط میان رخداد توامان مجموعه ای از اشیاء با یکدیگر میباشد.
در این قسمت عملیات ساخت مدل در فرآیند داده کاوی برای سه روش دسته بندی، خوشه بندی و کشف قوانین انجمنی ارائه میشود. بدیهی است برای هر کدام از این روشها علاوه بر الگوریتمهای معرفی شده، الگوریتمهای متنوعی دیگری نیز وجود دارد. در ادامه سعی میشود به صورت کلان به فلسفه یادگیری مدل پرداخته شود. فهرست مطالب به شرح زیر است:
1- دسته بندی:
1-1- دسته بندی مبتنی بر درخت تصمیم (Decision Tree based methods) :
1-2- دسته بندهای مبتنی بر قانون (Rule based methods) :
1-3- دسته بندهای مبتنی بر نظریه بیز (Naïve Bayes and Bayesian belief networks) :
2- خوشه بندی:
2-1- خوشه بندی افرازی (Centroid Based Clustering) :
2-1-1- الگوریتم خوشه بندی K-Means :
2-1-2- الگوریتم خوشه بندی K-Medoids :
2-1-3- الگوریتم خوشه بندی Bisecting K-Means :
2-1-4- الگوریتم خوشه بندی Fuzzy C-Means :
2-2- خوشه بندی سلسله مراتبی (Connectivity Based Clustering (Hierarchical Clustering :
2-2-1- روشهای خوشه بندی تجمیعی (Agglomerative Clustering) :
2-2-2- روشهای خوشه بندی تقسیمی (Divisive Clustering) :
2-3- خوشه بندی مبتنی بر چگالی (Density Based Clustering) :
3- کشف قوانین انجمنی :
3-1- الگوریتم های Apriori ، Brute-Force و FP-Growth:
1- دسته بندی:
در الگوریتمهای دسته بندی، برای هر یک از رکوردهای مجموعه داده مورد کاوش، یک برچسب که بیانگر حقیقتی از مساله است تعریف میشود و هدف الگوریتم یادگیری؛ یافتن نظم حاکم بر این برچسب هاست. به بیان دیگر در مرحله آموزش؛ مجموعه دادههای آموزشی به یکی از الگوریتمهای دسته بندی داده میشود تا بر اساس سایر ویژگیها برای مقادیر ویژگی دسته، مدل ساخته شود. سپس در مرحله ارزیابی؛ دقت مدل ساخته شده به کمک مجموعه دادههای آزمایشی ارزیابی خواهد شد. انواع گوناگون الگوریتمهای دسته بندی را میتوان بصورت ذیل برشمرد:
1-1- دسته بندی مبتنی بر درخت تصمیم (Decision Tree based methods):
از مشهورترین روشهای ساخت مدل دسته بندی میباشد که دانش خروجی را به صورت یک درخت از حالات مختلف مقادیر ویژگیها ارائه میکند. بدین ترتیب دسته بندیهای مبتنی بر درخت تصمیم کاملاً قابل تفسیر میباشند. در حالت کلی درخت تصمیم بدست آمده برای یک مجموعه داده آموزشی؛ واحد و یکتا نیست. به بیان دیگر براساس یک مجموعه داده، درختهای تصمیم مختلفی میتوان بدست آورد. عموماً به منظور فراهم نمودن اطلاعات بیشتری از داده ها، از میان ویژگیهای موجود یک Case ابتدا آنهایی که دارای خاصیت جداکنندگی بیشتری هستند انتخاب میشوند. در واقع براساس مجموعه دادههای آموزشی از میان ویژگی ها، یک ویژگی انتخاب میشود و در ادامه مجموعه رکوردها براساس مقدار این ویژگی شکسته میشود و این فرآیند ادامه مییابد تا درخت کلی ساخته شود. پس از ساخته شدن مدل، میتوان آن را بر روی مجموعه دادههای آزمایشی اعمال (Apply) نمود. منظور از اعمال کردن مدل، پیش بینی مقدار ویژگی یک دسته برای یک رکورد آزمایشی براساس مدل ساخته شده است. توجه شود هدف پیش بینی ویژگی دسته این رکورد، براساس درخت تصمیم موجود است.
بطور کلی الگوریتمهای تولید درخت تصمیم مختلفی از جمله SPRINT، SLIQ، C4.5، ID3، CART و HUNT وجود دارد. این الگوریتمها به لحاظ استفاده از روشهای مختلف جهت انتخاب ویژگی و شرط توقف در ساخت درخت با یکدیگر تفاوت دارند. عموماً الگوریتمهای درخت تصمیم برای شناسائی بهترین شکست، از یک مکانیزم حریصانه (Greedy) استفاده میکنند که براساس آن شکستی که توزیع دستهها در گرههای حاصل از آن همگن باشد، نسبت به سایر شکستها بهتر خواهد بود. منظور از همگن بودن گره این است که همه رکوردهای موجود در آن متعلق به یک دسته خاص باشند، بدین ترتیب آن گره به برگ تبدیل خواهد شد. بنابراین گره همگن گره ای است که کمترین میزان ناخالصی (Impurity) را دارد. به بیان دیگر هر چه توزیع دستهها در یک گره همگنتر باشد، آن گره ناخالصی کمتری خواهد داشت. سه روش مهم برای محاسبه ناخالصی گره وجود دارد که عبارتند از: ضریب GINI، روش Entropy و Classification Error.
از مزایای درخت تصمیم میتوان به توانایی کار با دادههای گسسته و پیوسته، سهولت در توصیف شرایط (با استفاده از منطق بولی) در درخت تصمیم، عدم نیاز به تابع تخمین توزیع، کشف روابط غیرمنتظره یا نامعلوم و ... اشاره نمود.
همچنین از معایب درخت تصمیم نسبت به دیگر روشهای داده کاوی میتوان این موارد را برشمرد: تولید درخت تصمیم گیری هزینه بالائی دارد، در صورت همپوشانی گرهها تعداد گرههای پایانی زیاد میشود، طراحی درخت تصمیم گیری بهینه دشوار است، احتمال تولید روابط نادرست وجود دارد و ... .
میتوان موارد استفاده از دسته بند درخت تصمیم نسبت به سایر دسته بندی کنندههای تک مرحله ای رایج را؛ حذف محاسبات غیر ضروری و انعطاف پذیری در انتخاب زیر مجموعههای مختلفی از صفات برشمرد. در نهایت از جمله مسائل مناسب برای یادگیری درخت تصمیم، میتوان به مسائلی که در آنها نمونهها به شکل جفتهای «صفت-مقدار» بازنمائی میشود و همچنین مسائلی که تابع هدف، مقادیر خروجی گسسته دارد اشاره نمود.
1-2- دسته بندهای مبتنی بر قانون (Rule based methods):
این دسته بندها دانش خروجی خود را به صورت یک مجموعه از قوانین «اگر-آنگاه» نشان میدهند. هر قانون یک بخش شرایط (LHS: Left Hand Side) و یک بخش نتیجه (RHS: Right Hand Side) دارد. بدیهی است اگر تمام شرایط مربوط به بخش مقدم یک قانون درباره یک رکورد خاص درست تعبیر شود، آن قانون آن رکورد را پوشش میدهد. دو معیار Accuracy و Coverage برای هر قانون قابل محاسبه است که هر چه میزان این دو معیار برای یک قانون بیشتر باشد، آن قانون؛ قانونی با ارزشتر محسوب میشود.
Coverage یک قانون، برابر با درصد رکوردهایی است که بخش شرایط قانون مورد نظر در مورد آنها صدق میکند و درست تعبیر میشود. بنابراین هر چه این مقدار بیشتر باشد آن قانون، قانونی کلیتر و عمومیتر میباشد.
Accuracy یک قانون بیان میکند که در میان رکوردهایی که بخش شرایط قانون در مورد آنها صدق میکند، چند درصد هر دو قسمت قانون مورد نظر در مورد آنها صحیح است.
چنانچه مجموعه همه رکوردها را در نظر بگیریم؛ مطلوبترین حالت این است که همواره یک رکورد توسط یک و تنها یک قانون پوشش داده شود، به بیان دیگر مجموعه قوانین نهایی به صورت جامع (Exhaustive Rules) و دو به دو ناسازگار (Mutually Exclusive Rules) باشند. جامع بودن به معنای این است که هر رکورد حداقل توسط یک قانون پوشش داده شود و معنای قوانین مستقل یا دو به دو ناسازگار بودن بدین معناست که هر رکورد حداکثر توسط یک قانون پوشش داده شود.
مجموعه قوانین و درخت تصمیم عیناً یک مجموعه دانش را نشان میدهند و تنها در شکل نمایش متفاوت از هم هستند. البته روشهای مبتنی بر قانون انعطاف پذیری و تفسیرپذیری بالاتری نسبت به روشهای مبتنی بر درخت دارند. همچنین اجباری در تعیین وضعیت هایی که در یک درخت تصمیم برای ترکیب مقادیر مختلف ویژگیها رخ میدهد ندارند و از این رو دانش خلاصهتری ارائه میدهند.
1-3- دسته بندهای مبتنی بر نظریه بیز (Naïve Bayes and Bayesian belief networks):
دسته بند مبتنی بر رابطه نظریه بیز (Naïve Bayes) از یک چهارچوب احتمالی برای حل مسائل دسته بندی استفاده میکند. براساس نظریه بیز رابطه I برقرار است:
هدف محاسبه دسته یک رکورد مفروض با مجموعه ویژگیهای (A1,A2,A3,…,An) میباشد. در واقع از بین دستههای موجود به دنبال پیدا کردن دسته ای هستیم که مقدار II را بیشینه کند. برای این منظور این احتمال را برای تمامی دستههای مذکور محاسبه نموده و دسته ای که مقدار این احتمال به ازای آن بیشینه شود را به عنوان دسته رکورد جدید در نظر میگیریم. ذکر این نکته ضروری است که بدانیم نحوه محاسبه برای ویژگیهای گسسته و پیوسته متفاوت میباشد.
2- خوشه بندی:
خوشه را مجموعه ای از دادهها که به هم شباهت دارند تعریف میکنند و هدف از انجام عملیات خوشه بندی فهم (Understanding) گروه رکوردهای مشابه در مجموعه دادهها و همچنین خلاصه سازی (Summarization) یا کاهش اندازهی مجموعه دادههای بزرگ میباشد. خوشه بندی از جمله روش هایی است که در آن هیچ گونه برچسبی برای رکوردها در نظر گرفته نمیشود و رکوردها تنها براساس معیار شباهتی که معرفی شده است، به مجموعه ای از خوشهها گروه بندی میشوند. عدم استفاده از برچسب موجب میشود الگوریتمهای خوشه بندی جزء روشهای بدون ناظر محسوب شوند و همانگونه که پیشتر ذکر آن رفت در خوشه بندی تلاش میشود تا دادهها به خوشه هایی تقسیم شوند که شباهت بین داده ای درون هر خوشه بیشینه و بطور مشابه شباهت بین دادهها در خوشههای متفاوت کمینه شود.
چنانچه بخواهیم خوشه بندی و دسته بندی را مقایسه کنیم، میتوان بیان نمود که در دسته بندی هر داده به یک دسته (طبقه) از پیش مشخص شده تخصیص مییابد ولی در خوشه بندی هیچ اطلاعی از خوشهها وجود ندارد و به عبارتی خود خوشهها نیز از دادهها استخراج میشوند. به بیان دیگر در دسته بندی مفهوم دسته در یک حقیقت خارجی نهفته است حال آنکه مفهوم خوشه در نهان فواصل میان رکورد هاست. مشهورترین تقسیم بندی الگوریتمهای خوشه بندی به شرح زیر است:
2-1- خوشه بندی افرازی (Centroid Based Clustering) :
تقسیم مجموعه دادهها به زیرمجموعههای بدون همپوشانی، به طریقی که هر داده دقیقاً در یک زیر مجموعه قرار داشته باشد. این الگوریتمها بهترین عملکرد را برای مسائل با خوشههای به خوبی جدا شده از خود نشان میدهند. از الگوریتمهای افرازی میتوان به موارد زیر اشاره نمود:
2-1-1- الگوریتم خوشه بندی K-Means :
در این الگوریتم عملاً مجموعه دادهها به تعداد خوشههای از پیش تعیین شده تقسیم میشوند. در واقع فرض میشود که تعداد خوشهها از ابتدا مشخص میباشند. ایده اصلی در این الگوریتم تعریف K مرکز برای هر یک از خوشهها است. بهترین انتخاب برای مراکز خوشهها قرار دادن آنها (مراکز) در فاصله هر چه بیشتر از یکدیگر میباشد. پس از آن هر رکورد در مجموعه داده به نزدیکترین مرکز خوشه تخصیص مییابد. معیار محاسبه فاصله در این مرحله هر معیاری میتواند باشد. این معیار با ماهیت مجموعه داده ارتباط تنگاتنگی دارد. مشهورترین معیارهای محاسبه فاصله رکوردها در روش خوشه بندی معیار فاصله اقلیدسی و فاصله همینگ میباشد. لازم به ذکر است در وضعیتی که انتخاب مراکز اولیه خوشهها به درستی انجام نشود، خوشههای حاصل در پایان اجرای الگوریتم کیفیت مناسبی نخواهند داشت. بدین ترتیب در این الگوریتم جواب نهائی به انتخاب مراکز اولیه خوشهها وابستگی زیادی دارد که این الگوریتم فاقد روالی مشخص برای محاسبه این مراکز میباشد. امکان تولید خوشههای خالی توسط این الگوریتم از دیگر معایب آن میباشد.
2-1-2- الگوریتم خوشه بندی K-Medoids :
این الگوریتم برای حل برخی مشکلات الگوریتم K-Means پیشنهاد شده است، که در آن بجای کمینه نمودن مجموع مجذور اقلیدسی فاصله بین نقاط (که معمولاً به عنوان تابع هدف در الگوریتم K-Means مورد استفاده قرار میگیرد)، مجموع تفاوتهای فواصل جفت نقاط را کمینه میکنند. همچنین بجای میانگین گیری برای یافتن مراکز جدید در هر تکرار حلقه یادگیری مدل، از میانه مجموعه اعضای هر خوشه استفاده میکنند.
2-1-3- الگوریتم خوشه بندی Bisecting K-Means :
ایده اصلی در این الگوریتم بدین شرح است که برای بدست آوردن K خوشه، ابتدا کل نقاط را به شکل یک خوشه در نظر میگیریم و در ادامه مجموعه نقاط تنها خوشه موجود را به دو خوشه تقسیم میکنیم. پس از آن یکی از خوشههای بدست آمده را برای شکسته شدن انتخاب میکنیم و تا زمانی که K خوشه را بدست آوریم این روال را ادامه میدهیم. بدین ترتیب مشکل انتخاب نقاط ابتدایی را که در الگوریتم K-Means با آن مواجه بودیم نداشته و بسیار کاراتر از آن میباشد.
2-1-4- الگوریتم خوشه بندی Fuzzy C-Means:
کارائی این الگوریتم نسبت به الگوریتم K-Means کاملاً بالاتر میباشد و دلیل آن به نوع نگاهی است که این الگوریتم به مفهوم خوشه و اعضای آن دارد. در واقع نقطه قوت الگوریتم Fuzzy C-Means این است که الگوریتمی همواره همگراست. در این الگوریتم تعداد خوشهها برابر با C بوده (مشابه الگوریتم K-Means) ولی برخلاف الگوریتم K-Means که در آن هر رکورد تنها به یکی از خوشههای موجود تعلق دارد، در این الگوریتم هر کدام از رکوردهای مجموعه داده به تمامی خوشهها متعلق است. البته این میزان تعلق با توجه به عددی که درجه عضویت تعلق هر رکورد را نشان میدهد، مشخص میشود. بدین ترتیب عملاً تعلق فازی هر رکورد به تمامی خوشهها سبب خواهد شد که امکان حرکت ملایم عضویت هر رکورد به خوشههای مختلف امکان پذیر شود. بنابراین در این الگوریتم امکان تصحیح خطای تخصیص ناصحیح رکوردها به خوشهها سادهتر میباشد و مهمترین نقطه ضعف این الگوریتم در قیاس با K-Means زمان محاسبات بیشتر آن میباشد. میتوان پذیرفت که از سرعت در عملیات خوشه بندی در برابر رسیدن به دقت بالاتر میتوان صرفه نظر نمود.
2-2- خوشه بندی سلسله مراتبی (Connectivity Based Clustering (Hierarchical Clustering:
در پایان این عملیات یک مجموعه از خوشههای تودرتو به شکل سلسله مراتبی و در قالب ساختار درختی خوشه بندی بدست میآید که با استفاده از نمودار Dendrogram چگونگی شکل گیری خوشههای تودرتو را میتوان نمایش داد. این نمودار درخت مانند، ترتیبی از ادغام و تجزیه را برای خوشههای تشکیل شده ثبت میکند، یکی از نقاط قوت این روش عدم اجبار برای تعیین تعداد خوشهها میباشد (بر خلاف خوشه بندی افرازی). الگوریتمهای مبتنی بر خوشه بندی سلسله مراتبی به دو دسته مهم تقسیم بندی میشوند:
2-2-1- روشهای خوشه بندی تجمیعی (Agglomerative Clustering) :
با نقاطی به عنوان خوشههای منحصر به فرد کار را آغاز نموده و در هر مرحله، به ادغام خوشههای نزدیک به یکدیگر میپردازیم، تا زمانی که تنها یک خوشه باقی بماند.
عملیات کلیدی در این روش، چگونگی محاسبه میزان مجاورت دو خوشه است و روشهای متفاوت تعریف فاصله بین خوشهها باعث تمایز الگوریتمهای مختلف مبتنی بر ایده خوشه بندی تجمیعی است. برخی از این الگوریتمها عبارتند از: خوشه بندی تجمیعی – کمینه ای، خوشه بندی تجمیعی – بیشینه ای، خوشه بندی تجمیعی – میانگینی، خوشه بندی تجمیعی – مرکزی.
2-2-2- روش های خوشه بندی تقسیمی (Divisive Clustering) :
با یک خوشهی دربرگیرندهی همه نقاط کار را آغاز نموده و در هر مرحله، خوشه را میشکنیم تا زمانی که K خوشه بدست آید و یا در هر خوشه یک نقطه باقی بماند.
2-3- خوشه بندی مبتنی بر چگالی (Density Based Clustering):
تقسیم مجموعه داده به زیرمجموعه هایی که چگالی و چگونگی توزیع رکوردها در آنها لحاظ میشود. در این الگوریتم مهمترین فاکتور که جهت تشکیل خوشهها در نظر گرفته میشود، تراکم و یا چگالی نقاط میباشد. بنابراین برخلاف دیگر روشهای خوشه بندی که در آنها تراکم نقاط اهمیت نداشت، در این الگوریتم سعی میشود تنوع فاصله هایی که نقاط با یکدیگر دارند، در عملیات خوشه بندی مورد توجه قرار گیرد. الگوریتم DBSCAN مشهورترین الگوریتم خوشه بندی مبتنی بر چگالی است.
به طور کلی عملکرد یک الگوریتم خوشه بندی نسبت به الگوریتمهای دیگر، بستگی کاملی به ماهیت مجموعه داده و معنای آن دارد.
3- کشف قوانین انجمنی :
الگوریتمهای کاشف قوانین انجمنی نیز همانند الگوریتمهای خوشه بندی به صورت روشهای توصیفی یا بدون ناظر طبقه بندی میشوند. در این الگوریتمها بدنبال پیدا کردن یک مجموعه از قوانین وابستگی یا انجمنی در میان تراکنشها (برای مثال تراکنشهای خرید در فروشگاه، تراکنشهای خرید و فروش سهام در بورس و ...) هستیم تا براساس قوانین کشف شده بتوان میزان اثرگذاری اشیایی را بر وجود مجموعه اشیاء دیگری بدست آورد. خروجی در این روش کاوش، به صورت مجموعه ای از قوانین «اگر-آنگاه» است، که بیانگر ارتباطات میان رخداد توامان مجموعه ای از اشیاء با یکدیگر میباشد. به بیان دیگر این قوانین میتواند به پیش بینی وقوع یک مجموعه اشیاء مشخص در یک تراکنش، براساس وقوع اشیاء دیگر موجود در آن تراکنش بپردازد. ذکر این نکته ضروری است که بدانیم قوانین استخراج شده تنها استلزام یک ارتباط میان وقوع توامان مجموعه ای از اشیاء را نشان میدهد و در مورد چرایی یا همان علیت این ارتباط سخنی به میان نمیآورد. در ادامه به معرفی مجموعه ای از تعاریف اولیه در این مبحث میپردازیم (در تمامی تعاریف تراکنشهای سبد خرید مشتریان در یک فروشگاه را به عنوان مجموعه داده مورد کاوش در نظر بگیرید):
• مجموعه اشیاء: مجموعه ای از یک یا چند شیء. منظور از مجموعه اشیاء K عضوی، مجموعه ای است که شامل K شیء باشد.
برای مثال:{مسواک، نان، شیر}
• تعداد پشتیبانی (Support Count) : فراوانی وقوع مجموعهی اشیاء در تراکنشهای موجود که آنرا با حرف σ نشان میدهیم.
برای مثال: 2=({مسواک، نان، شیر})σ
• مجموعه اشیاء مکرر (Frequent Item Set) : مجموعه ای از اشیاء که تعداد پشتیبانی آنها بزرگتر یا مساوی یک مقدار آستانه (Min Support Threshold) باشد، مجموعه اشیاء مکرر نامیده میشود.
• قوانین انجمنی: بیان کننده ارتباط میان اشیاء در یک مجموعه از اشیاء مکرر. این قوانین معمولاً به شکل X=>Y هستند.
برای مثال:{نوشابه}<={مسواک، شیر}
مهمترین معیارهای ارزیابی قوانین انجمنی عبارتند از:
• Support: کسری از تراکنشها که حاوی همه اشیاء یک مجموعه اشیاء خاص هستند و آنرا با حرف S نشان میدهند.
برای مثال: 2.2=({نان، شیر})S
• Confidence: کسری از تراکنشهای حاوی همه اشیاء بخش شرطی قانون انجمنی که صحت آن قانون را نشان میدهد که با آنرا حرف C نشان میدهند. برخلاف Support نمیتوانیم مثالی برای اندازه گیری Confidence یک مجموعه اشیاء بیاوریم زیرا این معیار تنها برای قوانین انجمنی قابل محاسبه است.
با در نظر گرفتن قانون X=>Y میتوان Support را کسری از تراکنش هایی دانست که شامل هر دو مورد X و Y هستند و Confidence برابر با اینکه چه کسری از تراکنش هایی که Y را شامل میشوند در تراکنش هایی که شامل X نیز هستند، ظاهر میشوند. هدف از کاوش قوانین انجمنی پیدا کردن تمام قوانین Rx است که از این دستورات تبعیت میکند:
در این دستورات منظور از SuppMIN و ConfMIN به ترتیب عبارت است از کمترین مقدار برای Support و Confidence که بایست جهت قبول هر پاسخ نهائی به عنوان یک قانون با ارزش مورد توجه قرار گیرد. کلیه قوانینی که از مجموعه اشیاء مکرر یکسان ایجاد میشوند دارای مقدار Support مشابه هستند که دقیقاً برابر با تعداد پشتیبانی یا همان σ شیء مکرری است که قوانین انجمنی با توجه به آن تولید شده اند. به همین دلیل فرآیند کشف قوانین انجمنی را میتوان به دو مرحله مستقل «تولید مجموعه اشیاء مکرر» و «تولید قوانین انجمنی مطمئن» تقسیم نمائیم.
در مرحله نخست، تمام مجموعه اشیاء که دارای مقدار Support ≥ SuppMIN میباشند را تولید میکنیم. رابطه I
در مرحله دوم با توجه به مجموعه اشیاء مکرر تولید شده، قوانین انجمنی با اطمینان بالا بدست میآیند که همگی دارای شرط Confidence ≥ ConfMIN هستند. رابطه II
3-1- الگوریتم های Apriori ، Brute-Force و FP-Growth:
یک روش تولید اشیاء مکرر روش Brute-Force است که در آن ابتدا تمام قوانین انجمنی ممکن لیست شده، سپس مقادیر Support و Confidence برای هر قانون محاسبه میشود. در نهایت قوانینی که از مقادیر آستانهی SuppMIN و ConfMIN تبعیت نکنند، حذف میشوند. تولید مجموعه اشیاء مکرر بدین طریق کاری بسیار پرهزینه و پیچیده ای میباشد، در واقع روشهای هوشمندانه دیگری وجود دارد که پیچیدگی بالای روش Brute-Force را ندارند زیرا کل شبکه مجموعه اشیاء را به عنوان کاندید در نظر نمیگیرند. همانند تولید مجموعه اشیاء مکرر، تولید مجموعه قوانین انجمنی نیز بسیار پرهزینه و گران است.
چنانچه یک مجموعه اشیاء مکرر مشخص با d شیء را در نظر بگیریم، تعداد کل قوانین انجمنی قابل استخراج از رابطه III محاسبه میشود. (برای مثال تعداد قوانین انجمنی قابل استخراج از یک مجموعه شیء 6 عضوی برابر با 602 قانون میباشد، که با توجه به رشد d؛ سرعت رشد تعداد قوانین انجمنی بسیار بالا میباشد.)
الگوریتمهای متعددی برای تولید مجموعه اشیاء مکرر وجود دارد برای نمونه الگوریتمهای Apriori و FP-Growth که در هر دوی این الگوریتم ها، ورودی الگوریتم لیست تراکنشها و پارامتر SuppMIN میباشد. الگوریتم Apriori روشی هوشمندانه برای یافتن مجموعه اشیاء تکرار شونده با استفاده از روش تولید کاندید است که از یک روش بازگشتی برای یافتن مجموعه اشیاء مکرر استفاده میکند. مهمترین هدف این الگوریتم تعیین مجموعه اشیاء مکرری است که تعداد تکرار آنها حداقل برابر با SuppMIN باشد. ایده اصلی در الگوریتم Apriori این است که اگر مجموعه اشیایی مکرر باشد، آنگاه تمام زیر مجموعههای آن مجموعه اشیاء نیز باید مکرر باشند. در واقع این اصل همواره برقرار است زیرا Support یک مجموعه شیء هرگز بیشتر از Support زیرمجموعههای آن مجموعه شیء نخواهد بود. مطابق با این ایده تمام ابرمجموعههای مربوط به مجموعه شیء نامکرر از شبکه مجموعه اشیاء حذف خواهند شد (هرس میشوند). هرس کردن مبتنی بر این ایده را هرس کردن بر پایه Support نیز عنوان میکنند که باعث کاهش قابل ملاحظه ای از تعداد مجموعههای کاندید جهت بررسی (تعیین مکرر بودن یا نبودن مجموعه اشیاء) میشود.
الگوریتم FP-Growth در مقایسه با Apriori روش کارآمدتری برای تولید مجموعه اشیاء مکرر ارائه میدهد. این الگوریتم با ساخت یک درخت با نام FP-Tree سرعت فرآیند تولید اشیاء مکرر را به طور چشمگیری افزایش میدهد، در واقع با یکبار مراجعه به مجموعه تراکنشهای مساله این درخت ساخته میشود. پس از ساخته شدن درخت با توجه به ترتیب نزولی Support مجموعه اشیاء تک عضوی (یعنی مجموعه اشیاء) مساله تولید مجموعه اشیاء مکرر به چندین زیر مسئله تجزیه میشود، که هدف در هر کدام از این زیر مساله ها، یافتن مجموعه اشیاء مکرری است که به یکی از آن اشیاء ختم خواهند شد.
الگوریتم Aprior علاوه بر تولید مجموعه اشیاء مکرر، اقدام به تولید مجموعه قوانین انجمنی نیز مینماید. در واقع این الگوریتم با استفاده از مجموعه اشیاء مکرر بدست آمده از مرحله قبل و نیز پارامتر ConfMIN قوانین انجمنی مرتبط را که دارای درجه اطمینان بالائی هستند نیز تولید میکند. به طور کلی Confidence دارای خصوصیت هماهنگی (Monotone) نیست ولیکن Confidence قوانینی که از مجموعه اشیاء یکسانی بوجود میآیند دارای خصوصیت ناهماهنگی هستند. بنابراین با هرس نمودن کلیه ابرقوانین انجمنی یک قانون انجمنی یا Confidence (Rx) ≥ ConfMIN در شبکه قوانین انجمنی (مشابه با شبکه مجموعه اشیاء) اقدام به تولید قوانین انجمنی مینمائیم. پس از آنکه الگوریتم با استفاده از روش ذکر شده، کلیه قوانین انجمنی با اطمینان بالا را در شبکه قوانین انجمنی یافت، اقدام به الحاق نمودن آن دسته از قوانین انجمنی مینماید که پیشوند یکسانی را در توالی قانون به اشتراک میگذارند و بدین ترتیب قوانین کاندید تولید میشوند.
جهت آشنائی بیشتر به List of machine learning concepts مراجعه نمائید.