انواع جدید فعالیتها، مدلسازها را قادر میسازد تا با دقت بیشتری، رفتار یک فعالیت را بیان کنند؛ با این وجود در صورت استفاده نادرست، خطاهای جدید به وجود میآید.
پیش از مطرح شدن BPMN 2.0، هیچگونه سردرگمی میان وظایف و رویدادها وجود نداشت. وظایف به صورت فعالیتهای اتمیک در یک جریان فرآیند مورد بررسی قرار میگرفتند که قابلیت تجزیه به بخشهای کوچکتر را نداشتند؛ در حالی که رویدادها، نمایانگر پدیدهای بودند که در فرآیند اتفاق میافتادند و نیازمند یک واکنش بودند.
با این وجود، از زمان پیدایش BPMN 2.0، گونههای متفاوتی از وظایف را میتوان تعریف نمود که به مدلسازها این امکان را میدهد تا رفتارهای گوناگونی را نشان دهند. در این میان، گونههای جدید ارسال و دریافت، اکنون مرز میان وظایف و رویدادها را نامشخص کردهاند. در این مطلب، سعی بر آن است تا تفاوتهای میان "رویدادهای مبتنی بر پیام" و "وظایف ارسال و دریافت" مورد بحث و بررسی قرار گیرد.
جریان پیام در وظیفه ها و رویدادها
به طور ذاتی، رویدادهای پیامی یا در حال فرستادن و یا گرفتن هستند و میتوانند موارد زیر را شامل شوند:
-فرایندی را آغاز کنند (رویداد آغاز پیام)، در واقع نمونهای جدید را زمانی که پیام دریافت میشود ایجاد میکنند.
-فرایندی را به پایان رسانند (رویداد پایان پیام)، در واقع نمونه فرآیند جاری را زمانی که پیام فرستاده میشود، به اتمام میرسانند.
-یک جریان فرایند را زمانی که یک پیغام فرا میرسد، دنبال میکنند (رویداد میانی که مسئول گرفتن پیام هستند).
-پیامی را جایی میان آغاز و اتمام یک فرآیند ارسال میکنند (رویداد میانی که مسئول فرستادن پیام است).
در نهایت رویداد میانی که مسئول گرفتن پیام است، میتواند در هر مکانی از مرز فعالیتها، قرار گیرد تا استثنائات را کنترل کرده و یا جبران خسارت نماید.
BPMN 1.x، جریانهای پیامی را مجاز به ارتباط مستقیم در درون یک وظیفه انتزاعی میدانست و به طور دقیق رفتار رویدادهای پیامی را تقلید نمیکرد. به علاوه BPMN 1.x، تنها اجازه میداد یک پیام به یک فعالیت، فرستاده یا دریافت شود و این امر، علاوه بر کار اصلی -که این فعالیت انجام میداد- بود. با معرفی وظایف ارسالی و دریافتی در BPMN 2.0، میتوانیم بگوییم که یک وظیفه در یک فرآیند، به طور دائمی، پیامی را ارسال یا دریافت میکند. پس از این که پیام، ارسال یا دریافت میشود، آن وظیفه تمام شده تلقی شده و هیچ کار دیگری اجراشدنی نیست.
صرفنظر از جزئیات، میان "رویدادهای پیامی" و "وظایف ارسال یا دریافت" تفاوتی وجود ندارد. هر دوی آنها مزایا و معایبی دارند که در ادامه به آنها میپردازیم.
مزایا و معایب استفاده از وظایف ارسال و دریافت
درحالیکه فعالیتها به طور معمول، نمایانگر کار انجام شده به وسیله یک شرکتکننده میباشد، وظایف ارسال و دریافت، تنها پیامی را ارسال یا دریافت میکنند و به محض رخ دادن، به پایان میرسند. تأکید بر اینکه چنین فعالیتهایی یک ایفاکننده نقش را تعریف میکنند و رویدادها چنین کاری را انجام نمیدهند، بسیار با اهمیت است.
فعالیتهای استاندارد، مدلساز را قادر میسازند تا نشانگرهای متفاوتی را اضافه کند که میتوانند نمایانگر گونههای موازی چندگانه، ترتیبی یا حلقهای از یک فعالیت باشند. چنین نشانههایی همچنین میتوانند در مورد وظایف ارسال یا دریافت بکار برده شوند و توصیفات اضافه در مورد رفتار پیشرفته یک وظیفه را ارائه دهند.
تصویر بالا نمایانگر رفتاریست که در آن، مجموعههای مختلف داده، محتوای پیام را تحت تأثیر قرار داده و سپس نمونههای ترتیبی یک وظیفه به وجود میآیند. چنین رفتاری با استفاده از رویدادهای پیامی به سختی نمایش داده میشود.
مزیت دیگر استفاده از وظایف ارسال و دریافت بر رویدادهای پیامی، قابلیت اتصال یک رویداد مرزی به یک وظیفه میباشد. در این صورت، میتوانیم استثنائات متعددی را که ممکن است در هنگام ارسال یا دریافت یک پیغام اتفاق بیفتند، کنترل نماییم.
همانگونه که در نمونه بالا دیده میشود، در صورتی که انتظار برای یک پاسخ بیش از یک ساعت زمان ببرد و یا یک خطای نرمافزاری رخ دهد، دو جریان استثنائی متفاوت تعریف شده است. اگر چنین استثنائی وجود نداشته باشد، پیام دریافت میشود و فعالیت بعدی به اجرا درمیآید. رویدادهای مرزی مشابه را نیز میتوان برای یک فعالیت ارسالی بکار برد.
همانند رویداد آغاز یک پیغام، فعالیت ارسال میتواند مثالی از فرآیند نیز باشد. بدین منظور، نمادی که کمی متفاوت است مورد استفاده قرار میگیرد؛ برای مثال یک پاکت نامه در میان یک دایره.
با استفاده از وظیفه دریافت -که نمونهای از یک فرآیند است- میتوانیم مدلی با ساختاری مستحکم را بدون نیاز به تعریف اضافی یک رویداد آغازین تعریف کنیم.
مزایای استفاده از رویدادهای پیامی میانی
در زمان تعریف جریان یک فرآیند، وضعیتهای متعددی وجود دارند که در آنها فعالیتهای ارسال و دریافت را نمیتوان مورد استفاده قرار داد. در این صورت، بهتر است از رویدادهای پیامی میانی استفاده کرد.
اول اینکه، اگر ما بخواهیم وضعیتی را مدلسازی کنیم که در آن دریافت یک پیام میتواند باعث وقوع یک استثناء در زمان اجرای یک فعالیت باشد، تنها میتوان از رویدادهای پیامی گیرنده که به صورت مرزی و میانی هستند، استفاده کنیم.
دوم اینکه، اگر بخواهیم وضعیتی را به نمایش بگذاریم که دریافت یک پیام لزوماً پایان یک فعالیت نیست، رویدادهای پیامی غیر مداخلهای گیرنده -که به صورت مرزی و میانی هستند- مورد استفاده قرار میگیرند.
مثال بالا نشاندهنده یک فعالیت انسانی است که شامل نگارش یک گزارش میباشد و میتواند با دریافت یک بروز رسانی مهم، متوقف شود. در این صورت، بروز رسانی فایلها اجرا شده و نگارش گزارش از نو مدلسازی میشود.
با این وجود، در صورت دریافت یک دعوت ملاقات، یادداشتی به وسیله اجراکننده فعالیت نوشته میشود؛ در حالی که فعالیت اصلی نگارش گزارش متوقف نمیشود. چنین رفتاری را نمیتوان تنها با استفاده از وظایف ارسال و دریافت ارائه کرد.
اشتباهات رایج
یک اشتباه رایج در زمان استفاده از فعالیتهای ارسال و دریافت، انتخاب عنوان است. همانگونه که پیشتر گفته شد، فعالیتهای ارسال آشکارا یک پیام -که می بایست ارسال شود- را تعیین میکنند و عمل دیگری نمیتواند در چارچوب چنین فعالیتی اجرا شود. تصویر شماره ۶ یک اشتباه رایج درباره انتخاب عنوان برای فعالیتهای ارسال پیام را ارائه میدهد.
همانطور که در مثال فوق دیده میشود، عنوان یک فعالیت به نحوی انتخاب میشود که مهیا/ارسال کردن یک پاسخ را بتواند پوشش دهد که این امر منطبق بر ویژگیهای BPMN نیست.
راهحل صحیح، تقسیم "مهیا نمودن پاسخ و اطلاع آن به کاربر" به دو عمل مجزا میباشد: یکی برای مهیا کردن یک پاسخ و دیگری برای ارسال آن.
در این صورت، فعالیت اول در "Pool ۱" کار مشخصی را انجام میدهد (برای مثال "مهیا کردن یک پاسخ") و فعالیت دوم این پاسخ را به "Pool ۲" میفرستد؛ جایی که در آن یک وظیفه دریافتی قرار داده شده است که به آن "دریافت پیام" گفته میشود. پس از دریافت پیام به صورت وظیفه دریافتی، وظیفه "تحلیل محتوا"، کار مربوطه را انجام میدهد.
اشتباه رایج دیگر نیز در هنگام مدلسازی، ارتباط میان Laneهای متعدد در یک Pool است. رویدادهای میانی ارسال و دریافت پیام به صورت تنگاتنگ با جریانهای پیامی جفت شدهاند. مورد دوم تنها برای ارائه ارتباط میان دو Pool استفاده شده و برای استفاده میان Laneهای همان Pool مناسب نیستند. کاربرد نادرست این چنینی در زمان استفاده از وظایف ارسال و دریافت، بسیار رایج است.
در مثال بالا، رویداد پیامی میانی -که از نوع ارسالی است و با برچسب "اعلان به Lane۲" مشخص شده است- در حقیقت یک جریان پیامی را ارسال مینماید و تا زمانی که "پیام از Lane۱ دریافت شود" ادامه مییابد و در آنجا منتظر جریانهای پیامی دریافتی که هیچگاه نمیرسند، میماند. چنین عملی در مورد وظیفه ارسالی "اعلان به Lane۲" و وظیفه دریافت "پاسخ دریافتی از Lane۱" نیز رخ میدهد.
با توجه به ویژگیهای BPMN ۲.۰، ارتباط میان Poolها را میتوان به سادگی و تنها با استفاده از جریانهای ترتیبی، همانگونه که در تصویر شماره ۹ نشان داده شده است، ارائه نمود.
نتیجه گیری
این مطلب، تفاوت میان رویدادهای پیامی و وظایف ارسالی و دریافتی را مورد بررسی قرار داد. درحالیکه هدف اصلی هر دو نوع المانها، ارائه یک ارتباط میان دو Pool و یا بیشتر با استفاده از یک جریان پیامی میباشد، تفاوتهای متعدد و متمایزی را می توان میان آن دو مشاهده نمود.
میتوانیم رویدادهای مرزی متفاوت و متعددی را به وظایف ارسال و دریافت متصل کنیم. علاوه بر این، نشانگرهای اضافی را میتوان به منظور ارائه حلقههای موازی، ترتیبی و استاندارد به وظایف اضافه نمود. از سوی دیگر، رویدادهای پیامی دریافتی که از نوع میانی هستند را می توان به منظور ارائه یک جریان استثناء به فعالیتها متصل نمود.
گونههای نوین فعالیتها، مدلسازان را قادر میسازد تا با دقت بیشتری رفتار یک فعالیت را بیان نموده و همچنین خطاهای جدید را در صورت استفاده نادرست معرفی کنند.
کاربران BPMN، به میزان زیادی به رویدادهای میانی ارسال و دریافت عادت دارند. استفاده ازفعالیتهای ارسال و دریافت ممکن است در صورت استفاده محض به منظور ارسال و دریافت جریانهای پیامی، مبهم به نظر برسد.
منبع: پایگاه دانش BPM رایورز