ما یک فرآیند پنج مرحله ای را در طراحی سیستم عامل دنبال می کنیم

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

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

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

مرحله 1: مشخصات لازم را تعیین کنید.

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

محصول چه چیزی به کاربر ارائه می دهد؟ ذکر این نکته ضروری است که یک نیاز به خوبی ساخته شده بر روی "چه چیزی" متمرکز است، و از جزئیات در مورد "چگونه" برای انجام یک ویژگی خاص در یک زمینه گسترده تر اجتناب می کند.

هر بیانیه الزامی باید دارای وضوح و قابلیت آزمایش باشد تا اطمینان حاصل شود که به راحتی قابل درک و تأیید است. بیانیه روشن مختصر و سرراست است و نیازی به توضیح بیشتر ندارد.

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

مجموعه کاملی از الزامات شامل اظهارات مکتوب است که با عبارت کلیدی "[محصول] باید ..." شروع می شود.

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

مرحله 2: تفاوت بین معماری و طراحی

با گذشت زمان، مشاهده کرده‌ایم که بسیاری از مهندسان و مدیران آنها برای تمایز بین اجزا یا سطوح مختلف مهندسی سیستم‌افزار تلاش می‌کنند.

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

طراحی سیستم به عنوان لایه میانی پیاده سازی عمل می کند. توجه به این نکته ضروری است که معماری مشخصات تابع یا نام متغیرها را شامل نمی شود. این جزئیات در سند طراحی سیستم عامل ثبت شده است.

نمونه‌هایی از این جزئیات شامل نام وظایف و مسئولیت‌های مرتبط در زیرسیستم‌های تعیین‌شده یا درایورهای دستگاه، نام تجاری RTOS انتخابی (در صورت وجود)، و مشخصات رابط بین زیرسیستم‌ها است.

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

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

مرحله 3: مدیریت زمان

مشخصات محصول شامل بازه های زمانی خواهد بود. معمولاً محصولات ترکیبی از نیازهای غیرواقعی، نرم-زمان واقعی و زمان واقعی سخت دارند.

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

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

جداسازی الزامات به موقع از بدنه اصلی نرم افزار به مجریان با تجربه کمتر اجازه می دهد تا کدی را بنویسند که ایمنی کاربر را به خطر نمی اندازد.

ترکیب عملکرد بلادرنگ نیز تحلیل مورد نیاز برای اثبات مهلت‌های زمانی را ساده می‌کند.

مرحله 4: طراحی تست محور

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

1. آزمایشات سیستم تأیید می کند که آیا محصول با الزامات مشخص شده مطابقت دارد یا از آن فراتر می رود. به طور معمول، آزمایش‌ها باید خارج از بخش مهندسی توسعه داده شوند، اما می‌توانند در یک مهار تست ایجاد شده توسط مهندسان نیز ادغام شوند.

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

3. تست‌های واحد تأیید می‌کنند که اجزای نرم‌افزار تعیین‌شده، مشخص‌شده در طراحی میانی، همانطور که توسعه‌دهنده در نظر گرفته‌اند، عمل می‌کنند.

آزمون‌های واحد، API عمومی (رابط برنامه‌نویسی کاربردی) را که مؤلفه به عناصر دیگر ارائه می‌کند، ارزیابی می‌کند. توسعه دهندگان به طور ایده آل باید تست های واحد را برای کد خود ایجاد کنند تا اثربخشی آنها به حداکثر برسد.

در میان این سه، تست‌های سیستم معمولاً ساده‌ترین برای توسعه هستند. یک آزمون مهندسی یا پذیرش کارخانه ممکن است نیاز به ایجاد یک مهار تست داشته باشد، اما این معمولاً پیچیده‌تر از آزمایش‌های یکپارچه‌سازی و واحد است که نیاز به درک عمیق‌تری از عملیات داخلی دستگاه دارد.

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

مرحله 5: برای تغییر آماده شوید

در مرحله معماری سفت‌افزار، اولویت دادن به تنوع ویژگی‌ها و سفارشی‌سازی محصول بسیار مهم است. برای آماده شدن برای تغییرات احتمالی، درک انواع تغییراتی که ممکن است در محصول خاص شما رخ دهد ضروری است.

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

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