نظرت چیه ؟

مرکز هم فکری و انتقال تجربه

همین الان ثبت نام کن و از ما باش

ثبت نام

توجه : وارد کردن هر دو گزینه ایمیل و موبایل اجباری نیست فقط یک مورد کافی است.

پرسشنامه

کد امنیتی

تغییر

یاد آوری کردن کلمه عبور

چنانچه رمز عبور خود را فراموش کرده اید ایمیل خود را وارد کنید تا اطلاعات حساب کاربری برای شما ارسال شود.

یاد آوری کلمه عبور به وسیله موبایل

یاد آوری کلمه عبور به وسیله ایمیل

تکامل بازیابی ، به صورت مفهومی

عنوان : تکامل بازیابی ، به صورت مفهومی

 

چکیده

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

-11مقدمه :

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

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

1-2ساختار سیستم :

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

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

این مسائل در بخش 6 . 1 بحث خواهد شد.

3. 1 : بلوکها (مانع های ) بازیابی :

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

 

در اینجا این دستور با انواع اشکال 2-1 مطابقت داردو آزمون پذیرش با کنترل عبارت انجام شده است.در ورود به یک بلوک بهبود وضعیت سیستم باید در حال خیره باشد تا اجازه بازیابی خطا به عقب را بدهد یعنی ایجاد یک ایستگاه بازرسی. جایگزین اولیه اجرا می شود و پس از آن آزمون پذیرش ارزیابی می شود و دارای اهمیت ویژه ای برای ارائه یک قضاوت در این کار است. آن آزمون به تصویب رسید در نتیجه به صورت موفقیت آمیز در نظر گرفته شده و بلوک بهبود را می توان خارج کرد با این حال اگر آزمایش با شکست مواجه شود و یا از هرگونه خطا در طول اجرای متناوب شناسایی شود پس از آن یک استثناء مطرح شده و خطا بازیابی می شود. این بازیابی سیستم شامل آنچه در ورودی بود انجام شد. پس از بهبود ، جایگزین بعدی اجرا می شود و پس از آزمون پذیرش دوباره اعمال می شود. این ترتیب ادامه می یابد تا دو آزمون تصویب شده یا همه به تفاوت در پذیرش شکست خورده باشند.اگر تمام تناوب یا شکست امتحان شود یا در نتیجه یک استثنا اتفاق بیافتد شکست در محیط بلوک بازیابی می شود. از آنجایی که بلوک های بهبود را می توان به صورت تو در تو در نظر گرفت و سپس با بالا بردن آن ها مانند یک استثنا از یک بلوک بازیابی داخلی را می توان بهبود داد. بهره برداری از بلوک بهبوددر شکل 1-3 نشان داده شده است. بدیهی است ساختار زبانی برای بلوک بهبود نیاز به یک ساز و کار مناسب برای ارائه به صورت بازیابی خطای خود کار دارد. نخستین شرایط بازیابی توسط راندل طراحی شد که شرح آن در این مقاله برای اولین بار بر روی بلوک هی بازیابی (Hor74) گنجانده شده است. هر چند این طرح بعدا در ((and76 جایگزین شد این مقاله همچنین شامل روش بازیابی است که ساز و کار پیچیده ای نداشته و به عنوان ابزاری برای گسترش طرح ذخیره سازی و بازیابی اطلاعات برای مقابله با انواع داده ها توسط برنامه نویس پیشنهاد شده است. این بخش از مقاله بدون شک می تواند بسیار واضح تر باشد در صورتی که ایده ها شی گرا بوده که در بخش 1-7 به اندازه کافی در مورد آن بحث خواهیم کرد.موفقیت کلی بلوک های بازیابی تا حد زیادی در اثر بخشی مکانیزم های تشخیص خطا استوار بوده اما نه منحصرا در آزمون پذیرش استفاده می شود. آزمون پذیرش باید ساده باشد در غیر این صورت شانس مهم است که آن به خودی خود حاوی گسل های طراحی باشد. و موفق به تشخیص برقی اشتباهات باشد.علاوه بر این آزمون در زمان اجرا می تواند یک فرایند را غیر قابل قبول معرفی کند که ان کار بسیار پیچیده ای است. توسعه ساده و آزمون پذیرش موثر می تواند یک کار دشوار بوده و نیاز به توجه به مشخصات فنی واقعی دارد. در واقع آزمون پذیرش در یک بلوک بازیابی باید به عنوان آخرین خط از تشخیص خطاها و نه تنها وسیله تشخیص خطا در نظر گرفته شود. انتظار می رود که از آن اظهارات اجرایی در تناوب زمان توسط سخت افزار تقویت خواهدشد. به طور کلی هر گونه استثنای مطرح شده در طول اجرای متناوب منجر به شکست آزمون می شود. در صورتی که جایگزین نهایی شکست به عنوان مثال با آزمون پذیرش عبور نباشداین یک شکست کل را تشکیل می دهدکه ماژول شامل بلوک بهبود است. به عبارت دیگر هر یک باید جایگزین جزء خطا دیده باشد روش مطرح شده توسط زمان اجرا در تناوب و یا توسط مکانیزم های سخت افزای خطا در تشخیص ممکن است توسط خود قابلیت تحمل خطا درمان شود. با وجود استفاده از قابلیت تحمل خطا این جایگزینی قادر به ارائه خدمات درخواست شده می باشد. جزء کنترل ممکن است یک فراخوانی را پس از جایگزینی انجام دهد. به طور کلی همانطور که در (Me177) توصیف شده است بازیابی خطا را می توان بیشتر در بلوک بهبود گنجانده شده است. درواقع یک مکانیزم ترمیم خطا می تواند جهت پیاده سازی بازیابی خطا را پشتیبانی کند. برای مثال یک برنامه در زمان واقعی که غیر قابل بازیابی است در ارتباط با یک بلوک بهبود بوده و قادر به بازیابی همراه برنامه ها می باشد. در این مورد بهبود سیستم به حالت سازگار بوده و با ارسال یک پیام اطلاع رسانی آن را نادیده گرفته و خروجی برنامه های قبلی را کمک می کند. در مقاله اول در مورد بلوک های بازیابی (nor74) هورنینگ و همکاران فهرست چهار شرط شکست را برای یک جایگزین ارائه نمودند

الف) شکست آزمون پذیرش

ب)تشخیص خطای ضمنی

د) سابقه شکست

با وجودی که این مکانیزم برای پیاده سازی تشخیص زمان مورد بحث نیست تعریف اصلی بلوک های بهبود را این موضوع پوشش می دهد. پیاده سازی چند تایمر نگهبان برای بلوک های بازیابی توصیف شده است فاصله را می توان به عنوان یک نحوی در ساختار بلوک بازیابی ارائه داد. همانطور که با بخش else error ، بخش time out اجازه می دهد تا الگوریتم برای رسیدن به هدف خود یک شکل از بهبود را نشان دهد. اگرچه هر یک از تناوب ها در یک بلوک بهبود تلاشی را برای برآوردن آزمون انجام می دهد لذا لزومی ندارد که همه آنها به همان نتایج برسند. تنها محدودیت این است که نتایج باید قابل قبول باشد که توسط آزمون تعیین می شود. بنابر این در حالی که جایگزینی های اولیه باید در راستای تلاش برای تولید نتیجه مورد نظر است تناوب بیشتر ممکن است خدمات را تخریب کند. این امر به ویژه در سیستم های واقعی مفید است زیرا ممکن است آنها زمان کافی برای جایگزینی کاملا کار برای زمانی که یک خطا متوجه آنها است اجرا شود. تحت این شرایط نقش بلوک بهبود به سادگی برای شناسایی و بازیابی خطاها با نادیده گرفتن این عملیات که در آن گسل آشکار می شود است. این تا حدودی شبیه به ارزیابی خطا است که جلوه ای از یک گسل می باشد.اما تفاوت مهم این است که بهبود تنها می تواند خطاهای قابل پیش بینی را از وضعیت سیستم را حذف کند در حالی که چنین بهبودی هنوز می تواند خطاهای غیر قابل پیش بینی ناشی از طراحی های گسل را بیابد. تنها محدودیت این است که خطاهای این مکانیزم واقعی نیست. تنها جایگزین اولیه بلوک بهبود اجرای آن است. با این حال این می تواند مشکل ایجاد کند که باید به تناوب داده های بین تماس ها را حفظ کند. در غیر اینصورت ماژول می تواند تبدیل به تضاد با یکدیگر شده و همه آنها در زمان فرا خوانی بلوک بازیابی اجرا شوند. مشکل زمانی آشکارتر می شود که یک تلاش برای طراحی یک جایگزین به عنوان یک شی است. هیچ تضمینی وجود ندارد که به درستی اصلاح شده است. برخلاف تحمل به اختلال در عملکرد سخت افزار تحمل خطای نرم افزار نمی تواند کاملا توسط برنامه نویسی های شفاف ساخته شود. از جمله صرفه جویی و بازگرداندن حالت سیستم که می تواند به صورت خودکار و شفاف ساخته شود. برنامه نویس مایل به استفاده از نرم افزاری است که تحمل خطای آن بالا باشد. بنا بر این مجموعه ای از ویژگیهای خاص زبانی برای ترکیب افزونگی نرم افزار در برنامه وجود دارد. نکته کلیدی در اینجا این است که تلاش برای نگه داشتن فرصت ساده طبیعی و کم است. این امر در بخش 1-7 بحث شده است.

1-4 پیاده سازی های اولیه و آزمایشی :

اولین پیاده سازی بلوک های بهبودی تعریف و شبیه سازی مجموعه دستور العمل ها و ذخیره یک ترکیب بازیابی است.

برنامه های تست بر روی یک کامپیوتر اجرا شده اند و یک کامپیوتر اجرا شده اند در یک کامپیوتر جداگانه برای ارائه اطلاعات و پذیرش و بررسی خروجی این برنامه ها مورد استفاده قرار گرفته است. این کامپیوتر دوم نیز شاملامکاناتی است که آزمایشگران می توانند تغییرات دلخواه را انجام دهند. آخری بازدید این پروژه به طور معمول برای استفاده از این امکانات به منظور تلاش برای ایجاد یک برنامه بلوک بهبود به چالش کشیده شد. یکی دیگر از سیستم های آزمایشی این بود که در آن بلوک بهبود براساس زبان پاسکال توصیف شده بود. بر این اساس گسترش در چند برنامه تجربی برخی از اندازه گیری های عملکرد را برای بلوک بهبود گزارش داده بود که به طور کلی حمایت از اینکه بلوک بهبود هیچ زمان اجرا و فضای بازیابی اطلاعات یک فشار جدی را تحمیل نمی کند. رای برنامه های نمونه زمان اجرا در بازه زمانی %11-1 در T1 بوده است. یعنی زمان اجرای برنامه بدون هیچگونه امکانات و تجهیزات ارزیابی هیچ خطایی شناسایی نشده بود مکانیزم بهبود ایده آل باید بخش جدایی ناپذیر از یک کامپیوتر را تشکیل دهد. این عدم امکان برای سخت افزار وجود دارد کار اصلی در نیوکاسل در اجرای طرح بلوک بهبود بوده که در طراحی و ساخت و ساز سخت افزار بهبود برای خانواده 11- Pαp بود. این دستگاه بین cpu  و کارت حافظه بدون نیاز به تغییرات سخت افزار قرار داده شده بود و به طور خودکار محتویات حافظه را که در مورد نوشته های مورد نیاز قبل از ذخیره سازی بود را تعیین می کرد. به منظور به حداقل رساندن هزینه های تحمیلشده بر میزبان سخت افزار ویژه ای برای فعال کردن همزمان بازیابی و سیستم میزبان طراحی شده است. ماهیت بحث انگیز نرم افزار تحمل خطا شواهد بالقوه ای را در سیستم های واقعی سب شد. همانطور که در بخش 2-4 در فصل دو دیده شد در سالهای 1981 تا 1984 یک پروژه بزرگ به نام تام اندرسون جهت اعمال ،فرمت بازیابی بلوک از یک سیستم فرماندهی و کنترل نیروی دریایی متشکل از 8000 خط برنامه نویسی انجام شد. توسعه کار عملی این پروژه شامل طراحی و پیاده سازی یک ماشین مجازی بود که مانع بهبود پشتیبانی همراه با پسوند برنامه کرال اجازه می دهد تا برنامه های کاربردی نرم افزار تحمل خطا در این زبان برنامهنویسی در سطح بالایی باشد. برای حفظ واقع گرایی سیستم توسط برنامه نویسان با تجربه بر اساس قوانین رسمی برای پروژه های نرم افزاری مربوط به دفاع ساخته شد. این سیستم نشان داد که پوشش شکست بیش از 70% بدست آمده است. هزینه مکمل در حال توسعه نرم افزار با قابلیت تحمل خطا در 60% قرار داده شده است. 33% حجم سیستم با کدهای اضافی و 35% حافظه شامل داده های اضافی بوده و 40% زمان اجرا اضافه اندازه گیری شده است. بنابر این به این نتیجه رسیدند که با استفاده از نرم افزار تحمل خطا بهبود قابل توجه و ارزشمندی در قابلیت اطمینان را می توان در هزینه های قابل قبول بدست آورد را منجر شد. تحقیققاتی در کالج نظامی سلطنتی پس از آن به منظور طراحی یک نشان دهنده مول در توابع ارائه شده در ترافیکهوایی لندن طراحی شد و نتایج خوبی را ارائه داد و کاربرد  عمومی از روش بلوک بازیابی را تقویت کرد.

5-1 توسعه و کاربرد بلوک های بازیابی پایه ای :

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

1-5-1 :

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

1-5-2 : اجماع بازیابی بلوک :

اجماع بلوک بهبود جهت تلاش برای ترکیب تکنیک های مورد استفاده در بلوک بهبود و نسخه برنامه نویسی است ادعا شده است که روش CRB اهمیت آزمون پذیرش مورد استفاده در بلوک های بهبود را کاهش می دهد و قادر است که مسئولیت رسیدگی به آن را داشته باشد چرا که خروجی در CRB به چند صورت وجود دارد. نیاز به طراحی و پیاده سازی انواع الگوریتم در جهت خدمت به کار گرفته شده است. تمام مدل ها در حال اجرا بوده و نتایج آنها دیده می شود. اگر دو جفت نتیجه یکسان را نشان بدهند نتیجه را به عنوان خروجی می توان استفاده کرد. اگر هیچ جفتی را نتوان یافت نتایج حاصل از این نوع با بالاترین رتبه آزمون پذیرش خواهد شد. اگر این شکست پس از آن انتخاب شود این تا تمام مدل ها آزمون شود ادامه خواهد یافت مدل قابلیت های توسعه یافته برای بلوک هی بازیابی ، برنامه نویسی و CRB است در مقایسه CRB نشان داده است که نسبت به دو جفت دیگر می باشد. با این حال CRB به طور عمده بر این اساس است که هیچ خطای رایجی بین مدلها وجود ندارد. البته این مورد به عنوان آزمایشی (KNj85) و (Sco84) نشان داده شده است. به طور خاصی می توان گفت اگر یک جفت منطبق یافت شود هیچ نشانه ای در نتیجه آزمون پذیرش وجود ندارد بنابر این یک ارتباط شکست در دو گونه می تواند یک خروجی اشتباه داده و به شکست فاجعه بار منجر شود.

1-5-3-سعی دوباره بلوک با تنوع داده ها :

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

1-5-4 خود پیکر بندی بهینه برنامه نویسی :

برنامه نویسی بهینه و خود پیکر بندی آن توسط ( Bon93) و (xu93) یکی دیگر از تلاشها برای ترکیب برخی تکنیک های مورد استفاده در RB و NVPبه منظور افزایش بهره وری از نرم افزار بوده و برای از بردن برخی از انعطاف پذیری ها می باشد این طرح سازماندهی شده جهت اجرای نرم افزار به صورت پویا است. بنابراین به عنوان نتایج قابل قبول با تلاش نسبتا کوچک و با استفاده بهینه از منابع در دسترس است. کنترل را می توان با توجه به سطح تولرنس پارامتر  گسل را می توان با توجه به سطح ، کنترل کرد. از آنجا که رفتار بسیار پویا می تواند پیچیدگی کنترل و نظارت را داشته باشد یک روش برای نمونه هی مختلف با یک فرایند ساده ابداع شده است. افزایش بهره وری می تواند محدود به زمانی باشد که سیستم برای حمایت برنامه خاصی را در نظر گرفته باشد. شاید مناسب تر این باشد که محیط نرم افزار پیچیده و بسیار متغیر باشد.

1-5-5- برنامه های دیگر:

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

1-6 بازیابی سیستم های همزمان :

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

1-6-1 مکالمات :

 هنگامی که یک سیستم از فرایندهای همکاری بلوک های بهبود استفاده می کند هر فرایند جهت ایجاد و حذف پست های بازرسی و همچنین نیاز به بازگرداندن به قبل تامین شد. اثر مهره های بازی دومینو عملیات بازیابی و ارتباطات به صورت هماهنگ انجام نشدو پس از آن این فرایند به دو صورت عقب گرد در حالت آبشاری منجر به برگشت تمام فرایندها گشت. این باعث از دست رفتن کل محاسبه قبل از تشخیص خطا می شود شکل 1-4 اثر مهره های بازی دو مینو را با دو فرایند برقراری ارتباط نشان می دهد. طرح گفتگو در نظر مایکل از رویکرد های اساسی در طراحی ساختار برنامه جهت تحمل خطاست. این برنامه یک ابزار هماهنگ بلوک بهبود برایجلوگیری از اثر دومینو است. شکل 1-5 یک مثال را که در آن سه مرحله از یک گفتگو را نشان می دهد و پروسه های p1 و p2در صحبت های تو در تو با هم در ارتباط می باشد. ارتباطات تنها می تواند بین فرایندهایی که در گفتگو شامل 1- ورود به یک مکالمه در یک فرایند و ایجاد پست بازرسی 2- اگر یک خطا توسط هر فرایند تشخیص داده شود سپس تمام فرایند های شکست کننده باید به پست های بازرسی خود برگردند 3- پس از ترمیم تمام مراحل استفاده شده تناوب بعدی خود را آغاز می کند 4- تمام مراحل گفتگو با هم می باشد. در واقع این تمایز اصطلاح بین منطقه برقراری ارتباط سستم ها و مبتنی بر شی است. تحقیقات قابل توجهی در رابطه با موضوع بازیابی خطای همزمان از جمله پیشرفت در مطالعه و پیاده سازی های مختلف انجام شده است. حداقل دو دسته از روشها برای جلوگیری از اثر دومینو وجود دارد.

1-هماهنگی با استفاده از برنامه ها

2-هماهنگی با استفاده از دستگاه

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

1-6-2 : ضمیمه ها و پیاده سازی گفتگو :

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

1-6-3- مشکلات عملی و راه حل های ممکن :

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

1-7 پشتیبانی زبان شناختی برای تحمل خطای نرم افزار به عنوان یک نگرانی در موضوعات کادر ما است از طراحی نرم افزار سیستم های تحمل پذیر خطا برای تبدیل شدن به طور معمول استفاده شد. یکی از مسائل مهم این است که باید این مشکل حل شده و به منظور توسعه قدم هایی برداشته شود.

1-7-1- نماد گذاری طراحی و محیط :

Lio92 پیشنهاد نمادی برای طراحی یک کلاس گسترده ای از تحمل خطا را در ساختار نرم افزاری ارائه نمود که به طور عمده ارائه کلیات و انعطاف پذیری را نشان می دهد. نشان دا که زبان BSM برای بیان ساختار معمولی نرم افزار مانند بلوک های بازیابی می باشد پیشنهاد شد که طرح تحمل خطا شامل سه بخش باشد 1- برنامه های نرم افزاری 2- RMP و 3- هسته. برنامه نویس باید انواع نرم افزار و آزمون اعتبار سنجی را تعریف کرده و نشان دهد که بخشی از برنامه در تحمل خطا با RMP در گیر است. اجرای روش RMP ممکن است هزینه ها را اضافی در قالب سوئیچ بافت فشرده و تماس های هسته را متحمل شود. با این حال در مقایسه با زبان ومحیط های بحث شده در بالا کار اصلی ما تا حد زیادی با موضوع در حال حاضر بر اساس برنامه های شی گرا می باشد.

1-7-2 تحمل خطای نرم افزار پیاده سازی در C++ :

فرمت های اخیر از C++  شامل کلاسهای عمومی توابع دیگر بوده که ممکن می سازد که اجرای بازیابی خطا درC++ به صورت اجزای قابل استفاده مجدد باشد. به طور کلی امکانات نشان می دهد که ارائه یک ابزار مناسب برای دستیابی به سطوح بالایی از استفاده مجدد نیاز است. ماهمچنین مجموعه ای از کلاس پیش تعریف شده C++را جهت حمایت از یک چهار چوب از پیش تعریف شده C++ حمایت از چهار چوببرای تحمل خطای نرم افزار به طور مستقیم در یک مدل انتزاعی بر اساس شکل 1-2 نشان دادیم. پایبندی به این کنوانسیون به صورت خودکار باعث اجرای نسخه مشخص شده است اگر چه این روش از پیش پردازنده می تواند کاملا عملی باشد اما دارای معایبی نیز است به طور خاص زبان ارائه شده به برنامه نویسان نرم افزار غیر استاندارد در شرایطی برای تولید برنامه توسط پیش پردازنده است.اما در حال توسعه یک زبان جدید پشتیبانی در زمان اجرا به فعال کردن اجرای مختلف تحمل خطا در نرم افزار می تواند این کار را از جریان اصلی توسعه زبان برنامه نویسی کاهش داده و به این ترتیب در رسیدن به پذیرش گسترده ای حرکت کند.

1-7-3 بازتاب و انعکاس زبان :

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

1-8 نتیجه گیری :

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


نظر دهی

برای نظر دهی باید وارد سایت شوید. با تشکر