از مدل سازی فرآیند تا طراحی سیستم خودکار (قسمت 2)

"یک روز در زندگی یک سنجاب" یا از مدل سازی فرآیند تا طراحی یک سیستم خودکار حسابداری ثروت "Belka-1.0" (قسمت 2)

یک تصویر برای "داستان تزار سلتان" اثر A.S. پوشکین، منتشر شده توسط "ادبیات کودکان"، مسکو، 1949، لنینگراد، نقاشی های K. Kuznetsov استفاده شد.

خلاصه سری قبل

В قسمت 1 ما از یک دامنه «افسانه» استفاده کردیم که از نمونه‌هایی از یادگیری نمودارهای UML بر اساس طرح‌های افسانه الهام گرفته شده بود (برای مثال، به اینجا [1]). قبل از شروع مدل‌سازی، در مورد استفاده از برخی عناصر نمودار Activity به توافق رسیدیم و شروع به تشکیل یک توافق‌نامه مدل‌سازی کردیم. با در نظر گرفتن این توافقات، در مرحله اول فرآیند را در قالب نمودارهای فعالیت شرح دادیم و در مرحله دوم مراحل فرآیندی را که اتوماسیون برای آنها لازم است (و امکان پذیر است) شناسایی کردیم.

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

...
جزیره ای روی دریا قرار دارد، (E1، E2)
تگرگ در این جزیره وجود دارد (E3، E1)
با کلیساهای گنبدی طلایی، (E4)
با برج ها و باغ ها؛ (E5, E6)
درخت صنوبر جلوی قصر می روید، (E7، E8)
و زیر آن خانه ای بلورین است. (E9)
یک سنجاب رام در آنجا زندگی می کند، (A1)
بله، چه ماجراجویی! (A1)
سنجاب آهنگ می خواند، (P1، A1)
بله، او مدام آجیل می خورد، (P2)
اما آجیل ساده نیست، (C1)
تمام پوسته ها طلایی هستند (C2)
هسته زمرد خالص است. (C3)
خدمتکاران از سنجاب محافظت می کنند، (P3، A2)
آنها به عنوان خدمتگزاران مختلف به او خدمت می کنند (P4)
و یک منشی تعیین شد (A3)
یک حساب سختگیرانه از آجیل خبر است. (P5, C1)
ارتش به او سلام می کند. (P6، A4)
یک سکه از پوسته ها ریخته می شود، (P7، C2، C4)
اجازه دهید آنها در سراسر جهان بگردند. (P8)
دختران زمرد می ریزند (P9، A5، C3)
داخل انبارها و زیر پوشش. (E10, E11)
...
(A.S. پوشکین "داستان تزار سلتان، قهرمان باشکوه و توانا شاهزاده گیدون سالتانوویچ و شاهزاده زیبای سوان" اعتقاد بر این است که اقتباسی آزاد از داستان عامیانه "تا زانو در طلا، تا آرنج در نقره" است که توسط پوشکین در نسخه های مختلف نوشته شده است.)

در این مثال، من از محیط Enterprise Architect از یک شرکت استرالیایی استفاده می کنم. سیستم های اسپارکس [2]، و در طول جلسات آموزشی استفاده می کنم مدلیو [3].
اجازه دهید به شما یادآوری کنم که فرآیندهای مختلفی وجود دارد، می توانید به عنوان مثال آشنا شوید اینجا [4] و اینجا [5].
برای جزئیات بیشتر در مورد رویکردهای کاربردی برای مدل‌سازی و طراحی، [6، 7] را ببینید.
برای مشخصات کامل UML، نگاه کنید اینجا [8].

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

مرحله 3. مرحله خودکار باید با عملکرد یا عملکردهای سیستم مرتبط باشد

سیستم خودکار (AS) در حال توسعه برای حفظ سوابق دقیق از آجیل طراحی شده است، به یاد دارید؟ برای هر مرحله برجسته شده (شکل 3، شکل 4 را ببینید در قسمت 1) که ما آن را خودکار می کنیم، یک نیاز کاربردی را با استفاده از ساختار زیر بنویسیم: "سیستم باید توانایی ..." را پیاده سازی کند و یک نمودار Use-case ایجاد کند. ما اکنون در واقع قوانین جدیدی را به توافقنامه مدل سازی خود اضافه می کنیم. اجازه دهید توضیح دهم که از چه عناصری استفاده خواهیم کرد.

ما از اتصال "Association" بین "User Role" و "Function" استفاده خواهیم کرد (شکل 5)، به این معنی که کاربری با این نقش می تواند این عملکرد را انجام دهد.

شکل 5. با استفاده از یک رابطه نوع Association

از «تابع» تا «نیاز»، اتصال «پیاده‌سازی» را ترسیم می‌کنیم (شکل 6) تا نشان دهیم که این نیاز توسط این توابع پیاده‌سازی می‌شود؛ رابطه می‌تواند «بسیاری به چند» باشد، یعنی. ممکن است یک تابع در اجرای چندین الزام دخیل باشد و ممکن است برای اجرای یک نیاز به بیش از یک تابع نیاز باشد.

شکل 6. با استفاده از رابطه نوع "پیاده سازی".

اگر یک تابع برای اجرای خود نیاز داشته باشد که تابع دیگری اجرا شود و لزوماً از پیوند "وابستگی" با کلیشه "Include" استفاده خواهیم کرد (شکل 7). اگر اجرای یک تابع اضافی تحت شرایط خاصی مورد نیاز باشد، از اتصال "وابستگی" با کلیشه "Extend" استفاده خواهیم کرد. به خاطر سپردن همه چیز بسیار آسان است: "شامل" همیشه و "توسعه" گاهی اوقات است.

شکل 7. با استفاده از رابطه "وابستگی (شامل)".

در نتیجه، نمودار ما چیزی شبیه به این خواهد بود (شکل 8).

شکل 8. نمودار مورد استفاده (مدل عملکردی AC)

علاوه بر این، یک نمودار Use-case برای مدل سازی نقش های کاربر استفاده می شود (شکل 9).

شکل 9. نمودار مورد استفاده (نقش کاربران AS)

مرحله 4. بیایید سازمان داخلی AS را با استفاده از نمودار کلاس توصیف کنیم

با استفاده از اطلاعات مربوط به مصنوعات ورودی و خروجی فرآیند خود (به نمودارهای فعالیت - شکل 2، شکل 3، شکل 4 مراجعه کنید)، یک نمودار کلاس ایجاد خواهیم کرد. ما از عناصر مدل سازی "Class" و انواع مختلف اتصالات بین آنها استفاده خواهیم کرد.

برای نشان دادن رابطه "کل بخش"، از یک رابطه از نوع "Aggregation" استفاده می کنیم (شکل 10): مهره کل است و پوسته و هسته قطعات هستند.

شکل 10. رابطه کل بخش

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

شکل 11. نمودار کلاس

نمودار کلاس همچنین برای مدل‌سازی سایر مصنوعات - نه تنها آن‌هایی که به مدل مفهومی فرآیند خودکار حسابداری دارایی‌های مادی مربوط می‌شوند، بلکه به محیط اجرا نیز مرتبط هستند - محیط (شکل 12) و "همسایه" استفاده شد. فرآیندهایی (شکل 13) که می توانند بر فرآیند خودکار تأثیر بگذارند، اما هنوز در کانون توجه ما نیستند (فرض می کنیم که سیستم توسعه می یابد و این اطلاعات مفید خواهد بود).

شکل 12. نمودار کلاس (محیط)

رابطه وراثت تعمیم ساختمان‌های مختلف، طبقات «فرزند»، تحت کلاس تعمیم‌دهنده «والد» «ساختمان» را نشان می‌دهد.

شکل 13. نمودار کلاس (اطلاعات اضافی در مورد مصنوعات)

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

مرحله 5. بیایید یادداشت های مربوط به مسیر "قوانین تجاری" را تجزیه و تحلیل کنیم

قوانین مشخص شد (شکل 2 را ببینید در قسمت 1):

1. نیاز به تقسیم یکی از مراحل به 2 قسمت ، قسمت دوم فقط تحت شرایط خاصی شروع به اجرا می کند.
2. انتصاب یک مقام خاص برای انجام حسابداری آجیل؛
3. یک تکنیک (رنگ سفید عناصر) که نشان می دهد عنصر به صراحت در توضیحات فرآیند مشخص نشده است.

لازم به ذکر است که ما قبلاً از تمام این قوانین هنگام توسعه نمودارها استفاده کرده ایم.

اظهارات پایانی

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

شکل 14. ساختار بسته پروژه

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

از مدل سازی فرآیند تا طراحی سیستم خودکار (قسمت 1)

فهرست منابع

1. وب سایت "UML2.ru". انجمن تحلیلگران بخش عمومی. مثال ها. نمونه هایی از افسانه هایی که به صورت نمودارهای UML قالب بندی شده اند. [منبع الکترونیکی] حالت دسترسی: اینترنت: http://www.uml2.ru/forum/index.php?topic=486.0
2. وب سایت Sparx Systems [منبع الکترونیکی] حالت دسترسی: اینترنت: https://sparxsystems.com
3. وب سایت مدلیو [منبع الکترونیکی] حالت دسترسی: اینترنت: https://www.modelio.org
4. فرهنگ لغت دایره المعارفی بزرگ. فرآیند (تفسیر). [منبع الکترونیکی] حالت دسترسی: اینترنت: https://dic.academic.ru/dic.nsf/enc3p/246322
5. وب سایت "سازمان مدیریت موثر". وبلاگ. دسته "مدیریت فرآیندهای کسب و کار". تعریف فرآیند کسب و کار [منبع الکترونیکی] حالت دسترسی: اینترنت: https://rzbpm.ru/knowledge/pochemu-processy-stali-s-pristavkoj-biznes.html
6. گواهی شماره 18249 مبنی بر ثبت و سپرده گذاری یک اثر فعالیت فکری. Alfimov R.V.، Zolotukhina E.B.، Krasnikova S.A. نسخه خطی یک کمک آموزشی با عنوان "مدل سازی یک حوزه موضوعی با استفاده از معمار سازمانی" // 2011.
7. Zolotukhina E.B.، Vishnya A.S.، Krasnikova S.A. مدل سازی فرآیندهای کسب و کار - M.: KURS، NITs INFRA-M، EBS Znanium.com. - 2017.
8. مشخصات زبان مدلسازی یکپارچه OMG (OMG UML). نسخه 2.5.1. [منبع الکترونیکی] حالت دسترسی: اینترنت: https://www.omg.org/spec/UML/2.5.1/PDF

منبع: www.habr.com