پرش به مطلب اصلی

اعتبارسنجی

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

اعتبارسنجی صرفاً بررسی Schema نیست؛ بلکه تجزیهٔ سند، بررسی قابلیت، تعیین فراداده، تحلیل Preflight، اعتبارسنجی متناسب با Runtime و پیام‌های تشخیصی مسدودکننده را ترکیب می‌کند.

مراحل اعتبارسنجی

یک عملیات کنترل‌شدهٔ BDL عموماً این مسیر را طی می‌کند:

  1. سند BDL را تجزیه کنید.
  2. فرادادهٔ زنده و شناسه‌های بومی موردنیاز را تعیین کنید.
  3. بررسی‌های پیش از اجرا (Preflight) را انجام دهید.
  4. بدون تغییر داده، کامپایل یا ValidateOnly را اجرا کنید.
  5. طرح اجرا را بسازید و بازبینی کنید.
  6. پیام‌های تشخیصی مسدودکننده را بررسی کنید.
  7. در موارد لازم، تأیید صریح بگیرید.
  8. از طریق سرویس‌های کنترل‌شدهٔ Runtime اجرا کنید.
  9. نتیجه را دوباره بارگذاری و پس از اجرا بررسی کنید.
  10. در موارد قابل‌اعمال، خروجی‌گیری، رفت‌وبرگشت و تطبیق انجام دهید.

تجزیه

تجزیه تأیید می‌کند که سند BDL بر اساس مدل زبان فعال قابل تفسیر است. قابل‌تجزیه‌بودن یک ویژگی به معنای پشتیبانی Runtime یا مجازبودن تألیف آن برای محیط عملیاتی نیست.

تعیین فرادادهٔ زنده

در موارد لازم، شناسه‌های بومی باید از فرادادهٔ زنده به دست آیند. این موارد را حدس نزنید:

  • شناسهٔ سیستم
  • شناسهٔ موجودیت
  • شناسهٔ فیلد
  • شناسهٔ فرم
  • شناسهٔ گزارش
  • شناسهٔ گردش‌کار
  • سایر شناسه‌های بومی

اگر فرادادهٔ لازم تعیین نشد، تألیف باید متوقف شود؛ نباید مقادیر حدسی جایگزین شوند.

بررسی پیش از اجرا

Preflight برای تشخیص عملیات نامعتبر یا ناایمن پیش از تغییر داده طراحی شده است. موضوعات معمول آن عبارت‌اند از:

  • مقادیر الزامی
  • ویژگی‌های پشتیبانی‌نشده
  • دسترس‌پذیری قابلیت
  • تعیین هویت بومی
  • محدودیت‌های محل قرارگیری و میزبان
  • سازگاری نسخه
  • الزامات قرارداد Runtime
  • محدودیت‌های شناخته‌شده
  • الزامات تأیید

اعتبارسنجی بدون تغییر

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

طرح اجرا

پیش از اجرای کنترل‌شده، ابزار باید طرح اجرای موردنظر را تولید یا ارائه کند. این طرح باید عملیات پیشنهادی را پیش از ایجاد تغییر قابل بازبینی کند.

پیام‌های تشخیصی مسدودکننده

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

تأیید

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

بررسی پس از اجرا

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

رفت‌وبرگشت و تطبیق

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

طبقه‌بندی خطا

اعتبارسنجی و عیب‌یابی باید دست‌کم این دسته‌ها را تفکیک کنند:

  • نقص تألیف
  • نقص تشخیص پیش از اجرا
  • اشکال Runtime
  • مشکل محیط یا نسخهٔ مبنا
  • محدودیت شناخته‌شده یا رفتار پشتیبانی‌نشده
  • شواهد ناکافی

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

قاعدهٔ کلیدی

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

ادامه

برای مدل تشخیص و روند بررسی خطا، بخش عیب‌یابی را مطالعه کنید.