مبتدی (مناسب برای درک مفهوم کلی مطلب) 

برای حل این مشکلات ضمن گرانی برای ویژگی های اساسی مکانیزم های اجازه دهی ابری شود یک مدل اجازه دهی و مجاز سازی انعطاف پذیر، غیر متمرکز و قابل مقیاس دهی برای مستاجران با سطوح مختلف برای به اشتراک گذاری منابع شخص سازی برنامه های خود و حفظ رازهایشان باید پشتیبانی شود.
نکات مهم این مقاله به شرح ذیل است.
1) یک مدل کنترل دسترسی مبتنی بر مستاجر (به نام TMS-ARBAC) بر اساس ARBAC برای STA ارائه شده است همانگونه که STA شامل MTA است برای MTA نیز لحاظ می شود.
2) استراتژیهای مختلف کنترل دسترسی اشتراک منابع با توجه به مدل سازی دو سطحی STA (TSTA) تعریف شد و این ها می تواند برای ایجاد مسئولیت و مجوز برای هر مستاجر باشد.
3) طرح کنترل دسترسی برای یک داده علم الکترونیکی جغرافیا و پلتفرم اشتراک ابزارها براساس زیر ساخت Easy SaaS توصیف شده است تا مدل TMS-ARBAC را نشان دهد.
این مقاله به شرح زیر سازمان دهی شده است در بخش 2 زیر ساخت های MTA و مدلهای کنترل دسترسی مرتبط مرور می شود در بخش 3، یک تعریف رسمی از مدل TMS-ARBAC فراهم شد و استراتژی های اشتراک منابع برای STA توصیف شده است. در بخش 4 تحلیل ایمنی TMS-ARBAC ارائه شد. و در بخش 5 TMS-ARBAC به طرح کنترل دسترسی برای اشتراک گذاری برنامه های علم الکترونیکی جغرافیا اعمال شده است و در بخش 6 از مقاله نتیجه گیری شده است.

2.کارهای مرتبط
در این بخش MTA و STA در SaaS و مکانیزم های اسمنی مرتبط با آنها مرور می شود.

2.1 MTA و STA در SaaS
در حال حاضر 5 روش برای پیاده سازی MTA وجود دارد : یکپارچه سازی با پایگاه داده، روش میانی، SaaS خدمات محور، روش PaaS محور و روشی هدف محور، اکثر این روشها روی شکل سازی مستاجران و اجرای برنامه آنها روی یک پلتقدم ابری متمرکز هستند.
اما کدبز و همکارانش اشاره کردند که چند مستاجری فاقد یک تعریف واضح است. به نظر می رسد که بسیاری از تکنولوژی های MTA موجود از قبیل مرکز داده، مجازی سازی و روشهای اشتراکی میانی یا MTA ، PaaS محور. MTA واقعی نیستند اما روشهای استفاده چند برنامه ای یا چند لحظه ای فاقد کارایی و اشتراک منابع هستند.
در MTA اکثر سیستم های موجود مستاجران را بعنوان نهادهای واحد که کاملاً از سایر مستاجران جدا شده¬اند لحاظ می کنند. اما SaaS اشتراک گذاری را ترویج می کند در جهان واقعی بسیاری از تعاونی ها، سازمانهای سطوح یکسان یا هم نوع دارای ملزومات برنامه ای یا پروسرهای تجاری مشابه هستند.رابطه بین در مستاجر باید بررسی شود. اما فقط تعداد اندکی از کارهای مرتبط چاپ شده است.
از نقطه نظر موازنه بار چهار نوع وابستگی (بدون وابستگی، وابسته به سرور، وابسته به کلاستر و وابستگی میان کلاستر) برای دسته بندی کاربران مختلف یک مستاجر برای گره های پردازش برای اشتراک منابع و کارایی موثر داده شده است.
من هات و همکارانش (17) یک مدل سلسله برای را برای نمایش منطقی درخت مستاجر و نگاشت به ذخیره فیزیکی معرفی که دراد اما انکار وی کارایی و تماس پذیری ذخیره دسترسی داده احراز هویت تمرکز کرده اند.
کسیتون رابط برنامه ریزی برنامه های هویت (APL) چند مستاجری سلسله مراتبی را برای Open Stack با استفاده از حوزه ها و پروژه برای ساخت سلسله مراتب گروه های کاربری و زیر مجموعه های منابع فراهم کرده است.
با در نظر گرفتن روابط سلسله مراتبی بین مستاجران در زندگی واقعی یک الگوی چند مستاجری سلسله مراتبی معرفی شده است .(6) اما هیچ یک از آنها اشتراک منابع شخصی شده یا جداسازی میان مستاجران را بررسی نمی کنند.
یک پلتوم. MTA SaaS ، Sales force است که یک نمونه برنامه و یک طرح پایگاه داده را برای حمایت از چند مستاجری (شامل مستاجران سطح سرمایه گذاری) با استناد از یک معماری نرم افزار درایو شده از متاداده، APL های مبتنی بر استاندارد و تولید کننده برنامه زمان اجرای برای فعال سازی برنامه های CRM چند مستاجری را اجرا می کند.
از نقطه نظر استفاده مجدد از منابع مشترک و مشخص سازی آسان، STA برای مدلسازی همه انواع چند مستاجری سلسله مراتبی با اشتراک منابع بین مستاجران سطوح مختلف ارائه شده است. این مستاجران اجازه می دهد که خدمات را برای توسعه دهندگان مستاجر دست دوم برای شخصی سازی کاربردهای آنها مجاز می سازد مدلهای مختلف STA با مدلهای مختلف شخص سازی تعریف شده اند.

مقالات انگلیسی و ترجمه های فارسی رایگان با فرمت PDF آماده دانلود رایگان میباشند

همچنین ترجمه مقاله با فرمت ورد نیز قابل خریداری و دانلود میباشد

مقاله انگلیسی رایگان (PDF)

ترجمه فارسی رایگان (PDF)

خرید ترجمه با فرمت ورد

فهرست مقاله:

چکیده
1.مقدمه
2-کارهای مرتبط
3-منشأ YARN
3-1 هادوپ
3-2 YARN
4-زمان بندهای کار پشتیبانی شده با YARN
4-1 زمان بند ظرفیت
4-2 زمان بند عادلانه
5-مدل‌های برنامه نویسی و انواع برنامه‌ها
5-1 مدل‌های برنامه نویسی
5-2 انواع برنامه‌ها
6-ارزیابی عملکرد و مقایسه
6-1 سناریوی تک صفی
6-2 سناریوی صف مجزا
6-3 سناریوی صف ادغام شده
7-نتیجه گیری و کارهای آینده

بخشی از ترجمه فارسی مقاله:

1- مقدمه
هادوپ (1) یک چارچوب نرم افزاری متن باز می‌باشد که توسط آپاچی برای پردازش حجم بالای مجموعه داده‌ها بر روی یک کلاستر (خوشه) شامل تعداد زیادی از دستگاه‌ها پشتیبانی می‌شود. به دلیل سهولت، مقرون به صرفگی، مقیاس پذیری و تحمل پذیری خطا،، طیف وسیعی از سازمان‌ها و شرکت‌ها نظیر گوگل، یاهو، فیسبوک و آمازون از هادوپ برای هم برای تحقیق و هم برای تولید استفاده کرده‌اند (2). با این حال هادوپ اصلی دارای چندین محدودیت می‌باشد (3). یک نمونه این است که تخصیص منابع مبتنی بر اسلات برای دستورات نقشه و دستورات کاهش موجب محدودیت منابع کلاستر هادوپ شده و منجر به بهره گیری کم‌تر از منابع می‌شود (3). یک مثال دیگر این اسن که هادوپ اصلی تنها یک نوع مدل برنامه نویسی را پشتیبانی می‌کند یعنی MapReduce(4) که برای پردازش همه نوع محاسبات بزرگ مقیاس (3-5-6) مناسب نیست.
به منظور حل این محدودیت‌ها، انجمن متن باز نسل جدیدی از پلتفرم محاسبه هادوپ موسوم به YARN(مخفف Yet Another Resource Negotiator)(3) را معرفی کرده است. نام‌های دیگر شامل MapReduce 2.0 و MRv2 می‌باشند.YARN به برنامه‌ها و نرم افزارها امکان بهره گیری از منابع یک کلاستر را به شکلی مشترک و چند مستأجری می‌دهد. YARN بر خلاف هادوپ اصلی (یعنی همه نسخه‌های قبل از MRv2) دستورات مدیریت منابع را از مدل برنامه نویسی جدا کرده و از این روی می‌تواند نه تنها از MapReduce بلکه از سایر مدل‌های برنامه نویسی نظیر Spark [5], Storm [7], Tez [8], و REEF [9] پشتیبانی کند. به عبارت دیگر، این تفکیک امکان اجرای انواع مختلفی از نرمافزار ها را به طور موازی بر روی YARN می‌دهد.
به منظور پشتیبانی از یک محیط محاسباتی مشترک،YARN دو زمان بند را برای زمان بندی منابع با نرم افزارها ارائه می‌کند. یکی زمان بند ظرفیت (زمان بند پیش فرض بر روی YARN)(10) و دیگری زمان بند عادلانه (11). هر دوی آن‌ها قادر به سازمان دهی ارسال برنامه به یک سلسله مراتب صف بندی می‌باشند. با این حال، اولی مقدار حداقل منابع را برای هر صف تضمین کرده و از FIFO(که مخفف به ترتیب ورود است) برای زمان بندی نرم افزارها در صف برگ استفاده می‌کند. مورد دوم، منابع را به طور عادلانه در میان همه صف‌ها تسهیم کرده و سه سیاست از جمله FIFO، Fair و عدالت منابع غالب (DRF) (12) را برای تسهیم منابع برای همه برنامه‌های در حال اجرا در یک صف ارائه می‌کند. همه رویکردهای زمان بندی فوق الذکر تشکیل چهار مجموعه سیاست زمان بندی زیر (SPC) را داده و انعطاف پذیری بالایی را برای مدیران YARN برای دست یابی به اهدافشان نظیر تسهیم منابع عادلانه و بهره گیری بالا از منابع در اختیار می‌گذارد.
1- Cap-FIFO که زمان بند ظرفیت با سیاست زمان بندی FIFO است
2- Fair-FIFO که زمان بند عادلانه با سیاست زمان بندی FIFO است
3- Fair-Fair که زمان بند عادلانه با سیاست زمان بندی عادلانه است
4- Fair-DRF که زمان بند عادلانه با سیاست زمان بندی DRF است
اگرچه YARN از چهار SPC و انواع متنوعی از برنامه‌ها پشتیبانی می‌کند با این حال هنوز مشخص نیست که این SPC ها وقتی که به طور جداگانه برای زمان بندی نرم افزارهای ترکیبی استفاده می‌شوند، چگونه کار می‌کنند. به علاوه، عملکرد آن‌ها زمانی نامشخص است که ساختارهای مختلف صف بندی استفاده می‌شود. از این روی، در این مقاله، ما به بررسی چهار SPC و همه مدل‌های برنامه نویسی پشتیبانی شده توسط YARN پرداخته همه برنامه‌ها را به چندین نوع طبقه بندی می‌کنیم. با این همه، ما آزمایشات گسترده‌ای را برای ارزیابی و مقایسه اثرات عملکرد چهار SPC بر روی متریک‌های متنوع با در نظر گرفتن نه تنها بارکار متشکل از انواع برنامه‌های مختلف، بلکه متشکل از سه سناریوی زیر انجام دادیم. هدف این مطالعه، بررسی این است که آیا ساختارهای صف بندی بر عملکرد چهار SPC تأثیر دارند یا خیر.
1- سناریوی تک صف: در این سناریو تنها یک صف در کلاستر YARN ما وجود دارد. از این روی همه نرم افزارها بایستی قبل از اجرا در این صف منتظر بمانند
2- سناریوی صف مجزا: در این سناریو، هر نوع از برنامه‌ها به طور جداگانه در یک صف مجزا قرارمی گیرند.
3- سناریوی صف ادغام شده: در این سناریوف دو نوع صف وجود دارند: یکی برای برنامه‌هایی که در نهایت توسط خودشان متوقف می‌شود. صف دیگر برای بقیه برنامه‌هاست. نتایج آزمایش نشان می‌دهد که 1- همه SPC ها از مسئله تقسیم منابع که در ادامه توضیح داده شده است رنج می‌برند. این مسئله موجب می‌شود تا هیچ یک از SPC ها نتوانند به طور موفق، بارکار متشکل از برنامه‌های ترکیبی را کامل کنند 2- هیچ یک از چهار SPC معمولاً، بهترین عملکرد اجرایی برنامه در همه سناریوها نبوده است و 3- در میان سه سناریو، استفاده از سناریوی صف ادغام شده، مناسب‌ترین سناریو برای همه SPC ها می‌باشد زیرا آن‌ها می‌توانند به نرخ تکمیل بارکار بالاتر و زمان بارکار کوتاه‌تر از دو سناریوی دیگر برسند. این مقاله دو اهمیت اصلی را دارد. 1- این مقاله یک مرور جامعی را بر روی زمان بندهای فعلی،SPC ها، مدل‌های برنامه نویسی و انواع برنامه‌های پشتیبانی شده توسط YARN دارد 2- ما به طور گسترده اقدام به ارزیابی و مقایسه چهار SPC با در نظر گرفتن نه تنها انواع برنامه‌های ترکیبی، بلکه سناریوهای متنوع ساختار صف می‌کنیم و 3- بر اساس نتایج ازمایشی، مدیران YARN می‌توانند یک ساختار صف و SPC مناسب را برای دست یابی به عملکرد برنامه بهتر برای کلاسترهای YARN انتخاب کنند.
ادامه این مقاله به صورت زیر سازمان دهی شده است: بخش دوم به توصیف کارهای مرتبط می‌پردازد. بخش سوم به بررسی منشأ YARN خواهد پرداخت. بخش چهارم دو زمان بند پشتیبانی شده توسط YARN و چهار SPC مشتق شده از دو زمان بند را معرفی می‌کند. بخش پنجم مدل‌های برنامه نویسی پشتیبانی شده توسط YARN و برنامه‌هایی که هر مدل برنامه نویسی می‌تواند بیان و پردازش کند را توصیف می‌کند. در بخش ششم، آزمایشات گسترده‌ای انجام شده و نتایج آزمایش بحث می‌شوند. بخش هفتم بخش نتیجه گیری این مقاله بوده و کارهای آینده ما را شامل می‌شود.

بخشی از مقاله انگلیسی:

1. INTRODUCTION

Hadoop [1] is an open-source software framework supported by Apache to process high volume of datasets on a cluster comprising a large number of commodity machines. Because of its simplicity, cost efficiency, scalability, and fault tolerance, a wide variety of organizations and companies, such as Google, Yahoo!, Facebook, and Amazon, have used Hadoop for both research and production [2]. However, the original Hadoop has several limitations [3]. One example is that the slot-based resource allocation for map tasks and reduce tasks bottlenecks the resource of an entire Hadoop cluster and results in low resource utilization [3]. Another example is that the original Hadoop supports only one type of programming model, i.e., MapReduce [4], which is not suitable for processing all kinds of large-scale computations [3, 5, 6]. To solve these limitations, the open-source community introduced the next generation of Hadoop’s compute platform called YARN (which is short for Yet Another Resource Negotiator) [3]. Other names are MapReduce 2.0 and MRv2. YARN allows individual applications to utilize the resources of a cluster in a shared and multi-tenant manner. Different from the original Hadoop (i.e., all versions before MRv2), YARN separates resource management functions from the programming model, and therefore can support not only MapReduce but also other programming models, including Spark [5], Storm [7], Tez [8], and REEF [9]. In other words, this separation enables various types of applications to execute on YARN in parallel. To enable a shared compute environment, YARN provides two schedulers to schedule resources to applications. One is the capacity scheduler (the default scheduler on YARN) [10], and the other is the fair scheduler [11]. Both of them can organize application submissions into a queue hierarchy. However, the former guarantees a minimum amount of resources for each queue and uses FIFO (which stands for first-in first-out) to schedule applications within a leaf queue. The latter fairly shares resources among all queues and offers three policies, including FIFO, Fair, and Dominant Resource Fairness (DRF for short) [12], to share resources for all running applications within a queue. All of the aforementioned scheduling approaches form the following four scheduling-policy combinations (SPCs for short) and provide great flexibility for YARN managers to achieve their goals, such as fair resource sharing and high resource utilization. 1. Cap-FIFO, which is the capacity scheduler with the FIFO scheduling policy. 2. Fair-FIFO, which is the fair scheduler with the FIFO scheduling policy. 3. Fair-Fair, which is the fair scheduler with the fair scheduling policy. 4. Fair-DRF, which is the fair scheduler with the DRF scheduling policy. Although YARN supports the four SPCs and diverse application types, it is unclear how these SPCs perform when they are individually used to schedule mixed applications. Besides, their performances are also unknown when different queue structures are utilized. Hence, in this paper, we survey the four SPCs and all programming models supported by YARN, and then classify all applications into several types. After that, we conduct extensive experiments to evaluate and compare the performance impacts of the four SPCs on diverse metrics by considering not only a workload consisting of mixed application types, but also the following three scenarios. The purpose is to study whether queue structures influence the performances of the four SPCs or not. 1. One-queue scenario: In this scenario, there is only one queue in our YARN cluster. Hence, all application submissions must wait in this queue before they are executed. 2. Separated-queue scenario: In this scenario, each type of applications is individually put into a separate queue. 3. Merged-queue scenario: In this scenario, there are two queues. One is for applications that will eventually stop by themselves. The other queue is for the rest of the applications. The experimental results show that (1) all SPCs suffer from a resource fragmentation problem, which will be explained later. This problem causes that none of the SPCs could successfully complete a workload consisting of mixed applications; (2) none of the four SPCs always has the best application execution performance in all scenarios; and (3) among the three scenarios, employing the mergedqueue scenario is the most appropriate for all SPCs since they can achieve a higher workload completion rate and a shorter workload turnaround time than they are in the other two scenarios. The contributions of this paper are as follows. (1) This paper provides a comprehensive survey on current schedulers, SPCs, programming models, and application types supported by YARN; (2) We extensively evaluate and compare the four SPCs by considering not only mixed application types, but also diverse queue-structure scenarios; and (3) Based on our experimental results, YARN managers can choose an appropriate SPC and queue structure to achieve a better application performance for their YARN clusters. The rest of this paper is organized as follows. Section 2 describes the related work. Section 3 surveys the origin of YARN. Section 4 introduces the two schedulers supported by YARN and the four SPCs derived from the two schedulers. Section 5 describes the programming models supported by YARN and applications that each programming model can best express and process. In section 6, extensive experiments are conducted and experimental results are discussed. Section 7 concludes this paper and outlines our future work.

مقاله انگلیسی رایگان (PDF)

ترجمه فارسی رایگان (PDF)

خرید ترجمه با فرمت ورد

بخشی از ترجمه فارسی مقاله:

1. مقدمه
در دهه گذشته، محتوای چند رسانه ای ترافیک غالب اینترنت شده است [2-4]. افزایش تقاضا برای محتوای غنی از رسانه ها، مستلزم روش های کارآمدتر برای بازیابی محتوا است. برای این منظور، شبکه اطلاعاتی محور (ICN) یک رویکرد امیدوار کننده طراحی است که این تقاضا را با ارائه دسترسی محتوا به نام و امکان ذخیره در شبکه در اختیار قرار می دهد [5،6]. در ICN ها، یک روتر محتوا (CR) با قابلیت ذخیره در شبکه می تواند برخی از (معمولا محبوبیت) تکه های داده را برای دسترسی را وساطت کند [7]. ذخیره سازی در شبکه می تواند تاخیر بازیابی محتوا، ترافیک شبکه و بار سرویس بر روی سرورها را تا حد زیادی کاهش دهد [8،9] .
برای مدیریت مخازن در شبکه در ICN، دو مساله مهم باید بصورت مشترک مورد توجه قرار گیرد. یکی استراتژی ذخیره سازی است که تعیین می کند که چه مقدار از داده ها باید در هر CR ذخیره شود، و دیگری مسیریابی محتوا است که تعیین می کند کجا برای مسیریابی محتوا لازم است و نحوه ارائه مطالب چگونه است.
در متون، دو نوع استراتژی ذخیره سازی وجود دارد: غیر تعاونی و تعاونی. در استراتژی های ذخیره سازی غیر تعاونی، CR به طور تصادفی داده های دریافتی را ذخیره می کند، که ممکن است منجر به به روز رسانی حافظه پنهان مکرر، تخصیص حافظه پنهان غیرقابل کپی و کپی مجدد شود [8]. در استراتژی های ذخیره سازی تعاونی، یک CR می تواند با CR های همسایه خود همکاری کند تا تعیین کند که کدام مجموعه داده ها برای حافظه پنهان است [9-12].
برای مسیریابی محتوا، دو روش مختلف برای استفاده از مخازن در شبکه وجود دارد. یکی از اینها فقط استفاده از حافظه های ذخیره شده در مسیر سرور اصلی محتوا برای آن درخواست است و دیگری استفاده از تمام مخازن ذخیره سازی نزدیک است. اولی نیازمند هیچ نوع همکاری بین CRها نیست اما ممکن است بصورت بالقوه تاخیر بازیابی محتوایی بیشتری را نشان دهد. دومی نیازمند همکاری میان CR ها برای ارسال درخواست به نزدیک ترین حافظه خارج از مسیر است [13]. هر دو حالت با ذخیره محتوا ارتباط نزدیکی دارند. در این مقاله، ما بر روی استراتژی ذخیره سازی همکاری و مسیریابی محتوا تمرکز خواهیم کرد تا تمام مخازن توزیع شده در شبکه را به طور کامل استفاده کنیم.
برای فعال کردن همکاری در میان CR های توزیع شده، برای جمع آوری اطلاعات مربوط به همکاری (به عنوان مثال، نرخ درخواست و وضعیت فعلی کش)، یک چارچوب مدیریت کش لازم است و تصمیم گیری های ذخیره سازی و مسیریابی را می گیرند. نرم افزار تعریف شبکه بندی (SDN)، که از نظر فیزیکی کنترل کننده هواپیما و هواپیما داده را جدا می کند، می تواند این نیاز را برآورده کند [14،15]. به طور معمول، در کنترل هواپیما، یک کنترل کننده مسئول جمع آوری اطلاعات شبکه و تصمیم گیری مسیریابی است که در روتر ها پیکربندی می شود. در هواپیما داده، روترها بسته های روبرو را با توجه به تنظیمات جریان توسط کنترل کننده تنظیم می کنند. طی چند سال گذشته، بسیاری از کنترل کننده های جدید با استفاده از سرورهای چند هسته ای قدرتمند برای رسیدگی به تعداد زیادی جریان داده در شبکه های بزرگ طراحی شده اند. به عنوان مثال، McNettle [16] می تواند حدود 20 میلیون درخواست در هر ثانیه را برای یک شبکه با 5000 سوئیچ مدیریت کند.
به تازگی، مطالعات مقدماتی برای امکان مدیریت کش در ICN ها براساس SDN انجام شده است [17،18]. با این حال، این مطالعات عمدتا بر چگونگی ادغام عملیات مرتبط با حافظه پنهان در معماری SDN موجود متمرکز شده و در مورد استراتژی ذخیره سازی واقعی بحث نمی کنند. در این مقاله، برای مطالعه استراتژی ذخیره سازی و مسیریابی محتوا ICN ها بر اساس SDN با هدف به حداقل رساندن پهنای باند شبکه و هزینه کش یک گام به جلو بر می داریم، که کل هزینه پهنای باند و مصرف حافظه پنهان در کل شبکه است.
به طور خاص، ما برنامه نویسی خطی شبکه (LNC) را برای بهینه سازی مشترک استراتژی ذخیره سازی و مسیریابی محتوا برای به حداقل رساندن پهنای باند شبکه و هزینه کش بکار می بریم. ما از نمونه ای که در شکل 1 نشان داده شده است برای نشان دادن مزایای استفاده از ذخیره سازی و LNC در ICN ها استفاده می کنیم. در این شکل، یک شبکه شامل هشت روتر (v 1 -v 8) و دو سرور (s 1 و s 2) است. کاربران همه به روترهای v1، v5 و v6 متصل می شوند و یک تکه محتوا را به عنوان f 1، که شامل دو تکه داده ای با اندازه یکسان، A و B است، درخواست می کنند. ما فرض می کنیم که هر لینک یک هزینه واحد برای ارسال یک تکه داده است و یک روتر یک هزینه واحد برای ذخیره یک تکه داده دارد. از لحاظ هزینه کل، یعنی مجموع هزینه پهنای باند و هزینه کش، ما در سه سناریوی تحویل محتوا مختلف، موارد زیر را داریم:
• در شکل 1 (a) سناریوی پایه ای را بدون کش در شبکه بررسی می کنیم، بنابراین بهترین راه برای به دست آوردن محتوای تعیین شده، استفاده از چندپخشی است که هفت پیوند در مسیریابی استفاده می شود.در این مورد، مخزن ذخیره شده در شبکه وجود ندارد. برای هر تکه داده، 7 پیوند استفاده می شود و هر لینک دارای ظرفیت واحد است. بنابراین، برای انتقال دو قطعه داده، هزینه حافظه کش 0 و هزینه پهنای باند 2 × 7 = 14 است. هزینه کل 14= 14 + 0 است.
• در شکل 1 (b)، ما فرض می کنیم که چهار CR (v 2، v 4، v 7 و v 8) وجود دارد و هر یک از آنها می توانند تنها یک تکه داده را ذخیره کنند. در این سناریو، ICN را بدون LNC در نظر می گیریم، بنابراین هر CR می تواند یک تکه داده اولیه را ذخیره کند. شکل 1 (b) استراتژی ذخیره سازی بهینه و مسیریابی محتوا را نشان می دهد، که در آن نماد پررنگ نشان داده شده در هر CR نشان دهنده داده های تکه ای ذخیره شده در CR است. در این حالت، مجموع 4 تکرار داده در CR ها ذخیره می شود، و انتقال دو تکه داده نیاز به 7 واحد مصرف پهنای باند دارد. بنابراین، برای انتقال دو قطعه داده، هزینه ذخیره سازی 4 است و هزینه پهنای باند 7 است. هزینه کل 4 + 7 = 11 است، که نشان دهنده پیشرفت 21.42 درصدی است.
• شکل 1 (c) سناریو را با مدیریت کش بهینه در ICN ها با LNC نشان می دهد. در این مورد، CR ها می توانند ترکیب خطی داده های اصلی را ذخیره کنند؛ و برای بازیابی داده های اصلی داده های A و B، کاربر فقط باید هر دو تکه داده های مستقل خطی مستقل را بدست آورد. با راه حل مطلوب، هر روتر (i.e.، v1، v5 و v6) می تواند دو تکه داده های کد شده را از دو تا از نزدیکترین CR ها به آنها دانلود کند، بنابراین CR فقط نیاز به ذخیره 3 تکه داده دارد و هزینه پهنای باند 6 واحد است. بنابراین، هزینه کل برابر 3 + 6 = 9 در مقایسه با بهترین راه حل در سناریو 1 است، راه حل بهینه برای سناریو 3 به افزایش 35.71% می رسد؛ و در مقایسه با بهترین راه حل در سناریو 2، به افزایش 18.18% می رسد.
مثال بالا مزیت مشترک در نظر گرفتن استراتژی ذخیره سازی در شبکه و مسیریابی محتوا با LNC در ICN ها، را نشان می دهد که کار این مقاله را پیش می برد. مفاد اصلی این مقاله به شرح زیر خلاصه شده است.
• ما یک چارچوب جدید مبتنی بر SDN را برای تسهیل در پیاده سازی استراتژی ذخیره سازی و مسیر محتوا در ICN ها با LNC پیشنهاد می کنیم. چارچوب مبتنی بر مفهوم در حال ظهور SDN است، که در آن یک کنترل کننده مسئول تعیین استراتژی ذخیره سازی بهینه و همچنین مسیریابی محتوای بهینه از طریق LNC است.
• ما یک مشکل مدیریت بهینه حافظه پنهان برای ICN ها را با LNC تحت یک استراتژی کش به عنوان یک مسئله برنامه نویسی خطی صحیح (ILP) تشکیل می دهیم. بر اساس این ILP پایه، ما فرموله سازی ILP را به منظور کاهش هزینه کل پهنای باند شبکه و هزینه ذخیره سازی به صورت مشترک با توجه به استراتژی ذخیره سازی و مسیر محتوا محاسبه می کنیم.
• ما یک الگوریتم مدیریت رمزنگاری مبتنی بر کدگذاری شبکه (NCCM) را برای رسیدن به یک راه حل مدیریت نزدیک به مطلوب به کار می بریم. بر اساس آرامش لاگرانژی، مشکل فرموله شده را می توان کم کرد و سپس به یک مسئله برنامه ریزی خطی و چندین مسئله ساده بزرگ شدن وزن با عدد صحیح ساده، که می تواند به طور مطلوب در طی زمان چندجمله ای حل شود، تجزیه می شود.
• ما انجام آزمایش های گسترده ای را برای مقایسه عملکرد الگوریتم NCCM پیشنهادی با حد پایین فرموله سازی ILP انجام می دهیم. ما همچنین عملکرد الگوریتم NCCM پیشنهاد شده را با سه حد بالایی از مشکل مقایسه می کنیم، یعنی بدون کش (بدون حافظه کش)، حافظه تصادفی (r-Cache) و کش های حریص (g-Cache). نتایج شبیه سازی اثربخشی الگوریتم NCCM پیشنهادی و چارچوب را اثبات می کند.
بقیه مقاله به شرح زیر است: ما درباره کار مرتبط در بخش 2 بحث می کنیم. در بخش 3، یک چارچوب مدیریت کل کش برای ICN ها را بر اساس SDN معرفی می کنیم. سپس ما مشکل مدیریت بهینه حافظه پنهان برای ICN ها با LNC را مطرح می کنیم که هدف آن کاهش پهنای باند شبکه و هزینه ذخیره با استفاده از مخازن در شبکه و LNC در بخش 4 می باشد. برای حل مشکل در عمل، در بخش 5، ما یک الگوریتم کارآمد را بر اساس کاهش لاگرانژی طراحی می کنیم. سپس تجربه های گسترده ای را برای نشان دادن عملکرد چارچوب مان در بخش 6 انجام می دهیم. در نهایت در مورد کاربرد طرح پیشنهادی در بخش 7 بحث خواهیم کرد و مقاله را در بخش 8 به پایان می رسانیم.

بخشی از مقاله انگلیسی:

1. Introduction

In the past decade, multimedia content has become the dominating traffic over the Internet [2–4]. The increasing demand for media-rich content calls for more efficient methods for content retrieval. To this end, Information-centric network (ICN) is a promising design approach that fulfills such a demand by introducing content access by name and enabling in-network caching [5,6]. In ICNs, a content router (CR) with in-network caching capability can buffer some (usually popular) data chunks for future access [7]. Innetwork caching can greatly reduce the retrieval delay of content, the traffic in the network, and the service load on the servers [8,9]. To manage in-network caches in ICNs, two major issues need to be jointly considered. One is the caching strategy that determines which data chunks shall be cached at each CR, and the other is content routing that determines where to route content requests and how to deliver content. In the literature, there are two types of caching strategies: noncooperative and cooperative. In non-cooperative caching strategies, a CR opportunistically caches the received data, which may lead to frequent cache updates, sub-optimal cache allocation and caching duplication [8]. In cooperative caching strategies, a CR can collaborate with its neighboring CRs to determine which set of data chunks to cache [9–12]. For content routing, there are two different ways to utilize the in-network caches. One is to only use caches along the path to the original content server for that request and the other is to utilize all nearby caches. The former does not require any cooperation among CRs but may exhibit potentially longer content retrieval delay. The latter requires cooperation among CRs to forward the request to the nearest off-path caches [13]. Either way is closely coupled with content caching. In this paper, we will focus on cohoperative caching strategy and content routing to fully utilize all distributed in-network caches. To enable cooperation among distributed CRs, a cache management framework is needed to collect cooperation-related information (e.g., request rates and the current cache status) and make caching and routing decisions. Software defined networking (SDN), which physically decouples the control plane and data plane, can satisfy this requirement [14,15]. Typically, on the control plane, a controller is responsible for collecting network information and making routing decisions that will be configured at routers. On the data plane, routers forward packets according to the flow tables configured by the controller. Over the past few years, many new controllers have been designed by using powerful multicore servers to handle a large number of data flows in big networks. For example, McNettle [16] can manage around 20 million requests per second for a network with 5000 switches. Recently, preliminary studies have been conducted to enable cache management in ICNs based on SDN [17,18]. However, these studies mainly focused on how to incorporate cache related operations into the existing SDN architecture and did not discuss the actual caching strategy. In this paper, we will go one step further to study caching strategy and content routing of ICNs based on SDN with the aim of minimizing both the network bandwidth and cache cost, which is the total cost of bandwidth and cache consumption in the whole network. Specifically, we will employ linear network coding (LNC) to jointly optimize caching strategy and content routing to minimize the network bandwidth and cache cost. We use an example shown in Fig. 1 to illustrate the benefits of using caching and LNC in ICNs. In this figure, a network consists of eight routers (v1–v8), and two servers (s1 and s2). The users are all connected to routers v1, v5, and v6 and request a piece of content, denoted as f1, that contains two equal-sized data chunks, A and B. We assume that each link has a unit cost to transmit one data chunk and a router has a unit cost to cache one data chunk. In terms of the total cost, i.e., the sum of bandwidth cost and cache cost, we have the following results in three different content delivery scenarios: • In Fig. 1(a), we consider a basic scenario with no in-network cache, so the best way to obtain the designated content is by utilizing multicast with which seven links are used in the routing tree. In this case, there is non in-network cache used. For each data chunk, 7 links will be used and each link has unit capacity. Therefore, to transmit two data chunks, the cache cost is 0 and the bandwidth cost is 2 × 7 =14. The total cost is 0 + 14 =14. • In Fig. 1(b), we further assume that there are four CRs (v2, v4, v7 and v8) and each of them can cache only one data chunk. In this scenario, we consider an ICN without LNC, so each CR can cache one original data chunk. Fig. 1(b) shows the optimal caching strategy and content routing, in which the bold symbol shown on each CR denotes the data chunk cached at the CR. In this case, a total of 4 data chunks are cached in CRs, and transmitting the two data chunks requires 7 units of bandwidth consumption. Therefore, to transmit two data chunks, the cache cost is 4 and the bandwidth cost is 7. The total cost is 4 + 7 =11, representing a 21.42% improvement. • Fig. 1(c) shows the scenario with the optimal cache management in ICNs with LNC. In this case, the CRs can cache the linear combination of the original data chunks; and to recover the original data chunks A and B, a user only needs to obtain any two linearly independent coded data chunks. With the optimal solution, each router (i.e., v1, v5 and v6) can download two coded data chunks from its two nearest CRs, thus CRs only need to cache 3 data chunks and the bandwidth cost is 6 units. Therefore, the total cost is 3 + 6 =9. Compared to the best solution in Scenario 1, the optimal solution for scenario 3 achieves a 35.71% improvement; and compared to the best solution in Scenario 2, it achieves 18.18% improvement. The above example demonstrates the advantage of jointly considering in-network caching strategy and content routing with LNC in ICNs, which motivates the work of this paper. The main contributions of this paper are summarized as follows. • We propose a novel SDN-based framework to facilitate the implementation of caching strategy and content routing in ICNs with LNC. The framework is based on the emerging concept of SDN, in which a controller is responsible for determining the optimal caching strategy as well as the optimal content routing via LNC. • We formulate an optimal cache management problem for ICNs with LNC under a given cache strategy as an integer linear programming (ILP) problem. Based on this basic ILP, we further develop the ILP formulation to minimize the total network bandwidth cost and cache cost by jointly considering caching strategy and content routing. • We develop an efficient network coding based cache management (NCCM) algorithm to obtain a near-optimal cache management solution. Based on Lagrangian relaxation, the formulated problem can be relaxed and then decomposed into a linear programming problem and several simple integer maximum weight placement problems, all of which can be solved optimally within polynomial time. • We conduct extensive experiments to compare the performance of the proposed NCCM algorithm with the lower bound of the ILP formulation. We also compare the performance of the proposed NCCM algorithm with three upper bounds of the problem, i.e., no cache (no-Cache), random cache (r-Cache) and greedy cache (g-Cache) strategies. Simulation results validate the effectiveness of the proposed NCCM algorithm and the framework. The rest of the paper is organized as follows. We discuss related work in Section 2. In Section 3, we introduce a general cache management framework for ICNs based on SDN. Next, we formulate the optimal cache management problem for ICNs with LNC, which aims to minimize the network bandwidth cost and cache cost by exploiting in-network caches and LNC in Section 4. To solve the problem in practice, in Section 5, we design an efficient algorithm based on Lagrangian relaxation. We then conduct extensive experiments to illustrate the performance of our framework in Section 6. Finally, we discuss the applicability of the proposed scheme in Section 7, and we conclude the paper in Section 8.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

2) پورتال وب: وب پورتال شامل اطلاعات در مورد اجزای مختلف استفاده مجدد، ویژگی های خود، لینک اسناد و مدارک، نسخه های انتشار، و صاحبان جزء خود بود. در نتیجه، تمام اطلاعات مورد نیاز برای تصمیم گیری در مورد استفاده کردن یا نکردن مجدد از یک جزء به راحتی در دسترس بود. پورتال استفاده از اجزاء قابل استفاده مجدد را گزارش داد. همچنین صرفه جویی مورد متوجه نیز محاسیه شد. پس انداز به عنوان (تعدادی از پروژه های-1) (نیمی از هزینه توسعه کل از جزء) محاسبه شد. این محاسبات در تجزیه و تحلیل داده های گذشته، هزینه های سربار در ارتباط با استفاده مجدد حدود نیمی از هزینه های توسعه، را نشان داد. جدول را مشاهده کنید.

4. تجارب و مسائل با رویکرد اولیه
رویکرد اولیه، موفق بود. ما قادر به شناسایی حدود 200 از اجزاء قابل استفاده مجدد بودیم. علاوه بر این، حدود 100 مورد از آن ها برای توسعه داخلی به طور موفقیت آمیز استفاده شدند. علاوه بر این، اعضای تیم در سراسر سازمان به طور فعال برای استفاده مجدد کمک کرده اند.
با این حال، در طول زمان، ما با انواع مختلفی از مسائل مواجه شدیم به این دلیل مدیران شروع به از دست دادن اعتماد در مورد طرح استفاده مجدد کردند. این موارد در زیر مفصل و در داده های کمی در جدول III معرفی شده
اند.
A. اولویت بندی
صاحبان جزء بخشی از یک تیم پروژه بودند، آنها اولویت های بالاتر را برای یک پروژه خاص اختصاص می دادند و مهلت پروژه و اولویت های پایین تر به وظایف برای اجزاء قابل استفاده مجدد اختصاص داده می شد. این توانایی از صاحبان جزء به ارائه اجزاء قابل استفاده مجدد به عنوان پروژه های دیگر برنامه ریزی شده بود و در نتیجه باعث افزایش مشاجره و بحث ناخوشایند را در پی داشته است.

B. بایاس ویژگی
صاحبان جزء نیز همچنین سوگیری هایی به سمت ویژگی های پروژه های خود و پروژه های بزرگ مهم مورد نیاز نشان داده اند. این تاثیر منفی دوبل داشتد. اول، پروژه های کوچکتر بودند و عملکرد آنها در اجزاء قابل استفاده مجدد مورد نیاز نبود. دو، قطعات استفاده مجدد به عنوان قابلیت های پروژه خاص، بیشتر و بیشتر در آنها استفاده می شدند.

C. کیفیت
از آنجا که تست استراتژی تحویل اجزاء قابل استفاده مجدد برای صاحبان جزء با طراحی استاندارد ارائه نمی شد، اینکار هیچ طراحی و تست استراتژی سازگاری را به دنبال نداشت. ین امر بر روی کیفیت قطعات استفاده مجدد تاثیر گذاشته است، به خصوص با توجه به نیازهای غیر کارکردی مانند نگهداری، مقیاس پذیری، و دیگر موارد. مسائل کیفیت در افزایش و تعمیر و نگهداری اجزا آشکار شد. همچنین در بیش از 200 نقص حل نشده و زمان قابل توجه، حدود 70 درصد صرف حل و فصل نقص های موجود شد.

D. ارتباطات
همانطور که هیچ نقطه تماس واحدی برای اجزای مختلف وجود ندارد، مدیران پروژه تا به حال مجبور به تعامل با صاحبان جزء متعدد شده اند، که کار را برای پیگیری پیشرفت در اجزای مختلف دشوار نمود. علاوه بر این، تمام مسائل استفاده مجدد به مدیریت ارائه و تشدید شد.

E. بودجه
به طور معمول، مدیران محصول تمایلی به تحمل هزینه های اضافی در ارتباط با استفاده مجدد از اجزای نرم افزار، مانند تلاش همراه با افزایش مدیریت ارتباطات و درگیری همراه با هزینه های مرتبط با طراحی دقیق تر، تست، و اسناد و مدارک را نداشته اند.

5. تجزیه و تحلیل مسائل
ما در این خصوص در رویکرد اولیه، مراحل رسیدگی به آنها را شناسایی کرده ایم. علل ریشه برای این مسائل عبارت بودند از:

A. مسئولیت دوگانه
ناتوانی صاحبان جزء در برنامه ریزی حجم کار در حالی که یک نقش دوگانه را در اعضای تیم پروژه و در همان زمان طراحی، توسعه، تست، نگهداری و افزایش یک جزء استفاده مجدد، بازی می کنند. اگرچه تلاش بودجه برای کارهای مربوط به استفاده مجدد از قطعات مناسب بود، چالش در برنامه ریزی این کارها همراه با فشار معمولا غیر قابل پیش بینی پروژه روزانه نهاده شده است.

B. اجرای فرآیند ها
صاحبان اجزا مجبور نبودند به دنبال فرآیندهای استاندارد تعریف شده باشند، در حالی که اجزاء قابل استفاده مجدد در حال توسعه بودند. علاوه بر این، پروسه های مورد نیاز برای نیازهای خاص اجزاء قابل استفاده مجدد نیز تعریف شده اند. از این رو، صاحبان جزء قادر به توسعه اجزاء قابل استفاده مجدد و پیشرفت به اندازه کافی بدون دخیل کردن تیمهای متخصص دیگر مانند معماری، قابلیت استفاده، و آزمون بوده اند. که منجر به کیفیت پایین تر نیز می شود.

C. تنها نقطه تماس
عدم وجود یک نقطه تماس برای همه اجزاء قابل استفاده مجدد باعث دشوار ساختن حل و فصل مسائلی مانند داشتن برخی از ویژگی ها، پیشرفت، و رفع نقص شده است. این با مشکلات همراه شدند با مشکلاتی در کیفیت قطعات استفاده مجدد شدند و مدیران پروژه سوال هایی درباره ارزش ابتکار استفاده مجدد کردند.

D. بی میلی در بودجه پایگاه کد استفاده مجدد
هر چند مدیران محصول حاضر به برداشت از مزایای استفاده مجدد بودند، آنها به هزینه های اضافی مربوط به توسعه و نگهداری از اجزای استفاده مجدد در بودجه موجود خود تمایل داشتند.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

به عنوان یک ابزار TCG جعبه سیاه، MoMuT::UML نیاز به یک محیط تست جهش قوی دارد، که بدان معنی است که آن تنها می تواند شامل یک جهش شناسایی (“خاتمه یافته “) باشد، اگر جهش یک تفاوت در رفتار قابل مشاهده نسبت به اصلی نشان دهد. رابطه انطباق که ما برای تست استفاده می کنیم، انطباق ورودی-خروجی Tretman است [17]، که در سیستم های انتقال برچسب شده تعریف می شود و گفته می شود که هر گونه مشاهده که بتواند از سیستم تحت تست (SUT) بعد از یک اثر خاص ایجاد شود، باید توسط مدل پیش بینی شود. توجه داشته باشید که اگر SUT فقط یک زیرمجموعه از مشاهدات ممکن تولید کند، آن هنوز خوب است. برای تعریف رسمی ioco و LTS، ما به Tretman [17] مراجعه می کنیم.
شکل 1 یک مرور کلی از معماری MoMuT را نشان می دهد. ابزار به عنوان فایل .jar توزیع شده و یک پایان جلو ، نوشته شده در جاوا، با یک پایان عقب را ترکیب می کند که در C++11 نوشته شده است. در حالی که پایان جلو برای چک کردن ورودی معتبر است، پایان عقب کار واقعی را انجام می دهد. توجه داشته باشید که پایان جلو و عقب توسط بافرهای پروتکل گوگل از هم جدا می شوند، بنابراین آن ممکن است از پایان عقب به طور مستقل استفاده کند. به عنوان ورودی، MoMuT::UML ممکن است از نمودارهای حالت UML یا سیستم-های عمل شیء گرا (OOAS) استفاده کند. اگر یک مدل UML – شامل نمودار حالت، نمودار کلاس، و نمودار نمونه – استفاده شود، MoMuT ابتدا آن را به کد OOAS ترجمه می کند [10]. مرحله بعد اضافه کردن جهش ها به مدل است. همانطور که در شکل مشاهده می کنید، این در سطح OOAS انجام می شود. استفاده از جهش ها به طور مستقیم برای OOAS، مزیت قابل اجرا بودن برای تمام زبان های پایان جلو است (نه تنها UML). چیزی که ممکن است دیده شود احتمال معرفی “جهش های UML معنایی” به عنوان یک نقطه ضعف است، اما از آنجایی که نگاشت UML به OOAS، ساختار مدل UML را حفظ می کند، اکثریت جهش ها دارای یک نگاشت یک به یک به UML هستند. برای مثال، عملگر جهش غیر فعال کردن یک نقشه فرمان محفوظ به غیر فعال کردن انتقال در مدل UML.
جدول 2 یک مرور کلی از عملگرهای جهش استفاده شده در آزمایش های شرح داده شده در این مقاله ارائه می-کند. بعد از اضافه کردن جهش، OOAS برای کد ماشین اجرا می شود و سرانجام مرحله تولید مورد تست آغاز می شود. مانند تمام ابزارهای تست مدل، MoMuT موارد تست در سطح انتزاع از مدل تحویل می دهد – به عبارت دیگر موارد تست انتزاعی [19]. از این رو قبل از اجرای هر تست در SUT، آنها ممکن است نیاز به واقعی شدن داشته باشند. به عنوان یک فرمت خروجی مورد تست، MoMuT فرمت دبران را استفاده می کند، اما یک نقطه نمودار را نیز می نویسد.

2.1 زبان ورودی: سیستم های عمل شیء گرا
OOAS یک زبان مدل سازی مناسب هستند که دارای معناشناسی رسمی هستند، نسبتاً ساده هستند، و به خوبی برای بیان سیستم انتقال حالت گسسته مناسب هستند. یک مثال از OOAS می تواند در سایت www.momut.org یافت شود. این زبان بر اساس یک تعمیمی از زبان فرمان محفوظ دیکسترا [14] و فرمالیسم سیستم عمل برگشت [5] است. این شبیه به رویداد-B در برخی مفهوم است، اگرچه از نظر دستورات و اقدامات محفوظ کمتر محدود است.

شکل 2 یک مدل نمونه در MoMuT::UML در حال تجزیه را نشان می دهد. هر سیستم عمل ممکن است ویژگی ها، روش ها، اقدامات برچسب شده، و یک بلوک do-od را اعلام کند، که اجرا را تحریک می کند. تا زمانی که یک عمل در بلوک do-od می تواند اجرا شود، بلوک تکرار کردن را ادامه می دهد. MoMuT:UML چندین تعمیم برای سیستم عمل اصلی را استفاده می کند، یکی از اقدامات برچسب شده است. عمل می تواند با “obs” (قابل مشاهده)، “ctr” (قابل کنترل) و یا نه، علامت دار شود، که به این معنی است که آن یک عمل درونی است. توجه کنید که ما بازگشت را در OOAS نمی پذیریم و همچنین حلقه ها را ارائه نمی دهیم (به استثنای بلوک do-od). در عوض، زبان یک عملگر برابر فراهم می کند. انواع داده ها، از جمله فهرست ها و اعداد صحیح، نیاز به اعلام شدن با کران ها دارند. دسترسی مستقیم به ویژگی های اشیاء دیگر ممنوع است. در عوض، روش گیرنده/گذارنده استفاده می شود.
توضیحات می توانند با ترتیبی (“;”)، غیر قطعی (“[]”)، یا اولویت بندی (“//”) عملگرهای ترکیب، ترکیب شوند. نمونه شیء فقط روی ویژگی های مقداردهی اولیه به عنوان MoMuT::UML مجاز است که مجموعه ای از اشیاء مؤثر در زمان اجرا را محاسبه می کند. فراخوانی روش روی شیء (late-binding) پشتیبانی نمی شود. ویژگی های زبان یک راه برای بیان یک سیاست برنامه ریزی ساده: بر اساس سیستم، اشیاء می توانند با توجه به اولویت (“//”) روی اشیاء سیستم های دیگر باشند. ویژگی نهایی زبان، پروژه نامیده می شود. با توجه به جمله var input: t_UserAction: c_userAction(input) که در آن t_UserAction یک شمارنده با مقدار SetPause…StopMeasurment است، سیستم برای اجرای c_userAction با تمام مقادیر ممکن t_UserAction تلاش خواهد کرد. به طور متفاوت، آن یک مخفف است برای گفتن c_userAction(SetPause) [] … [] c_userAction(StopMeasurement).
تفاوت اصلی بین OOAS و زبان های متعارف، راه ترکیب متوالی کارها همراه با دستورات محافظت شده (“نیاز”) است. اگر ما یک جمله نیاز (A): skip end، نیاز(B): skip end داشته باشیم، سیستم ابتدا بررسی می کند که آیا A و B برآورده می شوند در زمان مورد نیاز قبل از اجرای جمله ترکیب شده. این سیستم، به عبارت دیگر، نیاز به محاسبه قابل فعال بودن اعمال دارد. برای مدل انیمیشن این بدان معنی است که نوعی از عقبگرد الزامی است. همچنین، چنانکه همزمانی از طریق انتخاب غیر قطعی بیان می شود، یک موتور جستجو کارآمد مورد نیاز است، در هنگام محاسبه تمام آثار ممکن از طریق OOAS.

با توجه به تمام راه های مختلف ترکیب اعمال در راه های غیرمتوالی، آن جالب توجه است که چگونه بسیاری از سطوح عمقی این ساختارها معمولاً تو در تو است. شکل 3 یک برش از گراف تصمیم گرفته شده از مدل ایستگاه راه آهن بزرگ را نشان می دهد. گره قرمز بلوک اولیه است، که بخشی از زمانبندی است. این جایی است که اجرا شروع می شود. تمام دیگر گره ها، رنگی شده، گره ها نشان دهنده نقاط عقب گرد/تصمیم هستند. گره خاکستری برای ترکیب اولیه، گره نارنجی برای ترکیب غیرقطعی، و گره بنفش برای تصویر (خود حلقه نشان دهنده مقدار ارزش برای امتحان کردن است) استفاده می شود. گره های سفید نشان دهنده یک پایان ، بلوک متوالی است. همانطور که دیده می شود، نگاشت UML معمولاً ساختارهای عقب گرد بسیار عمیق تولید نمی کند. با این حال، این یک نگرش ایستا است و عملگرهایی مانند fold، foral و با جزئیات کامل را به حساب نمی آورد.

3. یک معماری برای جهش کوتاه مدت
در مقایسه با تولید های قبلی MoMuT::UML، تغییرات مهم معماری (a) کامپایل به موقع محلی ، (b) فشرده سازی جهش از طریق طرح، (c) اتخاظ روش های کاهش سفارش جزئی، و (d) نمونه پویا از جهش کوتاه مدت، هستند. به منظور تسهیل در این تغییرات، پایان عقب به طور کامل با تمرکز بر عملکرد بازنویسی می شود.
گام اول نسبت به این هدف، اجرای محلی مدل OOAS است. این جایی است که MoMuT متکی بر چارچوب کامپایلر LLVM [11] برای کامپایل به موقع مدل باشد. از آنجا که OOAS ذاتاً غیر قطعی هستند و نیاز به عقبگرد دارند، اولین نمونه اصلی، کد را برای جستجو عقبگرد در نمایش واسط LLVM (LLVM-IR) از مدل در خط می کند. با این حال، اثبات بسیار ضعیف (منطق حفظ پشته، ناتوانی برای مقایسه حالت های میانی، الگوریتم جستجوی ثابت)، بنابراین ما به رویکرد اجرای رو به جلو روی می آوریم. اجرای رو به جلو به این معنی است که هیچ عقبگردی در داخل مدل وجود ندارد. در عوض، در حین اجرا، مدل کامپایل شده درخواست اجزاء زمانبندی خارجی می کند، که بخشی از زمان اجرا ارائه شده توسط MoMuT است، که جایگزینی برای گرفتن است. این برای یک ردیابی در بلوک do-od در یک زمان انجام می شود. در مورد زمانبندی کردن هدایت موتور اجرا برای برخی از دستور محافظت که غیرفعال است، اجرا لغو شده و زمانبند در مورد نتیجه مطلع می شود.

در نمودار کلاس ساده شده شکل 4، کلاس های FWTraceExecutor و FWDfsScheduler چارچوب اجرای اساسی را می سازند. توجه داشته باشید که اجرای رو به جلو در مورد ما، به عنوان اعمال در داخل یک تکرار بلوک do-od از یک سیستم که توابع بسیار پیچیده ریاضی را محاسبه نمی کند ، کار می کند. بنابراین زمان صرف شده برای محاسبه دوباره نتایج، ناچیز است.
با استفاده از این چارچوب اجرای ساده مبتنی بر ردیابی به عنوان پایه، MoMuT::UML موفق در اضافه کردن یک جستجوگر عمومی (FWExplorerGeneric) شده و یکی که سفارشات جزئی (FWPartialOrderExplorer) را در بالا به حساب می آورد. در واقع برای تولید موارد تست، یک نمونه از کلاس FETcgGraphExplorer می تواند استفاده شود. این کلاس FWPartialOrderExplorer را می-گیرد و منطق برای ایجاد یک نمودار تست را می افزاید. منطقی که استراتژی جهش کوتاه مدت را ایجاد می کند، در FWOtfTaskmaster پیاده سازی می شود. این کلاس دارای مجموعه ای از کارگران (FWOtfWorker) است و وظایف اکتشاف را مدیریت می کند (FWOtfTask). هر کارگر در رشته خود اجرا می شود و یک نمونه از FWOtfExplorer را دارا است، یک زیر کلاس از FWTcgGraphExplorer.
در مجموع، معنی که شامل موتور عقب گرد است، MoMuT::UML شامل حدود 74600 LoC جاوا است، و 59300 LoC کدهای C++. بخش جاوا از کامپایلر OOAS اخیراً تحت BSD منتشر شده و در www.momut.org موجود است. ما در حال حاضر به دنبال گزینه های ساخت منبع C++ در دسترس تحت برخی مجوز تحقیقات دانشگاهی هستیم.

نگاشت کاهش: تجزیه و تحلیل ساده شده کلان داده

MapReduce: Simplified Data Analysis of Big Data

مبتدی (مناسب برای درک مفهوم کلی مطلب)

F1913

1 مدل برنامه نویسی نگاشت کاهش
نگاشت کاهش طوری طراحی شده است که برنامه نویسان بتوانند از آن به جای کاربران تجاری استفاده کنند. این یک مدل برنامه نویسی است، نه یک زبان برنامه نویسی. این مدل برنامه نویسی برای راحتی، عملکرد و کنترل کلان داده ها طراحی شده است. مراحل مربوط به کار نگاشت کاهش را می توان به صورت زیر نشان داد:

شکل : مراحل نگاشت کاهش به منظور پردازش پایگاه داده
برنامه های کاربردی که شامل نمایه سازی و جستجو، تجزیه و تحلیل نمودار، و متن، یادگیری ماشین، تبدیل داده ها است با استفاده از SQL استاندارد DBMSهایی که آسان نیستند را ایجاد می کند. در چنین مناطقی ماهیت رویه نگاشت کاهش به راحتی برای برنامه نویسان ماهر قابل درک است. همچنین این مزیت را هم دارد که توسعه دهندگان مجبور نیستند از اجرای محاسبات موازی استفاده کنند-و به صورت شفاف در سیستم بکار گرفته می شوند. اگرچه نگاشت کاهش برای برنامه نویسان طراحی شده است، با این حال برنامه های غیربرنامه-نویسی می توانند از برنامه های نگاشت کاهش از پیش ساخته شده و توابع کتابخانه ای بهره ببرند [3] برنامه های نگاشت کاهش معمولا در جاوا نوشته می شوند. آنها همچنین می توانند به زبان های دیگر مانند C++، پایتون، روبی و غیره کدگذاری شوند. این برنامه ها ممکن است داده های ذخیره شده در فایل ها و سیستم های پایگاه داده را پردازش کنند. به عنوان مثال در گوگل، نگاشت کاهش در بالای سیستم فایل گوگل (GFS) اجرا می شود.
4. تنظیم مسائل
هادوپ: یاهو! اولین عامل اصلی در سال 2006 شده است

آپاچی هادوپ شامل چندین مولفه است. مواردی که در یک پایگاه داده و پردازش تحلیلی مورد توجه هستند عبارتند از [23]:
سیستم فایل توزیع شده هادوپ (HDFS)، نگاشت کاهش، Pig، Hive، Hbase، اسکوپ

HDFS می تواند یک منبع یا سیستم فایل برای برنامه های نگاشت کاهش باشد. این بهترین درخواست برای فایل های بسیار بزرگ می باشد. استفاده از داده های تکراری برای دسترسی به داده ها در HDFS امکان پذیر است. اما این باعث افزایش ذخیره سازی مورد نیاز برای مقابله با داده ها می شود. چارچوب نگاشت کاهش هادوپ به توزیع نگاشت فرآیند کمک می کند بنابراین داده های HDFS به برنامه محلی نیاز پیدا می کنند. برای پردازش، تمام فایل های خروجی ایجاد می شوند و توسط فرآیند نگاشت و برنامه کاهش بیشتر حرکات و دسترسی به داده های گره داخلی را انجام می شوند. در زمان اجرا، هر دو برنامه نگاشت و کاهش ، داده های انجام شده را به سیستم فایل محلی ارسال می کنند تا بتوانند از سربارگذاری تکرار HDFS جلوگیری کنند. HDFS از خوانندگان متعدد و یک نویسنده (MROW) پشتیبانی می کند. مکانیسم شاخص در HDFS قابل دسترس نیست، از این رو، برای خواندن برنامه ها به منظور اسکن محتوای کامل یک فایل مناسب و بهتر است. در HDFS، محل واقعی داده ها برای برنامه ها و نرم افزار خارجی شفاف است.
معماری HDFS
معماری HDFS شامل گره های ارباب/برده است و گره ارباب گره نام و گره برده گره داده نام دارد. HDFS فقط شامل تک گره نام ارباب و تعداد زیادی گره داده (برده) در میان خوشه و معمولا در هر گره است. HDFS یک فضای نامی (شبیه بسته ای در جاوا) را برای ذخیره داده های کاربران اختصاص می دهد. یک فایل ممکن است به یک یا چند بلوک داده تقسیم شود و این بلوک های داده ممکن است در مجموعه ای از گره های داده نگهداری شوند. گره نام اطلاعات ضروری فراداده را که در مورد نحوه اتصال بلوک ها به یکدیگر است و نحوه ذخیره بلوک ها در گره نام را نشان می دهد. نیازهایی که توسط کلاینت برای خواندن و نوشتن سیستم فایل ساخته شده بودند به صورت مستقیم توسط گره داده پردازش شده بودند، در حالی که عملیات فضای نام مانند باز کردن، بستن و تغییر نام دایرکتوری ها توسط گره های نام انجام می شود. مسئولیت های گره نام و گره-های داده باید مربوط به فعالیت های خاصی مانند ایجاد بلوک داده، تکرار و حذف باشد [20]. معماری HDFS (سیستم فایل توزیع شده هادوپ) در زیر نشان داده شده است [23]:

نمونه ای از HDFS که دارای یک ماشین اختصاصی است فقط گره نام را اجرا می کند. معمولا هر یک از ماشین ها در خوشه یک نمونه از نرم افزار گره داده را اجرا می کنند، و این معماری به شما اجازه می دهد که چندین گره داده را در یک ماشین اجرا کنید. گره نام مربوط به محل ذخیره سازی فراداده و کنترل است، در صورتی که گره نام مربوط به موارد ذکر شده نباشد اطلاعات کاربر هرگز مدیریت نمی شود. گره نام از یک نوع خاص ورود به سیستم، به نام EditLog، و برای پایداری فراداده استفاده می کند.
توسعه هادوپ
اگرچه هادوپ یک پیاده سازی خالص در جاوا است، با این حال ما می توانیم از آن به دو روش مختلف استفاده کنیم. ما می توانیم از یک جریان موجود در API یا از لوله های هادوپ استفاده کنیم. گزینه دوم این امکان را فراهم می کند تا برنامه های هادوپ با استفاده از C++ ایجاد شوند. از این رو، ما روی سوابق تمرکز خواهیم کرد. هدف اصلی طراحی هادوپ فراهم کردن ذخیره سازی و ارتباطات موجود در بسیاری از ماشین های همگن است. برنامه نویسان لینوکس را به عنوان سیستم عامل اولیه خود برای توسعه و آزمایش انتخاب کردند؛ از این رو، اگر علاقمند به کار با هادوپ در ویندوز باشید، لازم است نرم افزار جداگانه ای را برای تقلید محیط پوسته نصب کنید.
هادوپ می تواند به سه روش مختلف بستگی به نحوه توزیع فرآیندها اجرا شود [24]:
• حالت مستقل: این حالت به صورت پیش فرض با هادوپ ارائه می شود. همه این موارد در یک فایل جاوا اجرا می شوند.
• حالت شبه کد توزیع شده: در اینجا، هادوپ برای اجرای بر روی یک ماشین واحد، با انواع دمون های هادوپ به عنوان فرآیندهای مختلف جاوا پیکربندی می شود.
• حالت خوشه ای یا توزیع شده: در اینجا، یک دستگاه در خوشه به عنوان گره نام نامگذاری می شود و دستگاه دیگری به عنوان Job Tracker تعیین می شود. فقط یک گره نام در هر خوشه قرار می گیرد و فضای نام، فایل سیستمی فراداده و کنترل دسترسی را مدیریت می کند. دومین گره نام نیز می تواند به قابلیت تحمل-پذیری خطا دستیابی پیدا کند. بقیه دستگاه های موجود در خوشه هر دو به عنوان گره نام و Task Tracker عمل می کنند. گره داده، داده های سیستم را نگه می دارد؛ و هر گره داده حافظه محلی را ذخیره می کند یا هارددیسک محلی آن را مدیریت می کند. Task Tracker عملیات نگاشت و کاهش را انجام می-دهد.
5. آزمایشات
نوشتن برنامه کاربردی نگاشت کاهش هادوپ
بهترین راه برای درک و کار کردن با هادوپ این است که از طریق فرآیند نوشتن برنامه، نگاشت کاهش هادوپ پیاده سازی شود. ما با یک برنامه ساده نگاشت کاهش کار می کنیم و این برنامه می تواند بسیاری از رشته ها را معکوس کند. مثالی که در زیر ارائه شده است از طریق تعدادی از مراحل ابتدا تمام داده ها را به گره های مختلف تقسیم می کند، عملیات را انجام می دهد تا داده ها معکوس شوند و نتیجه رشته ها را باهم مرتبط می-سازد و سپس نتایج را تولید می کند. این نرم افزار فرصتی را برای بررسی تمام مفاهیم اصلی هادوپ فراهم می کند. ابتدا، ما در مراحل زیر نگاهی به اعلان و وارد کردن بسته می اندازیم. بسته در کلاس رشته ای com.javaworld.mapreduce قرار دارد. این را می توان در دو مجموعه به صورت زیر نشان داد:

اولین مجموعه اعلان ها برای کلاس های استاندارد جاوا است و دومین مجموعه برای پیاده سازی نگاشت کاهش است. بازخوانی کلاس با توسعه org.apache.hadoop.conf.Configured و اجرای رابط org.apache.hadoop.until.Tool آغاز می شود.
نگاشت و کاهش
حالا شما می توانید به پیاده سازی نگاشت کاهش واقعی پرش پیدا کنید. دو کلاس داخلی عبارتند از: نگاشت: شامل عملکردی برای پردازش جفت های کلیدی ورودی به منظور تولید جفت خروجی کلیدی است.

مشارکت ما به تازگی، در برخی از آزمایشات کشف شده است که برنامه های کاربردی ای که از هادوپ استفاده می کرده اند در مقایسه با برنامه های مشابه که از پایگاه داده های موازی استفاده می کرده اند کارایی کمتری دارند. هدف اصلی ما این است که بهینه سازی HDFS و به طور قابل توجهی عملکرد کلی چارچوب نگاشت کاهش را که باعث افزایش کارایی کل برنامه های نگاشت کاهش در هادوپ می شود را فراهم کنیم. ممکن است نتیجه نهایی نگاشت کاهش در مقابل پایگاه داده موازی هیچ تغییری نداشته باشد، با این حال رویکرد جدید هادوپ و نگاشت کاهش مطمئنا امکان مقایسه دقیق تر مدل های برنامه نویسی را فراهم خواهد کرد. اگرچه هادوپ قابلیت-های داخلی را برای نمایش نگاشت و کاهش فراهم می کند، با این حال هیچ ابزار ساخته شده ای برای تنظیم چارچوب، که بتواند موانع عملکرد را بدون انعطاف نگه دارد وجود ندارد. این مقاله تعاملات بین هادوپ و ذخیره سازی را بازیابی می کند. در اینجا، ما بسیاری از موانع عملکرد را که به طور مستقیم به کد برنامه مربوط نمی شود (یا سبک برنامه نویسی نگاشت کاهش)، بلکه به واسط زمانبندی کار و سیستم های توزیع شده تمام برنامه های هادوپ مربوط می شود را توضیح دادیم. HDFS همزمان می تواند به طور قابل توجهی با استفاده از برنامه ورودی/خروجی زمانبندی شود و می تواند حفظ قابلیت حمل و نقل را بهبود ببخشد. بهبودهای بیشتر می توانند با کاهش پراکندگی و حافظه نهان و کاهش هزینه قابل حمل انجام شوند. هادوپ از قابلیت انتقال برای پشتیبانی کاربران و کاهش پیچیدگی نصب و راه اندازی استفاده می کند. این نتایج نمونه ای گسترده از محاسبات موازی است.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

2.2. مسئله ی کوله پشتی
KP یک مسئله ی بهینه سازی ترکیبی است که مچموعه ای از اقلام را مدیریت می کند. هر کدام از این اقلام با یک جرم و مقدار هستند که شماره ی هر قلم را برای شامل شدن در یک مجموعه مشخص می کند به طوریکه وزن کل کمتر یا برابر با محدودیت داده شده است و مقدار کل تا جای ممکن بزرگ است. KP به صورت پیش رو تعریف می شود:
بیشینه کردن ، مشروط که S برابر با مقدار کل کوله پشتی (سایت)؛ i شماره ی قطعه ؛ xi تعداد قطعات i ؛ vi مقدار (تشابه به قاعده ی رهبرِ سایت) قطعه ی i ؛ wi وزن (اندازه ی داده) قطعه ی i؛ W برابر با ظرفیت سایت است.این بهینه سازی با اجازه دادن به هر قطعه (قلم ) برای بیش از یک بار اضافه شدن به سایت ها، می تواند مسئله ی تکرار را مدیریت کند.
مسئله ی کوله پشتی در این مقاله از طریق برنامه نویسی پویای استاندارد برای مسئله ی کوله پشتی 0/1 حل می شود. به ما اجازه دهید تا آرایه ای دو بعدی را با i ردیف و w ستون تعریف کنیم. مقدار کوله پشتی را در زمان لحاظ کردن اقلام با شماره قلم را نشان می دهد و وزن کلی انها بوسیله ی معادله ی 2 محاسبه می شود.

قدم اول محاسبه کردن است، سپس بر مبنای مقادیر محاسبه می گردد. روندی مشابه برای محاسبه ی تکرار می شود. بعد از اتمام محاسبه ی ، مقدار بیشینه در میان همه ی به عنوان پاسخ مسئله انتخاب می شود.
در ان تحقیق، برنامه نویسی پویای استاندارد به کار گار گرفته شده تا KP را حل کند و توزیع قواعد توزیع شده بوسیله ی GNP در هر سایت را اداره نماید. قواعدی که با پوشش داده ی زیاد هستند، رهبرهای هر سایت خواهند بود و کاربردِ KP، تشابه بین قواعد رهبر و قواعد باقی مانده را در نظر می گیرد (که به عنوان مقدار قلم (قاعده) در KP در نظر گرفته می شود) و پوشش قواعد (که به عنوان وزن در KP در نظر گرفته می شود) باید مطابق با ظرفیت های سایت باشد.بنابراین، قواعد مشابه به یک قاعده ی رهبر، اساسا در یک سایت قرار داده می شوند. توضیحات پیاده سازی کاربرد KP در توزیع قاعده به تفصیل در بخش 4.2. قابل دسترسی است.

3. برررسی ادبیات علمی
روش پیشنهاد شده از الگوریتم GNP برای داده کاوی استفاده می کند که در Mabu ارائه شده است و روش ارائه شده برای مسئله ی ظرفیت انباره ی تخصیص قطعه در پایگاه های داده ی توزیع شده ای که در Ozsu and Valduriez نشان داده شده به کار گرفته می شود. این تحقیق شامل پیاده سازی برنامه نویسی شبکه ی ژنتیک (GNP) برای داده کاوی و برنامه نویسی پویای استاندارد می شود تا مسئله ی کوله پشتی (KP) را برای قاعده ای که بر مبنای خوشه بندی است، حل کند. مسئله ی ظرفیت انباره، خوشه بندی پایگاه داده را معرفی می کند و معرفی مفهوم KP برای حل کردنِ مسئله یکی از نکات منحصر به فردِ روش ارائه شده است. علاوه بر این، روش ارائه شده، گزینش تصادفی جزیی ویژگی را در استخراج قواعد فراهم می کند که می تواند الگوهای متداول در پایگاه داده را شناسایی کرده و کیفیت خوشه بندی را بهبود ببخشد. روش ارائه شده با توجه به ویژگی های بالا یک خوشه بندی رکورد خودکار ارائه می کند که قصد دارد تا یک سیستم پشتیبانی تصمیم برای خوشه بندی رکورد در پایگاه های داده باشد.
ادبیات علمی کنونی مرتبط به تخصیص قطعه Rahimi,Parand and Riahi است. این تحقیق یک رویکرد ارائه می کند که به طور همزمان به طور عمودی قطعات داده ایجاد می کند و در سایت قطعات را به سایت های مناسب تخصیص می دهد. الگوریتم انرژی پیوند (BEA) یا اندازه ی همبستگی بهتری به کار گرفته می شود که کیفیت خوشه های ویژگی ایجاد شده را بهبود می بخشد. BEA می تواند از طریق شناسایی اقلام متداول بین رکورد ها در پایگاه داده روابط خوبی بین ویژگی ها یافته شوند. روش پیشنهاد شده مجموعه های الگوی متداول را نیز شناسایی می کند اما برای شناسایی یک قطعه بندی افقی خودکار یا خوشه بندی رکورد است نه برای قطعه بندی عمودی ( همان طور که بوسیله ی این ادبیات علمی ارائه شده).
عنوان خوشه بندی مرتبط کنونی یک یادگیری وزن ویژگی خودکار است که بوسیله ی Saha and Das ارائه شده است. این مقاله نوعی جدید از الگوریتم خوشه بندی حالات k فازی را برای داده ی مطلق با یادگیری وزن ویژگی خودکار، ارائه و بررسی می کند. این روش به طور خودکار با وزن های زیاد ویژگی ها همراه است که در شناسایی الگوهای خوشه بندیِ داده در الگوریت حالات k فازیِ مطلق مفید هستند. روش پیشنهاد شده در این مقاله مجموعه های الگوی متداول برای ویژگی ها (خصوصیات) را نیز شناسایی می کند تا عملکرد خوشه بندی را بهبود ببخشد که در بخش 4.1.3. توضیح داده می شود و ضمنا، روش ارائه شده می تواند مسئله ی ظرفیت انباره را اداره کند که در این ادبیات علمی حل نشده است.
تنظیمات مناسب انقلایبیِ سیستم های یادآوری معنایی خودکار موضوع مرتبط دیگری است که بوسیله ی Cuzzola, Jovanovic, Bagheri, & Gasevic ارائه شده است. این مقاله یک ساختار تنظیم پارامتر (PTA) برای خودکار کردنِ کار تنظیم کردن مقادیر پارامتر ابزار یادگیری معنایی با محاسبات تکاملی ارائه می کند. استفاده از محاسبه ی تکاملی در جهت یافتن تجمیع های مناسبِ ویژگی ها برای حل کردن مسئله و استفاده از گزینش وزن ویژگی، تشابه با روش ارائه شده است. اما مشکل این مقاله (یادگیری معنایی) متفاوت از روش ارائه شده در این مقاله است. مسئله ی هدفی این مقاله یک خوشه بندی رکورد با یک مسئله ی محدودیت ظرفیت انباره ی اضافی است.

4. تجمیع مسئله ی کوله پشتی و GNP
پیاده سازی خوشه بندی رکورد به دو بخش تنظیم می شود: استخراج قاعده ی GNP و توزیع قاعده بر مبنای برنامه نویسی پویای استاندارد برای حل کردن مسئله ی کوله پشتی که در بخش 4.1 و 4.2 توضیح داده می شود. علاوه بر این، تحلیل پیچیدگیِ روند خوشه بندی کل در بخش 4.3 تشریح می شود.

4.1. استخراج قاعده ی GNP
GNP برای استخراج قواعد از پایگاه داده، بوسیله ی تحلیلِ ساختار پایگاه داده به کار گرفته می شود و شامل موارد زیر می شود:
مقدار ویژگی ها: تعداد ویژگی ها در مجموعه ی داده. هر ویژگی به چندین گره تقسیم می شود که وابسته به تنوع و محدوده های مقدار (فاصله ی بین مقدار کمینه تا مقدار بیشینه) آن هستند..
مقدار داده: تعداد رکوردها در مجموعه ی داده
تنوع داده: رکوردهای مختلف تا چه میزان در مجموعه ی داده موجود هستند. اگر همه ی رکوردها در مجموعه ی داده مختلف باشد، تنوع 100% است، اگر نصف این رکوردها در این مجموعه ی داده مختلف باشند، تنوع 50% . است و اگر همه ی رکوردها در مجموعه ی داده یکسان باشند، تنوع برابر با 1 روی ضرب تعداد داده در 100% است. برای مثال، در جدول 4 که در صفحه ی بعد نشان داده خواهد شد، شش نوع داده در مجموع 310 داده وجود دارد پس تنوع برابر است با: .
GNP برای استخراج قواعد از مجموعه داده از طریق تحلیل همه ی رکوردها به کار گرفته می شود. ساختارهای ژنوتیپ و فنوتیپِ GNP به ترتیب در شکل 3 و جدول 1 تشریح می شوند. هر گره در شکل 3 دارای شماره ی گره (1-11) مخصوص به خودش است و در جدول 1، اطلاعات گره برای هر شماره گره تشریح می شود. اندازه ی برنامه وابسته به تعداد گره ها است که روی مقدار قواعد ایجاد شده بوسیله ی برنامه تاثیر می گذارد.
گره داوری در پیاده سازی داده کاوی، یک ویژگی مجموعه داده را ارائه می کند که بوسیله ی Ai ارائه می شود و یک شاخص ویژگی مانند قیمت، سهام و غیره را نشان می کند و Ri شاخص محدوده ی مقدار ویژگی را نشان می دهد. برای مثال، Ai=A نشان دهنده ی ویژگی قیمت است و Ri=1 محدوده ی مقدار [0,50] و Ri=2 محدوده ی [51,80] را نشان می دهد. گره های پردازش، نقطه ی شروعِ بخش گره های داوری را نشان می دهد که از طریق اتصالشان به صورت بخش بخش اجرا می شود. بخش های گره ها که از هر گره پردازش شروع می شوند از طرقی خط نقطه چین a,b,c ارائه می شوند. یک بخش گره جریان می یابد تا زمانی که پشتیبان برای تجمیع بعدی، آستانه را ارضا نمی کند. گره ها با ویژگی هایی که پیش از این در بخش ظاهر شده اند، کنار گذاشته خواهد شد. قواعد کاندید استخراج شده بوسیله ی برنامه ی شکل 3 از مجموعه داده ی جدول 2 در جدول 3 نشان داده می شود. در جدول 3، سه قاعده بوسیله ی بخش گره از هر گره پردازش استخراج می شود.

مبتدی (مناسب برای درک مفهوم کلی مطلب)

F1874

تشخیص مرسوم ژست دست: روش های مبتنی بر سنسور RGB
2.1 تشخیص ژست های پویای دست
تکنیک های مورد استفاده برای HGR پویا را می توان به صورت زیر دسته بندی نمود: الف) HMM [10-23] و سایر روش های آماری [24-31]، ب) ANN [32-34] و سایر روش های مبتنی بر یادگیری [35، 36]، c) [37، 38]، d) روش های مبتنی بر فضای ویژه, تناسب منحنی [39]، و e) برنامه نویسی پویا [40] / انحراف زمان پویا [41، 42] (شکل 3).

2.1.1 HMM و سایر روش های آماری
HMM پراستفاده ترین تکنیک HGR است. HMM یک مدل آماری است که در آن سیستم مدلسازی شده به عنوان یک فرآیند مارکوف با پارامتر های مجهول فرض می شود. HMM, نشان دهنده رفتار آماری توالی نماد قابل مشاهده با استفاده از شبکه ای از حالات پنهان با احتمالات انتقال و انتشار است. HMM را زمانی می توان برای تشخیص الگو استفاده کرد که پارامترهای پنهان با استفاده از داده های قابل مشاهده شناسایی شوند.
روشهای پویای تشخیص ژست مبتنی بر HMM عمدتاً از ویژگیهای زمانی و فضایی تصاویر ورودی استفاده می کنند. Chen و همکاران [14] از توصیفگر فوریه و تحلیل حرکت مبتنی بر جریان اپتیک به ترتیب به منظور مشخص کردن ویژگی های فضایی و زمانی استفاده نمودند. این الگوریتم با استفاده از ردیابی دست در زمان واقعی، شکل دست را از پس زمینه های پیچیده استخراج می کند. شناساگرهای مبتنی بر HMM, بهترین مدل ژست احتمال را برای یک الگوی معین شناسایی می کنند. تغییرات در ژست از یک الگوی مرجع، احتمال این ژست را با مدل کاهش می دهند.
Lee و Kim [10] یک مفهوم مدل آستانه مبتنی بر HMM را برای فیلتر کردن الگوها با احتمال کمتر معرفی کردند. جهت حرکت دست برای نشان دادن توالی های فضایی-زمانی ژست ها استفاده می شود. این روش به طور قابل اعتماد نقطه پایانی یک ژست را تشخیص می دهد و نقطه شروع را با ردیابی به عقب می یابد.
HMM مبتنی بر زنجیره های مارکف همگن است زیرا پویایی سیستم تنها توسط احتمالات گذار مستقل زمان تعیین می شود. Marcel و همکاران [15] یک فرمت HMM، یعنی مدل ورودی / خروجی مخفی مارکوف (IOHMM) را برای HGR پیشنهاد کردند. IOHMM مبتنی بر یک زنجیره غیرهمگن مارکوف است که احتمالات انتقال و انتشار آن به ورودی بستگی دارد. IOHMM یاد می گیرد تا توالی های ورودی، مشاهدات، توالی های خروجی و کلاس های ژست را برای همه مشاهدات با استفاده از یادگیری اختیاری تحت نظارت یاد بگیرد. در مقایسه با HMMها، IOHMM یک رویکرد تبعیض آمیز است زیرا به طور مستقیم احتمالهای خلفی را مدلسازی می کند. مطالعه در [15] محدود به 2 کلاس بود. Just و همکاران [13], این مطالعه را برای شناختن حرکات تک و دوبل دست گسترش دادند و یک مقایسه از HMM و IOHMM ارائه کردند. آزمایشات انجام شده بر روی پایگاه های داده بزرگتر، اعم از 7 تا 16 کلاس ژست، نتیجه گرفتند که برای تعداد زیادی از کلاس ها, HMM عملکرد خوبی نسبت به IOHMM دارد.
ویژگی های موقعیت دست، زاویه و سرعت در [11] برای پیاده سازی HMM در HGR ترکیب می شوند. دست توسط تجزیه و تحلیل رنگ-پوست موقعیت یابی می شود و با اتصال مرکز حرکت ناحیه های دست ردیابی می شود. این مقاله، مطلوبیت سه ویژگی، موقعیت، زاویه و سرعت را مقایسه کردند و نتیجه گرفتند که ویژگی های زاویه ای, موثرترین هستند و دارای قدرت تشخیص بهتر هستند. ویژگی های مکان و سرعت, به ترتیب رتبه دوم و سوم را دارند. یک پیاده سازی HMM مشابه با استفاده از زوایای حرکت در امتداد مسیر مرکز دستی در [16] ارائه شده است.
Ramamoorthy و همکاران توسط ترکیب طرح مشخص سازی زمانی مبتنی بر HMM با یک سیستم تشخیص شکل استاتیک [12], یک سیستم HGR را توسعه دادند. آنها از یک ردگیر خط دستی مبتنی بر فیلتر کالمن استفاده کردند که ویژگی های زمانی ژست را ارائه می کند. اشکال با استفاده از طبقه بند مبتنی بر متمایزکننده خط شناخته می شوند. این توصیفگرهای نمادین ژست ها برای آموزش HMM استفاده می شوند. این سیستم می تواند به طور قابل اطمینان, ژست های دینامیک را به رغم تغییرات حرکت و گسسته در ژست های دست تشخیص دهد. همچنین این الگوریتم توانایی تشخیص نقاط شروع و پایان توالی های ژست را دارد.
الگوریتم های تشخیص ژست پویا از یک طرح نقطه یابی رو به عقب استفاده می کنند که ابتدا نقطه پایان یک ژست را تشخیص می دهد و سپس به سمت نقطه شروع ردیابی می شود. Kim و همکاران [17] یک روش جایگزین، یک طرح نقطه گذاری مستقیم را پیشنهاد کردند که به طور همزمان بخش بندی و تشخیص ژست را اجرا می کند. نقاط شروع و پایان ژست ها توسط عبورهای از صفر احتمال دیفرانسیل سیگنال شناسایی می شوند. مجموعه ای از ویژگی های مبتنی بر تشریح سه بعدی با استفاده از روش نگاشت ارتباطی استخراج می شوند که داده های شکل دو بعدی را به داده های مفصل سه بعدی متصل می کند. ژست ها با یک رای اکثریت با استفاده از HMM تجمعی طبقه بندی می شوند.
Davis و Shah [31] ژست ها را به چهار مرحله متمایز تقسیم نمودند که در یک نظم ثابت اتفاق می افتد و یک مدل ماشین حالت متناهی (FSM) را برای تشخیص توسعه دادند. نشانه زماني حرکت دست استخراج می شود و ژست های دست با استفاده از FSM در [29] مدلسازی می شود. مفهوم انرژی حرکت برای تخمین حرکت غالب از یک توالی تصویر استفاده می شود. Hong و همکاران [30] از موقعیت های دوبعدی مراکز سر و دستان افراد برای توسعه FSM استفاده نمودند. مدل پویای شبکه بیزی در [24] برای تشخیص ژست های جدا شده و پیوسته دست ارائه شده است. ویژگی های استفاده شده عبارتند از کدهای جهت برای حرکت دست، رابطه موضعی بین دو دست و رابطه موقعیتی بین صورت و دست.
Chen و همکاران [25] از یک روش دو مرحله ای تجزیه و تحلیل آماری و نحوی به ترتیب برای تشخیص ژست های دستی استاتیک و پویا پیشنهاد کردند. سطح اول، تجزیه و تحلیل آماری، بر اساس یک الگوریتم یادگیری AdaBoost و ویژگی های Haar-مانند است. سطح دوم، تجزیه و تحلیل نحوی، مبتنی بر یک گرامر تصادفی عاری از زمینه (SCFG) است. ویژگی های Haar-مانند به طور موثر الگوی وضعیت دست را توصیف می کنند و الگوریتم AdaBoost, یک طبقه بند قوی را با ترکیب یک دنباله ای از طبقه بندهای ضعیف ایجاد می کند. موقعیت های شناسایی شده توسط سطح اول به دنباله ای از رشته های ترمینال با توجه به دستور زبان، در مرحله دوم تبدیل می شوند.

2.1.2 ANN و سایر روشهای مبتنی بر یادگیری
Yang و همکاران [32، 33] از یک شبکه عصبی تاخیر زمانی (TDNN) برای یادگیری مسیرهای حرکت دو بعدی استفاده کردند. TDNN, یک شبکه چند لایه تغذیه-مستقیم است که از پنجره های جابجایی بین تمام لایه ها برای نشان دادن روابط زمانی بین وقایع استفاده می کند. طبقه بندی در TDNN, پویا است، زیرا این شبکه, تنها یک پنجره کوچک از الگوی حرکت ورودی را می بیند و پنجره بر روی داده های ورودی لغزش می کند در حالی که شبکه, یک سری تصمیمات موضعی می گیرد. این تصمیمات موضعی به صورت زمانی با یک تصمیم کلی در لایه خروجی یکپارچه می شوند.

بررسی راهبردهای آفلود رایانشی برای بهبود عملکرد برنامه هایی که روی دستگاه های موبایل اجرا می شوند

A survey of computation offloading strategies for performance improvement of applications running on mobile devices

چکیده :
دستگاه های موبایل از دستگاه های ارتباط صوتی ساده به منظور اجرای برنامه های پیشرفته تکامل یافته اند. علی رغم این تکامل، برنامه های اجرا شونده بر روی دستگاه های موبایل به دلیل منابع محدود دارای برخی از مشکلات هستند. محدودیت هایی نظیر عمر باطری محدود، حافظه محدود و قابلیت های پردازشی تولید اثرات نامطلوبی بر روی عملکرد برنامه های اجرا شونده بر روی دستگاه های موبایل می کنند.
آفلودینگ رایانشی به مسئله منابع محدود با انتقال بار کاری محاسبه به سایر سیستم های دارای منابع بهتر رسیدگی می کند. افلودینگ در راستای بهبود و توسعه طول عمر باطری، بهبود ظرفیت حافظه و بهبود عملکرد برنامه کار می کند. در این مقاله ما یک نظر سنجی از راهبرد های افلودینگ رایانشی را با بهبود عملکرد برای برنامه ها انجام می دهیم.. سپس این رویکرد ها از حیث توزیع بار کاری و تصمیمات افلود طبقه بندی می شوند. ما هم چنین تغییرات محیط مبتنی بر افلودینگ رایانشی و نیز طبقه بندی مکانیسم های پارتیشن بندی برنامه پذیرفته شده در بخش های مختلف را توصیف می کنیم. به علاوه، مقایسه پارامتری از چارچوب های خودکار ارایه شده و سپس دامین های برنامه ای ارایه می شود که از افلودینگ رایانش بهره برده و چالش های آینده در مسیر راه افلودینگ محاسباتی بررسی می شود

1- مقدمه
با ظهور فناوری های تلفن هوشمند، دستگاه های موبایل بسیار فراگیر شده اند. این دستگاه ها دیکر تنها برای خدمات ارتباطی استفاده نمی شوند. در عوض، این دستگاه ها قادر به اجرای برنامه ها با ملزومات متنوع هستند. پردازش مورد نیاز توسط این برنامه ها از محاسبات ریاضی ساده توسط ماشین حساب تا سیستم تشخیص صدای پیشرفته متغیر است.
اجرای برنامه های پیشرفته نیازمند دستگاه های موبایل است که دارای منابع قوی است. کمبود این منابع دارای اثرات ناطملوب بر روی کاربرد روز افزون دستگاه های موبایل می باشد. برای مثال، آماره های مربوط به StatCounter نشان می دهد که حدود 30.66 درصد پلتفرم های مورد استفاده برای مرور گر وب، یستم های موبایل(StatCounter 2014) می باشد. در نتیجه، بازار موبایل نقش مهمی در تجارت و رشد فروش ایفا می کند. اگرچه تلاش های زیادی برای استفاده از پردازنده های چند هسته ای با عملکرد بالا در تلفن های هوشمند وجود دارد ، فاصله بین منابع موجود و مورد نیاز افزایش یافته است. در این رابطه، افلودینگ رایانشی یک مکانیسمی است که به ما امکان ایجاد پلی بین فاصله با اجرای محاسبات بر روی سیستم های بزرگ دارای منابع کافی می دهد. این نه تنها موجب می شود تا سیستم های موبایل با منابع محدود به یک دستگاه پیشرفته تبدیل شود، بلکه امکان بهره برداری کامل را از منابع موجود می دهد.
افلودینگ رایانشی یک ایده جدید است که از پارادایم های دارای رایانش توزیعی تکامل حاصل کرده است( دین و همکاران 2013، کومار و لو 2010، سنایی و همکاران 2014، فونتل و همکاران 2013). بهبود عملکرد برنامه با پارتیشن بندی به چندین زیر برنامه حاصل می شود که هر یک از آن ها به پردازنده متفاوتی تخصیص داده شده است. هر پردازنده از حافظه خود استفاده کرده و یا حافظه مشترک با پردازنده دیگر برای انجام رایانش های موازی استفاده می کند. در نتیجه، نتایج به پردازنده کنترل کننده اجرای کلی بازگشت داده می شود.
یک پلتفرم رایانش ابری بر اساس شروع رایانش توزیعی بوده و خدمات رایانشی را از طریق توافق سطح سرویس بر روی یک شبکه بزرک ارایه می دهد. این از پارادایم های رایانشی دیگر متفاوت است زیرا اطمینان در خصوص قابلیت دسترسی سرویس ها به کاربران ارایه می شود. رایانش ابری موبایل اشاره به ارایه خدمات از طریق موبایل به ابر دارد که با منابع محدود همراه هستند( دین و همکاران 2013، کومار و لو 2010، سنایی و همکاران 2014، فونتانا و همکاران 2013، جونتن و همکاران 2012، خان و همکاران 2014ب، برل و همکاران 2010). رایانش برنامه موبایل به سیستم غنی از منابع موسوم به جایگزین افلود می شود. این نوع از افلودینگ رایانشی نه تنها موجب کاهش مسئله منابع محدود می شود بلکه قدرت پردازشی ماشین های پیشرفته را بالا می برد( باربارا و همکاران 2013، او و همکاران 2007، کومار 2013، استانیاران و همکاران 2009).
در این مقاله، ما یگ نظر سنجی جامع از راهبرد های افلود رایانشی موثر بر عملکرد برنامه های اجرا شونده بر روی دستگاه های موبایل را انجام دادیم. اکرچه افلودینک رایانشی با هدف صرفه جویی انرژی برای اجرای برنامه می باشد(لو و همکارا 2013، هانگ و همکاران 2009، ون و همکاران 2012، بادنکو و همکاران 1998، نانریم 2010، نامیگادا و همکاران 2009)، ولی در این مقاله، ما تنها عوامل موثر بر روی عملکرد اجرایی برنامه های اجرا شونده بر روی موبایل را بررسی می کنیم. این نظر سجی و مطالعه شامل کار تحقیقاتی برای افلود رایانشی از حیث ابعاد مختلف از جمله رده بندی، راهبرد ها، الگوی تکامل و برنامه مربوطه می باشد. هم چنین ما به طبقه بندی رویکرد های پارتیشن بندی در بخش های مختلف و مقایسه پارامتری چارچوب های افلودینگ می پردازیم. ما در مورد مسائل اصلی مربوط به افلود رایانشی صحبت کرده و رویکرد هایی را برای حل این مسائل پیشنهاد می کنیم.
ادامه این مقاله به صورت زیر سازمان دهی شده است. بخش 2 به توصیف رده بندی افلودینگ از حیث معیار ها و معماری ها برای اثر بخشی آن می پردازد. تحول فناوری های بی سیم و افلودینگ در بخش 3 بحث شده است. هدف رویکرد افلودینگ بهبود عملکرد در بخش 4 است. طبقه بندی رویکرد های پارتیشن بندی مورد استفاده در رویکرد افلودینگ رایانشی در بخش 5 نشان داده شده است. مقایسه پارامتر محور چارچوب رویکرد افلودینگ در بخش 6 بررسی شده است و این در حالی است که برنامه های ذی نفع شونده از رویکرد افلودینگ در بخش 7 بحث شده است. مسائل اصلی مربوط به اجرای موثر رویکرد افلودینگ در بخش 8 همراه با راه حل ها قبل از نتیجه گیری در بخش 9 می باشد.

Abstract

Handheld mobile devices have evolved from simple voice communication devices to general purpose devices capable of executing complex applications. Despite this evolution, the applications executing on the mobile devices suffer due to their constrained resources. The constraints such as limited battery lifetime, limited storage and processing capabilities produce an adverse impact on the performance of applications executing on the mobile devices. Computation offloading addresses the issue of limited resources by transferring the computation workload to other systems having better resources. It may be oriented towards extending battery lifetime, enhancing storage capacity or improving the performance of an application. In this paper, we perform a survey of the computation offloading strategies correlated with performance improvement for an application. We categorize these approaches in terms of their workload distribution and offloading decisions. We also describe the evolution of the computation offloading based environment as well as a categorization of application partitioning mechanisms adopted in various contributions. Furthermore, we present a parameter-wise comparison of automated frameworks, the application domains that benefit from computation offloading and the future challenges impeding the evolution of computation offloading.

1. Introduction

With the advent of smartphone technologies, the mobile devices have become ubiquitous. These devices are no longer constrained to providing only communication services. Instead, these devices are capable of executing applications with diverse requirements. The processing required by these applications may range from simple mathematical computations performed by a calculator to a very complex voice recognition system. The execution of complex applications requires the mobile devices to possess powerful resources. The scarcity of these resources has adverse effects on the ever-growing usage of the mobile devices. For instance, the statistics according to StatCounter show that about 30.66% of the platforms used for web browsing are the mobile systems (smartphones/tablets) (StatCounter, 2014). Consequently, the mobile market plays a significant role in ecommerce and sales growth. This role is however diminished by the fact that the mobile systems have limited energy and power resources. Although there have been efforts to incorporate high performance multiple core processors in smartphones, the gap between the existing and the required resources continues to grow. In this context, the computation offloading is a mechanism that enables us to bridge the gap by making intensive computations execute on large systems having sufficient resources as required by the application. This not only makes a resource constrained mobile system seem like a high-end powerful machine, but also enables to perfectly utilize the existing resources. The computation offloading is not a novel idea as it has evolved from various paradigms incorporating distributed computing (Dinh et al., 2013; Kumar and Lu, 2010; Sanaei et al., 2014; Fontana et al., 2013). The performance improvement of an application is achieved by partitioning it into several subprograms each of which may be assigned to a different processor for execution. Each processor makes use of its own memory and/or shares the memory with other processors to perform computations in parallel. Subsequently, the results are returned to the processor controlling the overall execution. A cloud computing platform is also based on the intuition of distributed computing and offers the compute services through a Service Level Agreement (SLA) on a large network usually the Internet. It differs from other computing paradigms since an assurance regarding availability of services is provided to the users. The Mobile Cloud Computing (MCC) therefore refers to provision of services through a cloud to mobile devices that are characterized with limited resources (Dinh et al., 2013; Kumar and Lu, 2010; Sanaei et al., 2014; Fontana et al., 2013; Juntunen et al., 2012; Khan et al., 2014b; Berl et al., 2010). The computation of a mobile application may be offloaded to another resource-rich system termed as surrogate. Such kind of computation offloading not only mitigates the issue of limited resources of mobile devices but also enables to harness the processing power of high-end machines that will otherwise be idle (Barbera et al., 2013; Ou et al., 2007; Cui et al., 2013; Sanaei et al., 2012; Miettinen and Hirvisalo, 2009; Kumar et al., 2013; Satyanarayanan et al., 2009). In this paper, we perform a comprehensive survey of the computation offloading strategies impacting the performance of the applications executing on mobile devices. Although the computation offloading has also been aimed at saving energy required for executing an application (Lu et al., 2013; Hong et al., 2009; Wen et al., 2012; Rudenko et al., 1998; Nurminen, 2010; Nimmagadda et al., 2009; Miettinen and Nurminen, 2010; Mayo and Ranganathan, 2004; Sinha and Kulkarni, 2011; Ge et al., 2012), but in this paper, we mainly consider the contributions which impact the execution performance (computation speed) of applications running on mobile devices. The survey encompasses the research work for computation offloading arranged in terms of multiple aspects including the taxonomy, strategies, evolution pattern and relevant application domains. We also present a categorization of partitioning approaches adopted in different contributions and a parameter-wise comparison of main offloading frameworks. We also discuss main issues related to computation offloading and suggest possible approaches to address these issues effectively. The rest of the paper is organized as follows. Section 2 describes the offloading taxonomy in terms of architectures and criteria for its effectiveness. The evolution of offloading and wireless technologies is described in Section 3. The offloading approaches and contributions aimed at performance improvement are surveyed in Section 4. A categorization of partitioning approaches used in computation offloading is given in Section 5. A parameter-wise comparison of the automated computation offloading frameworks is described in Section 6, whereas the applications benefiting from computation offloading are discussed in Section 7. The main issues related to an effective implementation of computation offloading are discussed in Section 8 together with their solutions before concluding at Section 9.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

2. کارهای گذشته
وب سرویس با تغییر در تکنولوژی و تکامل شیوه‌ های صنعت استنتاج شده است. هنگامی که تغییرات رخ می‌دهد، آزمون رگرسیون یک فعالیت مهم و بسیار گران قیمت به منظور حصول اطمینان از ایجاد اختلال توسط این تغییرات است که ویژگی‌های سیستم نرم‌افزار کاربردی وب را بعد از تغییرات بررسی می‌کند. آزمون رگرسیون می‌تواند:
1. براساس کد: تکنیک‌ های بر اساس کد، تغییرات موجود در کد منبع ساخته شده در نرم افزار را مشخص می‌کنند. موارد آزمون بر اساس تغییرات در کد ساخته شده برای نرم افزار، انتخاب شده است. بنابراین، تکنیک ‌های بر اساس کد برای زبان‌های برنامه‌ نویسی مورد استفاده برای توسعه کد منبع بسیار خاص است.
2. براساس مدل: این تکنیک ‌ها موارد آزمون رگرسیون را با نگاه به مدل‌های سیستم ‌های مختلف تولید می‌کنند. بیشتر تکنیک‌ های مبتنی بر مدل بر اساس زبان مدل‌سازی (UML) است.
3. براساس مشخصات: این روش براساس مشخصات و تغییرات در ویژگی‌های ارائه شده توسط مشتری می‌باشد. آزمون رگرسیون انجام می‌شود تا اطمینان حاصل شود که تمام مشخصات عنوان شده توسط مشتری برآورده شده است و سیستم امن است.
روت و همکارانش تحقیقات خود را در وب سرویس ساخته شده در جاوا انجام دادند. آنها یک روش آزمون رگرسیون امن برای این سرویس‌ها پیشنهاد دادند. نرم افزار تحت آزمون برای تحلیل ایستا و پویا از کد تجزیه و تحلیل می‌شود. یک گراف کنترل (CFG ) بر اساس کد جاوا با نام نمودار درون جاوا (JIF) نامیده شده است. پس از آن، JIF برای هر دو کد اصلی و جدید ایجاد می‌شود. یک مقایسه بین JIF و یال‌های بالقوه خطرناک شناسایی می‌شود. در نهایت، موارد آزمون بر اساس یال خطرناک انتخاب می‌شود. آنها اعتبار رویکرد را با یک ابزار شبیه‌ سازی مورد استفاده برای شناسایی یال خطرناک نشان داده‌اند [12].
روت و همکارانش به‌طور کلی کار خود را در وب سرویس‌های خاص جاوا به تمام وب سرویس‌ها گسترش دادند. آنها از یک چارچوب مشابه برای آزمون رگرسیون امن برای سرویس ‌های وب عمومی استفاده کردند. گراف کنترل جریان (CFG ) برای همه‌ی وب سرویس‌های تحت آزمون ایجاد شده است. سپس، یک مقایسه بین CFG برای وب سروی ‌های قدیمی و جدید به ‌منظور برجسته کردن تغییرات در وب سرویس انجام گرفته است. آنها همچنین پیشنهاد به انتشار موارد آزمون[13] همراه با مشخصات WSDL دادند، که می‌تواند در انتخاب موارد آزمون برای رگرسیون مفید واقع شود.
پنتا و همکاران، یک ابزار برای تولید موارد آزمون کد‌گذاری XML برای آزمون رگرسیون پیشنهاد دادند[7]. موارد آزمون به عنوان یک قرارداد بین سیستم و ارائه‌ دهنده‌ی خدمات استفاده شد. برنامه‌های کاربردی بر اساس سرویس‌ها پویایی را به عنوان یک عامل مهم در نظر داشتند. هدف اصلی از روش ارائه شده انجام انتخاب موارد آزمون در طول حالاتی از نرم افزار است که از خدمات استفاده می‌کند.
برای رسیدن به یک روش امن آزمون رگرسیون، برخی از اظهارات در کیفیت سرویس (QoS ) و سناریوها ساخته شد. آنها این تغییرات در مشخصات را در وریکرد خود در نظر نگرفتند. جعبه ابزار برای تجزیه و تحلیل آزمون JUnit استفاده شد و پس از آن آزمون کدگذاری XML انجام شد [7].
در طول این مرحله از پژوهش، همه‌ی تکنیک ‌های تست رگرسیون عمدتا بر اساس کد بودند. تکنیک‌ های تست رگرسیون براساس برای وب سرویس‌ ها پیشنهاد شد که در آن مدل برای شناسایی تغییرات و تاثیر این تغییرات در نرم افزار ایجاد شده است. مدل‌ها برای توصیف رابط سرویس هستند. اتوماتا های با حالت محدود برای رفتار بیرونی به‌کار گرفته شدند. برای ایجاد وابستگی داده‌ها، گراف وابستگی دوبخشی ایجاد شده است. در این روش نمودار و کلاس‌ ها توسط گره نشان داده است. سپس یک الگوریتم برای انتخاب مورد آزمون ارائه شده است [14].
بای و همکارانش بیشتر به تحقیق مشخصات WSDLپرداختند. آنها داده‌های آزمون را بر اساس عملیات مشخص شده در مشخصات وب سرویس WSDL تولید کردند. آنها همچنین به دنباله‌ای از زمان عملیات در وب سرویس توجه کردند. رابط WSDL برای تولید داده‌های تست برای تست مورد تحلیل قرار گرفت. رویکرد آنها در آزمون رگرسیون برای وب سرویس‌ها متمرکز نیست.
مطالعه‌ی دیگری، رویکرد مشخصات WSDL را برای انجام آزمون رگرسیون از برنامه ‌های کاربردی مبتنی بر وب سرویس مورد استفاده قرار داده است. مشخصات WSDL برای انتخاب موارد آزمون برای آزمون رگرسیون مورد استفاده قرار گرفت [8]. مشخصات WSDL XML تجزیه و تحلیل شد و تغییرات نوع داده انتخاب شد. سپس درختی از XML تجزیه شده، تولید شد. درخت برای هر دو وب سرویس اصلی و تغییر یافته تولید شده است. پس‌از‌آن، یک مقایسه بین درختان و موارد آزمون با استفاده از انتخاب‌گر آزمون رگرسیون انجام شده است. این انتخاب‌گر از تجزیه و تحلیل مقدار مرزی برای شناسایی موارد آزمون استفاده می‌کند. آنها یک ابزار خودکار برای حمایت از رویکرد خود ساخته‌اند.
مسعود و نادیم رویکرد خود را به عناصر شامل نوع پورت برای شناسایی تغییرات در مشخصات WSDL توسعه دادند. عنصر نوع پورت شامل عملیات نام، پیام‌ های ورودی و پیام خروجی از خصوصیات WSDL است. یک درخت برای هر دو WSDL اصلی و تغییریافته ایجاد شده است. مقایسه بین درختان به‌منظور انتخاب موارد آزمون در مجموعه آزمون رگرسیون انجام شده است.
رویکرد ما عنصر نوع پورت از مشخصات WSDL [8] را گرفته و سپس یک جدول هش برای هر دو WSDL اصلی و تغییر یافته ایجاد می‌کند. پس ‌از ‌آن، مقایسه ‌ای بین جداول هش، تغییرات در اسامی عملیات برای وب سرویس را نشان می‌دهد. براساس شناسایی تغییرات در عملیات، موارد آزمون برای گنجانده شدن در آزمون رگرسیون انتخاب می‌شود.

3. روش ارائه‌ شده
نرم ‌افزار تست رگرسیون برای تعریف اشکالات غیرعمدی و خطاهایی که ممکن است در کد در نتیجه‌ی اِعمال تغییرات در نرم ‌افزار کاربردی ایجاد شود، استفاده می‌شود. سهولت توسعه‌ی وب سرویس‌ها و وابستگی‌های متقابل بین خدمات و نرم ‌افزار، فشار زیادی بر آزمایش‌کنندگان وب سرویس به ‌منظور حصول اطمینان از قابلیت اعتماد، قوی، مقیاس ‌پذیر و امن بودن وب سرویس‌ها را تحمیل می‌کند. آزمون رگرسیون امن در تضمین کار وب سرویس در طول چرخه‌ی عمر نرم ‌افزار است.