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

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

مرحله ۱: تعریف الزامات

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

قابلیت آزمایش یک عامل کلیدی است؛ یک الزام خوب نوشته شده باید امکان ایجاد آزمون ساده برای تأیید برآورده شدن آن را فراهم کند. یک مجموعه مناسب از الزامات شامل عباراتی است که با «[محصول] باید ...» شروع می‌شوند، بر آنچه مورد نیاز است تمرکز می‌کنند نه بر نحوه دستیابی به آن، و وضوح و قابلیت آزمایش را تضمین می‌کنند. در نتیجه، معماری مؤثر به الزامات به خوبی تعریف شده متکی است.

مرحله ۲: تمایز قائل شدن بین معماری و طراحی

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

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

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

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

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

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

مرحله ۴: طراحی با در نظر گرفتن آزمایش

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

رایج‌ترین سطوح آزمایش شامل موارد زیر است

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

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

۳. تست‌های واحد تضمین می‌کنند که اجزای نرم‌افزاری منفرد، همانطور که در مرحله طراحی میانی تعریف شده‌اند، همانطور که در نظر گرفته شده عمل می‌کنند. این تست‌ها بر API عمومی (رابط برنامه‌نویسی کاربردی) که آن جزء به سایر اجزا ارائه می‌دهد، تمرکز دارند. معمولاً تست‌های واحد توسط همان افرادی که کد مورد آزمایش را می‌نویسند، توسعه داده می‌شوند.

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

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

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