مدلسازی با استاندارد BPMN (راهنمای نماد‌ها و نشانه‌ها)

مرور کلی بر نماد‌های BPMN

مروری بر نمادهای BPMN

 

 

 

---

مشارکت‌کنندگان

---

 

 

معرفی Pool  (استخر): رهبر ارکستر و نوازندگان

در BPMN می‌توان با استفاده از Laneها مسئولیت وظایف یا زیرفرایند‌ها را به مدیران مختلف تخصیص داد. Laneها (مسیرها) همیشه درون یک Pool قرار دارند و مرزهای آن‌ها، محدودهٔ یک فرایند را از آغاز تا پایان نشان می‌دهد. Pool جایگاهی بالاتر از Laneها دارد.  Pool کنترل فرایند را بر عهده می‌گیرد؛ به بیان دیگر، وظایف را تخصیص می‌دهد. رفتار آن مانند رهبر یک ارکستر است و به همین دلیل این نوع فرایند را «ارکستراسیون» می‌نامند.

در نمودار زیر، «رهبر ارکستر» برنامه‌ریزی می‌کند که به محض تکمیل وظیفهٔ ۱ توسط روبرت ، وظیفهٔ ۲ توسط  فالکو انجام شود. رهبر ارکستر بالاترین سطح کنترل فرایند را دارد و هر ساز در ارکستر همان نغمه‌ای را می‌نوازد که رهبر مشخص می‌کند.

 

 

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

در نمودار زیر، «رهبر ارکستر» برنامه‌ریزی می‌کند که به محض تکمیل وظیفهٔ ۱ توسط  روبرت، وظیفهٔ ۲ توسط  فالکو انجام شود. رهبر ارکستر بالاترین سطح کنترل فرایند را در اختیار دارد و هر ساز در ارکستر همان نغمه‌ای را می‌نوازد که رهبر مشخص می‌کند.

 

 

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

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

 

 

آیا دربارهٔ «ارکستراسیون سرویس» در ارتباط با معماری سرویس‌گرا (SOA) شنیده‌اید؟ این تقریباً همان کاری است که یک موتور فرایند انجام می‌دهد، با این تفاوت که این سرویس‌ها صرفاً سرویس‌های وب کاملاً خودکار نیستند؛ بلکه می‌توانند وظایفی باشند که توسط مشارکت‌کنندگان انسانی فرایند و تحت هدایت موتور فرایند اجرا می‌شوند.

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

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

با یک مثال، سودمندی این شیوهٔ جدید تفکر را نشان خواهیم داد. نکته‌ای که باید به خاطر داشت این است که اگر به‌دنبال همسویی بهتر میان مدل‌های عملکردی و فنی فرایند‌ها باشید تا ارتباط کسب‌وکار و IT بهبود یابد، ناگزیر با این نوع مدل‌سازی فرایند مواجه خواهید شد؛ چه از BPMN استفاده کنید و چه نه.

Poolها: هنر همکاری

پیش‌تر فرایندی را که در ادامه نشان داده شده است، در ارتباط با دروازهٔ مبتنی بر رویداد بررسی کردیم.

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

 

 

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

 

 

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

اگر از  Pool‌ها استفاده کنیم، کل فرایند همانند شکل زیر خواهد بود. هر دو فرایند در این نمایش ترکیبی دقیقاً همان شکلی را دارند که پیش‌تر داشتند، اما اکنون از طریق جریان پیام به یکدیگر متصل شده‌اند. در BPMN این نوع نمایش را «نمودار همکاری» (Collaboration Diagram) می‌نامند. این نمودار دو فرایند مستقل را نشان می‌دهد که با یکدیگر همکاری می‌کنند.

 

 

جمع کردن Poolها

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

به عنوان مشتری سرویس تحویل پیتزا، انتظار داریم که تحویل‌دهنده یا همان پیک:

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

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

در مدل‌سازی چنین مواردی، می‌توانیم فرایند تحویل‌دهنده را مخفی کنیم و Pool را جمع کنیم (collapse):

 

 

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

 

 

 Lanes- مسیر‌ها

ما دربارهٔ اینکه در فرایند‌های خود چه کارهایی باید انجام دهیم صحبت کرده‌ایم، اما هنوز توضیح نداده‌ایم که چه کسی مسئول اجرای هر وظیفه است. در BPMN، می‌توان با استفاده از مسیر‌ها یا Lanes به این سؤال پاسخ داد.

 

 

نمودار نشان می‌دهد که وظایف در فرایند نمونهٔ ما به افراد مشخصی اختصاص یافته‌اند. از روی این تخصیص‌ها می‌توانیم شرح فرایند زیر را استخراج کنیم: اگر کریستین گرسنه باشد، یک دستور پخت مشخص را انتخاب می‌کند. بسته به انتخاب کریستین، او یا خودش مسئول انجام آن می‌شود (مثلاً پاستا می‌پزد)، یا می‌تواند هم‌خانه‌هایش را درگیر کند. در حالت دوم، فالکو استیک می‌پزد و رابرت سالاد آماده می‌کند. در نهایت، کریستین غذا می‌خورد. سه Lane (کریستین، فالکو، رابرت) در یک Pool با عنوان «جامعهٔ هم‌خانه‌ای» متحد شده‌اند.

سوال متداول: آیا باید یک Lane را با نام یک فرد مشخص برچسب‌گذاری کنم؟

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

• موقعیت‌ها در سازمان اصلی، برای مثال کارمند حسابداری
• نقش‌ها در سازمان ثانویه، برای مثال مأمور حفاظت از داده
• نقش‌های عمومی، برای مثال مشتری
• دپارتمان‌ها، برای مثال بخش فروش
• نرم‌افزارهای IT، برای مثال سیستم CRM

 

---

فعالیت‌ها

---

 وظیفه -Task

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

 

 

نشانگرهای وظیفه –  Task Markers

علاوه بر انواع مختلف Task، می‌توان وظایف را با نشانگرهایی مانند «تکرار» (Loop)، چندنمونه‌ای (Multiple Instances)  یا جبرانی (Compensation) مشخص کرد. این نشانگرها می‌توانند با نوع تخصیص‌داده‌شدهٔ Task نیز ترکیب شوند.

Loop –  تکرار

یک Task از نوع Loop تا زمانی تکرار می‌شود که یک شرط تعریف‌شده برقرار باشد یا از بین برود. برای مثال، شاید ما چندین غذای مختلف به مهمانان شام پیشنهاد کنیم تا زمانی که همه روی یک گزینه توافق کنند. سپس می‌توانیم وعدهٔ غذایی را آماده کنیم:

 

 

در این مثال، ابتدا Task اجرا شد و سپس بررسی کردیم که آیا لازم است دوباره اجرا شود یا خیر. برنامه‌نویسان این اصل را به‌عنوان ساختار «do-while»  می‌شناسند. البته می‌توان از ساختار «while-do» هم استفاده کرد؛ یعنی شرط قبل از اجرای Task بررسی شود، نه بعد از آن. این حالت به‌ندرت رخ می‌دهد، اما زمانی منطقی است که ممکن باشد Task اصلاً اجرا نشود.

شما می‌توانید شرطی را که باعث اجرای اولیهٔ یک Loop Task می‌شود مشخص کنید، یا همان‌طور که در مثال نشان داده شده است، شرط تکرار را به‌صورت یک توضیح (annotation) به Task اضافه کنید. همچنین می‌توان این شرط را در ابزار BPMN خود به‌عنوان یک ویژگی (attribute) به زبان رسمی ذخیره کرد. این کار زمانی معنا پیدا می‌کند که قرار باشد فرایند توسط یک موتور فرایند (process engine) اجرا شود.

 Multiple Instance – چندنمونه‌ای

چرخه‌های متوالی یک Loop Task باید پشت سر هم انجام شوند. برای مثال، اگر در یک خانهٔ دانشجویی زندگی کنیم و هم‌خانه‌ها بخواهند پیتزا بخورند، وظیفهٔ «انتخاب پیتزا» باید برای هر هم‌خانه یک‌بار تکرار شود تا در نهایت بتوان سفارش داد. همه دور هم می‌نشینند و منو را دست‌به‌دست می‌کنند تا سرانجام هر کس تصمیمش را بگیرد.

اما روش بسیار کارآمدتر این است که همهٔ هم‌خانه‌ها همزمان به منو نگاه کنند و با هم پیتزا انتخاب کنند. این فرایند را می‌توان با استفاده از Task چندنمونه‌ای (multiple task) مدل‌سازی کرد (تصویر زیر). یک Task چندنمونه‌ای به‌طور مکرر ایجاد (instantiate) می‌شود و می‌تواند به‌صورت ترتیبی یا موازی اجرا گردد که حالت دوم (موازی) جالب‌تر است.

 

 

آیا این مثال به‌نظر شما اغراق‌آمیز است؟ شرکت شما چگونه فاکتورهای سفارش‌های گروهی، مانند ملزومات اداری، را بررسی می‌کند؟ آیا فاکتور را از یک کارمند به کارمند بعدی می‌فرستید تا هر کس آیتم‌هایی را که سفارش داده است تأیید کند و سپس فاکتور پرداخت شود؟ اگر چنین است، شما هم مانند یک «خانهٔ دانشجویی» عمل می‌کنید و باید فوراً به فکر بهینه‌سازی فرایندتان باشید. خودکارسازی فاکتورها همچنان یکی از پروژه‌های اصلی BPM است، و هدف کلیدی چنین پروژه‌هایی اغلب موازی‌سازی (parallelization) فرایند‌هاست.

Compensation  – جبرانی

مزیت رویداد جبرانی (compensation event) را با یک مثال توضیح می‌دهیم. نوع Task جبرانی تنها در بستر یک رویداد جبرانی به‌کار گرفته می‌شود. بنابراین، در نمودار فرایند تنها از طریق ارتباط‌ها (associations) نمایش داده می‌شود، نه از طریق جریان‌های دنباله‌ای  .(sequence flows)

ترکیب وظیفهٔ جبرانی با تکرار (loop) یا چندنمونه‌ای (multiple instance)، همان‌طور که در شکل زیر نشان داده شده، قابل توجه است. در این حالت، هر دو نشانگر به‌صورت موازی روی Task قرار می‌گیرند. همانند سایر نشانگرها، وظیفهٔ جبرانی را نیز می‌توان با انواع  Taskهایی که تاکنون معرفی کردیم ترکیب کرد. به این ترتیب، یک  Task جبرانی دستی که تا زمان موفقیت تکرار می‌شود یا بارها و حتی به‌صورت موازی اجرا می‌شود، در عمل بسیار کاربردی خواهد بود.

 

 

Subprocess – زیرفرایند

فشرده‌سازی پیچیدگی

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

امکان جزئی‌سازی از بالا به پایین (top-down refinement) یا تجمیع از پایین به بالا (bottom-up aggregation)  همان چیزی است که مرز میان یک مدل واقعی فرایند و یک فلوچارت ساده را مشخص می‌کند؛ و همچنین تفاوت میان نرم‌افزارهای پیشرفتهٔ BPM و صرفاً ابزارهای رسم نمودار را مشخص می‌کند.

BPMN برای پشتیبانی از نمایش گسترش‌پذیر/جمع‌شونده (expanding/collapsing view) ابزار زیرفرایند‌ها را در اختیار ما قرار می‌دهد. یک زیرفرایند توالی جزئیات را توصیف می‌کند، اما در نمودار فرایند والد دقیقاً به‌اندازهٔ یک Task فضا اشغال می‌کند. هم  Taskها و هم  زیرفرایند‌ها در کلاس فعالیت‌ها  قرار می‌گیرند و بنابراین به‌صورت مستطیل‌هایی با گوشه‌های گرد نمایش داده می‌شوند. تنها تفاوت در علامت مثبت است که نشان می‌دهد یک توالی جزئیات برای زیرفرایند ذخیره شده است:

 

 

این قابلیت چه سودی برای ما دارد؟ این موضوع بیشتر بستگی به آن دارد که ابزار BPMN شما چگونه از گزینه‌های زیر برای اتصال  زیرفرایند‌ها به فرایند والد پشتیبانی کند:

• نمایش در یک نمودار فرایند جداگانه: نماد زیرفرایند به یک نمودار مستقل لینک می‌شود. برای مثال، اگر ابزار BPMN شما مدل فرایند را در مرورگر وب نمایش دهد، با کلیک روی نماد، صفحهٔ جدیدی باز می‌شود که نمودار جزئیات را نشان می‌دهد.
• گسترش درون نمودار فرایند والد: فعالیتی که همراه با علامت مثبت نمایش داده می‌شود، یک زیرفرایند  جمع‌شده (collapsed subprocess) است. علامت مثبت نشان می‌دهد که می‌توانید روی آن کلیک کنید و زیرفرایند را گسترش دهید. مشخصات BPMN این امکان را در نظر گرفته است، هرچند همهٔ عرضه‌کنندگان ابزارها آن را پیاده‌سازی نمی‌کنند. نمودار زیر نشان می‌دهد که چگونه زیرفرایند  به‌طور مستقیم درون نمودار فرایند والد گسترش داده شده است. ابزاری که از این قابلیت پشتیبانی کند به شما اجازه می‌دهد زیرفرایند را مستقیماً در همان نمودار باز یا جمع کنید تا جزئیات نمایش داده شوند یا پنهان گردند.

 

 

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

جریان‌های دنباله‌ای (Sequence Flows) در هر دو حالت در لبهٔ چپ زیرفرایند پایان می‌یابند و جریان بعدی از لبهٔ راست آغاز می‌شود. این یعنی جریان‌ها مجاز نیستند از مرزهای زیرفرایند عبور کنند؛ نکته‌ای که بسیاری از مبتدیان نمی‌دانند و هنگام گسترش زیرفرایند می‌تواند مشکل‌ساز شود. برای درک بهتر، یک توکن (Token) را در نظر بگیرید که این‌گونه رفتار می‌کند:

• فرایند والد شروع می‌شود و یک توکن ایجاد می‌شود.
• توکن وظایف را طی می‌کند و به زیرفرایند می‌رسد، که باعث می‌شود فرایند والد یک نمونهٔ جدید از زیرفرایند ایجاد کند.
• درون زیرفرایند یک توکن جداگانه متولد می‌شود که از شروع تا رویداد پایان زیرفرایند پیش می‌رود، در حالی که توکن فرایند والد منتظر می‌ماند تا زیرفرایند تکمیل شود.
• زمانی که توکن زیرفرایند به رویداد پایان می‌رسد، مصرف (consumed) می‌شود و زیرفرایند پایان می‌یابد. اکنون توکن فرایند والد به سمت رویداد پایان خودش حرکت می‌کند.

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

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

پیوست‌کردن رویدادها  (Attaching Events)

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

 

 

وقتی پای رویدادهای پیام (Message )، زمان‌سنج (Timer) و شرطی (Conditional) در میان باشد، فرایند والد همیشه هنگام واکنش به شرایط بیرونی، زیرفرایند را متوقف می‌کند.

اما در مورد رویدادهای خطا (Error) ، ابطال (Cancellation) و تشدید  (Escalation)، این خودِ زیرفرایند است که رویدادها را تولید کرده و آن‌ها را به فرایند والد گزارش می‌دهد.

این موضوع آن‌قدرها هم که به نظر می‌رسد انتزاعی یا پیچیده نیست.

 

 

در پایینِ سمت راستِ نمودار بالا، وظیفهٔ تأمین کالا ممکن است شکست بخورد، زیرا آن کالا دیگر موجود نیست. از آن‌جا که تأمین کالا یک زیرفرایند سراسری (global subprocess) است، یک رویداد خطا (error event) را فعال می‌کند تا به فرایند والد اطلاع دهد که مشکلی رخ داده است. از نظر تجاری، این می‌تواند به این معنا باشد که مشتری‌ای که قصد خرید کالا را داشته، به فروشنده اطلاع می‌دهد که سفارش او به دلیل اتمام موجودی انجام نشده است.

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

رویداد سیگنال (Signal Event) دو نقش ایفا می‌کند. فرایند والد می‌تواند در حین اجرای یک زیرفرایند، به سیگنالی که از بیرون دریافت می‌شود واکنش نشان دهد؛ مشابه همان چیزی که در رویداد پیام  (Message Event)  رخ می‌دهد. اما ما همچنین از رویداد سیگنال برای این استفاده می‌کنیم که زیرفرایند بتواند چیزهایی غیر از خطا را به فرایند والد منتقل کند. دلیل اصلی این است که با رویداد پیام نمی‌توان این نوع ارتباط را مدل کرد. در BPMN فرض بر این است که ما همواره پیام‌ها را برای سایر مشارکت‌کنندگان که خارج از مرزهای Pool  (pool boundaries) ما هستند ارسال می‌کنیم؛ بنابراین ارتباط بین فرایند والد و زیرفرایند در این قالب نمی‌گنجد. ما از رویدادهای سیگنال برای ارتباط مستقیم و هدفمند استفاده نمی‌کنیم، بلکه برای انتشار عمومی اطلاعات استفاده می‌کنیم؛ شبیه تبلیغاتی که از رادیو پخش می‌شوند.

یک جایگزین بهتر که در BPMN 2.0  معرفی شده، رویداد تشدید (Escalation Event) است. زیرفرایند می‌تواند با استفاده از رویداد تشدید، مستقیماً به فرایند والد گزارش دهد، بدون آنکه پیام به‌عنوان پیام خطا در نظر گرفته شود. همچنین فرایند والد می‌تواند پیام‌های حاصل از رویدادهای تشدید را دریافت و پردازش کند، بدون آنکه زیرفرایند لغو شود، زیرا می‌توان رویدادهای میانی غیرمتوقف‌کننده (non-interrupting intermediate events)  را به آن متصل کرد.

 

 

 

فعالیت فراخوانی  (Call Activity)

ماژولار‌سازی و استفادهٔ مجدد

در نسخهٔ ۱.۲، BPMN  بین زیرفرایند‌های درج‌شده (embedded) و قابل استفاده مجدد (reusable) تفاوت قائل می‌شد و این تفاوت را با اختصاص یک ویژگی به زیرفرایند مشخص می‌کرد. در نسخهٔ ۲.۰، BPMN  این تمایز را از نظر اصول حفظ کرده است، اما تعریف آن متفاوت است. اکنون یک زیرفرایند به صورت ذاتی درج‌شده است و تنها با تعریف آن به‌عنوان یک زیرفرایند سراسری (global subprocess) و ارجاع به آن از طریق فعالیت فراخوانی (call activity) می‌توان از آن استفادهٔ مجدد کرد. از این رو، در ادامه به زیرفرایند‌های درج‌شده و زیرفرایند‌های سراسری اشاره خواهیم کرد.

یک زیرفرایند درج‌شده تنها می‌تواند در فرایند والد خود وجود داشته باشد. زیرفرایند درج‌شده نمی‌تواند شامل Pool‌ها (pools) یا مسیرها (Lanes) باشد، اما می‌توان آن را در داخل Pool یا مسیر فرایند والد قرار داد. علاوه بر این، یک زیرفرایند درج‌شده تنها می‌تواند یک رویداد شروع بدون شرط (none start event) داشته باشد؛ رویدادهای شروعی مانند پیام یا تایمر مجاز نیستند. اساساً، زیرفرایند درج‌شده چیزی بیش از یک حوزهٔ محدود شده در فرایند والد نیست و ممکن است دو هدف را دنبال کند:

• کپسوله‌سازی پیچیدگی‌ها )همان‌طور که پیش‌تر توضیح داده شد(
• بیان جمعی (collective statement) دربارهٔ بخشی از فرایند والد، با اتصال رویدادها یا قرار دادن نشانگرها؛ در ادامه با این گزینه بیشتر کار خواهیم کرد.

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

 

 

ارتباط یک زیرفرایند سراسری با فرایند والد خود به‌مراتب کمتر نزدیک است و این زیرفرایند‌ها می‌توانند Pool‌ها و مسیرهای و مخصوص خود را داشته باشند. می‌توان شرکت‌کننده‌ای که مسئول زیرفرایند است را به‌عنوان یک ارائه‌دهندهٔ خدمات برای چندین فرایند والد در نظر گرفت؛ این مانند یک مرکز خدمات مشترک (shared service center) است.

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

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

• نشانی صدور فاکتور
• تاریخ ارائهٔ خدمت
• توصیف خدمت انجام شده
• مبلغ قابل فاکتور شدن
• تاریخ پیش‌بینی شدهٔ پرداخت

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

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

ادهاک Adhoc

یک نشانگر که تنها برای زیرفرایند‌ها موجود است، ادهاک ad-hoc  نام دارد. آن را می‌توان با کاراکتر ~ شناسایی کرد، همان‌طور که در نمودار زیر نشان داده شده است.

 

 

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

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

هر کسی که این زیرفرایند را اجرا می‌کند، تصمیم می‌گیرد چه کاری انجام دهد و چه زمانی انجام دهد. می‌توان گفت که ماهیت «کم‌تر ساختاریافته» آنچه در این زیرفرایند رخ می‌دهد، کل ایدهٔ مدل‌سازی فرایند را به نوعی پوچ می‌کند؛ زیرا همان چیزهایی که بیشتر می‌خواهیم کنترل کنیم، یعنی چه اتفاقی می‌افتد و چه زمانی، در این زیرفرایند آزاد هستند.

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

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

می‌توان از زیرفرایند Ad-hoc برای نشانه‌گذاری وضعیتی که ممکن است نامطلوب باشد استفاده کرد. این کار می‌تواند گامی به سوی رویه‌ای استانداردتر باشد.

BPMN 2.0  مشخص می‌کند که کدام نمادها باید وجود داشته باشند، کدام می‌توانند، و کدام‌ها در زیرفرایند Ad-hoc ممنوع هستند:

• باید وجود داشته باشند: فعالیت‌ها
• می‌توانند وجود داشته باشند: اشیاء داده، جریان‌های توالی، ارتباط‌ها  (associations)، گروه‌ها، جریان‌های پیام، دروازه‌ها (gateways) و رویدادهای میانی
• ممنوع: رویدادهای شروع و پایان، نمادهای مکالمه و رقص‌آوایی‌ها

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

 

 

زیرفرایند رویدادی (Event Subprocess)

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

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

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

این نکته‌ها کمی انتزاعی است، اما می‌توان با یک مثال عملی نشان داد که زیرفرایند رویدادی چگونه کار می‌کند.

 

 

ما چند نفر از دوستان‌مان را برای شام دعوت کردیم. این کار زیرفرایند «آماده‌سازی شام» را فعال می‌کند که شامل انتخاب یک دستور غذا و سپس آماده کردن وعده غذایی است.

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

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

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

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

 

 

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

• پیام
• زمان‌سنج
• تشدید  (Escalation)
• شرطی
• سیگنال
• چندگانه
• چندگانه موازی

دو نوع دیگر وجود دارد که فقط برای زیرفرایند‌های رویدادی متوقف‌کننده کاربرد دارند:

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

---

دروازه‌ها (Gateways)

---

دروازه‌های انحصاری مبتنی بر داده (Data-based Exclusive Gateways)

 

 

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

نقطهٔ تصمیم‌گیری دربارهٔ کاری که بعداً باید انجام شود را دروازه (Gateway) می‌نامیم. تصمیم‌گیری بر اساس داده‌های موجود (دستور غذای انتخاب‌شده) انجام می‌شود و تنها یکی از مسیرها را دنبال می‌کنیم؛ این همان دروازهٔ انحصاری مبتنی بر داده است.

در مدل‌سازی اختصاری، «دروازهٔ انحصاری» را به صورت XOR نمایش می‌دهند.

توجه داشته باشید!

به یاد داشته باشید که دروازه یک وظیفه (Task) نیست! قبل از رسیدن به دروازه باید واقعیت‌ها و نیازها را مشخص کنید.

بهروش: قراردادهای نام‌گذاری

همان‌طور که در نمودار بالا نشان داده شده، سؤال کلیدی را قبل از دروازه قرار می‌دهیم. این قرارداد ما است که در پروژه‌هایمان ارزش خود را ثابت کرده است. پاسخ‌های ممکن روی مسیرهای موازی بعد از دروازه قرار می‌گیرند؛ همان‌طور که در مشخصات BPMN نمایش داده شده است.

ما همیشه با دروازه‌های XOR به این صورت کار می‌کنیم:

• فعالیتی که نیازمند تصمیم‌گیری است را مدل کنید.
• دروازه XOR را پس از آن مدل کنید.
• یک سؤال با پاسخ‌های انحصاری و متقابل ایجاد کنید.
• برای هر پاسخ ممکن، یک مسیر خروجی (یا جریان توالی) مدل کنید و مسیر را با همان پاسخ برچسب‌گذاری کنید.

BPMN برای دروازه‌های XOR از دو نماد مختلف استفاده می‌کند:

 

 

معنی آن‌ها یکسان است. ما همیشه نسخه‌ای را استفاده می‌کنیم که دارای علامت X است، زیرا کمتر ابهام ایجاد می‌کند.

دروازه‌های موازی (Parallel Gateways)

فرض کنید اکنون می‌خواهیم یک سالاد همراه غذا داشته باشیم. اگر بخواهید سالاد را در هر شرایطی داشته باشید، می‌توانید آن را همان‌طور که در این نمودار مدل شده است، مدل کنید:

 

 

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

با این حال، این یعنی باید ۲۳ یا حتی ۲۸ دقیقه صبر کنید تا بتوانید شروع به خوردن کنید. غیرقابل تحمل! واقعاً گرسنه هستید، اما چه می‌توان کرد؟ شاید به جای اینکه ابتدا سالاد را آماده کنید و سپس پاستا یا استیک را بپزید، همزمان روی هر دو کار کنید؛ به صورت موازی. نماد مناسب، دروازه موازی یا به اختصار دروازه AND است، همان‌طور که در اینجا نشان داده شده است:

 

 

نمودارسازی فعالیت‌ها به‌صورت موازی به معنای اجباری بودن اجرای هم‌زمان آن‌ها نیست. برخلاف مثال قبلی، لازم نیست که سالاد را قبل از شروع سایر فعالیت‌ها آماده کنید. با این حال، انجام موازی فعالیت‌ها زمان کل را ۱۰ دقیقه کاهش می‌دهد. این همان بهینه‌سازی کلاسیک فرایند است که تا حد ممکن وظایف را موازی می‌کنیم.

خودتان بررسی کنید: اگر همان فرایند را رسم کنیم، اما به دلیل کمبود فضا دروازه AND merge را حذف کنیم و مسیر فعالیت «آماده کردن سالاد» مستقیماً به XOR merge برود، چه اتفاقی می‌افتد اگر فرایند را اجرا کنیم و تصمیم به پختن پاستا بگیریم؟

توکن همانند همیشه در AND split ایجاد و سپس کپی می‌شود. به محض اینکه آماده کردن سالاد تمام شود، توکن از XOR merge عبور کرده و فعالیت «خوردن غذا» اجرا می‌شود. پنج دقیقه بعد، «پخت پاستا» نیز تکمیل می‌شود. توکن آن دوباره از XOR merge عبور کرده و «خوردن غذا» دوباره اجرا می‌شود! این رفتار همان چیزی نیست که ما می‌خواستیم.

 

 

دروازه‌های انتخابی مبتنی بر داده (Data-based Inclusive Gateways)

اگر بخواهیم فرایند خود را انعطاف‌پذیرتر کنیم. زمانی که گرسنه‌ایم، ممکن است بخواهیم:

• فقط سالاد بخوریم،
• هم سالاد و هم یک غذای اصلی مانند پاستا یا استیک بخوریم، یا
• فقط غذای اصلی بخوریم.

برای نمایش فشرده‌تر این شرایط، می‌توانیم از دروازه انتخابی مبتنی بر داده استفاده کنیم که به اختصار دروازه OR نامیده می‌شود. این دروازه به شما اجازه می‌دهد که یکی یا چند مسیر خروجی را هم‌زمان بسته به شرایط داده‌ها انتخاب کنید.

 

 

 

هشدار! در عمل، کار با دروازه‌های OR به سادگی مثال‌های بالا نیست. درک این موضوع آسان است که ادامهٔ فرایند به رسیدن یک نشانهٔ دیگر به نقطهٔ ادغام OR وابسته است. اما در نمودارهای پیچیده‌ای که در چندین صفحه گسترش یافته‌اند، دنبال‌کردن قوانین همگام‌سازی می‌تواند بسیار دشوار باشد.

دروازه‌های مبتنی بر رویداد  (Event-based Gateways)

پیش‌تر با دروازهٔ انحصاری مبتنی بر داده (XOR) آشنا شدیم که امکان انتخاب مسیرهای مختلف را بر اساس داده‌های در حال پردازش فراهم می‌کند. کاربران سایر نمادگذاری‌های فرایندی نیز با این نوع شاخه‌بندی آشنا هستند، اما BPMN راه دیگری هم برای طراحی مسیرهای فرایند به ما می‌دهد: دروازهٔ مبتنی بر رویداد، یا به اختصار «دروازهٔ رویداد». این دروازه مسیر را نه بر اساس داده، بلکه بر اساس رویدادی که بعداً رخ می‌دهد تعیین می‌کند.

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

 

 

همان‌طور که در اینجا می‌بینید، همه رویدادهای واسطه‌ای را نمی‌توان با دروازه مبتنی بر رویداد ترکیب کرد. با این حال، می‌توان آن را با وظیفه دریافت (Receive Task) ترکیب کرد.

 

 

---

رویدادها (Events)

---

مفاهیم پایه

تاکنون با دو عنصر جریان آشنا شدیم: وظایف (Tasks) و دروازه‌ها .(Gateways) وظایف چیزهایی هستند که باید انجام شوند و دروازه‌ها شرایطی را تعیین می‌کنند که چه زمانی باید انجام شوند. حالا سومین عنصر جریان چه چیزی است؟ همان چیزهایی که قرار است اتفاق بیفتند، یعنی رویدادها .(Events) رویدادها به اندازه کارها و دروازه‌ها برای مدل‌سازی فرایند‌ها در BPMN اهمیت دارند. ابتدا با برخی اصول پایه برای استفاده از آنها شروع می‌کنیم. ما پیش‌تر رویدادهای شروع (Start events)، میانی (Intermediate events)  و پایان (End events) را دیدیم. این سه نوع رویداد همچنین می‌توانند «دریافت‌کننده»  (Catching)  یا «ایجادکننده» (Throwing) باشند:

رویدادهای دریافت‌کننده رویدادهایی هستند که یک محرک مشخص دارند. این رویدادها وقتی رخ می‌دهند که محرک آنها فعال شود یا اتفاق بیفتد. به عنوان یک مفهوم ذهنی، کمی پیچیده است، بنابراین ساده‌سازی کرده و آنها را «رویداد دریافت‌کننده» می‌نامیم. نکته این است که این رویدادها مسیر فرایند را تحت تأثیر قرار می‌دهند و بنابراین باید مدل شوند. نتایج رویدادهای دریافت‌کننده می‌تواند شامل موارد زیر باشد:

• شروع فرایند
• ادامه مسیر فرایند یا یک مسیر فرعی
• لغو کار فعلی یا زیرفرایند
• استفاده از مسیر دیگر فرایند در حالی که یک کار یا زیرفرایند در حال اجراست

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

• در حین فرایند فعال شوند
• در پایان فرایند فعال شوند

همچنین می‌توانیم رویدادهای میانی متصل (Attached Intermediate Events) را در BPMN مدل کنیم. این رویدادها لزوماً نیاز به انتظار ندارند، اما فعالیت‌های ما، چه کارها و چه زیرفرایند‌ها، را قطع می‌کنند. این رویدادهای میانی «متصل» نامیده می‌شوند زیرا در مرز فعالیتی قرار می‌گیرند که می‌خواهیم آن را مختل کنند.

 

 

یک توکن که در طول فرایند حرکت می‌کند، به این صورت رفتار می‌کند:

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

در نسخه BPMN 1.2، به جز رویدادهای جبرانی، رویدادهای میانی متصل به‌طور اجتناب‌ناپذیر منجر به لغو فعالیت‌ها می‌شدند. BPMN 2.0 یک نماد جدید معرفی کرده است: رویداد میانی غیرمخاطره‌آمیز (Non-interrupting Intermediate Event)  این نام کمی عجیب به نظر می‌رسد، اما کاربردی است:

 

 

توکن در طول فرایند به این صورت حرکت می‌کند:

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

در بخش‌های بعدی، انواع رویدادهایی که هنگام کار با BPMN استفاده می‌شوند معرفی می‌شوند. همچنین توضیح می‌دهیم چگونه می‌توان به رویدادهای مختلف با استفاده از دروازه مبتنی بر رویداد (Event-based Gateway) واکنش نشان داد.

پیام (Message)

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

 

 

توجه! ما همیشه از رویداد میانی پرتابی (throwing intermediate event) راضی نیستیم. القای یک وظیفهٔ «ارسال پیام» بدون مدل‌سازی صریح آن می‌تواند مصرف‌کنندگان تازه‌کار مدل‌های ما را به‌راحتی سردرگم کند. به همین دلیل ترجیح می‌دهیم برای پیام‌ها از رویداد میانی پرتابی استفاده نکنیم و به جای آن از یک وظیفه (Task) بهره ببریم. در BPMN همچنین انواع ویژه‌ای از وظایف برای ارسال و دریافت پیام‌ها در نظر گرفته شده است.

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

 

 

زمان‌سنج  (Timer)

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

 

 

زمان بدون توجه به اینکه ما یا فرایندهایمان چه می‌کنیم پیش می‌رود، بنابراین رویدادهای زمان‌سنج تنها می‌توانند به‌عنوان رویدادهای آغازگر یا میانی از نوع «گیرنده» (catching starts) وجود داشته باشند.

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

 

 

با BPMN 2.0، رویدادهای زمان‌سنج غیرقطع‌کننده (non-interrupting) امکان‌پذیر شدند:

 

 

خطا Error

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

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

یک خطا در BPMN یک رویداد جدی به‌شمار می‌رود، بنابراین اگر از نوع «گیرنده» (Catching) باشد، تنها می‌توان آن را به‌عنوان یک رویداد میانی متصل مدل کرد. این بدان معناست که یک خطا در طول اجرای فعالیت باید به‌صورت خاصی مدیریت شود. در حالت «رویداد پرتاب‌کننده» (throwing event)، خطا تنها می‌تواند در پایان یک مسیر فرایند مدل شود تا شرکت‌کننده بداند که فرایند شکست خورده است. فرایند والد نیز باید این شکست را تشخیص دهد.

نمونه‌هایی از رویدادهای خطا را می‌توانید در بخش پیاده‌سازی مربوط به «زیر‌فرایندهای رویدادی» (Event Subprocesses) پیدا کنید.

شرطی  Conditional

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

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

 

 

سیگنال Signal

سیگنال‌ها شباهت زیادی به پیام‌ها دارند و به همین دلیل می‌توان آن‌ها را در BPMN همانند پیام‌ها به صورت رویداد مدل‌سازی کرد. نماد سیگنال یک مثلث است.

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

 

 

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

پس از امتحان پیتزای جدید، به سایت Pizzatest.de می‌رویم تا محصول جدید را ارزیابی کنیم. این یک سیگنال است. همچنین سیگنالی برای عموم مردم نیز محسوب می‌شود.

پایان‌بندی (Termination)

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

یک توکن که در طول فرایند حرکت می‌کند در تقسیم AND تکثیر می‌شود. نشانهٔ اول در وظیفهٔ ۲ به مدت ۴۵ دقیقه باقی می‌ماند؛ نشانهٔ دوم در وظیفهٔ ۳ به مدت ۳۰ دقیقه می‌ماند. نشانهٔ دوم ابتدا به رویداد none می‌رسد و در آنجا مصرف می‌شود. پس از ۱۵ دقیقهٔ دیگر، نشانهٔ اول به رویداد none بالایی می‌رسد و آن هم مصرف می‌شود. از آنجا که دیگر هیچ نشانه‌ای باقی نمی‌ماند، نمونهٔ فرایند پس از ۵۵ دقیقه پایان می‌یابد.

 

 

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

 

 

لینک Link

رویداد لینک یک مورد خاص است. این رویداد معنای محتوایی ندارد، اما روند ترسیم نمودار را ساده‌تر می‌کند. همان‌طور که در شکل زیر نشان داده شده، می‌توانید به‌جای یک جریان توالی (Sequence Flow) از دو لینک مرتبط استفاده کنید. منظور از «مرتبط» این است که یک رویداد لینک پرتابی (Throwing Link) به‌عنوان «نقطه خروج» و یک رویداد لینک گیرنده (Catching Link) به‌عنوان «نقطه ورود» وجود دارد و این دو رویداد به‌صورت یک جفت علامت‌گذاری می‌شوند که در مثال ما با نشانهٔ «A» مشخص شده است.

 

 

رویداد لینک می‌تواند بسیار مفید باشد اگر:

• باید نمودار فرایند را در چند صفحه توزیع کنید. لینک‌ها خواننده را از یک صفحه به صفحه بعد هدایت می‌کنند.
• نمودارهای فرایند جامع با جریان‌های دنباله‌ای متعدد رسم می‌کنید. لینک‌ها کمک می‌کنند از چیزی که در غیر این صورت ممکن است شبیه یک نمودار «اسپاگتی» به نظر برسد، جلوگیری شود.

رویدادهای لینک تنها می‌توانند به‌عنوان رویدادهای میانی استفاده شوند.

جبران  (Compensation)

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

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

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

 

 

می‌توانیم بخش انتهایی مدل را به‌صورت فشرده‌تر با یک رویداد جبران نشان دهیم، همان‌طور که در تصویر زیر مشاهده می‌کنید:

 

 

قوانین ویژه‌ای برای مدیریت جبران خسارت وجود دارد:

• رویدادهای جبران پرتابی به فرایند خودشان اشاره دارند، بنابراین این رویداد در محدوده همان poolمؤثر است. این نشان می‌دهد که این نوع رویداد با رویداد پیام پرتابی چه تفاوتی دارد.
• سایر رویدادهای متصل تنها زمانی مؤثرند که فعالیت‌هایی که به آن‌ها متصل شده‌اند فعال باقی بمانند. در مقابل، یک رویداد جبران متصل تنها زمانی مؤثر است که فرایند جبران را فعال کند و فعالیتی که جبران به آن متصل است، با موفقیت کامل شده باشد.
• رویدادهای جبران متصل از طریق ارتباط (association) به وظایف جبران متصل می‌شوند و نه از طریق جریان توالی (sequence flow) که در سایر مواقع رایج است. بدین ترتیب، BPMN تأکید می‌کند که جبران‌ها خارج از جریان عادی فرایند هستند و اجرای آن‌ها یک استثناء به شمار می‌آید.

بهروش: استفاده از رویدادهای جبران

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

چندگانه Multiple

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

 

 

بهروش: اجتناب از رویدادهای چندگانه

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

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

مدل موجود در اینجا همان فرایند را نشان می‌دهد، اما رویدادها به‌طور کامل مدل‌سازی شده‌اند.

 

 

رویداد موازی (Parallel)

رویداد موازی در BPMN 2.0 برای تکمیل رویداد چندگانه اضافه شد. در حالی که یک رویداد چندگانه گیرنده (catching)  دارای منطق XOR است، یعنی به محض وقوع یکی از رویدادهای دربرگیرنده فعال می‌شود، رویداد موازی از منطق AND استفاده می‌کند. این رویداد تنها زمانی رخ می‌دهد که همهٔ رویدادهای دربرگیرندهٔ آن رخ داده باشند. از آنجا که رویداد چندگانهٔ پرتاب‌کننده (throwing) ذاتاً دارای منطق AND است، در مشخصات استاندارد، رویدادهای موازی صرفاً به‌عنوان رویدادهای گیرنده تعریف شده‌اند.

رویداد تشدید  (Escalation)

در BPMN 2.0 رویداد تشدید اضافه شد. این رویداد عمدتاً برای نشان دادن ارتباط بین فرایند‌های والد و زیرفرایند‌ها استفاده می‌شود.

رویداد لغو (Cancel)

رویداد لغو تنها در زمینه تراکنش‌ها قابل استفاده است.