از IFEM تا BOUND: افزودن دامنه و مرز به مسیر اجرای موازی
مسئلهٔ محوری: مسئولیت در کارِ همزمان
کارِ موازی در توسعهٔ نرمافزار تنها به تقسیم یک مسئله به چند فعالیت همزمان محدود نیست. هنگامی که چند مشارکتکننده—انسانی، یا انسان با کمک ابزارهای هوش مصنوعی—روی بخشهای مرتبط کار میکنند، روشن نبودن مرز مسئولیت میتواند فهمِ اینکه چه کسی مسئول کدام تصمیم، اتصال یا نتیجه است را دشوار کند. مسئله در اینجا توان محاسباتی یا خودکاربودنِ ابزار نیست؛ مسئله، صراحتِ مرزهایی است که اجزای کار را از هم جدا و در عین حال به هم متصل میکند.
**BOUND**، کوتاهشدهٔ *Boundary-Oriented Unified Development*، این مسئله را با جهتگیریِ «مرز-محور» صورتبندی میکند. این روش برای تیمهای انسانی و تیمهایی که از هوش مصنوعی کمک میگیرند قابل استفاده است، اما روشی صرفاً هوشمصنوعیمحور نیست. نقطهٔ تمرکز آن، روشنکردن مرزهای مسئولیت در اجرای موازیِ کار نرمافزاری است.
IFEM: مسیر رابط تا راستیآزمایی
برای فهم جایگاه BOUND، باید از **IFEM** آغاز کرد: *Interface-First Execution Methodology*. IFEM یک توالی روشن را مطرح میکند:
> **Interface → Contract → Execution → Verification**
در این توالی، رابط نقطهٔ آغاز است؛ سپس قرارداد مطرح میشود، اجرا انجام میگیرد و در پایان راستیآزمایی قرار دارد. ارزش تحلیلی این ترتیب در آن است که اجرای یک کار را مستقیماً از نقطهٔ آغازِ مشترکِ اجزا دنبال نمیکند، بلکه رابطهٔ میان رابط، قرارداد، اجرا و راستیآزمایی را بهصورت یک زنجیره بیان میکند.
با این حال، در کار موازی ممکن است پیش از آنکه بتوان دربارهٔ قرارداد گفتگو کرد، دو پرسش مقدماتی باقی بماند: کار در چه دامنهای قرار دارد و مرز مسئولیت در کجا تعریف میشود؟ IFEM این دو گام را در نام و توالی اصلی خود پیش از قرارداد نمیآورد؛ BOUND دقیقاً این نقطه را گسترش میدهد.
BOUND: گسترش توالی با دامنه و مرز
توالی BOUND چنین است:
> **Domain → Boundary → Contract → Execution → Verification**
این تغییر، جایگزینیِ بیقیدوشرط IFEM با اصطلاحات تازه نیست. BOUND اجزای **Contract، Execution و Verification** را حفظ میکند و دو گام **Domain** و **Boundary** را پیش از قرارداد میافزاید. بنابراین نسبت این دو روش را میتوان یک گسترش ساختاری دانست: مسیر رابطمحورِ IFEM به مسیری تبدیل میشود که ابتدا دامنه و مرز را آشکار میکند و سپس به قرارداد، اجرا و راستیآزمایی میرسد.
افزودن Domain به این معناست که بحثِ قرارداد بدون اشاره به قلمرو مسئله شروع نشود. افزودن Boundary نیز باعث میشود محل تفکیک مسئولیت پیش از صورتبندی قرارداد مورد توجه قرار گیرد. در نتیجه، قرارداد در BOUND پس از دو صورتبندی قبلی قرار میگیرد: نخست مشخصکردن دامنه و سپس مشخصکردن مرز.
خوانش عملی از پنج گام
پنج واژهٔ BOUND را نباید صرفاً فهرستی از برچسبها دانست؛ ترتیب آنها بخش مهمی از روش است. در یک کار مشترک، **Domain** پرسشِ قلمرو را پیش میکشد: مسئله یا بخش مورد بحث به کدام حوزه تعلق دارد؟ **Boundary** پرسشِ تفکیک مسئولیت را مطرح میکند: کدام سوی کار، تصمیم یا اتصال در محدودهٔ کدام مسئولیت قرار میگیرد؟ تنها پس از این دو گام، **Contract** میتواند محل توافق یا تعریف رابطهٔ میان بخشها باشد.
پس از قرارداد، **Execution** به مرحلهٔ انجام کار مربوط است و **Verification** جایگاه بررسیِ نتیجه نسبت به آن مسیر را دارد. این بیان، برای همکاری انسانها نیز معنادار است و در همکاریهایی که هوش مصنوعی در آن نقش کمکی دارد هم کاربرد دارد. حضور ابزار هوش مصنوعی، نیاز به بیان دامنه، مرز، قرارداد، اجرا و راستیآزمایی را حذف نمیکند؛ همچنین BOUND را نباید بهاشتباه با یک چارچوب ویژهٔ عاملهای هوشمند یکی دانست.
نتیجهگیری
BOUND با نام کامل *Boundary-Oriented Unified Development*، پاسخ خود را بر روشنشدن مرز مسئولیت در کار موازی بنا میکند. نسبت آن با IFEM دقیق و قابل بیان است: IFEM از **Interface** به **Contract، Execution و Verification** میرود؛ BOUND پیش از قرارداد، **Domain** و **Boundary** را مینشاند و توالی پنجگانهای میسازد. این تمایز کوچک در ترتیب، بحث مسئولیت را به نقطهای پیش از قرارداد منتقل میکند. برای مطالعهٔ منابع اصلی، مقالهٔ BOUND با DOI [10.5281/zenodo.22257583](https://doi.org/10.5281/zenodo.22257583) و مقالهٔ IFEM با DOI [10.5281/zenodo.20621561](https://doi.org/10.5281/zenodo.20621561) در دسترساند. نویسندهٔ BOUND، **Soheil Mozaffari**، است.