مرور

مرور نمادها

Click on orange symbols for explanation

Participants

Artifacts

 

Gateways


Responsive image


Responsive image













Data

 

Activities












 

Events

Type شروع Intermediate پایان
Normal Event Subprocess Event Subprocess
non-interrupt
catch boundary boundary
non-interrupt
throw
None
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Message
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Timer
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Conditional
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Link
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Signal
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Error
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Escalation
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Termination
Created with Raphaël 2.1.0
Compensation
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Cancel
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Multiple
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Multiple Parallel
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0
Created with Raphaël 2.1.0

Participants

Pool

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

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

Created with Raphaël 2.1.0فرآیند ارتباطیرابرتاستفانکریستینفالکوشروعوظیفه ۱وظیفه ۴وظیفه ۳وظیفه ۲

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

Created with Raphaël 2.1.0رابرتاستفانکریستینفالکوشروعوظیفه ۱انتقال به فالکووظیفه ۴وظیفه ۳انتقال به استفانوظیفه ۲انتقال به کریستین

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

Created with Raphaël 2.1.0رابرتاستفانکریستینفالکوشروعوظیفه ۱انتقال به فالکووظیفه ۴وظیفه ۳انتقال به استفانوظیفه ۲انتقال به کریستین

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

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

Created with Raphaël 2.1.0احساس گرسنگیانتخاب پیتزاسفارش پیتزادریافت پیتزاخوردن پیتزادریافت پیتزاسرویس تحویل پیتزاشصت دقیقهبرطرف شدن گرسنگی

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

Created with Raphaël 2.1.0پیتزا فروشیآشپزتحویل دهندهدریافت سفارش پیتزاپخت پیتزاتحویل پیتزادریافت پولپایان


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

Created with Raphaël 2.1.0فرآیند – پیتزامشتریتامین کنندهآشپزتحویل دهندهاحساس گرسنگیانتخاب پیتزا سفارش پیتزادریافت پیتزاخوردن پیتزاسرویس تحویل پیتزاشصت دقیقهدریافت پیتزاپخت پیتزاتحویل پیتزادریافت پول

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

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

Created with Raphaël 2.1.0پیتزا فروشیسفارش پیتزا – مشتریاحساس گرسنگی انتخاب پیتزاسفارش پیتزاخوردن پیتزابرطرف شدن گرسنگیدریافت پیتزاشصت دقیقهدریافت پیتزاسرویس تحویل پیتزاواحد تحویل و فروشآشپزتحویل پیتزادریافت پولپایانپخت پیتزاسفارش دریافت شده

در شکل بالا، در دو مورد جریان های حاوی پیام به یک فعالیت با رویداد ختم نمی شوند و به خطوط حاشیه ای Pool وارد می شوند که اولین مورد مربوط به فعالیت call pizza delivery service و دومین مورد مربوط به فعالیت دریافت پول می باشد. منطقی که شاید بتواند مورد اول را توجیه نماید این می باشد که پرس و جوهای ما بر روی جریان توالی تحویل پیتزا تاثیری ندارد. در این حالت ممکن است خدمات پیتزا سرعت پردازش و ارائه اطلاعات را در پیش بینی سفارشات جدید لحاظ نماید اما فعالیت های پخت، تحویل و دریافت پول در اثر این پرس و جو هیچ تغییری نخواهند نمود. در مورد دوم نیز، یک نقص در مدل فرآیندی مشتری وجود دارد و آن این است که بایستی قبل از خوردن پیتزا، پول آن پرداخت شود و این در حالیست که فعالیت پرداخت تعریف نشده است. در شکل زیر این فعالیت به نمودار اضافه شده و حال می توانیم جریان های حاوی پیام را مستقیماً به فعالیت pay for pizza متصل نماییم.

Created with Raphaël 2.1.0پیتزا فروشیسفارش پیتزا – مشتریاحساس گرسنگیانتخاب پیتزاسفارش پیتزاخوردن پیتزابرطرف شدن گرسنگیدریافت پیتزاشصت دقیقهسرویس تحویل پیتزاپرداخت هزینه پیتزاتحویل دهندهآشپزتحویل پیتزاپایاندریافت پولپخت پیتزاسفارش دریافت شده

Collapsing Pools

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

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

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

Created with Raphaël 2.1.0سفارش پیتزا – مشتریتامین کنندهاحساس گرسنگی انتخاب پیتزاسفارش پیتزاخوردن پیتزابرطرف شدن گرسنگیدریافت پیتزاشصت دقیقهسرویس تحویل پیتزاپرداخت هزینه پیتزادریافت پیتزا

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

Created with Raphaël 2.1.0تحویل پیتزا – تامین کنندهسفارش پیتزا – مشتریinquiryسفارشدریافت پولتحویلپرداخت


Lane

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

Created with Raphaël 2.1.0فرآیند رفع گرسنگیرابرتفالکوکریستینتهیه سالاداحساس گرسنگیانتخاب دستورالعمل آشپزیغذای مطلوبپخت پاستامیل نمودن وعده غذاییبرطرف شدن گرسنگیتصیممگیری برای انتخاب نوع غذاپخت استیکسالاداستیکپاستاغذای کامل تر

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

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

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

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

Activitie

Task

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

Responsive image









Task Markers

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

Loop

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

Created with Raphaël 2.1.0وقت شامپیشنهاد شامتهیه وعده غذاییوعده غذایی آماده شدهانتظار برای موافقت مدعوین

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

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

Multiple Instance

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

Created with Raphaël 2.1.0لیست انواع پیتزاانتخاب پیتزاسفارش پیتزاپیتزا سفارش داده شدهافرادی که باید از منو رستوران پیتزا انتخاب کنند

Compensation

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

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

زیر فرآیند


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

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

Created with Raphaël 2.1.0فرآیند اصلیشروعفعالیتزیر فرآیندپایان

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

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

Created with Raphaël 2.1.0فرآیند اصلیشروعپایانوظیفهزیر فرآیندوظیفهوظیفه

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

Attaching Events

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

Created with Raphaël 2.1.0احساس گرسنگیانتخاب دستورالعمل آشپزیتهیه وعده غذاییمیل نمودن وعده غذاییرفتن به رستورانبرطرف شدن گرسنگی

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

Created with Raphaël 2.1.0نگهداری موجودیفرآیند سفارشتهیهسفارش دریافت شدهبررسی موجودیآیا کالا موجود است؟بارگیری و حمل کالامدیریت مالیپایاناطلاع به شتریحذف کالا از کاتالوگپایانتهیهموجود نیستبلهخیرحداقل سطح موجودی دردسترستهیهکالای تهیه شدهحذف کالا از کاتالوگکالای حذف شدهموجود نیستشروعرزرو جاموجود؟تحویل جا رزرو شدهموجود نیستبلهخیر

در گوشه پایین و سمت چپ نمودار بالا، فعالیت 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 شوند.

Created with Raphaël 2.1.0فرآیند سفارشتهیهسفارش دریافت شدهبررسی موجودیآیا کالا موجود است؟بارگیری و حمل کالامدیریت مالیپایاناطلاع به شتریحذف کالا از کاتالوگپایانتهیهاطلاع به شتریپایانتحویل با تاخیرموجود نیستبلهخیرشروعرزرو جاموجود؟تحویل جا رزرو شدهموجود نیستتحویل با تاخیردر کمتر از دو روزدر بیشتر از دو روزخیر

 

 

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 ها با خطوط ضخیم تر اطراف فعالیت مشخص شده اند.

Created with Raphaël 2.1.0حل و فصل مالیفرآیند سفارشنگهداری موجودیتعمیرتهیه کالابررسی موجودیسفارش دریافت شدهآیا کالا موجود است؟بارگیری و حمل کالاپایانتهیه کالاحل و فصل مالیبلهخیرحداقل سطح موجودی در دسترسکالای تهیه شدهکالای تهیه شدهدرخواست تعمیر دریافتیانجام دادنپایانمدیریت مالیشروعرزرو جاشروعارسال صورتحسابوجه دریافت شدهمنقضی شدن زمان پرداخت

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

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

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

 

Adhoc

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

Created with Raphaël 2.1.0دو روز قبل عزیمتخاموش کردن سیستم گرمایشیتنظیم تلفن روی پیغامگیردادن کلید به همسایهبستن چمدانها

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

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

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

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

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

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

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

Created with Raphaël 2.1.0کتاب درسی بایدنوشته شوداستخدام مولفاندستورالعملهادستورالعملهاسرفصل بندینظراتنظراتعناوین تحقیقنتایج تحقیقنتایج تحقیقwrite text یادداشت یا پیشنویستهیه تصاویرجاگذاری تصاویر در متنتصاویرتصاویرانجام اقدامات تکمیلیمتن کامل شدهتهیه دستنویس دستنویس کامل شدهدستورالعملهادستورالعملهانظراتنظراتنتایج تحقیقنتایج تحقیقتصاویرتصاویرeach author!

Event Subprocess

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

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

Created with Raphaël 2.1.0دعوت دوستان به صرف شامراه های تهیه غذامخصوص مهمانک مهمان جدید خوذدش را دعوت می کنددرنظر گرفتن مهمان جدید در تدارکات مهمانیسفارش غذاشکست فرآیند پخت غذاسفارش غذاانتخاب دستورالعمل آشپزیتهیه وعده غذاییمیل نمودن وعده غذایی

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

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

Created with Raphaël 2.1.0دعوت دوستان به شامراه های تهیه غذاانتخاب دستورالعمل آشپزیتهیه وعده غذاییمخصوص مهمانسفارش غذامیل نمودن وعده غذایی

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

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

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

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

Data-based Exclusive Gateways

Created with Raphaël 2.1.0احساس گرسنگیانتخاب دستورالعمل آشپزیغذای مطلوبپخت پاستاپخت استیکتهیه سالادمیل نمودن وعده غذاییپاستااستیکسالاد

فرایندهای زیادی وجود دارند که شرایط خاص خود را جهت اجرایی شدن می طلبند و تنها فرآیندهای بسیار کمی وجود دارد که روال اجرایی آنها شبیه به هم باشد. برای مثال اگر بخواهیم مثال ساده ارائه شده در رابطه با پختن غذا را دقیق تر و با جزییات بیشتر توضیح دهیم. در این رابطه، بایستی فرآیند را از فعالیت گرسنه شدن درنظر بگیریم. درواقع، بایستی آنچه که ما در فعالیت پخت و پز به آن فکر می کنیم را درنظر بگیریم. در این حالت تنها چیزی که می دانیم این موضوع می باشد که سه دستور پخت دراختیار داریم و بایستی یکی از آنها را انتخاب کنیم. در این حالت ما می توانیم یا پاستا را بپزیم و یا استیک را یا اینکه سالاد تهیه کنیم. حال بیایید دقیق تر راجع به این موضوع صحبت کنیم. فرض می کنیم تنها یکی از موارد بیان شده را می توانیم آماده کنیم. در اینجا به نقطه ای از تصمیم گیری می رسیم که بایستی مشخص شود از این به بعد چکار کنیم که به این نقطه در 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 دارای ابهام کمتری است، از این رو پیشنهاد می‌شود بیشتر از این نوع در مدل‌سازی استفاده شود.

Created with Raphaël 2.1.0

Parallel Gateway

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


Created with Raphaël 2.1.0احساس گرسنگیانتخاب دستورالعمل آشپزیتهیه سالادغذای مطلوب پخت پاستاپخت استیکمیل نمودن وعده غذاییپاستااستیکبیست دقیقهده دقیقهده دقیقهسه دقیقهپانزده دقیقه

به طور کلی زمان انجام کل فرآیند برابر با مجموع زمان اجرای تک تک فعالیت های فرآیند مربوطه می باشد که در مثال بالا، ۴۸ دقیقه برای برای تهیه پاستا و ۴۳ دقیقه برای تهیه استیک نیاز می باشد. تا اینجا شما اولین فرآیند را براساس داده‌های کلیدی آنالیز نمودید. با توجه به مطالب گفته شده نتیجه می شود که بسته به نوع غذای انتخابی حداقل بایستی ۲۳ دقیقه و یا حتی ۲۸ دقیقه صبر نمود تا غذا اماده سرو شود که این موضوع کمی ناخوشایند به نظر می رسد، چرا که شما واقعا گرسنه اید و چنین حالتی یعنی انتظار برای سرو غذا اصلا خوشایند به نظر نمی رسد. در چنین حالتی چه کاری از دست شما برمیاید؟ در این وضعیت ممکن است شما در ابتدا سالاد را تهیه نکنید و برای پختن پاستا یا استیک اقدام نمایید. در چنین حالتی ممکن است شما در هر دو جبهه به طور موازی کار نمایید که در این حالت نماد مناسب برای کنترل این وضع parallel gateway یا AND gateway می باشد که در زیر نمایش داده شده است:

Created with Raphaël 2.1.0احساس گرسنگیانتخاب دستورالعمل آشپزیغذای مطلوبپخت پاستاپخت استیکتهیه سالادمیل نمودن وعده غذاییبرطرف شدن گرسنگی پاستااستیکده دقیقهده دقیقهبیست دقیقهسه دقیقهپانزده دقیقه

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

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

Created with Raphaël 2.1.0احساس گرسنگیانتخاب دستورالعمل آشپزیغذای مطلوبپخت پاستاپخت استیکتهیه سالادمیل نمودن وعده غذاییبرطرف شدن گرسنگی پاستااستیکده دقیقهده دقیقهبیست دقیقهسه دقیقهپانزده دقیقه

Data-based inclusive gateways

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

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

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

Created with Raphaël 2.1.0احساس گرسنگیانتخاب دستورالعمل آشپزیتصمیم انتخاب نوع غذاتهیه سالادپخت پاستاغذای مطلوبپخت استیکمیل نمودن وعده غذاییبرطرف شدن گرسنگیسالاداستیکپاستاغذای کامل تربیست دقیقهسه دقیقهپانزده دقیقهده دقیقهده دقیقه

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

 

Event-based Gateways

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

Created with Raphaël 2.1.0احساس گرسنگیانتخاب پیتزاسفارش پیتزادریافت پیتزاخوردن پیتزادریافت پیتزاسرویس تحویل پیتزاشصت دقیقهبرطرف شدن گرسنگی

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

Created with Raphaël 2.1.0پیامزمانشرطسیگنالچندگانهوظیفه دریافتی

مفاهیم پایه

تا اینجا از بین ۳ عنصر بکار رفته در مدل های فرآیندی یعنی 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 ها را بر روی لبه فعالیت‌هایی قرار می دهیم که می خواهیم تحت شرایط خاصی در آن فعالیت وقفه ای ایجاد شود.

Created with Raphaël 2.1.0وظیفه ۱وظیفه ۲رویداد ۱وظیفه ۳

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

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


Created with Raphaël 2.1.0وظیفه ۱وظیفه ۲رویداد ۱وظیفه ۳

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

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

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

 

Message

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

Created with Raphaël 2.1.0احساس گرسنگیانتخاب پیتزاسفارش پیتزاپیتزا دریافت شدهخوردن پیتزابرطرف شدن گرسنگی

 

Created with Raphaël 2.1.0احساس گرسنگیانتخاب پیتزاپیتزا سفارش داده شده پیتزا دریافت شدهخوردن پیتزابرطرف شدن گرسنگی

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

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

Created with Raphaël 2.1.0گزارش کاربر : خطا در وبسایت!جستجو برای یافتن خطاتعمیر خطاکاربراشتباه‌کرده؟÷تذکر به کاربربه کاربر تذکر داده شدتشکر از کاربراز کاربر تشکر شدگزارش کاربر:متاسفم، اشتباه شد!بلهخیر

 

Timer

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

Created with Raphaël 2.1.0روزهای تعطیلاتواحد پشتیبانیروز کاریروز مادردوشنبه تا جمعه ۷ صبحبیدار شدنشستن دست و صورتاتوبوس سوار شدنساعت هشت صبحهر دوساعتچک کردن ایمیلبررسی ایمیل های مهم پیگیری ایمیلهای مهمده دقیقه استراحتدوماه قبل از سفرانتخاب مقصدرزرو بلیطبستن چمدانهادو ماه قبل از سفرروز مادر ۱۰ صبحبیدار شدنخریدن دسته گلتقدیم دسته گلروز مادر ۱۱ صبح

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

Created with Raphaël 2.1.0احساس گرسنگیانتخاب پیتزاسفارش پیتزاپیتزا دریافت شدهمیل نمودن وعده غذاییپخت پاستاسی دقیقهبرطرف شدن گرسنگی

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

Created with Raphaël 2.1.0احساس گرسنگیانتخاب دستورالعمل آشپزیتهیه وعده غذاییچیدن میزده دقیقه قبل از پختمیل نمودن وعده غذاییبرطرف شدن گرسنگی

 

Error

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

 

Conditional

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

Created with Raphaël 2.1.0پیتزا فریز شده مطلوببرداشتن پیتزا از فریزرروشن کردن فردمای ۱۸۰ درجهگذاشتن پیتزا درون فرپیتزا حاضر استخوردن پیتزابرطرف شدن گرسنگی

 

Signal

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

Created with Raphaël 2.1.0پیتزا دیده شده در تلویزیونخرید پیتزاگرسنه شدنخوردن پیتزاشرکت در نظر سنجی

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

 

Termination

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

Created with Raphaël 2.1.0شروعوظیفه ۱وظیفه ۲پایان ۱وظیفه ۳پایان ۲سی دقیقهچهل و پنج دقیقهده دقیقه

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

Created with Raphaël 2.1.0شروعوظیفه ۱وظیفه ۲پایان ۱وظیفه ۳تکرار وظیفه ۲پایان ۲پایان فرآیندخیربلهچهل و پنج دقیقهسی دقیقهده دقیقه

 

از بین رویدادهای بکار رفته شده در BPMN، رویداد link یکی از موارد خاص به شمار می رود و هیچ ارتباطی با محتوای فرآیند ندارد اما روند نمودار فرآیند را می تواند تسهیل ببخشد. همانطور که در شکل زیر نشان داده شده است، شما می توانید از دو link مرتبط به هم به عنوان جایگزینی برای یک جریان توالی استفاده نمایید. در اینجا از یک throwing link event به عنوان نقطه خروج استفاده و از سوی دیگر از یک catching link event به عنوان نقطه ورود استفاده می شود و بدین ترتیب این دو رویداد را به عنوان یک جفت مرتبط با هم با و تحت عنوان یک اسم یکسان نامگذاری می کنیم که در مثال بالا هر دو رویداد A نامیده شده اند.

رویدادهای Link می توانند بسیار مفید باشند اگر:

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

نکته آخر اینکه رویدادهای Link تنها می توانند به عنوان رویدادهای میانی مورد استفاده قرار گیرند.

 

Compensation

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

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

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

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

Created with Raphaël 2.1.0جمعه ساعت۱بعدازظهرتنظیم تاریخبرنامه تنظیم شده؟رزرو بلیط تئاترتنظیم قرار ملاقاتجمعه ساعت ۶ بعدازظهرقصد رفتن دارید؟انجام فعالیتبرنامه چیست؟کنسل بلیط تئاترتماشای تلویزیونکنسل کردن قرارتماشای تئاتربیرون رفتن با دوستانبلهخیرتماشای تئاتربیرون رفتن با دوستان

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

Created with Raphaël 2.1.0جمعه ساعت۱بعداز‌ظهرتنظیم تاریخبرنامه تنظیم شدهرزرو بلیط تئاترتنظیم قرار ملاقاتکنسل کردن قرارجمعه ساعت ۶ بعداز ظهرقصد رفتن دارید؟انجام فعالیتلغو فعالیتتماشای تلویزیونکنسل بلیط تئاترتماشای تئاتربیرون رفتن با دوستانبلهخیر

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

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

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

 

Multiple

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

Created with Raphaël 2.1.0تبلیغات تلویزیون یا توصیه دوستانخرید پیتزاهوس کردن پیتزاخوردن پیتزا سایت نظرسنجی‌یالینکهای‌ارتباطی

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

Created with Raphaël 2.1.0pizza commercial seen on TVfriend recommended پیتزاخرید پیتزاهوس کردن پیتزاخوردن پیتزاشرکت در نظر سنجیsend evaluationto friend

 

Parallel

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

 

Escalation

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

 

Cancel

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





دسته‌ها: BPMN

0 دیدگاه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *