مرور

مرور نمادها

۱

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

۲

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

۷

Data Object نشان دهنده جریان اطلاعات نظیر اسناد کسب و کار، ایمیل‌ها و یا نامه‌ها در سرتاسر فرآیند می‌باشد.

۸

Data Store مکانی است که فرآیند می‌تواند در آنجا داده ها را وارد و یا از پایگاه داده ای ذخیره شده در آن استفاده نماید. نکته قابل توجه امکان استفاده از Data Store پس از اتمام فرآیند و در فرآیندهای دیگر می باشد.

Events

TypeشروعIntermediateپایان
NormalEvent Subprocess Event Subprocess
non-interrupt
catch boundaryboundary
non-interrupt
throw
None
Message
Timer
Conditional
Link
Signal
Error
Escalation
Termination
Compensation
Cancel
Multiple
Multiple Parallel

Participants

Pool

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

در نمودار زیر، مشاهده می‌شود که به محض اینکه Task1 در Lane رابرت تکمیل می‌شود، وظیفه ۲ در فالکو Lane شروع می شود. همانطور که در نمودار مشاهده می‌شود، Task های هر بخش به صورت جداگانه در هر Lane تکمیل شده و درنهایت همه این Task ها منجر به انجام کل فعالیت در Pool Process conductor می شود.

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

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

رویه بیان شده در بالا پیچیده به نظر می رسد و در عمل نیز نیازی به استفاده از این روش جهت مدلسازی فرآیندها نمی باشد و در این قسمت تنها برای تفهیم و کاربرد Lane ها در BPMN این مثال ارائه شد. با توجه به نقش کلیدی Lane ها در مدل های فرآیندی و تسهیل ارتباط بخش های مختلف به یکدیگر، به راحتی می توان فرآیندهایی را که دارای مسئول وظایف مختلفی می باشند را در قالب یک فرآیند یکپارچه مدلسازی نمود. در واقع با استفاده از Lane ها می توان Pool ها و وظایفی که برای انتقال پیام بین بخش ها استفاده می شوند را حذف نموده و تنها از طریق جریان های عملیاتی فرآیند را مدلسازی نمود (همانطور که در شکل ۱ مشاهده شد). در ادامه، فواید بکارگیری این روش از طریق ارائه یک مثال بیشتر توضیح داده خواهد شد.

همانطور که در شکل زیر مشاهده می شود، در این قسمت مدلسازی فرآیندی با گذرگاه مبتنی بر رویداد ارائه خواهد شد.

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

حال ما می خواهیم دو فرآیند را یعنی تعامل مشتری و خدمات تحویل را از یک دیدگاه بی طرفانه مورد بررسی قرار دهیم. به همین منظور، سعی کرده ایم که این تعامل را در قالب Pool و Lane هایی در قالب شکل زیر مدل نماییم:

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

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

در شکل بالا، در دو مورد جریان های حاوی پیام به یک فعالیت با رویداد ختم نمی شوند و به خطوط حاشیه ای Pool وارد می شوند که اولین مورد مربوط به فعالیت call pizza delivery service و دومین مورد مربوط به فعالیت دریافت پول می باشد. منطقی که شاید بتواند مورد اول را توجیه نماید این می باشد که پرس و جوهای ما بر روی جریان توالی تحویل پیتزا تاثیری ندارد.

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

در شکل زیر این فعالیت به نمودار اضافه شده و حال می توانیم جریان های حاوی پیام را مستقیماً به فعالیت pay for pizza متصل نماییم.

Collapsing Pools

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

  • سفارش های پیتزا را دریافت نمایند
  • پیتزاهای سفارش داده شده را تحویل داده و پول آنها را دریافت نمایند.
  • برای رسیدگی به پرس و جو و پیگیری ها در دسترس باشند.

به عنوان یک مشتری، ما علاقه کمی برای آشنایی با چگونگی فرایند داخلی تحویل داریم. برای مثال ممکن است به محض اینکه پیتزا پخته شد به مشتری تحویل داده شود و یا ممکن است سفارش پیتزای دیگری نیز دریافت شود و پس از پختن، هر دو پیتزا با هم تحویل داده شوند که تصمیم گیری در مورد این موضوع مشکل تحویل دهنده است نه مشتری و ما به عنوان مشتری انتظار داریم که به سادگی و در اسرع وقت پیتزای سفارش داده شدمان را دریافت نماییم. در مدلسازی چنین مواردی، می توانیم فرآیند تحویل را درنظر نگرفته و Pool آن را خالی در نظر بگیریم که به آن Collapsing Pools گفته می شود.

حال می توانیم یک گام فراتر برویم و Pool مربوط به مشتری را نیز Collapsing Pools درنظر بگیریم. در این حالت تنها می توانیم پیام های رد و بدل شده بین دو Pool را مشاهده کنیم و با توجه به جهت فلش ها، بایستی ایده کلی از فرایند بدست اوریم. در این حالت ما نمی توانیم وابستگی های بیشتر بین فعالیت ها را تشخیص دهیم . برای مثال در این حالت نمی توانیم ببینیم که آیا پیگیری ها و پرس و جوهای ما همیشه به نتیجه می رسد و یا تنها در موارد خاصی نتیجه می دهد:

Lane

تا اینجا بیشتر در مورد جزئیاتی که بایستی در فرآیندها اجرا شوند بحث شد، اما هنوز توضیحی در مورد اینکه چه کسی مسئول انجام این فرآیندها می باشد ارائه نشده است. در BPMN این وظیفه را Lane ها به عهده دارند.

نمودار بالانشان می دهد که وظایف در فرآیند نمونه ما به افراد خاصی اختصاص داده شده است. با توجه به نمودار می توان نتیجه گرفت که روال کاری فرآیند به شرح زیر می باشد:

‌اگر کریستین گرسنه باشد، یک غذا انتخاب می کند. با توجه به آنکه انتخاب کریستین چه چیزی بوده است، دو حالت پیش می آید. در حالت اول کریستین به پخت ماکارونی می پردازد و در حالت دوم کریستین می تواند از همکارانش کمک بگیرد که در این حالت فالکو وظیفه پختن Steak و رابرت وظیفه آماده کردن سالاد را بر عهده دارد. در پایان، کریستین غذا را سرو می کند. در این مثال، سه Lane به نام‌های کریستین و فالکو و رابرت در قالب یک Pool واحد تحت عنوان flat-sharing community قرار گرفته اند.

در مثال ذکر شده، Lane به افراد نسبت داده شد اما در BPMN این موضوع کلیت ندارد و شما می توانید Lane ها را تحت عناوین مختلف طراحی نموده و نسبت دهید. در عمل، Lane ها اغلب برای تخصیص عناوین زیر نسبت داده می شوند:

  • پوزیشن های شغلی در سازمان های بزرگ نظیر منشی حسابداری
  • نقش های سازمانی در سازمان های متوسط نظیر افسر حفاظت اطلاعات
  • نقش های کلی مانند مشتری
  • بخش ها مانند بخش فروش
  • برنامه های IT مانند سیستم CRM

Activitie

Task

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

۱
۲
۳
۴
۵
۶
۷
۸
۱

در BPMN 2.0 دریافت پیام می‌تواند در قالب یک وظیفه جداگانه مدل شود. Receive task یک وظیفه ساده است که طی آن فرد در انتظار دریافت پیام از یک شریک خارجی (وابسته به فرآیند) می‌باشد. هنگامی که پیام دریافت می‌شود، این وظیفه به اتمام می‌رسد. این نوع وظیفه می‌تواند جایگزینی برای catching message event باشد که برای نمایش آن از یک پاکت نامه خالی در درون مستطیل Task استفاده می‌شود.

۲

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

۳

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

۴

اگر در یک فرآیند، یک Receive Task نقش شروع فرآیند را داشته باشد یا به عبارت دیگر Receive Task جایگزین یک message شروع event شده باشد، در این صورت از یک Receive (instantiated) استفاده می‌شود که آن را نماد یک رویداد message کوچک در گوشه بالا سمت است Task نمایش می‌دهند.

۵

وظیفه‌ای است که از انواع گوناگون سرویس‌ها استفاده می‌کند که می‌تواند به صورت یک وب سرویس یا یک برنامه کاربردی خودکار باشد. این نوع از وظایف توسط نرم‌افزار انجام می‌شوند که در آن‌ها از یکسری توابع برنامه‌ای به صورت اتوماتیک استفاده می‌شود، که BPMN فرض می‌کند که این توابع در قالب وب سرویس فراهم شده‌اند. Service Task جزئی از یک پیاده‌سازی یکپارچه فرآیندمحور است که توضیح می‌دهد چرا این پیاده‌سازی شباهت زیادی با مفهوم معماری سرویس‌گرا (SOA) دارد. از جمله مثال‌هایی که می‌توان برای این نوع وظیفه نام برد می‌توان به رتبه‌بندی‌های اعتباری که توسط آژانس رتبه‌بندی در قالب فایل XML و از طریق HTTP در طول بررسی اعتبار انجام می‌پذیرد نام برد. همچنین پیشنهاد کالاهای غیراستاندارد توسط حراجی‌های آنلاین، نمونه دیگری از وب سرویس می‌باشد.

۶

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

۷

Send Task یک وظیفه ساده است که طی آن یک پیام به شریک خارجی (وابسته به فرآیند) ارسال می‌شود و هنگامی که پیام ارسال شود این وظیفه به اتمام می‌رسد. از آنجایی که این نوع از وظایف فنی بوده و ماشین فرآیند کسب و کار آن‌ها را اجرا می‌نماید، از این‌رو از آن‌ها عمدتاً برای فراخوانی وب سرویس غیرهمزمان از طریق صفوف متنی (پیام) استفاده می‌شود.

۸

Business Rule Task مکانیزمی را ایجاد می‌کند که طی آن ورودی برای یک ماشین قوانین کسب و کار تأمین می‌شود و خروجی ماشین که محاسبات است را دریافت می‌کند. ویژگی ورودی-خروجی این وظیفه به فرآیند این اجازه را می‌دهد که اطلاعات و داده را به ماشین قوانین کسب و کار فرستاده و ازآن دریافت کند. این نوع از وظیفه تنها به منظور بکارگیری قوانین کسب و کار استفاده می‌شود.

Task Markers

علاوه بر انواع وظایف ارائه شده در شکل بالا، ما می توانیم با علامت گذاری وظایف از آنها به عنوان Loop، multiple instances و یا compensations استفاده نماییم که در ادامه به تفصیل آنها را توضیح خواهیم داد. در این رابطه، Marker ها می توانند با انواع مختلف وظایف ارائه شده ترکیب شوند.

Loop

یک Loop task تا زمانی که شرایط تعریف شده یا اعمال و یا متوقف شود تکرار می شود. برای مثال ممکن است ما غذاهای مختلفی را آنقدر به میهمانان پیشنهاد دهیم تا در انتها یکی از آنها را انتخاب نمایند. حال می توانیم غذاهای مورد نیاز را آماده نماییم:

در این مثال ما Loop task را برای یکبار اجرا می کنیم و پس از آن بررسی میکنیم تا در صورت نیاز وظیفه را دوباره اجرا نماییم که برنامه نویسان برای انجام این کار از ساختار do-while استفاده می نمایند. همچنین می توانیم از ساختار while-do استفاده نماییم که در آن وظیفه قبل از اینکه اجرا شود چک می شود. هرچند مورد دوم به ندرت اتفاق می افتد اما در مواردی که وظیفه کلا قابل اجرا نیست این مورد رخ می دهد.

همچنین شما می توانید شرایطی که در آن یک Loop task برای اولین بار اجرا می شود را به وظیفه مورد نظر ضمیمه کنید و یا همانطور که در مثال نشان داده شده است، شرایط اعمال تکرارهای مجدد را برای اجرایی شدن وظیفه به عنوان یک یادداشت به وظیفه اضافه نمایید. در این حالت شما می توانید این شرایط را به عنوان یک ویژگی در یک زبان رسمی از ابزار BPMN خود نیز ذخیره کنید. این کار باعث می‌شود که اگر فرآیند قابلیت اجرایی داشته باشد با استفاده از یک موتور فرآیند اجرا شود.

Multiple Instance

چرخه های تکی در یک Loop task بایستی از یکدیگر تبعیت کنند. برای مثال ما با هم اتاقی هایمان برای ناهار به یک رستوران می رویم و قصد داریم از منوی رستوران غذای مورد علاقه خود را سفارش دهیم. در این حالت وظیفه “انتخاب غذا” قبل از اینکه ما بتوانیم سفارش دهیم بایستی انقدر برای هم اتاقی هایمان تکرار شود تا غذای مورد علاقشان را انتخاب نمایند. در طرف دیگر رستوران چند نفر دیگر که تعدادشان از شما بیشتر می باشد نیز منتظر انتخاب شما و دریافت و مشاهده منو جهت انتخاب غذا می باشند.

در این حالت شما می توانید مدل فرآیند را با یک multiple task به راحتی رسم نمایید (شکل ارائه شده در ادامه را ببینید). یک multiple task instantiates می تواند می تواند به صورت یک توالی و یا به صورت موازی بارها و بارها تکرار و اجرا شود که در حالت موازی بودن روال اجرایی فرآیند جالبتر می شود.

چرخه های تکی در یک Loop task بایستی از یکدیگر تبعیت کنند. برای مثال ما با هم اتاقی هایمان برای ناهار به یک رستوران می رویم و قصد داریم از منوی رستوران غذای مورد علاقه خود را سفارش دهیم. در این حالت وظیفه “انتخاب غذا” قبل از اینکه ما بتوانیم سفارش دهیم بایستی انقدر برای هم اتاقی هایمان تکرار شود تا غذای مورد علاقشان را انتخاب نمایند. در طرف دیگر رستوران چند نفر دیگر که تعدادشان از شما بیشتر می باشد نیز منتظر انتخاب شما و دریافت و مشاهده منو جهت انتخاب غذا می باشند.

در این حالت شما می توانید مدل فرآیند را با یک multiple task به راحتی رسم نمایید (شکل ارائه شده در ادامه را ببینید). یک multiple task instantiates می تواند می تواند به صورت یک توالی و یا به صورت موازی بارها و بارها تکرار و اجرا شود که در حالت موازی بودن روال اجرایی فرآیند جالبتر می شود.

Compensation

compensation task type به طور انحصاری در زمینه جبران یک رویداد استفاده می شود. بر این اساس، این وظیفه در نمودار فرآیند تنها توسط associations نشان داده می شودو به هیچ عنوان از جریان های ترتیبی استفاده نمی شود.

ترکیب احتمالی compensation با یک Loop یا Multiple Instance در شکل زیر نشان داده شده است. در این مورد، هر دو نشانگر به صورت موازی قرار می گیرند. همچنین compensation می تواند با سایر انواع وظیفه نیز استفاده شود. یک compensation نیز می تواند به صورت موازی بارها و بارها تکرار و اجرا شود تا در نهایت به موفقیت برسد.

زیر فرآیند (Subprocess)

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

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

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

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

این ویژگی دو مزیت دارد که عبارتند از:

  • نمایش دادن جزیئات subprocess در یک نمودار فرآیند جداگانه؛ که با کلیک بر روی آیکون + در subprocess صفحه جدیدی باز می‌شود که جزییات subprocess را نمایش می دهد.
  • توسعه مدل فرآیندی از طریق subprocess؛

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

در این حین، ممکن است توسعه مستقیم جالب تر به نظر برسد، اما معمولا چنین اقدامی در کارهای عملی زیاد مفید به نظر نمی رسد، چرا که توسعه مستقیم subprocess مستلزم این موضوع می باشد که تمام نمادهایی که در همسایگی subprocess قرار دارند را بایستی متناسب با اندازه و ساختار subprocess جابجا نمود که این موضوع می تواند باعث بروز مشکلاتی نظیر کندی در اجرای عملکرد و به هم ریختن ظاهر کلی فرآیند گردد.

با توجه به مطالب بیان شده، با این نتیجه خواهیم رسید که با استفاده از subprocess می توان جزییات هر یک از بخش‌ها را به طور کامل و بدون اینکه هیچ یک از مشکلات بیان شده ایجاد شود در مدل فرآیندی منظور نمود و این موضوع یک ویژگی بسیار مهم در BPMN می باشد.

Attaching Events

تا اینجا یادگرفته ایم که که چگونه رویدادهای میانی می توانند به فعالیت ها ضمیمه (پیوست) شوند. این رویدادها همچنین می توانند به به subprocess نیز ضمیمه شوند که این ویژگی، طیف گسترده ای از فرصت ها را در مدل سازی فرایند ایجاد می نماید. همانطور که در نمودار زیر نشان داده شده است، ما می توانیم نشان دهیم که چگونه یک دعوت شام بخودی خود می تواند منجر به لغو فرآیند پخت و پز شود. هر چند که در فرآیند نشان داده شده، اگر سفارش ما اماده شده باشد و مشغول خوردن غذا باشیم ، می توانیم دعوت را نادیده بگیریم.

جاهایی که رویدادهای message، timer و conditional استفاده می شوند، فرآیند اصلی همیشه در واکنش به شرایط خارجی طوری عمل می کند که subprocess بی نتیجه بماند. همچنین با ضمیمه کردن subprocess با رویدادهایی نظیر error، cancellation و escalation مراتب را به فرآیند اصلی گزارش می دهد.

در گوشه پایین و سمت چپ نمودار بالا، فعالیت procurement می تواند به اتمام برسد چرا که دیگر در دسترس نیست. از آن جایی که فعالیت procurement، یک global subprocess می باشد، از این رو می تواند یک رویداد error را مبنی بر اینکه در فرآیند خطایی وجود دارد به فرایند اصلی ارسال نماید. به عبارت دیگر با این عمل به فرآیند اصلی اطلاع می دهد که در روند اجرایی فرآیند مشکلی وجود دارد. یک مثال خوب در این زمینه می تواند این موضوع باشد که برای مثال در شرایط کسب و کار، ممکن است مشتری که قصد خرید کالایی را داشته است به دلیل عدم موجودی انبار، سفارشش انجام نشده باشد و بخواهد این موضوع را به فروشنده اطلاع دهد. در واقع این مثال می تواند یک نمونه واقعی از آنچه که در بالا به آن پرداخته شد باشد.

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

رویداد signal در دوحالت مورد استفاده قرار می گیرد. به طور کلی یک فرآیند می تواند به سیگنال دریافت شده از خارج که توسط subprocess منتشر شده است واکنش نشان دهد. در این حالت، رویداد signal بسیار شبیه به رویداد message عمل می کند. اما مورد استفاده دیگر این سیگنال زمانی می‌باشد که بخواهیم به subprocess اجازه ارتباط برقرار کردن با فرآیند اصلی را با ابزاری به جز error ها فراهم نماییم. اصولاً دلیل اصلی استفاده از این رویداد عدم قابلیت استفاده از رویداد message در برخی از موارد ارتباطی می‌باشد. در واقع BPMN فرض می کند که ما همیشه message ها را برای ارسال پیام به مشارکت کنندگانی که در خارج محدوده Pool موردنظر قرار دارند ارسال می کنیم و این موضوع سبب می شود که در این موارد خاص از رویداد signal استفاده شود. بایستی به این نکته نیز توجه داشت که از رویداد signal برای ارتباط های مستقیم استفاده نمی شود بلکه برای پخش اطلاعات شبیه به تبلیغات در رادیو و تلویزیون استفاده می شود.

رویداد جایگزین بهتری که در .BPMN 2.0 در نظر گرفته شده است رویداد escalation می باشد. یک subprocess می تواند از رویداد escalation به منظور گزارش دادن مستقیم به فرآیند اصلی استفاده نماید که در این حالت پیغام مورد نظر نمی تواند از نوع پیغام خطا باشد. همچنین فرآیند اصلی می تواند پیغام های فرآیند را از طریق رویداد escalation و البته بدون توقف subprocess دریافت نماید چرا که این رویدادهای میانی بدون وقفه می توانند در چنین مواردی ضمیمه subprocess شوند.

Call Activity

در BPMN 1.2 ، با اختصاص یک ویژگی به subprocess، بین subprocess های تعبیه شده و قابل استفاده مجدد تفاوت ایجاد می شد. در ۲.۰ BPMN نیز، این اصل کماکان برقرار می باشد اما نحوه تعریف آن متفاوت می باشد. در نسخه جدید، اگر یک subprocess در مدل تعبیه شود، این subprocess تنها زمانی می تواند مجددا استفاده شود که به عنوان یک global subprocess تعریف شود و آنرا از طریق یک call activity به منبع آن ارجاع داد. به عبارت دیگر بایستی برای بکارگیری مجدد آنرا به subprocess تعبیه شده ارجاع داده شود.

یک subprocess تعبیه شده تنها در فرایندی که به آن تعلق دارد می تواند رخ دهد و این subprocess نمی تواند شامل Pool ها و Lane ها باشد، اما می تواند درون یک Pool و یا یکی از Lane های فرآیند اصلی قرار گیرد. علاوه بر این، subprocess تعبیه شده ممکن است دارای رویداد شروع نباشد و در این حالت، استفاده از رویدادهای شروع از نوع message یا timer مجاز نمی باشد. درواقع subprocess تعبیه شده چیزی بیشتر از ناحیه ای محدود در دل فرآیند اصلی نمی باشد که به طور کلی اهداف زیر را دنبال می کند:

  • جلوگیری از بوجود آمدن پیچیدگی های غیر ضروری در مدل
  • به منظور فرموله کردن یک بیانیه جمعی در قسمتی از فرآیند اصلی با ضمیمه کردن رویدادها یا بکارگیری marker ها. (در قسمت های بعدی توضیح داده خواهد شد)

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

ارتباط بین یک global subprocess با فرآیند اصلی اش بطور قابل توجهی نزدیک نبوده و آنها می‌توانند Pool ها یا Lane های خاص خود را داشته باشند. همچنین ارتباطات ضعیف نیز میتواند بر انتقال داده ها بین مدل اصلی و subprocess تاثیر بگذارد. در این حالت BPMN فرض میکند که embedded subprocess های میتوانند تمامی داده ها فرآیند اصلی را مستقیما بخوانند. اما global subprocess ها برای چنین کاری نیاز به یک تخصیص صریح و روشن دارند تا قادر به خواندن اطلاعات باشند.

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

  • آدرس قبض
  • تاریخ تحویل عملکرد
  • شرح عملکرد
  • مبلغ صورت حساب
  • تاریخ مورد انتظار پرداخت

در همین راستا، مسئولین پردازش سفارش و نه فقط بخش تعمیر، بایستی این اطلاعات را فراهم نمایند. در این حالت آیا واحد حسابداری داده های موردنیاز را در قالب یک فرمت استاندارد نیاز دارد؟ این مسئله ارتباطات بین فرآیندهای اصلی و global subprocess ها را به خوبی نشان می دهد که در BPMN به آن required data mapping می گویند.

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

Adhoc

‌یکی از شاخص‌های مختص Subprocess ها Ad-hoc نامیده می‌شودکه با افزودن علامت ᷉ به قسمت پایینی Subprocess ایجاد می شود که در شکل ذیل نشان داده شده است.

از Ad-hoc subprocess به منظور علامت زدن (مشخص نمودن) یک بخش استفاده می شود که فعالیت های این بخش (tasks or subprocesses) می توانند :

  • در هر سفارشی اجرا شوند،
  • چندین بار اجرا شوند و یا ،
  • کنار گذاشته شوند.

هر قسمتی که از این Subprocess استفاده می‌کند، تصمیم می‌گیرد که چکار کند و چه زمانی آن را انجام دهد. در ابتدای کار ممکن است برداشت شود که عدم اطلاع از اینکه داخل این Subprocess چه اتفاقی می‌افتد، کاری بیهوده و به درد نخور است. اما در حقیقت طبیعت بسیاری از فرآیندها اینگونه بوده و شما اطلاعات دقیقی از آن ندارید و یا کارکنان به نحو دیگری وظایف مربوط به خود را انجام می‌دهند. در چنین مواردی می توان از Ad-hoc subprocess استفاده نمود تا مکان‌ها و نقاطی را که ممکن است فرآیند در آنها به طور مطلوب عمل نکند را مشخص نمود، که با قدم نهادن در این مسیر می توان گام بلندی در راستای استاندارد سازی فرآیندها برداشت.

همچنین در BPMN 2. مشخص شده است که چه نمادهایی می‌توانند در Adhoc استفاده شوند و یا حق استفاده از آن‌ها وجود ندارد، که در ادامه به آنها اشاره شده است:

  • باید بیایند: فعالیت‌ها
  • می‌توانند بیایند: داده‌ها مانند فرم‌ها، جریان های توالی، گروه‌ها، ارتباط ها، جریان پیام‌ها، Gateway ها و رویدادهای میانی.
  • نباید بیایند: رویدادهای شروع و پایان و نماد‌های مربوط به گفتگو و نمایش.

با استفاده از خصوصیات ذکر شده، می توان فرم های ترکیبی مانند شکل زیر ایجاد نمود که در اصطلاح به آنها فرآیندهای ساختاری ضعیف (weakly structured processes) می گویند.

یک فرآیند خاص با فرم‌های آمیخته و ساختار فرآیندی ضعیف به شکل ذیل ترسیم گشته است.

Event Subprocess

درBPMN 2.0 یک ماژول جدید با نام Event Subprocess معرفی شده است که این ماژول درون یک فرآیند و یا Subprocess دیگر قرار می‌گیرد و با قالب خط نقطه‌چین شناسایی می‌شود.

یک رویداد شروع همیشه یک Event Subprocess را به راه می‌اندازد و این فقط زمانی رخ می‌دهد که فرآیند محصور در آن فعال باشد. Event Subprocess ها می‌توانند Interrupting (با وقفه) باشند که با خط ممتد نمایش داده می‌شوند و یا می توانند Non-Interrupting (بدون وقفه) باشند که با خط‌چین نمایش داده می‌شوند که این دقیقاً همان فرقی است که در رویدادهای میانی هم مشاهده شد. با توجه به نوع رویداد آغازین، Event Subprocess فرآیند محصور را کنسل خواهد نمود و یا به طور همزمان اجرا خواهد شد. در ادامه نحوه کار یک event subprocess را با ارائه مثالی توضیح خواهیم داد:

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

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

در شکل ذیل نشان داده شده است که چگونه Event Subprocess در قالب یک Collapsed State نمایش داده شده است که در آن برای نشان دادن collapsed subprocess علامت + به پایین فعالیت اضافه شده است.

انواع رویدادهایی که می‌توانند Event Subprocess های وقفه ای و بدون وقفه را راه بیاندازند عبارتند از:

  • پیام (Message)
  • زمان (Timer)
  • Escalation
  • شرط (Conditional)
  • سیگنال (Signal)
  • چندگانه(Multiple)
  • چندگانه موازی (Multiple parallel)

البته دو نوع دیگر از این رویدادها وجود دارد که تنها برای Interrupting وجود دارد:

  • خطا (error)
  • جبران (Compensation)

Gateways

Data-based Exclusive Gateways

فرایندهای زیادی وجود دارند که شرایط خاص خود را جهت اجرایی شدن می طلبند و تنها فرآیندهای بسیار کمی وجود دارد که روال اجرایی آنها شبیه به هم باشد.

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

حال بیایید دقیق تر راجع به این موضوع صحبت کنیم. فرض می‌کنیم تنها یکی از موارد بیان شده را می‌توانیم آماده کنیم. در اینجا به نقطه‌ای از تصمیم‌گیری می‌رسیم که بایستی مشخص شود از این به بعد چکار کنیم که به این نقطه در BPMN، Gateway گفته میشود. در این نقطه با توجه به اطلاعات و داده های موجود تصمیم می گیریم که کدام مسیر را انتخاب نماییم و بایستی این نکته را مدنظر قرار دهیم که تنها یکی از مسیرها قابل اجرا می باشد و در چنین حالتی بایستی از یک data-based exclusive gateway که مبتنی بر داده های موجود می باشد استفاده شود که به آن exclusive gateway یا XOR نیز گفته میشود.

نکته قابل توجه در این زمینه این می باشد که Gateway ها با Task ها متفاوت هستند و بایستی واقعیت ها و نیازهایی که برای ادامه کار ضروری می باشند را قبل از رسیدن به gatewayها مشخص و تعیین نمود.

همانطور که در نمودار فوق مشاهده می‌شود، ما یک سوال تعیین‌کننده قبل از Gateway قرار دادیم. در واقع اهمیت این سوال در پروژه ما به قدری است که می‌تواند مسیر حرکت در نمودار بالا را تغییر دهد.

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

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

در ادامه بایستی یک مسیر خروجی (یا جریان توالی) را برای هریک از جواب‌های ممکن درنظر بگیریم و هر یک از مسیرهای ممکن را با توجه به پاسخ درنظر گرفته شده برای آن نامگذاری نماییم.

در پاسخ به این سوال بایستی به این موضوع اشاره شود که BPMN از دو نماد برای نمایش XOR gateway استفاده می‌کند که از نظر معنایی کاملاً مشابه هستند. از آنجایی که به نظر می‌رسد نماد همراه علامت X دارای ابهام کمتری است، از این رو پیشنهاد می‌شود بیشتر از این نوع در مدل‌سازی استفاده شود.

Parallel Gateway

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

به طور کلی زمان انجام کل فرآیند برابر با مجموع زمان اجرای تک تک فعالیت های فرآیند مربوطه می باشد که در مثال بالا، ۴۸ دقیقه برای برای تهیه پاستا و ۴۳ دقیقه برای تهیه استیک نیاز می باشد. تا اینجا شما اولین فرآیند را براساس داده‌های کلیدی آنالیز نمودید.

با توجه به مطالب گفته شده نتیجه می شود که بسته به نوع غذای انتخابی حداقل بایستی ۲۳ دقیقه و یا حتی ۲۸ دقیقه صبر نمود تا غذا اماده سرو شود که این موضوع کمی ناخوشایند به نظر می رسد، چرا که شما واقعا گرسنه اید و چنین حالتی یعنی انتظار برای سرو غذا اصلا خوشایند به نظر نمی رسد.

در چنین حالتی چه کاری از دست شما برمیاید؟ در این وضعیت ممکن است شما در ابتدا سالاد را تهیه نکنید و برای پختن پاستا یا استیک اقدام نمایید. در چنین حالتی ممکن است شما در هر دو جبهه به طور موازی کار نمایید که در این حالت نماد مناسب برای کنترل این وضع parallel gateway یا AND gateway می باشد که در زیر نمایش داده شده است:

استفاده از parallel gateway در نمودارهای فرآیندی شما را مجبور به انجام فعالیت ها به طور همزمان نمی نماید. از طرفی این ابزار همانطور که در نمودار بالا نشان داده شد، شما را مجبور نمی کند که حتماً سالاد را قبل از تهیه پاستا یا استیک تهیه نمایید.

در واقع با تهیه این دو به موازای هم، زمان کلی برای سرو غذا ۱۰ دقیقه کاهش می یابد. مثال ارائه شده در این قسمت نمونه ای از بهینه سازی فرآیندهای کلاسیک بود که در آن سعی شده است فعالیت های مدل تا جایی که ممکن است به موازای هم انجام شوند

در مثال بالا اگر parallel gateway دوم را از مدل حذف کنیم و هر سه فعالیت به یک XOR ختم شوند، به محض اینکه سالاد آماده شود XOR فعال شده و فعالیت سرو غذا اجرا می شود. این در حالیست که ممکن است ۵ دقیقه بعد پخت پاستا نیز به اتمام برسد و با ورود به درگاه XOR فعالیت سرو غذا دوباره اجرا شود و این موضوعیست که اتفاق افتادن آن به هیچ عنوان مطلوب ما نیست.

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

  • فقط یک سالاد را
  • یک سالاد را به همراه یک غذای کامل تر مثل پاستا یا استیک
  • فقط یک غذای کامل (بدون سالاد)

برای درنظرگرفتن چنین حالتی در مدل فرآیندی از data-based inclusive gateway که به اختصار به آن OR gateway نیز می گویند استفاده می شود که در نمودار زیر این حالت به تصویر کشیده شده است:

Heads up!در واقعیت، بکارگیری و استفاده از OR gateway ها به آسانی و راحتی مثالی که در اینجا بدان اشاره شد نمی باشد و در مواقعی که نیاز به تعریف شرط برای فرآیند ها می باشد و یا مدل فرآیند در قالب چندین صفحه ارائه شده است، بکارگیری و فهم این درگاه بسیار مشکل خواهد شد.

Event-based Gateways

تا اینجا یاد گرفتیم که از exclusive data-based (XOR) gateway در مواقعی ک بخواهیم از بین مسیرهای موجود یک مسیر را با توجه داده های موجود برگزینیم استفاده می کنیم. در چنین مواردی کاربران از این درگاه استفاده می کنند اما BPMN، به ما ابزار دیگری را برای طراحی مسیرهای مختلف در یک فرآیند معرفی کرده است که به آن event-based gateway یا به اختصار event gateway گفته می شود. این درگاه، پایه و اساس انتخاب مسیر را بر مبنای داده های موجود قرار نمی دهد بلکه بر اساس رویدادی ک در ادامه ظاهر می شود، مسیر فرآیند را انتخاب می کند.

برای درک بهتر مزیت بکارگیری این درگاه، فرایند نشان داده شده در زیر را درنظر بگیرید: فرض کنید ما یک پیتزا سفارش می دهیم و منتظر می مانیم تا تحویل داده شود. در این حالت زمانی می توانیم پیتزا را سرو کنیم که آنرا دریافت کرده باشیم، اما اگر تا ۶۰ دقیقه بعد از سفارش، پیتزایی به ما تحویل داده نشد تکیف چیست؟ آیا نبایستی اقدامی کنیم؟ می‌توانیم این موضوع را در قالب نمودار زیر مدل کنیم:

همانطور که در شکل زیر دیده می شود، ضرورتی ندارد که بعد از event gateway فقط از رویدادهای میانی استفاده شود بلکه می توان از receive task ها نیز بعد از این درگاه استفاده نمود.

Events

مفاهیم پایه

تا اینجا از بین ۳ عنصر بکار رفته در مدل های فرآیندی یعنی Task ها، Gateway ها و Event ها دو مورد اول به طور کامل مورد بررسی قرار گرفت و آموختیم که کارها و فعالیت‌هایی به نام Task ، تحت شرایط خاصی که Gateway نام داشتند، قابلیت اجرایی شدن پیدا می کردند. در این قسمت نوبت به معرفی Event ها می رسد. در مدل‌های فرآیندی اهمیت Event ها بیشتر از دو مورد دیگر نباشد کمتر نیز نیست و به همین دلیل در این بخش به معرفی آنها خواهیم پرداخت. به طور کلی Event ها به سه دسته شروع events، intermediate events و end events تقسیم می شوند که هرسه دسته خود نیز شامل دو نوعcatching و throwing می شوند.

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

  • شروع یک فرآیند شوند.
  • ادامه یک فرآیند و یا مسیری از یک فرآیند شوند.
  • اجرای یک فعالیت شوند و یا یک sub-process را لغو نمایند.
  • استفاده از مسیر دیگری در فرآیند شوند در حالیکه Taskو sub-process در حال اجرا باشند.

Throwing eventsرویدادهایی هستند که بر خلاف Catching events به عنوان نقاطی از فرآیند که در آن یک محصول (خروجی) تولید شده و حال این محصول بایستی به قسمت دیگری از همان فرایند و با یک فرآیند دیگر ارسال شود استفاده می شوند. در واقع Throwing events نقش ارسال کننده و Catching events نقش دریافت کننده را در این پروسه بازی می کنند. در واقع می توان گفت این رویدادها تا زمانی فعال هستند که Catching events متناظر با آنها هنوز فعال نشده است و به محض فعال شدن Catching events متناظرشان، این رویدادها غیر فعال می شوند. Throwing events می توانند به عنوان :

  • هدفی تحقق یافته در طول فرآیند استفاده شوند که نتیجه را برای قسمت دیگری ارسال می کنند.
  • هدفی تحقق یافته در پایان فرآیند استفاده شوند که در این حالت نیز نتیجه بدست آمده از اتمام فرآیند را برای قسمت و یا فرآیند دیگری ارسال می کنند.

علاوه بر مطالب بیان شده دربارهEvent ها، ما می توانیم intermediate event ها را به فعالیت‌ها ضمیمه کنیم. ضمیمه کردن intermediate event به فعالیت‌های مدل، می تواند منجر به ایجاد وقفه در task ها و sub-process ها شود. در این حالت ما intermediate event ها را بر روی لبه فعالیت‌هایی قرار می دهیم که می خواهیم تحت شرایط خاصی در آن فعالیت وقفه ای ایجاد شود.

  • فرض کنید در نمودار بالا با رسیدن به وظیفه ۱ فرآیند آغاز شود.
  • اگر در حین اجرای وظیفه ۱، event 1 رخ دهد، task1 سریعاً متوقف شده و از مسیر دیگر به سمت وظیفه ۳ حرکت می کنیم.
  • به عبارت دیگر، اگر event 1 دخ ندهد، وظیفه ۱ اجرا خواهد شد و در مرحله بعد به سمت وظیفه ۲ خواهیم رفت.
  • همچنین اگر event 1 بعد از اینکه وظیفه ۱ به طور کامل اجرا شد رخ دهد، این رویداد تاثیری بر مدل نخواهد گذاشت و می توان آنرا نادیده گرفت.

در BPMN 1.2، به جز compensation event ها، سایر intermediate events قطعا باعث لغو شدن فعالیت‌ها خواهند شد و این در حالیست که در BPMN 2.0 نمادهای جدیدی در نظر گرفته شده است که intermediate event می توانند بدون ایجاد وقفه در مدل اتفاق بیفتند. هر چند این موضوع بسیار پیچیده می باشد ولی می تواند مفید واقع شود.

برای درک بهتر موضوع بالا به مثال زیر توجه نمایید:

  • فرض کنید در نمودار بالا با رسیدن به وظیفه ۱ فرآیند آغاز شود.
  • اگر event 1 در حالیکه وظیفه ۱ در حال اجراست اتفاق بیفتد، این event یک همزاد تولید می کند. در این حالت اجرای وظیفه ۱ در حالی ادامه می یابد که همزاد event به سمت وظیفه ۳ حرکت می کند که باعث اجرای آن می شود. این پروسه ممکن است بارها تکرار شود، به عبارت دیگر event می تواند بارها اتفاق بیفتد که بر بار اتفاق منجر به تولید یک همزاد دیگر می شود.
  • اگر event 1 رخ ندهد، وظیفه ۱ کامل اجرا خواهد شد و با توجه به نمودار به سمت وظیفه ۲ حرکت خواهیم نمود.
  • اما اگر event 1 بعد از اینکه وظیفه ۱ کامل اجرا شد رخ دهد، همانند حالت قبل این رویداد تاثیری بر مدل نخواهد گذاشت و می‌توان آنرا نادیده گرفت.

در بخش بعدی، انواع event ها را که در مدل BPMN بکار گرفته می شوند توضیح خواهیم داد. همچنین در مورد نحوه واکنش event های مختلف در مواقعی که بعد از event-based gateway قرار می گیرند نیز توضیحاتی ارائه خواهد شد.

Message

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

  • فرض کنید در نمودار بالا با رسیدن به وظیفه ۱ فرآیند آغاز شود.
  • اگر در حین اجرای وظیفه ۱، event 1 رخ دهد، task1 سریعاً متوقف شده و از مسیر دیگر به سمت وظیفه ۳ حرکت می کنیم.
  • به عبارت دیگر، اگر event 1 دخ ندهد، وظیفه ۱ اجرا خواهد شد و در مرحله بعد به سمت وظیفه ۲ خواهیم رفت.
  • همچنین اگر event 1 بعد از اینکه وظیفه ۱ به طور کامل اجرا شد رخ دهد، این رویداد تاثیری بر مدل نخواهد گذاشت و می توان آنرا نادیده گرفت.

در BPMN 1.2، به جز compensation event ها، سایر intermediate events قطعا باعث لغو شدن فعالیت‌ها خواهند شد و این در حالیست که در BPMN 2.0 نمادهای جدیدی در نظر گرفته شده است که intermediate event می توانند بدون ایجاد وقفه در مدل اتفاق بیفتند. هر چند این موضوع بسیار پیچیده می باشد ولی می تواند مفید واقع شود.

برای درک بهتر موضوع بالا به مثال زیر توجه نمایید:

  • فرض کنید در نمودار بالا با رسیدن به وظیفه ۱ فرآیند آغاز شود.
  • اگر event 1 در حالیکه وظیفه ۱ در حال اجراست اتفاق بیفتد، این event یک همزاد تولید می کند. در این حالت اجرای وظیفه ۱ در حالی ادامه می یابد که همزاد event به سمت وظیفه ۳ حرکت می کند که باعث اجرای آن می شود. این پروسه ممکن است بارها تکرار شود، به عبارت دیگر event می تواند بارها اتفاق بیفتد که بر بار اتفاق منجر به تولید یک همزاد دیگر می شود.
  • اگر event 1 رخ ندهد، وظیفه ۱ کامل اجرا خواهد شد و با توجه به نمودار به سمت وظیفه ۲ حرکت خواهیم نمود.
  • اما اگر event 1 بعد از اینکه وظیفه ۱ کامل اجرا شد رخ دهد، همانند حالت قبل این رویداد تاثیری بر مدل نخواهد گذاشت و می‌توان آنرا نادیده گرفت.

در بخش بعدی، انواع event ها را که در مدل BPMN بکار گرفته می شوند توضیح خواهیم داد. همچنین در مورد نحوه واکنش event های مختلف در مواقعی که بعد از event-based gateway قرار می گیرند نیز توضیحاتی ارائه خواهد شد.

در پاسخ به این سوال بایستی بگوییم بله می توانستیم. اما بایستی به این نکته نیز توجه شود که بکارگیری و استفاده از throwing intermediate event همیشه توصیه نمی‌شود، چراکه بکارگیری یک فعالیت “send message” بدون درنظر گرفتن یک مدل‌سازی صریح و آشکار می‌تواند کاربران و مشتریان بی‌تجربه را گمراه کرده و به اشتباه بیاندازد.

به همین دلیل در مدل بالا از یک وظیفه (سفارش پیتزا) بجای استفاده از یک “throwing intermediate events” استفاده نمودیم. همچنین می‌توانیم در مدل بالا از انواع وظیفه‌های خاص تعریف شده در BPMN برای پیام‌های دریافتی و ارسالی استفاده نماییم.

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

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

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

Timer

رویداد timer معمولا! زمانی که با BPMN کار می کنیم استفاده می شود چرا که این رویدارد قابلیت انعطاف پذیری بالایی در فرآیندها دارد . این رویداد با نماد ساعت نمایش داده می شود. نمودار زیر مثال های کمی از کاربردهای این رویداد را نشان می دهد.

از آنجایی که زمان بدون توجه به این موضوع که ما و یا فرآیند قصد انجام چه کاری را داریم در گذر می باشد، از این رویدادهای timer تنها می توانند به عنوان catching شروع و یا intermediate event استفاده شوند. شما می توانید با ضمیمه کردن یک timer event به یک فعالیت خاصیتی شبیه شمارش معکوس در آن ایجاد نمایید که در مدل‌های BPMN از این خاصیت به مراتب استفاده می شود. در این حالت شما می توانید یک محدودیت زمانی برای حد بالای زمان اجرای فعالیت تعریف نمایید که نمونه ای از این خاصیت در نمودار زیر آورده شده است:

در BPMN 2.0، رویداد جدیدی تحت عنوان Non-interrupting timer events (رویداد زمانی پیوسته) در نظر گرفته شده است که در نسخه های قبلی وجود نداشت.

Error

آیا فرآیندهای شما بطور کامل بدون خطا اجرا می شوند؟

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

در BPMN، رویدادهای error بوسیله نماد فلش نشان داده می شوند. خصوصیات BPMN مشخص نکرده است که یک error ممکن است چه چیزهایی را شامل شود؛ به همین دلیل شما به عنوان سازنده مدل، بایستی تصمیم بگیرید که در چه جاهایی از ان استفاده نمایید.

رویداد error یکی از مهمترین رویدادهای BPMN می باشد که اگر قرار باشد به عنوان یک رویداد catching استفاده شود، این جمله بدین معناست که اگر خطایی در طول اجرای یک فرآیند وجود داشته باشد، رویداد error بایستی آنرا در همان حین اجرا کنترل و برطرف نماید؛ اما اگر قرار باشد به عنوان یک رویداد throwing استفاده شود، در این حالت تنها می تواند در پایان مسیر مدل شود و این بدان معناست که اجرای فرآیند با شکست همراه شده است.

Conditional

گاهی اوقات ما فقط می خواهیم یک فرآیند تحت شرایط خاصی شروع و یا ادامه پیدا کند.

در اینجا هر چیزی می تواند به عنوان شرط درنظر گرفته شود و ماهیت شرایط مستقل از نوع فرایند می باشد و این باعث می شود که رویداد condition نیز مانند رویداد timer تنها بتواند در قالب یک catching event استفاده شود. از این رو فرآیندی که خروجی اش یاعث ادامه و یا شروع فرایند دیگری میشود نمیتواند به یک رویداد condition ختم شود.

در اینجا ما میتوانیم فرایند سفارش پیتزا را با تعریف یکسری شرایط توسعه دهیم. اگر ما یک پیتزای فریز شده بخواهیم، فرآیند به شکل نمودار زیر شروع میشود. در این حالت ما پیتزا را از فریزر برداشته و فر را روشن می کنیم اما فقط زمانی که دمای درون فر به ۱۸۰ درجه سانتی گراد رسید پیتزا را درون فر قرار میدهیم و تنها زمانی که فرآیند گرم کردن به اتمام برسد آن را از فر بیرون آورده و سرو میکنیم.

Signal

رویداد Signal بسیار شبیه رویداد message می باشد و در جاهایی که رویداد message می تواند استفاده شود، این رویداد نیز بکار گرفته می شود که نماد این رویداد یک مثلث می باشد. در واقع تفاوت اصلی بین رویدادهای message و Signal این می باشد که message همیشه به یک گیرنده خاص آدرس داده می شود (برای مثال یک ایمیل ادرس دریافت کننده ایمیل را شامل می شود و یا یک تماس تلفنی با شماره گیری یک شماره خاص شروع می شود و مثال‌هایی از این قبیل). یک Signal بیشتر شبیه یک تبلیغ در روزنامه و یا یک تلویزیون تجاری است. در واقع Signal برای آدرس و یا نفر خاصی ارسال نمی شود و هرکسی می تواند دریافت کننده آن باشد و اگر بخواهد می تواند نسبت به آن واکنش نشان دهد.

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

Termination

مثال ارائه شده در زیر را درنظر بگیرید. تا اینجا در مورد آنالیز شاخص عملکرد کلیدی(KPI) صحبت نمودیم و می دانیم که اجرای فرایند زیر ۵۵ دقیقه به طول میانجامد. پس از وظیفه ۱، وظیفه ۲ و وظیفه ۳ می توانند به طور همزمان شروع شوند و این در حالیست که اجرای وظیفه ۲ نسبت به وظیفه ۳ زمان بیشتری را می طلبد و به همین دلیل زمان اجرای کل فرآیند را این فعالیت تعیین می کند. در این مثال زمانی که وارد parallel gateway می شویم هر رو مسیر به طور همزمان فعال می شوند. در این حالت بایستی ۴۵ دقیقه برای اجرای وظیفه ۲ و ۳۰ دقیقه برای اجرای وظیفه ۳ صرف نماییم. در ادامه ۳۰ دقیقه طول می کشد تا وظیفه ۳ اجرا شود، اما پس از اجرای این فعالیت، فرآیند به اتمام نمی رسد و ادامه خواهد داشت. ۱۵ دقیقه بعد، وظیفه ۲ نیز تکمیل شده و کل زمان فرآیند برابر با ۵۵ دقیقه خواهد شد.

حال بیایید فرض کنیم اگر بعد از تکمیل شدن وظیفه ۳، وظیفه ۲ تکرار شود چه اتفاقی خواهد افتاد؟ این سوال موضوعی است که در اکثر فعالیت هایی که به موازای هم اجرا می شوند مطرح می شود. در چنین مواردی ما می توانیم الگویی که در ادامه ارائه شده است را بکار بگیریم:

Compensation

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

در این رابطه می توان مثال هایی نظیر موارد زیر بیان نمود:

  • رزرو بلیط هواپیما یا قطار
  • رزرو کردن یک ماشین کرایه ای
  • شارژ کردن یک کارت اعتباری
  • راه اندازی یک ارائه دهنده خدمات

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

ما می توانیم قسمت آخر مدل بالا را با بکارگیری یک رویداد compensation خلاصه تر کنیم که در سکل زیر این موضوع نشان داده شده است:

در رابطه با رویداد compensation قوانین خاصی وجود دارد که در ادامه به آنها اشاره شده است:

  • Throwing compensations ها به فرآیندهای خود ارجاع داده می شوند ، از این رو خود رویداد می تواند در درون Pool موثر باشد. این موضوع نشان می دهد که چگونه این نوع رویداد با throwing message event متفاوت است.
  • یک رویداد compensation ضمیمه شده تنها در صورتی که فعالیتی که به آن ضمیمه شده به طور کامل و با موفقیت اجرا شده باشد و فرآیند منجر به اصلاح شود ، می تواند رخ دهد و این در حالیست که انواع رویدادهای ضمیمه شده دیگر تنها در صورتی می توانند رخ بدهند که فعالیتی که بر روی آن ضمیمه شده اند فعال شود.
  • رویدادهای compensation ضمیمه شده از طریق وابستگی های مجازی به compensation tasks متصل می شوند و برای این اتصال نیازی به جریان های توالی ندارند. به همین دلیل BPMN بر روی این موضوع که compensation ها قابلیت انجام کارهایی فراتر از یک جریان فرآیندی معمولی را دارند تاکید دارد.

مثال بیان شده در این قسمت می‌تواند به راحتی و خیلی خوب به شما نشان دهد که استفاده از این ساختار چقدر می‌تواند در زمان شما صرفه‌جویی ایجاد نماید.

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

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

Multiple

ما می توانیم از رویدادهای Multiple به منظور خلاصه کردن چند رویداد در یک نماد جداگانه استفاده نماییم. نمودار نشان داده شده در زیر، از یک رویداد multiple برای سناریوی خرید پیتزا استفاده نموده است. در این مثال، ما قصد داریم تا یک پیتزای جدید را بعد از تماشای آن در تلویزیون و یا توصیه یک دوست امتحان کنیم. بعد از خوردن پیتزا، ما در مورد کیفیت پیتزا نظر می دهیم و به آن در Pizzatest.de امتیاز می دهیم و اگر نظرمان در مورد آن مثبت باشد، آنرا به دوستانمان نیز پیشنهاد می دهیم.

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

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

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

مدلی که در زیر نمایش داده شده است کاملاً شبیه مدل توصیف شده در بالا می‌باشد، با این تفاوت که در آن تمامی رویدادها به طور کامل در نودار مدل شده‌اند.

Parallel

رویداد parallel به منظور تکمیل نمودن رویداد multiple در BPMN 2.0 اضافه شده است. در حالیکه یک رویداد catching multiple به محض وقوع یکی از رویدادهایی را که شامل می شود اتفاق می افتد اما رویداد parallel تا زمانیکه کل رویدادهای وارده به آن فعال نشوند رخ نمی دهد و در بیشتر مواقع به عنوان یک catching event از آن استفاده می شود.

Escalation

در BPMN 2.0 رویدادی تحت عنوان escalation اضافه شده است که عمدتا روابط بین فرآیند اصلی و زیر فرآندهای را نشان می دهد.

Cancel

شما می توانید از رویداد cancel تنها در زمینه های تراکنشی استفاده نمایید.

۴۲۶۲۳ (۰۲۱)