نظرت چیه ؟

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

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

ثبت نام

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

پرسشنامه

کد امنیتی

تغییر

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

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

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

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

نرم افزار تحمل خطا در سیستم عامل های کامپیوتری:

نرم افزار تحمل خطا در سیستم عامل های کامپیوتری:

 

تحمل خطا در سیستم در این فصل تجزیه وتحلیل برای 3 سیستم عملیاتی VA*IVMS و BM/MVS و GUARDIAN می باشد. یزاساس اندازه گیری این سیستم ویزگی های اساسی  خطا در نرم افزار بررسی شده است. تحمل خطا در سیستم عامل ناشی از استفاده از بهبود می باشد. دو سطح از مدل های توسعه یافته به تجزیه وتحلیل خطا و بازیابی فرایندها در داخل سیستم یک سیستم عامل را در میان چندین نمونه از سیستم عامل های در حال اجرا در یک محیط توزیع شده است. ایناندازه گیری ها نشان می دهد که استفاده از جفت فرایند در سیستم ها  که در اصل برای تحمل خرابیهای سخت افزاری در نظرگرفته شده است. اجازه می دهد تا سیستم در حدود 70% از نقص در نرم افزار که به شکست پردازنده منجر می شود. را تحمل کند. اتصال  ضعیفی بین پردازنده ها به دلیل عدم پشتیبان گیری متفاوت از اجزا اصلی دلیل عمده برای اجرای نرم افزار تحمل خطا است. سیستم های IBM/MV تقریبا دو برابر زمانی روال بهبود را طی می کنند و در   مقایسه با مواردی که هیچ روال بهبودی ندارند در دسترس هستند. با این حال حتی زمانی که  که بهبود ارائه نشده است تقریاب با احتمال 50% نارسایی در سیستم وجود دارد.

1-11 مقدمه:

پژوهش ارائه شده در این فصل  از مطالعات قبلی برروی سیستم های tan94 و Lee93a و Lee 92 و Hsu87  انجام شده است. در این فصل داده های تجزیه و تحلیل قابلیت اعتماد و اطمینان را جهت تحمل در 3 سیستم عامل حرفه ای نشان داده است.

1-تحمل خطا در سیستم عامل کواردیان

2-سیستم توزیع VA/VMS

3-سیستم IBM/MVS

مطالعه این سه سیستم عامل جالب است. زیرا انها به طور گسترده ای استفاده شده و نشان دهنده تنوع در این زمینه است. این سه سیستم عامل اطلاعات سطح بالایی را در تحمل خطای نرم افزار را تحمل می کند. داده های MVS اطلاعات سطح پایینی را از بازیابی خطا است. مشاهده بصری ما از سیستم  گواردیان و MVS یک تنوع از ویژگی های تحمل خطای نرم افزار است. در حالی که VMS صریح و روشن تر تحمل خطا را دارد. اگرچه سیستم عامل به صورت نرم افزاری ضروری است کار کمی در رابطه با مدل سازی و ارزیابی از تحمل خطا از سیست معامل انجام می شود. عمده نرم افزار ها برای تحمل خطا در تحمل طراحی تکیه می کند. با این حال این روش ها معمولا غیرقابل اجرا در سیستم عامل های بزرگ به دلیل هزینه های بالا می باشد در این فصل  نشان داده می شود که چگونه تجزیه وتحلیل  تحمل خطا در سیستم های نرم افزاری واقعی با طرح های مختلف را داده و می تواند در اندازه گیری واقعی به کار رود. در این فصل اطلاعاتی را از چگونگی تحمل خطای نرم افزار در سیستم عامل و چگونگی تکنیک های ان برای تحمل خطا را فراهم می کند. آن را نیز از طراحی مسائل مرتبط در بهبود تحمل خطای نرم افزار در سیستم عامل را نشان می دهد. تجزیه وتحلیل انجام شده نشان می دهد که چگونه روش های ریاضی را می توان برای تجزیه وتحلیل تحمل خطا در سیستم عامل ها استفاده کرد. در حالت ایده آل ما دوست داریم برای اندازه گیری سیستم های مختلف تحت شرایط یکسان اقدام کنیم. طبق مقررات امنیتی با این حال تفاوت در معماری سیستم عامل،شرایط ابزار دقیق،دوره های اندازه گیری و محیط های عملیاتی برای این شرایط ایده آل عملا غیرممکن است. از این رو یک مقایسه مستقیم و دقیق بین سیستم های نامناسب است. این است که برای نشان دادن تکنیک های مدلسازی و ارزیابی با استفاده از اندازه گیری در سیستم های  مختلف اقداماتی شده است. همچنین این سیستم عامل های بالغ که آهسته در حال تغییر بوده اند قابلیت های  مشترک قابل توجهی دارند. بنابراین برای نتایج مهم می توان برخی از مقایسه های سطح بالا که به نوع و ماهیت مسایل مربوط می شود را ارائه می کند. موضوعات قابل بحث عبارتند از 1:بررسی ویژگی های اساسی خط مانند گسل های نرم افزاری و نمایش خطا(TTE) و زمان بازیابی (TTR) و همبستگی خطا

2: ارزیابی تحمل خطا در سیستم عامل های ناشی از استفاده از جفت روند و روال بازیابی

3:مدل سازی طح پایین تشخیص خطا در سیستم عامل با استفاده از داده های (IBM/MVS)

4:مدل سازی سطح بالا و ارزیابی از دست دادن کار در یک محیط توزیع شده در گواردیان و VAX/MVS در بخش بعد تحقیقات مرتبط را معرفی می کنیم. بخش 3-11 سیستم های اندازه گیری را توضیح می دهد. در بخش 4-11 به بررسی گسل نرم افزاری و نمایش خطا و شکست در ارتباط را نشان می دهد. بخش 5-11 تحمل خطا در عملیات سیستمها بررسی می شود. بخش 6-11 ایجاد مدل سطحی برای بررسی نرم افزار تحمل خطا و انجام تجزیه و تحلیل نرم افزار در راستای قابلیت اعتماد  واطمینان بوده و بخش 7-11 منابع تحقیقاتی را ارائه نموده است.

2-11 تحقیقات مرتبط:

خطاهای نرم افزاری توسط محققان در زمینه مهندسی نرم افزار مورد مطالعه قرار گرفته است. داده های نرم افزاری سیستم عامل DOS در مرحله آزمایش جمع آوری شده است و استفاده شده است. تجزیه و تحلیل گسترده ای از نرم افزار توسعه یافته و انواع عوامل محیطی در ان استفاده شده است. یک روش به نام طبقه بندی نقص متعامد به استفاده از نقص های نرم افزاری به ارائه بازخورد در فرایند توسعه پرداخته است. این مطالعات تلاش برای تنظیم فرایند توسعه نرک افزار و تجزیه وتحلیل خطا بوده است . مدل سازی قابلیت اطمینان نرم افزرار را به طور گسترده مورد مطالعه قرار داده و تعداد زیادی از مدل ها پیش بینی شده است. با این حال مدل سازی  و ارزیابی سیستم های نرم افزاری با قابلیت تحمل خطا به خوبی درک نشده است. اگرچه محققان زیادی در زمینه مدل های تحلیل نرم افزار تحمل خطا فراهم آورده اند. یک مدل تقریبی به دلیل طراحی گسل مشتق شده است. این مدل همچنین برای ارزایبی سیستم های نرم افزار با قابلیت  تحمل خطا مورد استفاده قرار گرفت . دراین مدل ها قابلیت مختلفی برای ارزیابی 3 روش نرم افزار تحمل خطا استفاده شد/ به تازگی مدل سازی اعتماد و اطمینان بیشتر و ارزیابی از دو تحمل خطای نرم افزار با روش بازیابی بلوک و برنامه نویسی ارائه شده است. تجزیه و تحلیل مبتنی براندازه گیری اعتماد و اطمینان از نرم افزار عملیاتی در طول 15 سال گذشته تبدیل شده است. مطالعه اولیه یک مدل وابسته به حجم کار به پیش بینی خطاهای نرم افزاری براساس  اندازه گیری یمک سیستم ارائه شده است.  یک مدل از خرابی و بهبود سیستم عامل MVS در حال اجرا برروی یک دستگاه بوده و این موضوع از خطاهای مربوط به سخت افزار و نرم افزار است. تجزیه و تحلیل اخیر از اطلاعات سیستم عامل IBM نقص نرم افزار و تاثیر آن در سیستم را بررسی کرده اند . بحث در مورد مسائل مربوط به قابلیت اطمینان نرم افزار در زمینه سیستم از جمله اثر سخت افزار و مدیریت فعالیت ها در قابلیت اطمینان نرم افزار و مدل شکست ارائه شد. روش ها و پیشرفت در تجزیه و تحلیل تجربی از کامپیوتر در طی 15 سال گذشته بررسی شد.

3-11:اندازه گیری:

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

1-3-11: سیستم عامل تاندم-گواردیوم

سیستم تاندوم-گواردیوم یک سیستم چندپیامی  بوده که برای پردازش معامله ساخته شده است. در دسترس بودن باالا از طریق تحمل یک شکست به دست می آید. عملکرد سیستم حیاتی بوده و یا بر درخواست کاربر برروی دو پردازنده به عنوان فرایند اصلی و پشتیبان گیری می باشد. به طور معمول تنها روند اولیه را فراهم می کند. در این ایست های بازرسی نسخه پشتیبان تهیه شده به طوری که بتواند تابع را در شکست اولیه شناسایی کند. خرابی نرم افزارها وقتی رخ می دهد که نرم افزار سیستم گوردیام تشخیص خطا ار انجام داده و توقف پردازنده را بخواهد. پروتوکل اجازه می دهد تا پردازنده های دیگر برای  تشخیصتوقف برروی پردازنده اجرا شود. یک کلاس از گسل ها و اشتباهات وجود دارد که باعث جمع اوری شکست های نرم افزاری می ود. دو نوع از داده ها استفاده شده است 1- گزارش خرابی نرم افزارهای تولید شده و 2- توقف پردازنده های مربوط به نرم افزار گزارش شکست. تولید اطلاعات  دقیق در مورد گسل های زمینی رفع اشکال را ارائه می کند. توقف پردازش گرها نزدیک به صددرصد بوده و اطلاعات دقیق زمان بندی در شکست های نرم افزاری بدست آورده و بهبود ارائه می کند. نرم افزار منبع گزارش شکست پشت سرهم گزارش از پایگاه TPRO را گزارش می دهند. گزارش تمام مشکلات و سوالات و درخواست ها برای افزایش و توجیح مشتریان یا کارمندان استفاده شده است. زمینه های ثابت برای اطلاعاتی مانند تاریخ مشتری و مشخصات سیستم و شرح مشکل کوتاه را فراهم می کند. اگر TP گزارش خرابی نرم افزار را شامل ورود سیستم از تجزیه و تحلیل سیستم است را اعلام می کند. شتمل تمام شکست های نرم افزاری گزارش شده در تمام سایت های مشتری در طول دوره زمانی 1991 مورد استفاده قرار گرفت. ورود به سیستم توقف پردازنده یک زیر مجموعه از تعمیر ونگه داری سیستم عامل تاندم را دارد. اندازه گیری در پنج سیستم انجام شده است. شکست نرم افزار در سیستم پشت سر هم یک فرایند نادر است. و تنها یکی از خانه ها در سیستم می تواند منجر به شکست نرم افزاری شده و قابل تجزیه وتحلیل است. این سیستم یک سیستم تاندم است که توسط نرم افزار پشت سر هم برای طیف گسترده ای از طراحی و توسعه استفاده می شود. آن ار به عنوان یک سایت بتا معرفی کرده و با سخت افزار قدیمی پیکربندی شده است. به این ترتیب دوره اندازه گیری 23 ماه در نظر گرفته شده است.

2-3-11 IBM/MBS:

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

3-3-11: VAX/VMS:

خوشه های VAX در یک سیستم کامپیوتری که متشکل از چندین وسیله وکنترل ذخیره سازی  انبوه متصل به کامپیوتر است. یکی از اهداف طراحی خوشه های VAX رسیدن به دسترسی بالا با ادغام چندین ماشین در یک سیستم واحد است. سیستم عامل اشتراک گذاری خوشه گسترده ای از منابع  شامل  دستگاه ها و فایل ها و سوابق را در میان کاربران فراهم می کند. همچنین مختصات اعضای خوشه و دسته شکست بازیابی در گره های راه دور از طریق الگوریتم انجام می شود. هر سیستم عامل در حال اجرا در خوشه VAX دارای یک پارامتر به نام رای و یک پارامتر به نام حدالنصاب است. اگر n ماشین در سیستم وجود داشته باشد هریک از سیستم عامل معمولا به مجموعه حدالنصاب خود می رسد. پارامتر آن را به صورت پویا به تعدادی از ماشین آلات ماشین های در حال حاضر زنده در خوشه. VAX تنظیم می شود. پردازش خوشه  VAX تنها درصورتی  که آراء زیاد بوده یا به حدانصاب برابر شد اتفاق می افتد. بنابراین توابع خوشه VAX  خارج  از  n سیستم تجزیه می شود. این سیستم برای اولین بار در مرکز تحقیقات AMES ناسا به کار رفت. نرم افزارهای عملی معمولا وجود داشتند. این هفت ماشین با چهار کنترل کننده است دوره ها جمع آوری داده ها برای دستگاه های مختلف از 10 تا 18 ماه متفاوت است. سیستم دوم در دانشگاه ایلینویز واقع شده است. این شامل 4 ماشین و یک کنترل کننده بود. دوره جمع آوری داده ها 27 ماه در نظر گرفته شد.

4-11: مشخصات خطاهای پایین:

در این بخش ویژگی اساسی خطا با استفاده از داده های اندازه گیری شده بررسی می شود. این ها شامل خطاهای TTP و بهبود TTR است

1-4-11: خطاها و طبقه بندی آن ها:

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

1-14-11:سه عامل گواردیان:

 علل این شکست ها نشان می دهد که سخت افزار و خطاهای عملیاتی گاهی اوقات باعث شکست بوده  که به عنوان توجه به گسل نرم افزار می باشد و تجربه  به ما نشان می دهد  تعیین اینکه  آیا شکست در نرم افزار همیشه ساده نیست. این امر تا حدی به دلیل پیچیدگی سیستم و تا حدودی به دلیل تعامل نزدیک بین نرم افزار و سیستم عامل سخت افزار است. VAX تنظیم می شود. پردازش خوشه  تحلیل گران معتقد بودند که مشکلات زمینه ای گسل نرم افزار وجود دارد. این به مشکلات با عنوان ناشناس اشاره شده است. جدول 2-11 نتایج حاصل از یک طبقه بندی با استفاده از  TPR153 که توسط نرم افزار علل آن شناسایی شده است را نشان می دهد. جدول نشان می دهد که تعداد TPR و تعداد گسل ها منحصر به فرد است تفاوت بین این دو نشان دهنده شکست های متعدد با توجه به همان گسل است اعداد داخل پارانتز بیشتر از یک گسل را نشان می دهد. محاسبه اشتباه به معنای محاسباتی و یا استفاده از یک تابع اشتباه محاسباتی است. خطا در داده ها به معنی استفاده  از یک ثابت نادرست و یا یک متغیر است . گسل داده ها به عنوان خطا در اعلام داده ها و یا در تعریف یک ساختار داده است. عوارض جانبی وابستگی بین اجرای نرم افزارها در هنگام به روزرسانی نرم افزار را نشان می دهد. وضعیت غیر منتظره اشار به مواردی دارد که طراحان نرم افزار به یک وضعیت بالقوه نرسند و نرم افزار وضعیت نرسند و نرم افزار وضعیت درستی نداشته باشد. جدول 2-11 نشان می دهد که عملیات از دست رفته  وضعیت غیرمنتظره شایعتری علل ز TPRS می باشد. تلاش های بازرسی اضافی لازم است بخش زیادی از گسل ساده  مانند محاسبات نادرست و یا عملیات های از دست رفته است که معمولا در نرم افزارهای جدید قابل مشاهده بوده در حالی که نسبت بالایی از عوامل پیچیده مانند حوادث غیر مترقبه را که در نرم افزارهای کامل دیده می شود را دارد. همزیستی تعداد قابل توجهی از گسل های ساده و پیچیده تعجب آور  نیست . چرا که سیستم اندازه گیری سیستم های نرم افزاری بزرگ از هر جزء جدید وکامل تشکیل شده است. علاوه براین برخی از مشتری در اجرای نسخه قبلی نرم افزار موفق بوده اند. با این حال می خواهیم تعداد گسل ها کمتر بشود . وجود بخش قابل توجهی از گسل های ساده نشان می دهد که بهبود در طی بازرسی و تست اتفاق افتاده است که به عنوان یک اتفاق برای اولین بار بوده  وطراحی نرم افزارها با توجه به گسل گزارش شده است. TPR153 ،100 گسل منحصر به فرد مشخص شده است. بناباین 43 گسل نرم افزار جدید در طول دوره اندازه گیری جدید مشخص شده است. به این معنا که حدود 72% از شکستگی های نرم افزار قبلا مشخص شده است. با توجه به اینکه جانشینی سریع شکست در یک سایت احتمالا با توجه به همان کس بوده به طور معمول در یک TPR است. این نشان می دهد که در محیط هایی که در آن تعداد زیادی از کاربران نرم افزارهای مشابه توسعه نرم افزار تنها عامل تعیین کننده کیفیت نرم افزار نیست. به طور جدی نرم افزار قابلیت اعتماد و اطمینان را باید داشته باشد:

2-1-4-11: MVS:

MVS خطای نرم افزار در داده ها است که نشان دهنده خطا، شدت و نتایج حاصل از سخت افزار و نرم افزار برای یافتن مشکل توسط سیستم است. علایم خطای ارائه شده توسط سیستم به صورت اشتباهاتی در نظر گرفته شده است. شش کلاس از خطاهای ذکر شده تعریف می شود.

1-کنترل:نشان می دهد که استفاده نادرست از اظهارات منترل وجود دارد.

2-مدیریت داده ها: نشان می دهد که مشکل در مدیریت و یا ایجاد و پردازش مجموعه داده ها رخ داده است.

3-مدیرت ذخیره سازی: نشان دهنده خطا در ذخیره سازی و روند آزادسازی آن است.

4-استثنا در داد ها :نشان می دهد پرداختن به محل حادثه امکان ندارد و یا غیر قابل دسترس است.

5-استثنا برنامه نویسی:نشان می دهد که خطای برنامه به غیر از یک استثنا ذخیره سازی است.

6-زمان:نشان می دهد سیستم و یا حلقه های بی پایان اپراتور  شناسایی شده است   وزمان تعریف شده توسط کاربر محدود می باشد. جدول 3-11 توزیع درصد اشتباهات در طول  اندازه گری نشان می دهد. به طور متوسط سه طبقه خطای بزرگ مدیریت ذخیره سازی (40%) استثنا ذخیره سازی (21%) و مدیریت داده ها (19%) وجود دارد. این نتیجه به این واقعیت نزدیک است که یکی از ویژگی های اصلی MVS این سازمان ذخیره سازی متعدد است و مدیریت داده ها فعالیتهای با حجم بالا را برای سیستم حیاتی می داند. بنابراین ممکن است که اشتباهاتی را در پی داشته باشد.

3-1-4-11: VMS:

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

1-کنترل:مشکلات مربوط به کنترل در جریان برنامه  و یا هماهنگ سازی است.

2-حافظه: مشکلات با اشاره به مدیریت حافظه و یا استفاده از آن به عنوان مثال جهت آزادسازی حجم و یا بلوک حافظه.

3-I/O:خدمات مدیریت مدارک شناسایی می شود

4-سایر:دیگر مشکلات نرم افزار کشف می شود. جدول 4-11 فراوانی هرنوع از نرم افزارهای تشخیص خطا را برای دو سیستم خوشه VAX را نشان می دهد که نزدیک به 13% از اشتباهات نرم افزار قابل تشخیص بوده وهمه آنها به VAX2 تعلق دارند. داده VAX2 نشان داد که بسیاری از این اشتباهات وجود دارد که مربوط به خطای VAX! می باشد.یک مطالعه دقیق از یک VAX مربوط به خطا نشان می دهد که مدل های مختلف VAX ممکن است از همان خطا را گزارش کنند. بنابراین برای تشخیص طبقه بندی خطاها لازم است.

2-4-11:توزیع خطا:

زمان خطا TTE و زمان شکست TTF برای ارائه اطلاعات در مورد خطا و عدم ورود است. شکل 1-11،TTE،TTF را برای توزیع های تجربی برای بدست آوردن سه سیستم اندازه گیری با توابع تحلیل را نشان می دهد. در اینجا یک شکست به معنی شکست پردازنده و یک شکست سیستم است و به خطا به عنوان یک ضعیت غیر استاندارد شناسایی شده توسط نرم افزار سیستم تعریف می شود. با توجه به تفاوت در معانی و مکانیزم ورود به سیستم بین سیستم های اندازه گیری یک مقایسه مستقیم از توزیع امکان پذیر نیست. اما ما می توانیم مشاهدات را در سطح بالا به مسائل مربوط به اعتماد و اطمینان ارتباط دهیم. هیچ یک از توزیع ها در شکل 1-11 متناسب با توابع ساده نمایی نیست. اتصالات با استفاده از آزمون کولموگروف ابمیرنوف و یاچی اسکوار در سطح معنی داری در حدود 5% انجام شده است. این نتیجه گیری مطابق با اندازه گیری های قبلی است. دلایل متعددی برای این رفتار وجود دارد که از جمله آن حجم کار است. توزیع دو فاز متناسب برای خوشه VAX در TTE بوده و توزیع نرم افزار تاندم برای TTF ارائه شده است. تلاش برای TTE و MVS به یک توزیع نمایی فاز به تعداد زیادی از مراحل منجر شده است در نتیجه توزیع گاما در چند مرحله یه شرح زیر اس

رابطه 2-11 و 1-11

این است که توزیع گاما در مرحله 5 رضایت بخش ارائه دشه است. شکل b-1-11 و c -1-11 نشان می دهد که TTE نرم افزار اندازه گیری شده و توزیع های TTF می تواند به عنوان یک ترکیب احتمال دو متغیر تصادفی مدل نمایی نشان داده شود که دو حالت خطای غالب وجود دارد. نرخ خطای بالاتر A2 است که خطای متعددی برروی سیستم عامل یکسان را با یک دوره کوتاه اتفاق می افتد و خطاهای هم زمان معینی خطاهای متعدد در موارد مختلف از یک سیستم عانل در  یک دوره کوتاه از زمان در این سیستم است. میزان خطای پایین تر A1 احتمال وقوع را دارد.  و میزان خطا در آن بالا است. آنها به وضوح در شکل a-1-11 نشان داده شده است. زیرا هریک از پشت سرهم خطا را به عنوان یک ئاحد تحت درمان قرار دادند. ویژگی های خطاهای متعدد و اهمیت آن در بخش 2-6-11 بحث شده است. نتایج نشان می دهد که وجود خطا باید به حساب طراحی سیستم و مدل سازی گذاشته شود. گنجاندن خطا در مدل می تواند شکلی را که ممکن است روش راه حل بهبود باشد را بوجود بیاورد. خطا همچنین می تواند از تکرار مشکل نرم افزار یا از همان اثرات متعدد از یک مشکل نرم افزاری در نرم افزار بوجود بیاید. خطای نرم افزار در آزمایش های آزمایشگاهی گزارش شده است. این مطالعه نشان می دهد که اگر توالی ورودی نرم افزار بررسی شود می توان انتظار دااشت که بیشتر خطاها را بتوان با استفاده از  یک فرض ثابت پیش بینی کرد. در یک سیستم عامل توالی ورودی به احتمال زیاد به درخواست کاربر ارتباط دارد. از این رو می توان یک منطقه نقص را بارها باعث شود.

3-4-11 شکست همبستگی نرم افزار:

هنگامی که موارد متعددی از سیستم عامل در یک محیط تعاملی  چند سیستمی کار می کند. موضوع شکست باید خطاب قرار داده شود. داده ها نشان می دهد که حدود 10% از شکست های نرم افزاری در  خوشه VAX و 20% از شکست های نرم افزار به صورت پشت سرهم در یک سیستم بوجود می آید. برای درک این شکست های نرم افزاری یک مورد واقعی از شکست را با جزئیات آن آورده ایم. شکل 2-11 یک سناریو از شکست های نرما افزار همبسته را نشان می دهد. در شکل اروپا،مشتری،عطارد نام دستگاه ها در خوشه VAX می باشد. خط نقطه چین نشان دهنده آن است که دستگاه متناظر بوده و در حال شکست است. یک زمان یک خطای شبکه از NETL در پورت اتصال اراوپا گزارش شده است. این منجر به خرابی نرم افزارها پس از 13 ثانیه است. 24 ثانیه پس از خطای شبکه تول خطاهای شبکه اضافی گزارش شده است. دنباله خطا در دستگاه سوم نیز تکرار می شود. این سه ماشین در 5 دقیقه 45 تجربه شکست نرم افزاری را به صورت همزمان داشته است. هر سه شکست نرم افزار رخ داده در مدت کوتاهی بوده که پس از خطاهای شبکه رخ داده است. به طوری که آنها به خطای شبکه مرتبط هستند. تجزیه و تحلیل بیشتر داده ها نشان داد که نرم افزار مربوط به شکل VAX/VMS شرایط بالقوه ای برای شکست را دارد. نشان داده شده است که حتی درصد کمی از شکست های همبسیته می تواند تاثیر بزرگی برروی سیستم قابلیت اطمسنان و اعتماد داشته باشد. بنابراین شکست های همبسته را نمی توان نادیده گرفت.

4-4-11:توزیع بازیابی:

در MVS زمان بهبودی (TTR) به عنوان تفاوت پس از خروج سیستم عامل از حالت عادی به دلیل تشخیص خطا و بازگشت متعاقب ان به حالت نرمال تعریف شده است. حالت  عادی بدان معنی است که هیچ بازیابی خطای مورد انتظار نباشد. به عنوان مثال تمام اظتباهات قبلا شناسایی شده که توسط سیستم عامل می باشد. در سیستم گواردیان TTR به عنوان اختلاف زمان بین یک پردازنده رو به کاهش است که با توجه به نرم افزار و تعریف آن می باشد.. این احتمالا به دلیل وجود سیستم های VMS مربوط به خطاهای نرم افزاری جدی است. حدود 80% از اشتباهات نرم افزاری منجر به خرابی در سیستم می شود. از آنجا که هر سیستم دارای محیط عمل بازیابی و تعمیر ونگه داری مختلفی است،آن برای مقایسه با سیستم های اندازه گیری از نظر توزیع توزیع نامناسب می باشد. قصد ما این است که به درک و بحث در مورد مکانیزم های مختلف و در نتیجه ویژگی های زمان بهبودی در سه سیستم عامل بپردازد. شکلa3-11 یک خطای نرم افزاری را با TTR توزیع کرده است. خطای نرم افزارهای متعدد پشت سرهم که متشکل از انواع مختلف خطاهای نرم افزاری است مورد مطالعه قرار گرفته است. چرا که این اشتباهات باید زمان بهبودی طولانی تری از خطاهای نرم افزارهای دیگر را از نظم بهبود در نظر داشته باشد. تجزیه و تحلیل ما نشان می دهد که یک تابع  با سه فاز را می توان برای تقریب توزیع مورد استفاده قرار داد که نشان می دهد بهبود روند اتفاق افتاده است. از آنجا که خطاهای نرم افزار MVS به سیستم شکست منجر نشده است. TTR برای اشتباهات کوتاه بوده اگرچه این اشتباهات طولانی ترین زمان برای بهبودیافتن تمام خطاهای نرم افزاری استB-3-11،85%از TTR را به کمتر از 15 دقیقه نشان می دهد. این است که همان اشتباهات را جهت بهبود و یا راه اندازی مجدد و یا تعمیر کردن بدون خاموش کردن سیستم انجام داد. با این حال برخی از موارد TTR حداکثر  حدود 6.6 کار می کند. این شکست است. در تجربه ما احتمالا به علت ترکیبی از نرم افزار و سخت افزار مشکلاتی را داشته باشید. از انجایی که سیستم، بازیابی خودکار می کند اجازه  نمی دهد توقف اتفاق بیفتد. و شکل c-3-11 نشان دهنده زمان بارگزاری و راه اندازی مجدد اپراتور است. به طور معمول مدل های تحلیلی زمان بازیابی را ثابت فرض می کند. نتایج آن احتمالا درست نیست. برای سیستم های خوشه ای  VAX و تاندم از مدل نمایی و نه ثابت زمانی می تواند برای ارزیابی در نظر گرفته شود توابع چند حالت پیچیده تر به مدل توزیع TTR نیاز دارد.

5-11 ارزیابی تحمل خطاک

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

 1-5-11 : بررسی جفت فرایند:

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

1-1-5-11: اندازه گیری تحمل خطا نرم افزار:

TPRS179 با توجه به گسل نرم افزار در طول دوره اندازه گیری وجود داشت. از آنجا که گزارش هر TPR تنها یک مشکل است گاهی اوقات دو TPRS به عنوان یک نتیجه از توقف چند پردازنده تولید می شود. پنج گونه مورد وجود دارد و در مجموع 174 شکست نرم افزار را نشان می دهد. توقف تکرار در تعامل بدان معنی است که تحمل شکست سیستم در نرم افزار وجود دارد. جمع تمام پردازنده های متعدد  به یک گروه واحد تبدیل شده است که در یک سیستم پشت سر هم بوده و به طور بالقوه می تواند باعث پردازنده هایی اضافی با توجه به معماری سیستم باشد. یک مورد که در ان یک شکست نرم افزار رخ داده است وجود دارد. بنابراین آن نشان دهنده توانایی درک کاربر از سیستم تحمل گسل در نرم افزار سیستم می باشد که به طور خاص با توجه به استفاده از جفت روند می باشد. جدول 5-11 نشان می دهد که جفت فرایند می تواند یک سطح قابل توجهی از گسل نرم افزار را در محیط های پردازش تراکنش های توزیع شده فراهم کند. اندازه گیری تحمل خطای نرم افزار 82% اعلام شده است. این اندازه گیری در شکست های نرم افزاری گزارش شده است. اجماع در میان مهندسین این است که حدود 80%از شکست های نرم افزاری می تواند به عنوان TPRS بوده و می تواند بسیاری از انها با یک تک پردارزنده پایان یابد. اگر این درست باشد پس از تحمل خطا نرم افزار ممکن است بالای 96% تحمل خطا از خود نشان دهد.

2-1-5-11: قطعی به خاطر نرم افزار:

ما برای اولین بار برروی چند پردازنده متمرکز شدیم. برای هر یک توقف چند پردازنده را برای تعیین اینکه آیا توقف دوم برروی پردازنده از پشتیبان گیری از فرایند اولیه شکست خورده رخ داده است را اجرا کند. در چنین مواردی ما نیز اثر این را بررسی می کنیم که آیا این دو پردازنده با توجه به گسل نرم افزار  متقف می شود. جدول 6-11 نشان می دهد که در 86% از شکستیهای نرم افزار را تنها با یک پردازنده از دست می دهد و در نتیجه تحمل گسل نرم افزار که باعث این شکست است دیده می شود. دلایلی برای تحمل خطای نرم افزار در تمام فرایند با شناسایی یک تک پردازنده پایان خواهد یافت و آن را در چند گروه طبقه بندی می شود. جدول 7-1 نشان می دهد که در 29% از تک پردازنده ها توقف اتفاق می افتد که گسل باعث شکست یک فرایند اولیه می شود. این اتفاق می افتد. چرا که برخی از گسل های نرم افزارها در موقعیت های نادر مثلا حالت خاصی از حافظه قرار می گیرند.  این شرایط معمولا برروی نسخه پشیابن تکرارنخواهد شد. در زیر یک مثال واقعی از یک گسل آمده است که تنها در حالت خاصی از حافظه رخ می دهد. اولین جفت روند برای رفع درخواست است. با توجه به فعالیت بالا در پردازنده اولیه حافظه موقت در دسترس نیست. اما با توجه به  گسل روال مدیریت حافظه  موقت موفقیت آمیز بوده است. پشتیابن گیری در این زمان و در راستای خدمت به همان درخواست است. اما گسل بار دیگر به حافظه موقت در پردازنده در حال اجرای نسخه پشتیابن اعمال نمی شود. جدول 7-11 نشان می دهد که 20% از مشاجره پایان خواهد یافت که با تهیه یک پشتیابن از یک فرایند اولیه با شکست مواجه خواهد شد .دلیل این است که برخی از گسل ها مهم هستند. در حالی که به طور خودکار نسخه پشتیابن را در  شکست اولیه تهیه می کنند. نمونه های درخواست چنین اپرداتوری برای پیکربندی مجدد خطوط است. این درخواست به صورت خودکار به نسخه پشتیابن درخواست را ارسال می کند. چرا که انها وظایف تعاملی دارند که می تواند توسط اپراتور از آخرین پیشرفت های علمی در صورت شکست استفاده کنند. همچنین برخی از مشکلات نرم افزاری در حال اجرای توابع سیستماتیک مهم است. به عنوان جفت پروسه ها اجرا نمی شود. یک مثال از چنین عملکرد سیستم یک برنامه جانبی برای نظارت بر عملکرد پردازنده است. در نظر بگیرید که زمان پاسخ در یک پردازنده افزایش می یابد. سپس اپراتور چنین برنامه را اجرا می کند. در این وضعیت آن امری ضروری برای اجرای ابزار به عنوان جفت روند نیست زیرا نیازی به نظارت بر یک پردازنده دیگر وجود دارد. اگر پردازنده ای نظارت را داشته باشد پس از آن اپراتور می توانددر پردازنده های دیگر نیز اجرا شود. در این مورد این کار می تواند به شکست منجر شود. اما جفت فرایند اجازه می دهد برنامه های کاربردی دیگر برروی پردازنده برای  اجرا متوقف شود. این یک نرم افزار تحمل خطا است،به نفع استفاده کننده از جفت روند می باشد. اگر این شکست ها حذف شوند اندازه گیری تحمل خطای نرم افزار در حدود 77%خواهد بود. دلیل دیگر برای تحمل خطا نرم افزار که برخی از گسل نرم افزار باعث بروز خطا می شود که این سرویس ناشی از اشتباهات است. به عنوان مثال یک فرایند در داده های سیستم با توجه به  اشاره گر مقداردهی زمانی که آن را در خدمت  یک درخواست قرار داده ایم. گسل اساسی این بود که عملیات از دست رفته به عنوان مثال مقداردهی اولیه اشاره گر نیست. این فرایند که باعث شده که خطا به پایان برسد درخواست خوبی است که با موفقیت به خود نسخه پشتیبان برمی گردد. خطا در انجام خدمات تاثیر نمی گذارد و بخشی از اطلاعات نیست. بعد از مدتی یکی دیگر از فرایندها در پردازنده مشابه تشخیص خطا بوده و توقف می کند. پشتیبان گیری از این پروسه ادامه دارد. اما این سرویس ناشی از خطاء تکرار می باشد. چرا که خدمات در حال حاضر ارائه شده است. تفاوت بین این مورد و در گروه اول در جدول 7-11 فهرست شده است که عملکرد نرم افزاری است که ناشی از نارسایی اولیه می باشد که دوباره در نسخه پشتیبان تهیه می شود و جدول 7-11 نشان می دهد که 16% از اختلافات با تک پردازنده پایان خواهد یافت که با توجه به شکست یک فرایند پشتیبان یری رخ می دهد. این نشان می دهد که تحمل خطای نرم افزار کم است. چرا که با توجه به اجرا جفت روند در نرم افزار سیستم معرفی گسل نرم افزاری است. اندازه تحمل خطاء نرم افزار 77% بوده می توان دوباره به 72%شکست تنظیم شود. تمام شکست در تک پردازنده خواهد بود. این قابل درک است چرا که این با توجه به گسل ظریف می باشد که بسیار مشاهده و تشخیص آن سخت می باشد. به همین دلیل یک مشکل ناشناس باعث توقف تک پردازنده شده است. براساس نشانه های موجود ما براین باوریم که تعداد قابل توجهی از این مشاجره ها با توجه به اثر تاخیر خطا در تک پردازنده پایان خواهد یافت.

4-1-5-11: بحث:

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

2-5-11: بررسی روال بازیابی:

اثر روال های بازیابی با استفاده از لیست های مربوط به خطاهای جمع آوری شده از یک سیستم عامل IBM/MVS مورد بررسی قرار گرفت. با استفاده ازنام عرضه شده توسط سیستم سه گروه است. توابع تعریف شده است. یک مهم که برای بقای سیستم است. دو ضرورتی که برای تنزل سیستم است و غیر ضروری که برای بقای سیستم می باشد. جدول 8-11 اثر روال بهبود در برخورد با آن را نشان می دهد. هر جدول نشان می دهد که 43% از اشتباهات مربوط به سیستم های حساس و 68%از انها سیستم های اساسی مربوط می شود. نکته مهم این است که در بیش از 50% از موارد که در ان کار سیستم حیاتی است نتایج مشخص می باشد و اگرچه کمی بهبودیافتگی دیده می شود اما ارقام به کارهای ضروری می باشد. این اشاره به نارسایی در بهبود مدیریت بوده و کار کمتری در شرایط مهم و ضروری انجام شده است. جدول 8-11 نشان می دهد که روال بهبود در حدود 65% از اشتباهات را که در ان درگیر شده است مشخص شده است. در تفسیر این جدول می توان گفت که بهبود ممکن است هیچ روال بازیابی ارائه نشده است بهبود اتفاق بیفتد. درصد شکست در مواردی که منجر به بهبود روال شده است 44% در مقایسه با زمانی که هیچ بهبودی وجود نداشت 80% را نشان می دهد. این به نظر می رسد  که روال بازیابی بر بهبود تحمل به گسل اثر مثبت داشته است. اما هنوز جای زیادی برای پیشرفت وجود دارد. برای مشاغل ضروری درصد شکست ها که در ان روال بهبود نزدیک به 20%است. در مقایسه با زمانی که 72% هیچ روال بهبودی را نشان نمی داد بنابراین برنامه های بهبود در حال انجام یک کار خیلی بهتر از کسب وکار یک امر ضروری و حیاتی است. در جدول 9-11 بهبود روال را مربوط به کلاس های خطایی مشخص شده را نشان می دهد. برای تعریف کلاس های خطا در MVS به قسمت 1-4-11 مراجعه کنید. این نشان داد که روال بهبود بیشتر در داد و ستد با مدیریت ذخیره سازی است. وقتی که هیچ روال بهبودی ارائه نشده است و احتمال شکست در مدیریت ذخیره سازی بالای 71%  است. روال بهبود در برخورد با خطاهای زمان بندی ضعیفتر بوده  و جزء استثناهای برنامه نویسی می باشد. بنابراین به نظر می رسد که این مناطق به ویژه مناطق آسیب پذیر در آن به توجه زیادی نیاز داشته باشد برای تعیین کمیت ارقام فوق اقداماتی از تحمل خطا را می توان انجام داد برای تعیین کمیت ارقام فوق اقدامات از تحمل خطا تعریف شده و مورد بررسی قرار گرفت.

معادله4-11

که در آن تعدادی از شکست نشان داده شده است. این اندازه گیری برای تمام اشتباهات و هر دسته خطای تعریف شده در سیستم عامل  مورد بررسی قرار گرفت. جدول 10-11 تحمل گسل را در دو حالت نشان می دهد که چگونه به خوبی سیستم همه مشکلات را دسته بندی می کند. همچنین اندازه گیری تحمل خطا را دستور کار. به طور کلی تحمل  گسل در نرم افزار یافت می شود. جدول 10-11 نشان می دهد که سیستم برخوردهای ضعیفی را با خطاها در پست های بحرانی از خود نشان داده است. مشاهده می شود که بهترین شرایط با مدیریت ذخیره سازی و کنترل مشکلات است. این ضعیف ترین برخورد را با خطاهای  زمانی نشان می دهد. این رقم برای I/O و مدیریت داده ها نسبتا کم است.

6-11:مدل سازی و تجزیه وتحلیل:

در بخش های قبلی در مورد تحمل خطا در سیستم عامل های استفاده شده از جفت روند و روال بازیابی اشاره شد و ویژگی های خطای اساسی مانند توزیع TTE و TTR پرداخت. در این بخش به بررسی چگونگی این عوامل و در دسترس بودن آنها در سیستم با استفاده از مدل مارکوف و تجزیه وتحلیل ان می پردازیم. ساخت دو سطح مدل با استفاده از داده های تجزیه وتحلیل برای تعیین کمیت اثرات خطاها و بهبود آن انجام می شود. مدل سازی سطح پایین تمرکز بر کشف خطا و بازیابی در داخل یک سیستم عامل است. در حالی که در مدل سازی سطح بالا در توزیع نظام مند آن چند نمونه از سیستم های عانل تداخل می کنند. داده ها نشان داده است که برای سیستم IBM/MVS مدل سطح پایین تر مناسب است. در حالی که برای سیستم تاندم-گواردیان و VAX/WMS مدل سازی سطح بالاتر مناسب است. دو سطح مورد تجزیه وتحلیل قرار می گیرد و اجازه می دهد تا ما به ارزیابی نرم افزار تحمل خطا و قابلیت اطمینان و اعتماد آن در یک چهارچوب برای مدلسازی سیستم های نرم افزاری پیچیده اقدام کنیم.

1-6-11: مدل سازی سطح بالا:

در محیط های توزیع شده مانند پشت سر هم و خوشه ای VAX سیستم چند نمونه از سیستم عامل در حال اجرا را نشان می دهد . و این موارد به صورت یک سیستم واحد نرم افزاری است. در این بخش هریک به عنوان مثال در یک سیستم عامل به عنوان یکی از عناصر نرم افزار سیستم نرم افزار بوده و تحمل خطای نرم افزاری در سطح بالا مورد بحث است. مدل سازی با استفاده از داده های تاندم-گواردیان .و VAX/VMS انجام شده است.1-1-6-11:تفسیر مدل:

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

معادله 5-11

2-1-6-11:توابع پاداش:

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

معادله 6-11

معادله7-11

معادله8-10

معادله9-11


نظر دهی

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