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

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

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

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

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

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

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

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

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

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

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

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

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

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

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