فرایندکاوی به‌عنوان سرویس

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

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

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

قسمت اول: تعاریف، محدوده و دامنه

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

مخاطبان این مطلب

مشخص نمودن مخاطبان این مطلب دشوار است؛ اما به‌طور کلی می‌توان اشخاص زیر را نام برد:

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

نمای موارد کاربری

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

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

برای مثال چنین سناریویی را درنظر بگیرید:

کاربری می‌خواهد فایل Log خود را در سامانه آپلود کند و مدل کشف شده از آن را ببیند.

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

نمونه‌ای از این فرایند اجرایی به‌صورت یک نمودار BPMN در شکل (2) نمایش داده شده است. این نمودار که در واقع Hand-off را نمایش می‌دهد، جابه‌جایی اطلاعات میان سرویس‌های مختلف به تصویر کشیده شده و جهت ادراک بهتر سناریوی بالا مفید است.

محدودیت‌ها

محدودیت‌های این پروژه را می‌توان به دو قسمت تقسیم نمود: (1) محدودیت‌های فنی شامل محدودیت‌های نرم‌افزاری، سخت‌افزاری و سایر موارد مرتبط؛ (2) محدودیت‌های سازمانی شامل محدودیت‌های ساختاری، بودجه‌بندی و غیره. به‌صورت کلی محدودیت‌های پروژه در جداول (1) و (2) آورده شده‌اند.

ویژگی‌های کیفی سناریو‌های عمومی

در جداول (3) تا (11) ویژگی‌های کیفی سناریو‌های عمومی مربوط به سرویس فرایندکاوی به‌ترتیب اهمیت آورده شده است. در این جداول یک یا چند سناریو نیز برای درک بهتر ویژگی کیفی و همچنین نحوۀ محاسبه ویژگی‌ها نوشته شده است.

1) قابلیت استفاده (Usability)

2) دسترسی پذیری (Availability)

3) کارایی(Performance)

4) توسعه‌پذیری(Modifiability)

5) امنیت (Security)

ویژگی‌های کیفی سناریو‌های خاص

در جداول (12) و (13) ویژگی‌های کیفی سناریو‌های خاص مربوط به سرویس فرایندکاوی به‌ترتیب اهمیت آورده شده است. در این جداول یک یا چند سناریو نیز برای درک بهتر ویژگی کیفی و همچنین نحوۀ محاسبه ویژگی‌ها نوشته شده است.

1) تحلیل گزارش‌ها و مدل‌ها به‌منظور بهینه‌سازی

2) اطمینان از گزارش‌ها و مدل‌های ایجاد شده در سیستم

ویژگی‌های کیفی

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

قسمت دوم: معماری سیستم

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

نمای کلی معماری

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

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

در شکل (3) نمایی کلی از سیستم فعلی نشان داده شده است. در این سیستم مولفه‌های مختلفی وجود دارند که در زیر به آن‌ها اشاره شده است:

• میکروسرویس Event Data Extraction: استخراج داده‌ها از فایل‌های Log و یا ایجاد داده‌های مصنوعی.
• میکروسرویس Event Data Transformation: پیش‌پردازش داده‌ها (مثلاً فیلترکردن) قبل از تجزیه و تحلیل.
• میکروسرویس Process Model Extraction: استخراج مدل از نگاره‌های رویدادها.
• میکروسرویس Process Model & Event Data Analysis: آنالیز مدل‌ها و نگاره‌ها و همچنین محاسبۀ معیارها.
• میکروسرویس Process Model Transformation: تبدیل مدل‌ها به اشکال مختلف. در این پروژه پیش‌فرض مدل براساس BPMN درنظر گرفته شده است.
• میکروسرویس Process Model Enhancement: غنی‌سازی گزارش‌ها و مدل‌های استخراج شده به‌منظور بهبود الگوریتم‌های استخراج.

نمای منطقی

نمای منطقی این سیستم به کمک نمودار کلاس (Class Diagram) ترسیم شده است. به‌صورت کلی چهار دیاگرام کلاس وجود دارند که در ادامه توضیح داده خواهند شد. همچنین به‌دلیل بدیهی بودن و همچنین عدم ارتباط به این پروژه، از ترسیم کلاس‌های مرتبط با ذخیره‌سازی و پایگاه داده خودداری شده است. در شکل‌های (4) تا (7) نمودار کلاس‌های BPMN، سرویس وب، مدیریت کاربران و فرایندکاوی آورده شده است.

کلاس BPMN مربوط به مدل خروجی فرایندکاوی است که در قسمت قبلی بیان شد. در این کلاس:

• از الگوی طراحی Proxy استفاده شده است که در آن کلاس BPMN Graph Impl در واقع کل زیر سیستم را کنترل می‌کند و به‌نوعی نمایندۀ کل آن است.
• از الگوی Private Data استفاده شده است که در آن اطلاعات کلاس‌ها فقط به همان کلاس مربوط شده و برای دسترسی به اطلاعات باید از set و یا get استفاده کرد.

کلاس Web Service مربوط به صفحات تحت وب است که در قسمت قبلی بیان شد. در این کلاس:

• از الگوی طراحی Composite استفاده شده است که در آن فُرم درخت‌گونه مشهود است.
• از الگوی طراحی Singleton استفاده شده است که در آن فقط یک نمونه از کلاس Web Page Controller وجود دارد که اقدام به ساخت صفحات وب می‌کند.

کلاس User Management مربوط به کاربران است که در قسمت قبلی بیان شد. در این کلاس:

• از الگوی طراحی Singleton استفاده شده است که در آن فقط یک نمونه از کلاس‌های Login Controller و User Controller وجود دارد که جهت مدیریت کاربران استفاده می‌شود.
• از الگوی طراحی Proxy استفاده شده است که در آن کلاس User Service Impl در واقع کل زیر سیستم را کنترل می‌کند و به‌نوعی نمایندۀ کل آن است.
• از الگوی Private Data استفاده شده است که در آن اطلاعات کلاس‌ها فقط به همان کلاس مربوط شده و برای دسترسی به اطلاعات باید از set و یا get استفاده کرد.

کلاس Process Mining مربوط به استخراج فرایند است که در قسمت قبلی بیان شد. در این کلاس:

• از الگوی طراحی Singleton استفاده شده است که در آن فقط یک نمونه از کلاس Log Handler وجود دارد که جهت مدیریت کاربران استفاده می‌شود.
• از الگوی طراحی Proxy استفاده شده است که در آن کلاس Miner Impl در واقع کل زیر سیستم را کنترل می‌کند و به‌نوعی نمایندۀ کل آن است.
• از الگوی Private Data استفاده شده است که در آن اطلاعات کلاس‌ها فقط به همان کلاس مربوط شده و برای دسترسی به اطلاعات باید از set و یا get استفاده کرد.

نمای فیزیکی

نمای فیزیکی این سیستم به کمک نمودار استقرار (Deployment Diagram) ترسیم شده است. شکل (8) نشان‌دهندۀ نمای فیزیکی سیستم است. طبق آنچه در قسمت نمای معماری کلی گفته شد، سیستم از سه قسمت برای استقرار تشکیل می‌شود: سرویس وب، محل ذخیره‌سازی و برنامۀ کاربردی. سرویس وب در واقع همان Host یا میزبان است. محل ذخیره‌سازی می‌تواند با Host یکسان باشد اما برای نمایش بهتر و درک عمیق‌تر از یکدیگر جدا ترسیم شده است. برنامۀ کاربردی نیز قسمت‌های مختلف کُد است که مهمترین آن‌ها، برنامۀ استخراج فرایند به‌شمار می‌رود.

نمای پیاده‌سازی

نمای پیاده‌سازی این سیستم به کمک نمودار مولفه (Component Diagram) ترسیم شده است. شکل (9) نشان‌دهندۀ نمای پیاده‌سازی سیستم است. روند کلی آن است که سرویس Http Request Handler به‌عنوان یک Mediator عمل کرده و درواقع درخواست‌ها را به سرویس‌های مختلف ارسال نموده و پاسخ‌ آن‌ها را دریافت نموده و به کاربر ارائه می‌دهد. به همین ترتیب سایر سرویس‌ها نیز با ارائه درخواست عملیاتی را انجام داده و پاسخ آن را به فرستنده بازمی‌گردانند.

نمای فرایند

نمای فرایند این سیستم به کمک نمودار فعالیت (Activity Diagram) ترسیم شده است. برای مشاهدۀ تمامی نمودارهای فعالیت لطفاً به این لینک مراجعه کنید. نمایش تمامی نمودارهای فعالیت در این مطلب جاگیر و خسته کننده است؛ لذا در شکل (10) فقط به چندین نمونه از آن اشاره شده است.

قسمت سوم: پیاده‌سازی

پیاده‌سازی این سیستم با زبان Java انجام شده است و کُدهای آن در ریپازیتوری گیت‌هاب موجود است. کدهای منتشر شده همگی به‌صورت یک قالب کلی بوده و فاقد دستورات ترتیبی هستند. در واقع آن‌ها نمایندۀ یک معماری کلی جهت سرویس فرایندکاوی هستند. شاخه‌بندی کُدها به‌صورت مرکب است؛ یعنی مثلاً کلاس Node یک زیرشاخه از کلاس BPMN است و لذا در فولدر جداگانه در داخل همان کلاس به‌نام Elements نگهداری می‌شود. برای استفاده از کلاس‌های مختلف از مرجع‌دهی استاندارد استفاده شده است. مثلاً برای ارجاع به کلاس Node باید از BPMN.Elements.Node استفاده کرد.

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

public SwimLane[] getLanes() 
{
		return this._lanes;
}

در واقع این تابع عملیات خاصی را انجام نمی‌دهد و فقط برای دستیابی به فیلدها تعبیه شده است.

در کلاس‌هایی که با Impl پایان می‌یابند (کلاس‌های Proxy) فقط توابع آورده شده‌اند و این توابع باید به کلاس پروکسی مربوطه وصل شوند. برای مثال این قطعه کد مربوط به کلاس UserServiceImpl است:

package UserManagement;
public interface UserServiceImpl
 {
	public void addUser(User aUser);
	public void disableUser(User aUser);
	public void changePassword(User aUser, String aPwd);
	public void updateUser(object[] aDetails);
	public void addCredential(Credential aCred);
	public void removeCredential(Credential aCred);
	public void checkUserDetails(User aUser);
	public void login(String aUsername, String aPwd);
	public void logout(String aSession);
	public void register(object[] aDetails);
}

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

قسمت آخر: نتیجه‌گیری و کارهای آینده

در این مطلب معماری یک سرویس فرایندکاوی ارائه شد. ابتدا به نیازمندی‌ها، محدودیت‌ها، ویژگی‌های کیفی و دامنۀ مبحث پرداخته شد و روند کلی یک سناریوی فرضی ارائه شد. در ادامه به کمک نماهای 1+4، معماری این سیستم تشریح شده و سپس نمودارهای کلاس، مولفه و پیاده‌سازی تشریح شدند. درنهایت نیز توضیحات کوتاهی مربوط به کُدهای پیاده‌سازی ارائه شد.

برای تکمیل این پروژه در آینده می‌توان عملیات زیر را نام برد:

• تکمیل کدهای مربوط به نگهداری فایل‌ها و پایگاه‌های داده.
• تکمیل کدهای داخلی و ارتباط توابع با یکدیگر.
• اضافه کردن مدل‌های الگوریتم‌های فرایندکاوی به‌عنوان پلاگین‌های قابل نصب.

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

1. این مستند یک نوشتۀ فنی و بررسی شده نیست و نباید آن را به چشم یک مرجع یا رفرنس برای پروژه‌های عملی در دنیای واقعی مشاهده نمود.
2. این مستند پیشنهادی نیست؛ یعنی هیچ پیشنهادی دربارۀ توسعه، اولویت‌بندی، روش و تکنولوژی سیستم فرایندکاوی نمی‌دهد، حتی اگر پیشنهاد دادن در متن آمده باشد. تصمیم صحیح و یا غلط بودن مطالب ذکر شده در این مستند به عهدۀ خواننده است.
3. این مستند تاییدی نیست؛ مطالب ذکر شده در این مستند هیچ روش و تکنیک خاصی را تایید و یا رد نمی‌نمایند.
   

مراجع

A. Augusto, R. Conforti, M. Dumas, M. La Rosa, A. Polyvyanyy, Split miner: automated discovery of accurate and simple business process models from event logs, Knowledge and Information Systems. 2019, 59, 251–284.
I.H. Kwon, Book Review: Process Mining: Discovery, Conformance and Enhancement of Business Processes, 2014.
A. Augusto, R. Conforti, M. Dumas, M. La Rosa, F.M. Maggi, A. Marrella, M. Mecella, A. Soo, Automated Discovery of Process Models from Event Logs: Review and Benchmark, IEEE Transactions on Knowledge and Data Engineering. 2019, 31, 686–705.
J. De Weerdt, M. De Backer, J. Vanthienen, B. Baesens, A multi-dimensional quality assessment of state-of-the-art process discovery algorithms using real-life event logs, Information Systems. 2012, 37, 654–676.
J.C.A.M. Buijs, B.F. Van Dongen, W.M.P. Van Der Aalst, On the role of fitness, precision, generalization and simplicity in process discovery, in: Lecture Notes in Computer Science, Springer, Berlin, Heidelberg: pp. 305–322.
R. Conforti, M. Dumas, L. García-Bañuelos, M. La Rosa, Beyond tasks and gateways: Discovering BPMN models with subprocesses, boundary events and activity markers, Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). 2014, 8659 LNCS, 101–117.
R. Conforti, M. Dumas, L. García-Bañuelos, M. La Rosa, BPMN Miner: Automated discovery of BPMN process models with hierarchical structure, Information Systems. 2016, 56, 284–303.
T. Molka, D. Redlich, M. Drobek, X.J. Zeng, W. Gilani, Diversity guided evolutionary mining of hierarchical process models, GECCO 2015 - Proceedings of the 2015 Genetic and Evolutionary Computation Conference. 2015, 1247–1254.
S.K.L.M. vanden Broucke, J. De Weerdt, Fodina: A robust and flexible heuristic process discovery technique, Decision Support Systems. 2017, 100, 109–118.
K. Diba, K. Batoulis, M. Weidlich, M. Weske, Extraction, correlation, and abstraction of event data for process mining, Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery. 2020, 10, 1–31.
S. Katoch, S.S. Chauhan, V. Kumar, A review on genetic algorithm: past, present, and future, Multimedia Tools and Applications, 2021.
J. Mendling, H.A. Reijers, W.M.P. van der Aalst, Seven process modeling guidelines (7PMG), Information and Software Technology. 2010, 52, 127–136.
I. Zakarija, F. Škopljanac-Mačina, B. Blašković, Automated simulation and verification of process models discovered by process mining, Automatika. 2020, 61, 312–324.
O. Kramer, Genetic Algorithm Essentials, 2017.
A. Adriansyah, B.F. Van Dongen, W.M.P. Van Der Aalst, Conformance checking using cost-based fitness analysis, in: Proceedings - IEEE International Enterprise Distributed Object Computing Workshop, EDOC, : pp. 55–64.
A. Adriansyah, J. Munoz-Gama, J. Carmona, B.F. van Dongen, W.M.P. van der Aalst, Measuring precision of modeled behavior, Information Systems and E-Business Management. 2015, 13, 37–67.
W.M.P. Van Der Aalst, K.M. Van Hee, A.H.M. Ter Hofstede, N. Sidorova, H.M.W. Verbeek, M. Voorhoeve, M.T. Wynn, Soundness of workflow nets: Classification, decidability, and analysis, Formal Aspects of Computing. 2011, 23, 333–363.
M. Camargo, M. Dumas, O. González-Rojas, Learning Accurate Business Process Simulation Models from Event Logs via Automated Process Discovery and Deep Learning, 2021,.
J. Munoz-Gama, J. Carmona, Enhancing precision in Process Conformance: Stability, confidence and severity, IEEE SSCI 2011: Symposium Series on Computational Intelligence - CIDM 2011: 2011 IEEE Symposium on Computational Intelligence and Data Mining. 2011, 184–191.
J. De Weerdt, M. De Backer, J. Vanthienen, B. Baesens, A robust F-measure for evaluating discovered process models, IEEE SSCI 2011: Symposium Series on Computational Intelligence - CIDM 2011: 2011 IEEE Symposium on Computational Intelligence and Data Mining. 2011, 148–155.