همه چیز درباره DMN و رابطه آن با BPMN- قسمت اول

همه چیز درباره DMN و رابطه آن با BPMN- قسمت اول

چرا باید به DMN اهمیت دهیم؟

مدل تصمیم گیری (DMN) یک استاندارد صنعتی برای مدل سازی و اجرای تصمیماتی است که توسط قوانین کسب و کار تعیین می شوند.

استانداردهای DMN در سال ۲۰۱۵ منتشر شده است و در حال حاضر شاهد تصویب بسیار سریع آن هستیم. مهمترین دلایل اهمیت DMN عبارتند از:

استاندارد بودن: DMN متعلق به یک شرکت خاص نیست، بلکه مربوط به یک موسسه (OMG) است که قبلاً از طریق سایر استانداردهای جهانی همچون BPMN و UML بنا نهاده شده است. استاندارد DMN توسط چندین محصول نرم افزاری پشتیبانی می شود. بنابراین کمتر وابسته به محصولات یک فروشنده خاص خواهید بود.

اجرای مستقیم: در DMN، تصمیم گیری ها می توانند با استفاده از یک زبان مشابه، مدل سازی و اجرا شوند. تحلیلگران کسب و کار می توانند قوانینی را که منجر به تصمیم گیری در جدول‌هایی واضح و آسان می‌شود، مدل کنند و آن جداول می‌توانند مستقیماً توسط یک موتور تصمیم گیری(مانند Camunda) اجرا گردند. این امر ریسک سوء تفاهم بین تحلیلگران کسب و کار و توسعه دهندگان نرم افزارها را به حداقل رسانده و حتی اجازه می دهد تغییرات سریع در تولید وجود داشته باشد.

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

 

این مطلب آموزشی  مقدمه و خلاصه ای در ارتباط با DMN ارائه می دهد.

 

یک جدول تصمیم گیری ساده

می‌خواهیم آموزش DMN خود را با یک جدول تصمیم گیری نسبتاً ساده شروع کنیم:

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

بیایید عناصر موجود در این مثال را بررسی نماییم:

• در گوشه سمت چپ بالا نام جدول تصمیمات را می یابیم: “Dish” (ظرف).
• در زیر آن یک “U” وجود دارد که مخفف منحصر به فرد(unique) است و خط مشی تعریف شده برای این جدول تصمیم گیری می‌باشد. این بدان معناست که وقتی تصمیمی اتخاذ شود، تنها یکی از ردیف های پایین می تواند درست باشد. در این حالت فصل جاری فقط می‌تواند پاییز، زمستان، بهار یا تابستان باشد. نمی توانیم دو فصل را به طور همزمان داشته باشیم، حتی اگر تابستان امسال خنک باشد.
• ستون های با رنگ سبز به داده های ورودی احتمالی اشاره دارد. در این مثال فقط یک ستون ورودی وجود دارد، زیرا فقط فصل جاری برای ما دارای اهمیت است. سلول با نوشته ” Season” (فصل) آن را تعریف می کند. در DMN، این یک برچسب برای عبارت ورودی(input expression) است. در این مثال عبارت ورودی برای ساده شدن پنهان شده است، اما در ادامه مطلب آشکار خواهد شد. خانه ‌ها یا سلول‌های زیرین(که input entries یا داده ورودی نامیده می‌شوند) به شرایط احتمالی مربوط به ورودی اشاره می‌کنند. این شرایط داخل علامت نقل قول قرار می‌گیرند(مانند “Summer”)، علت آن این است که قرار است مقادیر رشته‌ها را از نظر فنی مقایسه کنیم.
• برای هر داده ورودی احتمالی(مثلا نام فصل جاری)، یک داده خروجی(output entry) متناظر در سلول کناری آن تعریف می‎کنیم. به این ترتیب بر اساس فصل، غذای خاصی را انتخاب می‌نماییم. باز هم باید از علامت نقل قول استفاده کنیم (مانند “استیک”) زیرا می‌خواهیم از لحاظ فنی مقادیر رشته‌ها را اختصاص دهیم.
• وقتی یک تعریف با توجه به یک داده ورودی(یا ترکیبی از داده‌های ورودی) صحیح است، باید یک داده خروجی خاص را اعمال نماید و این یک قاعده است. هر قاعده در یک ردیف از جدول و در زیر هدر جدول تعریف شده است و دارای یک عدد است که می توانید آن را در سلول های سمت چپ پیدا کنید.
• در آخر می توانید قواعد خود را در ستون سمت راست حاشیه نویسی کنید. چنین یادداشت هایی فقط برای توضیحات بیشتر وجود دارد و توسط موتور تصمیم گیری نادیده گرفته می شوند.

 

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

 

 

ترکیب شرایط

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

در این حالت ممکن است بخواهیم میهمانان گیاهخوار را در نظر بگیریم. بنابراین صرف نظر از فصل، نمی توانیم هیچ نوع گوشتی برای آنها سرو کنیم. خوشبختانه ما همیشه مقداری ماکارونی در دسترس داریم. با ترکیب دو ستون ورودی “Season” (فصل) و ” Vegetarian Guests”( میهمانان گیاهخوار)، اطمینان حاصل کرده ایم که چهار قانون اول(چهار سطر اول) تنها در صورتی می‌توانند صحیح ارزیابی شوند که مهمانان گیاهخوار نباشند. قانون شماره ۵ دارای یک “-” برای داده ورودی است که فصل را بررسی می کند و این بدان معنی است که تا زمانی که میهمانان گیاهخوار باشند فارغ از اینکه چه فصلی باشد ماکارونی دریافت خواهند کرد.

همانطور که مشاهده می‌کنید، ترکیب راه‌های ورودی به عنوان یک قاعده(یعنی یک ردیف جدول)، همیشه از منطق AND پیروی می کند: “اگر پاییز باشد و میهمانان گیاهخوار نباشند، گوشت دنده خوک سرو خواهد شد.”

 

معرفی FEEL

اکنون که درکی اساسی از ساختار جدول تصمیم گیری پیدا کردید، اجازه دهید نگاهی دقیق تر به ورودی های احتمالی بیندازیم. بسیار ساده است که بگوییم داده های خاص را باید با رشته های خاصی مقایسه کرد(مثل این واقعیت که فصل باید تابستان باشد). اما DMN مفاهیم پیشرفته تری را برای بررسی داده‌های ورودی ارائه می دهد. بخشی از استاندارد DMN، زبان ابراز دوستانه و کافی[۱] (FEEL) نام دارد.

FEEL یک ترکیب منطقی برای بیان شرایطی تعریف می کند که داده های ورودی باید در برابر آنها ارزیابی شوند. به عنوان مثال می توانید در FEEL توضیح دهید که داده ورودی خاص باید به یکی از شکل‌های زیر باشد:

• یک رشته عینی (مثل فصل که باید “summer” باشد)
• درست یا غلط (مانند این واقعیت که میهمانان ما گیاهخوار هستند)
• عددی که پایینتر، بالاتر یا دقیقاً مشابه عدد داده شده دیگر است
• عددی که بین یک مقدار حداقل و حداکثر داده شده است
• تاریخی که قبلتر، بعدتر یا همانند تاریخ معین دیگری است
• …و خیلی موارد بیشتر

 

برای به دست آوردن یک ایده اولیه، لطفاً به مثال زیر توجه کنید:

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

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

بیایید به هر قانون، در هر سطر نگاه کنیم:

1. اگر پاییز باشد و انتظار حداکثر ۸ مهمان را داشته باشید، گوشت دنده تهیه خواهید کرد.
2. اگر زمستان است و شما انتظار حداکثر ۸ مهمان را دارید، برای آنها رست بیف سرو خواهید کرد.
3. اگر بهار است و انتظار دارید نهایتا ۴ مهمان داشته باشید، از آنها با استیک گاو بسیار خوب و خشک پذیرایی خواهید کرد.
4. اگر بهار است و انتظار ۵ تا ۸ مهمان را دارید، یک استیک معمولی برای آنها سرو می کنید.
5. اگر پاییز، زمستان یا بهار است و انتظار بیش از ۸ مهمان را دارید، به دنبال خورش می روید.
6. اگر تابستان باشد، یک سالاد سبک و البته استیک خوب، مهم نیست که چند نفر باشند.

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

 

فرآیندهای DMN و BPMN

شاید این فکر ذهنتان را مشاین فکر ذهنتان را مشغول کرده باشد که: چرا باید از DMN استفاده کنیم؟ چنین قوانینی را می‌توانیم به کمک دروازه های BPMN نیز بیان نماییم!

اگر بخواهیم مثال بالا را در BPMN بیان کنیم، به صورت زیر خواهد بود:

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

به همین دلیل است که BPMN شامل یک به اصطلاح وظیفه قانون کسب و کار(business rule task) است که بهتر است در نسخه بعدی استاندارد BPMN وظیفه تصمیم گیری نامگذاری شود: این کار به تصمیمی برمی‌گردد که باید اتخاذ شود و نتیجه تصمیم نیز اجازه می‌دهد که دروازه اختصاصی برای عبور جریان متعاقباً باز شود. همانطور که در مثال زیر مشاهده می‌کنید.

در حین مدل سازی و همچنین اجرا، می توانیم وظیفه “Decide Dish” را به جدول تصمیم گیری DMN پیوند دهیم، که در صورت اتخاذ تصمیم باید اجرا شود و سپس نتیجه حاصل، جریان بعدی در BPMN را مشخص می کند.

در این مثال خاص، می توانید از مسیریابی جریان استفاده نمایید. شش وظیفه در مورد تهیه غذا وجود دارد که تنها تفاوت آنها در نوع غذا است. داشتن این شش وظیفه متمایز هیچ مزیت چشمگیری ندارد. یک الگوی جایگزین می‌تواند به صورت زیر باشد:

بیش از اندازه راحت به نظر می‌رسد. اما در این مورد، در واقع الگوی مناسبی محسوب می‌شود.

ترکیب BPMN با DMN یک رویکرد بسیار مناسب است. متأسفانه این قضیه هنوز توسط OMG استاندارد نشده است. این بدان معنی است که ارجاع دادن یک وظیفه قانون کسب و کار متعلق به BPMN به یک تصمیم متعلق به DMN، فقط مخصوص تامین کنندگان نرم افزار است.

[۱] – Friendly Enough Expression Language

 

بدون DMN، دانش شما در مدیریت فرایند ناقص است

فرصت را از دست ندهید برای کسب اطلاعات بیشتر و روی لینک زیر کلیک کنید !

می‌خواهم درباره DMN بیشتر بدانم