https://virgool.io/feed/@alihanifi fa 2026-06-16 17:57:50 https://files.virgool.io/upload/users/1322963/avatar/1mNvWY.jpeg?height=120&width=120 https://virgool.io/@alihanifi https://virgool.io/@alihanifi/%D9%86%D8%AD%D9%88%DB%80-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%BE%D9%84%D8%A7%DA%AF%DB%8C%D9%86-%D8%A8%D8%B1%D8%A7%DB%8C-prom-cjjrpa0ja6mz آیا تابحال براتون پیش اومده که دنبال یکسری مطالب درسی و آکادمیک باشید و هیچ‌جا پیداش نکنید؟ این مسئله برای من که در زمینۀ نرم‌افزار فعالیت دارم، بارها و بارها اتفاق افتاده. منظورم فقط منابع فارسی نیست، بلکه بعضی اوقات درمورد منابع انگلیسی هم چنین مسئله‌ای رو تجربه کردم. شاید شما که این مطلب رو میخونی و مهندس کامپیوتر هم هستی، بگی که خُب موردی نداره، برو داخل سایت StackOverflow بعد سوالت رو مطرح کن و جواب بگیر؛ و البته این پاسخ شما درست هست، اما ...اما در پروژه‌های مقیاس بزرگ و کارهایی که یک جواب ساده ندارند، پرسش و پاسخ خیلی آدم رو درگیر میکنه و نیازمند گذاشتن وقت زیادی هست. خلاصه سَرتون رو درد نیارم، خوندن یک پُست ساده در ویرگول اونهم به زبان فارسی، خیلی ساده‌تر از 100 تا پرسش و پاسخ مختلف و پیدا کردن و خوندن کلی مطلب متفاوت هست.پُستی که در حال بازدیدش هستید، نحوۀ توسعۀ یک پلاگین ساده برای نرم‌افزار ProM هست. اگر با ProM آشنایی ندارید که خُب این مطلب برای شما فایده‌ای نداره؛ درغیراینصورت اگر با ProM آشنا هستید و قبلاً باهاش کار کردید و الآن قصد این رو دارید که یک پلاگین جدید براش بسازید، این پُست رو بخونید.فاز اول: آماده‌سازیدر فاز اول، آماده‌سازی محیط رو براتون خواهم گفت و در ادامه به بحث توسعۀ پلاگین خواهیم پرداخت.1) دانلود و نصب JDKاول از همه باید بدونید که کل عملیات توسعۀ پلاگین در ProM با زبان جاوا هست. بنابراین اول JDK باید روی کامپیوتر شما نصب باشه. پیشنهاد میشه که JDK 8 رو نصب کنید. البته نسخه‌های بالاتری هم وجود داره که بنده شخصاً تست نکردم. برای دانلود و نصب JDK یک ویدئوی عالی وجود داره که می‌تونید از این لینک اون ببینید.2) دانلود و نصب Eclipseبرای نوشتن یک پلاگین، به محیط برنامه‌نویسی احتیاج داریم. به همین دلیل باید Eclipse روی کامپیوتر شما نصب شده باشه. میتونید از این لینک برنامه رو دانلود و نصب کنید.3) نصب Ivy روی Eclipseپلاگین Ivy در واقع برای مدیریت Dependency استفاده میشه. برای نصب Ivy اول برنامۀ Eclipse رو باز کنید و بعدش منوی Help رو باز کنید و دکمۀ Install New Software رو بزنید. داخل پنجرۀ جدیدی که باز میشه جلوی Work with لینک زیر رو کپی کنید و دکمۀ Enter روی کیبورد رو بزنید:http://www.apache.org/dist/ant/ivyde/updatesiteاگر خطایی نشون داده شد، ممکنه به این دلیل باشه که به‌خاطر تحریم‌ها این آدرس قابل دسترسی نباشه و پیشنهاد می‌کنم که از یک پروکسی (VPN) استفاده کنید. پس از کمی صبر کردن چند گزینه ظاهر خواهد شد که باید IvyDE plugin رو انتخاب کرده و نصب رو ادامه بدید.اگر در نصب کردن Ivy به مشکل برخوردید، پیشنهاد می‌کنم که این ویدئو رو تماشا کنید که نکات نصب پلاگین روی Eclipse داخلش توضیح داده شده.لینک اصلی پروژۀ Ivy در قسمت زیر آورده شده و اگر Update Site (لینک بالا) از کار افتاد، می‌تونید از طریق پروژۀ اصلی اون رو پیدا کنید:https://ant.apache.org/ivy/ivyde/index.htmlضمناً پلاگین Ivy در Marketplace برنامۀ Eclipse هم موجود هست اما من نتونستم از Marketplace نصب رو انجام بدم. بعد از تمام شدن نصب ممکنه Eclipse از شما بخواد که نرم‌افزار رو ری‌استارت کنید که شما اینکار رو انجام ندید.4) نصب Subclipse روی Eclipseپلاگین Subclipse در واقع برای کنترل ورژن استفاده میشه. برای نصبش دقیقاً مثل مرحلۀ سوم لینک زیر رو برای نصب وارد کنید:https://subclipse.github.io/updates/بعد از وارد کردن گزینه‌های Core SVNKit Library و Subclipse رو انتخاب کنید و نصب رو انجام بدید. لینک اصلی پروژۀ Subclipse در قسمت زیر آورده شده و اگر Update Site (لینک بالا) از کار افتاد، می‌تونید از طریق پروژۀ اصلی اون رو پیدا کنید:https://github.com/subclipse/subclipseبعد از کامل شدن نصب Eclipse پیغام ری‌استارت شدن میده که این‌بار برنامه رو ری‌استارت کنید تا نصب تکمیل بشه و بتونید از پلاگین‌ها استفاده کنید.5) اضافه کردن پروژهبعد از اینکه برنامۀ Eclipse مجدداً باز شد، روی گزینۀ File کلیک کنید و بعدش این مسیر رو دنبال کنید:New => Project => Other => SVN => Checkout Projects from SVNدر پنجره‌ایی که باز میشه دو گزینه وجود داره؛ باید گزینۀ Create a new repository location رو انتخاب کنید و در پنجرۀ بعدی این آدرس رو بدید:https://svn.win.tue.nl/repos/promبعد از اینکه محتویات آدرس بارگزاری شد، مسیر پوشۀ Packages/Workshop/Trunk رو انتخاب کنید و در نهایت دکمۀ Next و رو بزنید؛ نهایتاً از شما یک اسم پروژه می‌خواد که پیشنهاد می‌کنم بگذارید همون Workshop باقی بمونه که کارهای بعدی آسون‌تر باشه. درنهایت دکمۀ Finish رو بزنید. 6) راه‌اندازیبعد از اینکه پروژۀ جدید اضافه شد، روی اسم پروژه کلیک کنید و از طریق منوی Ivy گزینۀ Resolve رو بزنید. اگر همه چیز درست انجام شده باشه اروری بوجود نخواهد اومد و فقط چند تا Warning نشون داده میشه که مهم نیستند. البته این قسمت ممکنه کمی طولانی بشه.برای Run کردن روی دکمۀ Play کلیک کنید و گزینۀ ProM with UITopia رو بزنید. در این مرحله برنامه راه‌اندازی میشه و شروع میکنه به دانلود کردن کتابخانه‌ها که این مرحله زمان‌بَر هست. ضمناً استفاده از پروکسی در این مرحله هم برای بنده ضروری بود. بعد از اینکه نصب‌ها انجام شد، برنامه ProM راه‌اندازی میشه.نکات آماده‌سازی1. اکثر مشکلاتی که ممکن هست در زمان نصب پلاگین‌ها یا دانلود کتابخانه‌ها بوجود بیاد، از بابت تحریم کشور ایران هست و با استفاده از پروکسی حل خواهد شد.2. معمولاً به هنگام نصب در Eclipse، پنجره‌ها پنهان میشن ولی در قسمت سمت چپ - پایین، می‌تونید مقدار انجام شدنش رو ببینید. همچنین در منوی Console هم عملیات نمایش دادن میشن.3. دانلود کتابخانه‌ها در قسمت ششم ممکنه حتی تا چندین ساعت زمان ببره. شکیبا باشید.فاز دوم: توسعهتا اینجای کار راجع‌به راه‌اندازی اولیه گفتیم. حالا به سراغ اصل مطلب خواهیم رفت و توسعۀ پلاگین رو توضیح خواهیم داد.1) با زبان جاوا آشنا بشیدهمونطور که قبلاً گفته شد، طراحی و ساخت یک پلاگین برای ProM به یادگیری زبان جاوا احتیاج داره و برای توسعۀ پلاگین در ProM باید به این زبان مسلط باشید؛ درغیراینصورت کامل متوجه همه چیز نخواهید شد و عملاً علت رخ دادن بعضی وقایع رو متوجه نمی‌شید. برای یاد گرفتن زبان جاوا منابع بسیار عالی حتی به زبان فارسی موجود هست. من شخصاً وبسایت w3schools رو برای یادگیری پیشنهاد می‌کنم.2) کدهای آماده رو مشاهده کنیددر ریپازیتوری‌های وبسایت ProM کدهای تستی آماده‌ای موجود هست که می‌تونید از طریق مسیر پوشه زیر اون‌ها رو به‌عنوان پروژه در Eclipse بارگذاری کنید و استفاده ببرید:Packages/GettingStarted/Trunk3) کد نمونه یک پلاگین سادهدر اینجا یک نمونه کد برای یک پلاگین ساده آورده شده که به‌صورت زیر هست:package org.processmining.plugins.gettingstarted; import org.processmining.contexts.uitopia.annotations.UITopiaVariant; import org.processmining.framework.plugin.PluginContext; import org.processmining.framework.plugin.annotations.Plugin; public class HelloWorld { @Plugin( name = &quotMy Hello World Plugin&quot, parameterLabels = {}, returnLabels = { &quotHello world string&quot }, returnTypes = { String.class }, userAccessible = true, help = &quotProduces the string: 'Hello world'&quot ) @UITopiaVariant( affiliation = &quotMy company&quot, author = &quotMy name&quot, email = &quotMy e-mail address&quot ) public static String helloWorld(PluginContext context) { return &quotHello World" } }با همین چند خط شما می‌تونید یک پلاگین جدید به نام HelloWorld رو ایجاد کنید. با یادگیری این مراحل اولیه، شما می‌تونید هر پلاگین دلخواهی رو به نرم‌افزار ProM اضافه کنید. امیدوارم تونسته باشم بهتون کمک کنم. علی حنیفی علی حنیفی Fri, 21 Oct 2022 12:34:36 +0330 https://virgool.io/CTO-insight/process-mining-as-a-service-kheoiro0qphn امروزه سیستم‌های اطلاعاتی بیش از گذشته در فرایندهای عملیاتی دخیل هستند و به همین دلیل مشخصات رویدادهای بسیاری توسط این سیستم‌ها ذخیره می‌شوند. هدف فرایندکاوی، استفاده از این اطلاعات رویدادها و استخراج فرایندهای عملیاتی از آن‌هاست. فرایندکاوی این امکان را فراهم می‌سازد که بتوان با استفاده از لیست رویدادهای عملیاتی کسب‌وکار که در سیستم‌های اطلاعاتی ذخیره شده‌اند، اطلاعاتی راجع به نحوه انجام کار و بهینگی آن بدست آورد.از سوی دیگر، اصطلاح سرویس به مجموعه‌ای از عملکردهای نرم‌افزاری با هدفی اشاره دارد که مشتریان مختلف می‌توانند از آن برای اهداف مختلف، همراه با یکسری سیاست‌هایی کنترلی، مجدداً استفاده کنند. بنابراین موضوع فرایندکاوی به‌عنوان سرویس، به مفهومی اشاره دارد که در آن یک سرویس قابل استفادۀ مجدد که در آن می‌توان با ارائۀ یک نگارۀ رویدادها را به‌عنوان ورودی، یک مدل فرایند به‌عنوان خروجی دریافت می‌شود، تعریف نمود.مطلبی که پیش روی خود می‌بینید، در واقع یک مستند معماری نرم‌افزار است که جهت ارائۀ یک معماری یکپارچه فرایندکاوی ترکیبی ایجاد شده است. نام این پروژه عبارتست از «ارائۀ یک معماری مناسب برای رویکرد ترکیبی فرایندکاوی به‌عنوان سرویس» و خروجی این پروژه عبارتست از یک معماری نرم‌افزار فرایندکاوی به‌عنوان سرویس. تمامی خروجی‌ها در قالب نمودارهای UML و توسط نرم‌افزار Visual Paradigm ترسیم شده و تمامی فایل‌های خروجی این پروژه به‌صورت متن‌باز در گیت‌هاب منتشر شده‌اند. برای مشاهده ریپازیتوری گیت‌هاب لطفا از این لینک دیدن فرمایید.قسمت اول: تعاریف، محدوده و دامنههدف این مطلب، ارائۀ توضیحات و تشریح یک معماری یکپارچه جهت سیستم‌های فرایندکاوی ترکیبی بوده و به پنج قسمت کلی تقسیم می‌شود: قسمت اول شامل تعاریف، محدوده و دامنۀ معماری است. قسمت دوم به نماهای مختلف معماری (منطقی، پیاده‌سازی و غیره) پرداخته و در قسمت سوم نیز، پیاده‌سازی بیان شده و برخی قطعات کد معرفی می‌شوند. درنهایت قسمت چهارم به جمع‌بندی اختصاص دارد. پیشنهاد می‌شود که این قسمت‌ها به‌ترتیب مطالعه شوند و جهت بررسی دقیق پیاده‌سازی به صفحۀ گیت‌هاب این پروژه مراجعه شود، زیرا ارائۀ دقیق همۀ قطعات کد در مستند ممکن نیست. (ریپازیتوری)مخاطبان این مطلبمشخص نمودن مخاطبان این مطلب دشوار است؛ اما به‌طور کلی می‌توان اشخاص زیر را نام برد:فعالان و متخصصان حوزۀ فرایندکاوی جهت طراحی نرم‌افزار و پلاگین‌های جدید.پژوهشگران حوزۀ فرایندکاوی و آمار و احتمالات جهت بررسی روند عملیات فرایندکاوی.دانشجویان معماری نرم‌افزار و یا فرایندکاوی جهت مطالعه و گرفتن الگو.نمای موارد کاربرینمای موارد کاربری (Use Case Diagram) منجر به تجزیه و تحلیل عناصر ساختاری در نمای منطقی و پیاده‌سازی در نمای توسعه می شود. سناریوها در این نما، در نمای فرایند تحقق یافته و در نمای فیزیکی مستقر می‌شوند. در شکل (1) نمای موارد کاربری مربوط به سیستم سرویس فرایندکاوی آورده شده است.شکل (1): نمای موارد کاربری سیستم سرویس فرایندکاویهمانطور که در این شکل قابل مشاهده است، کل سیستم به سه دسته تقسیم می‌شود: سرویس‌های تحت وب، سرویس‌های فرایندکاوی و سرویس‌های مدیریت کاربران. سرویس‌های تحت وب در واقع مامور کسب درخواست‌ها از کاربران و همچنین نمایش بازخورد سایر سرویس‌ها به کاربران هستند؛ یعنی این سرویس به‌عنوان یک دیوار بین سرویس‌های داخلی و کاربر عمل می‌نماید. سرویس‌های فرایندکاوی، درواقع سرویس‌های عملکردی هستند که فایل‌های نگارۀ رویداد را دریافت کرده و سپس از روی آن مدل را کشف می‌کنند. همچنین محاسبۀ معیارهای فرایندکاوی نیز به عهدۀ این سرویس‌هاست. در نهایت سرویس‌های مدیریت کاربران نیز جهت مدیریت اطلاعات کاربران و نگهداری نشست‌ها (Sessions) و سایر موارد مانند فایل‌ها و غیره استفاده می‌شوند.برای مثال چنین سناریویی را درنظر بگیرید:کاربری می‌خواهد فایل Log خود را در سامانه آپلود کند و مدل کشف شده از آن را ببیند.برای انجام این عملیات، کاربر باید درخواست خود را از طریق سرویس وب ثبت نموده و فایل خود را آپلود کند. همچنین کاربر باید پارامترهای مربوطه و همچنین الگوریتم‌های مورد نظرش را انتخاب نماید. سپس سرویس وب این اطلاعات را به سرویس فرایندکاوی می‌دهد و سرویس فرایندکاوی نیز مدل را استخراج کرده و آن را در پایگاه داده ذخیره می‌نماید. سپس پیغامی به کاربر نمایش داده می‌شود که مدل استخراج شده و آماده است. در نهایت کاربر درخواست جدیدی به سرویس وب می‌دهد که می‌خواهد مدل را ببیند و سرویس وب نیز مدل را از پایگاه داده فراخوانی نموده و به کاربر نمایش می‌دهد.نمونه‌ای از این فرایند اجرایی به‌صورت یک نمودار BPMN در شکل (2) نمایش داده شده است. این نمودار که در واقع Hand-off را نمایش می‌دهد، جابه‌جایی اطلاعات میان سرویس‌های مختلف به تصویر کشیده شده و جهت ادراک بهتر سناریوی بالا مفید است.شکل (2): نمودار BPMN یک سناریوی فرضیمحدودیت‌هامحدودیت‌های این پروژه را می‌توان به دو قسمت تقسیم نمود: (1) محدودیت‌های فنی شامل محدودیت‌های نرم‌افزاری، سخت‌افزاری و سایر موارد مرتبط؛ (2) محدودیت‌های سازمانی شامل محدودیت‌های ساختاری، بودجه‌بندی و غیره. به‌صورت کلی محدودیت‌های پروژه در جداول (1) و (2) آورده شده‌اند.جدول (1): محدودیت‌های فنیجدول (2): محدودیت‌های سازمانیویژگی‌های کیفی سناریو‌های عمومیدر جداول (3) تا (11) ویژگی‌های کیفی سناریو‌های عمومی مربوط به سرویس فرایندکاوی به‌ترتیب اهمیت آورده شده است. در این جداول یک یا چند سناریو نیز برای درک بهتر ویژگی کیفی و همچنین نحوۀ محاسبه ویژگی‌ها نوشته شده است.1) قابلیت استفاده (Usability)جدول (3): ویژگی کیفی عمومی - قابلیت استفاده2) دسترسی پذیری (Availability)جدول (4): ویژگی کیفی عمومی - دسترسی‌پذیری (1)جدول (5): ویژگی کیفی عمومی - دسترسی‌پذیری (2)جدول (6): ویژگی کیفی عمومی - دسترسی‌پذیری (3)3) کارایی(Performance)جدول (7): ویژگی‌های کیفی عمومی - کارایی (1)جدول (8): ویژگی‌های کیفی عمومی - کارایی (2)جدول (9): ویژگی‌های کیفی عمومی - کارایی (3)4) توسعه‌پذیری(Modifiability)جدول (10): ویژگی‌های کیفی عمومی - توسعه‌پذیری5) امنیت (Security)جدول (11): ویژگی‌های کیفی عمومی - امنیتویژگی‌های کیفی سناریو‌های خاصدر جداول (12) و (13) ویژگی‌های کیفی سناریو‌های خاص مربوط به سرویس فرایندکاوی به‌ترتیب اهمیت آورده شده است. در این جداول یک یا چند سناریو نیز برای درک بهتر ویژگی کیفی و همچنین نحوۀ محاسبه ویژگی‌ها نوشته شده است.1) تحلیل گزارش‌ها و مدل‌ها به‌منظور بهینه‌سازیجدول (12): ویژگی‌های کیفی خاص - تحلیل گزارشات و مدل‌ها به‌منظور بهینه‌سازی2) اطمینان از گزارش‌ها و مدل‌های ایجاد شده در سیستمجدول (13): ویژگی‌های کیفی خاص - اطمینان از گزارش‌ها و مدل‌های ایجاد شده در سیستمویژگی‌های کیفیدر قسمت‌های قبلی ویژگی‌های سناریو‌های عمومی و خاص به‌صورت نمونه‌ای بیان شدند. در جدول (14) سایر ویژگی‌های کیفی کل سیستم به همراه معیار اندازه‌گیری و مقدار مطلوب برای هر معیار آورده شده است.جدول (14): سایر ویژگی‌های کیفیقسمت دوم: معماری سیستمدر این مطلب برای تشریح معماری سرویس فرایندکاوی از نماهای 1+4 استفاده شده است. همچنین در ادامه الگوها و روش‌های معماری استفاده شده بیان شده‌اند. البته توضیحاتی که در این مطلب آورده شده‌اند مختصر بوده و برای درک بهتر می‌توانید به آدرس گیت‌هاب این پروژه مراجعه کنید. همچنین مستندات از پنجرۀ زیر نیز قابل مشاهده است. https://alihanifi.github.io/PMService/ نمای کلی معمارینمای کلی معماری این سیستم را می‌توان چنین تشریح نمود که چندین سرویس برای تشکیل این سیستم گردهم آمده و نیازمندی‌ها را فراهم می‌کنند. این سیستم از معماری میکروسرویس استفاده می‌کند چون: معماری یکپارچه با افزایش مقیاس دچار مشکل می‌شود. این پروژه در حالت پیش‌فرض مقیاس بزرگ است و لذا باید از معماری یکپارچه دوری کرد.این سیستم درواقع مجموعه‌ای از خدمات جدا از هم است که می‌توان آن‌ها را دسته‌بندی کرد. بنابراین هر خدمت را می‌توان به‌عنوان یک سرویس جداگانه درنظر گرفت.فرایندکاوی یک شاخۀ جدید است که در آینده یقیناً دچار تغییرات بسیاری خواهد شد. میکروسرویس‌ها راه توسعه و پیشرفت را هموار می‌نمایند.در شکل (3) نمایی کلی از سیستم فعلی نشان داده شده است. در این سیستم مولفه‌های مختلفی وجود دارند که در زیر به آن‌ها اشاره شده است:میکروسرویس Event Data Extraction: استخراج داده‌ها از فایل‌های Log و یا ایجاد داده‌های مصنوعی.میکروسرویس Event Data Transformation: پیش‌پردازش داده‌ها (مثلاً فیلترکردن) قبل از تجزیه و تحلیل.میکروسرویس Process Model Extraction: استخراج مدل از نگاره‌های رویدادها.میکروسرویس Process Model & Event Data Analysis: آنالیز مدل‌ها و نگاره‌ها و همچنین محاسبۀ معیارها.میکروسرویس Process Model Transformation: تبدیل مدل‌ها به اشکال مختلف. در این پروژه پیش‌فرض مدل براساس BPMN درنظر گرفته شده است.میکروسرویس Process Model Enhancement: غنی‌سازی گزارش‌ها و مدل‌های استخراج شده به‌منظور بهبود الگوریتم‌های استخراج.شکل (3): نمای کلی معماری سیستمنمای منطقینمای منطقی این سیستم به کمک نمودار کلاس (Class Diagram) ترسیم شده است. به‌صورت کلی چهار دیاگرام کلاس وجود دارند که در ادامه توضیح داده خواهند شد. همچنین به‌دلیل بدیهی بودن و همچنین عدم ارتباط به این پروژه، از ترسیم کلاس‌های مرتبط با ذخیره‌سازی و پایگاه داده خودداری شده است. در شکل‌های (4) تا (7) نمودار کلاس‌های BPMN، سرویس وب، مدیریت کاربران و فرایندکاوی آورده شده است.شکل (4): نمودار کلاس مربوط به کلاس BPMNکلاس BPMN مربوط به مدل خروجی فرایندکاوی است که در قسمت قبلی بیان شد. در این کلاس:از الگوی طراحی Proxy استفاده شده است که در آن کلاس BPMN Graph Impl در واقع کل زیر سیستم را کنترل می‌کند و به‌نوعی نمایندۀ کل آن است.از الگوی Private Data استفاده شده است که در آن اطلاعات کلاس‌ها فقط به همان کلاس مربوط شده و برای دسترسی به اطلاعات باید از set و یا get استفاده کرد.شکل (5): نمودار کلاس مربوط به کلاس Web Serviceکلاس Web Service مربوط به صفحات تحت وب است که در قسمت قبلی بیان شد. در این کلاس:از الگوی طراحی Composite استفاده شده است که در آن فُرم درخت‌گونه مشهود است.از الگوی طراحی Singleton استفاده شده است که در آن فقط یک نمونه از کلاس Web Page Controller وجود دارد که اقدام به ساخت صفحات وب می‌کند.شکل (6): نمودار کلاس مربوط به کلاس User Managementکلاس User Management مربوط به کاربران است که در قسمت قبلی بیان شد. در این کلاس:از الگوی طراحی Singleton استفاده شده است که در آن فقط یک نمونه از کلاس‌های Login Controller و User Controller وجود دارد که جهت مدیریت کاربران استفاده می‌شود.از الگوی طراحی Proxy استفاده شده است که در آن کلاس User Service Impl در واقع کل زیر سیستم را کنترل می‌کند و به‌نوعی نمایندۀ کل آن است.از الگوی Private Data استفاده شده است که در آن اطلاعات کلاس‌ها فقط به همان کلاس مربوط شده و برای دسترسی به اطلاعات باید از set و یا get استفاده کرد.شکل (7): نمودار کلاس مربوط به کلاس Process Miningکلاس Process Mining مربوط به استخراج فرایند است که در قسمت قبلی بیان شد. در این کلاس:از الگوی طراحی Singleton استفاده شده است که در آن فقط یک نمونه از کلاس Log Handler وجود دارد که جهت مدیریت کاربران استفاده می‌شود.از الگوی طراحی Proxy استفاده شده است که در آن کلاس Miner Impl در واقع کل زیر سیستم را کنترل می‌کند و به‌نوعی نمایندۀ کل آن است.از الگوی Private Data استفاده شده است که در آن اطلاعات کلاس‌ها فقط به همان کلاس مربوط شده و برای دسترسی به اطلاعات باید از set و یا get استفاده کرد.نمای فیزیکینمای فیزیکی این سیستم به کمک نمودار استقرار (Deployment Diagram) ترسیم شده است. شکل (8) نشان‌دهندۀ نمای فیزیکی سیستم است. طبق آنچه در قسمت نمای معماری کلی گفته شد، سیستم از سه قسمت برای استقرار تشکیل می‌شود: سرویس وب، محل ذخیره‌سازی و برنامۀ کاربردی. سرویس وب در واقع همان Host یا میزبان است. محل ذخیره‌سازی می‌تواند با Host یکسان باشد اما برای نمایش بهتر و درک عمیق‌تر از یکدیگر جدا ترسیم شده است. برنامۀ کاربردی نیز قسمت‌های مختلف کُد است که مهمترین آن‌ها، برنامۀ استخراج فرایند به‌شمار می‌رود.شکل (8): نمودار استقرار سرویس فرایندکاوینمای پیاده‌سازینمای پیاده‌سازی این سیستم به کمک نمودار مولفه (Component Diagram) ترسیم شده است. شکل (9) نشان‌دهندۀ نمای پیاده‌سازی سیستم است. روند کلی آن است که سرویس Http Request Handler به‌عنوان یک Mediator عمل کرده و درواقع درخواست‌ها را به سرویس‌های مختلف ارسال نموده و پاسخ‌ آن‌ها را دریافت نموده و به کاربر ارائه می‌دهد. به همین ترتیب سایر سرویس‌ها نیز با ارائه درخواست عملیاتی را انجام داده و پاسخ آن را به فرستنده بازمی‌گردانند.شکل (9): نمودار مولفه سرویس فرایندکاوینمای فرایندنمای فرایند این سیستم به کمک نمودار فعالیت (Activity Diagram) ترسیم شده است. برای مشاهدۀ تمامی نمودارهای فعالیت لطفاً به این لینک مراجعه کنید. نمایش تمامی نمودارهای فعالیت در این مطلب جاگیر و خسته کننده است؛ لذا در شکل (10) فقط به چندین نمونه از آن اشاره شده است.شکل (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، معماری این سیستم تشریح شده و سپس نمودارهای کلاس، مولفه و پیاده‌سازی تشریح شدند. درنهایت نیز توضیحات کوتاهی مربوط به کُدهای پیاده‌سازی ارائه شد.برای تکمیل این پروژه در آینده می‌توان عملیات زیر را نام برد:تکمیل کدهای مربوط به نگهداری فایل‌ها و پایگاه‌های داده.تکمیل کدهای داخلی و ارتباط توابع با یکدیگر.اضافه کردن مدل‌های الگوریتم‌های فرایندکاوی به‌عنوان پلاگین‌های قابل نصب.این مطلب به‌عنوان پاسخی برای پروژۀ پایانی درس معماری نرم‌افزار در دانشگاه شهید بهشتی، به کمک دوست عزیزم آقای محمدحسین جلیلی نوشته شده است که امیدوارم از آن استفاده برده باشید. لطفاً موارد زیر را راجع‌به مطالب بالا درنظر داشته باشید:این مستند یک نوشتۀ فنی و بررسی شده نیست و نباید آن را به چشم یک مرجع یا رفرنس برای پروژه‌های عملی در دنیای واقعی مشاهده نمود.این مستند پیشنهادی نیست؛ یعنی هیچ پیشنهادی دربارۀ توسعه، اولویت‌بندی، روش و تکنولوژی سیستم فرایندکاوی نمی‌دهد، حتی اگر پیشنهاد دادن در متن آمده باشد. تصمیم صحیح و یا غلط بودن مطالب ذکر شده در این مستند به عهدۀ خواننده است.این مستند تاییدی نیست؛ مطالب ذکر شده در این مستند هیچ روش و تکنیک خاصی را تایید و یا رد نمی‌نمایند.مراجع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. علی حنیفی علی حنیفی Sat, 12 Feb 2022 18:26:17 +0330 https://virgool.io/@alihanifi/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%A7%D8%AD%D8%B1%D8%A7%D8%B2-%D9%87%D9%88%DB%8C%D8%AA-%DB%8C%DA%A9%D9%BE%D8%A7%D8%B1%DA%86%D9%87-zxwmbrfmblve اگر عضوی از یک تیم توسعه دهندۀ وب باشید و قبلاً در این زمینه فعالیت نموده‌اید یا اینکه یک کاربر معمولی اینترنت هستید، حتماً می‌دانید که امنیت یکی از دغدغه‌های اصلی به‌شمار می‌رود. در این عصر مدرن، معمولاً کاربران از چندین سیستم استفاده می‌کنند که هر کدام پیاده‌سازی امنیتی خاص خود را دارند. علاوه بر این وبسایت‌ها و سامانه‌های مختلف، از داده‌های متنوعی نگهداری می‌کنند که فقط توسط خود کاربر یا گروهی از کاربران قابل دسترسی است.از آنجایی که رایج ترین نوع امنیت، ترکیب قدیمی نام کاربری و رمز عبور است، اگر کاربر از آن دسته افرادی باشد که از یک ترکیب نام کاربری و رمز عبور در همه جا استفاده می‌کند، امنیت خود را به خطر می‌اندازد. از طرف دیگر به خاطر سپردن چندین ترکیب نام کاربری و رمز عبور برای سیستم‌های مختلف، بسیار دشوار است.برای حل چنین مشکلاتی راه‌حل‌های متنوعی پیشنهاد شده‌اند که احراز هویت یکپارچه، یکی از آن‌هاست. در این پست به تشریح سیستم‌های احراز هویت یکپارچه می‌پردازیم و در ادامه چندین ابزار متن‌باز را در این زمینه معرفی می‌کنیم. در نهایت نیز شرکت‌های ایرانی فعال در این زمینه آورده شده‌اند.احراز هویت یکپارچه چیست؟احراز هویت یکپارچه (Single Sign on که معمولاً SSO نامیده می‌شود)، یک راه‌حل مناسب برای افزایش امنیت و مدیریت دسترسی به یک یا چند برنامه برای کاربران است. در سطح بالا، احراز هویت یکپارچه به این معنی است که شما یک مجموعه نام کاربری و رمز عبور برای دسترسی به چندین نرم‌افزار را در یکجا تجمیع نموده‌اید. تمام برنامه‌های مورد علاقۀ خود را تصور کنید: فیسبوک، توییتر، اینستاگرام، گوگل و غیره. نام کاربری و رمز عبور همۀ آن‌ها در یک انبار داده ذخیره می‌شود.سیستم‌های احراز هویت یکپارچه، به‌عنوان یک ارائه‌دهندۀ هویت کار می‌کنند؛ مثلاً به نوعی مانند کارت شناسایی هستند. این یعنی سیستم احراز هویت یکپارچه در سیستم توسعه دهنده موجود نیست و در عوض، با یک ارائه‌دهندۀ احراز هویت (مانند لینکدین، مایکروسافت یا گوگل) همکاری می‌کند تا ببیند آیا می‌تواند هویت کاربر را تأیید کند یا خیر؟احراز هویت بر یک رابطۀ اعتماد میان دامنه‌ها (وبسایت‌ها) متکی است. وقتی می‌خواهید به کمک احراز هویت یکپارچه وارد سیستم یا وبسایت جدیدی شوید، مراحل زیر طی خواهند شد: 1. وبسایت ابتدا بررسی می‌کند که آیا قبلاً توسط SSO احراز هویت شده‌اید یا خیر؟ در اینصورت به شما امکان دسترسی به سایت را می‌دهد. اگر این کار را نکرده‌اید، شما را به SSO می‌فرستد تا وارد شوید. 2. شما تنها نام کاربری و رمز عبوری را که برای دسترسی به SSO استفاده می‌کنید، وارد می‌نمایید (مثلاً اکانت گوگل یا فیسبوک) 3. سیستم SSO احراز هویت را از ارائه دهندۀ هویت یا سیستم احراز هویتی که وبسایت از آن استفاده می‌کند، درخواست نموده و سپس هویت شما را تأیید می‌کند و در نهایت SSO را مطلع می‌کند. 4. سیستم SSO داده‌های احراز هویت را به وبسایت ارسال می‌کند و شما را به آن سایت باز می‌گرداند. 5. پس از ورود به سیستم، سایت مقصد داده‌های تایید هویت را به مرورگر شما ارسال می‌کند تا هر بار که به صفحه جدیدی می‌روید تأیید شود.حالا که متوجه شده‌ایم که احراز هویت یکپارچه چیست و چگونه کار می‌کند، به تشریح فواید و معایب آن می‌پردازیم. مزایای استفاده از احراز هویت یکپارچه عبارتند از:کاهشِ سطحِ حمله: احراز هویت یکپارچه مشکل استفاده از رمز عبور ضعیف را برطرف می‌نماید. این امر به کاربران امکان می‌دهد تا روی حفظ یک رمز عبور قوی و منحصر‌به‌فرد تمرکز کنند و بازنشانی رمز عبور زمان بَر و پرهزینه را کاهش می‌دهد.دسترسیِ یکپارچه و ایمن کاربر: احراز هویت یکپارچه، بینشی ارائه می‌دهد که کاربران در چه زمانی و از کجا به برنامه‌ها دسترسی داشته‌اند و به سازمان‌ها اجازه می‌دهد از یکپارچگی سیستم‌های خود محافظت کنند. سیستم‌های احراز هویت همچنین خطرات امنیتی را برطرف می‌کنند و تیم‌های فناوری اطلاعات را قادر می‌سازند تا فوراً دسترسی دستگاه به حساب‌ها و داده‌های حیاتی را غیرفعال کنند.مدیریت سادۀ دسترسی کاربران: اطمینان از دسترسی افراد مناسب به داده‌ها و منابع حساس، در محیط کسب‌وکاری که همواره در حال تغییر است، می‌تواند دشوار باشد. از رویکردهای احراز هویت یکپارچه، می‌توان برای پیکربندی حقوق دسترسی کاربر بر اساس نقش و سطح ارشدیت آن‌ها استفاده کرد. این امر شفافیت و دید در سطوح دسترسی را همیشه تضمین می‌کند.توانمندسازی کاربران: کاربران به‌طور فزاینده‌ای خواستار دسترسی سریع و یکپارچه به برنامه‌هایی هستند که برای انجام کارهای خود به آن‌ها نیاز دارند. مدیریت درخواست‌ها به‌صورت دستی، یک فرایند پر زحمت است که فقط باعث نااُمیدی و نارضایتی کاربران می شود. احراز هویت یکپارچه نیاز به نظارت دستی را از بین می‌برد و با یک کلیک امکان دسترسی فوری به هزاران برنامه را فراهم می‌سازد.اما با وجود اینکه فواید بسیاری را می‌توان برای استفاده از سیستم‌های احراز هویت یکپارچه نام بُرد، چالش‌هایی نیز وجود دارند که اطلاع داشتن از آن‌ها مهم است:خطرات دسترسی کاربر: اگر یک مهاجم به اعتبارنامۀ SSO کاربر دسترسی پیدا کند، به هر برنامه‌ای که کاربر حق آن را دارد نیز دسترسی پیدا می‌کند. بنابراین، استقرار مکانیزم‌های احراز هویت اضافی فراتر از رمزهای عبور، بسیار مهم است.آسیب‌پذیری‌های بالقوه: قبلاً آسیب‌پذیری‌هایی در SAML و OAuth کشف شده بودند که به مهاجمان دسترسی غیرمجاز به حساب‌های وب و تلفن همراه قربانیان را می‌دادند. بنابراین مهم است که با ارائه دهنده‌ای کار کنید که این موارد را در سیستم خود درنظر گرفته‌اند و SSO را با عوامل دیگر احراز هویت جفت می‌کنند.سازگاری برنامه: گاهی اوقات اتفاق می‌افتد که یک برنامه برای ادغام موثر با یک SSO تنظیم نشده باشد. ارائه‌دهندگان برنامه باید دارای قابلیت SSO واقعی باشند، چه از طریق SAML ،Kerberos یا OAuth. درغیراینصورت، راه حل SSO فقط یک رمز عبور دیگر برای به‌خاطر سپردن کاربران است و پوشش جامعی ارائه نمی‌دهد.معرفی ابزارها و فناوریهای متن بازدر این قسمت به پنج ابزار متن‌باز برتر در زمینۀ احراز هویت یکپارچه اشاره می‌شود.ابزار IdentityServerابزار IdentityServer یک نرم‌افزار متن‌باز و رایگان و یک چارچوب متقابل پلتفرم مبتنی بر OpenID Connect و OAuth 2 است. ضمناً این نرم‌افزار قابلیت‌های احراز هویت مرکزی و مجوز را برای چندین برنامه فراهم نموده و از هویت‌های فِدِرال، جریان‌های متعدد و مجوز API پشتیبانی می‌کند. علاوه بر این،خود ابزار IdentityServer دارای میزبانی است که کاربران را قادر می‌سازد تا با یک مجموعه از نام‌های کاربری و رمز عبور در بسیاری از برنامه‌ها وارد سیستم شوند. ابزار IdentityServer به زبان #C نوشته شده و تمام کد منبع آن به همراه اسناد مربوط به استقرار و توسعه در ریپازیتوری گیت‌هاب آن موجود است.برای کسب اطلاعات بیشتر راجع به ابزار IdentityServer می‌توانید به آدرس وبسایت آن مراجعه نمایید.ابزار KeyCloakابزار KeyCloak یک نرم‌افزار رایگان و متن‌باز و بر پایه OpenID Connect ،OAuth2.0 و SAML2.0 بوده و قابلیت‌های احراز هویت را برای برنامه‌های تحت وب ارائه می‌دهد. مهم‌تر از همه اینکه، این نرم‌افزار امکان ادغام با LDAP و Active Directory را فراهم می‌کند. در ابزار KeyCloak یک رابط کاربری منطقی وجود دارد که در آن کاربران می‌توانند نقش‌ها، مجوزها و جلسات را مدیریت کنند. ابزار KeyCloak عمدتاً به زبان جاوا و با ورودی کمی از زبان‌های دیگر مانند جاوا اسکریپت و HTML نوشته شده است که کد منبع آن در ریپازیتوری گیت‌هاب مربوطه موجود است.برای کسب اطلاعات بیشتر راجع به ابزار KeyCloak می‌توانید به آدرس وبسایت آن مراجعه نمایید.ابزار CASابزار CAS یک نرم‌افزار متن‌باز با احراز هویت واگذار شده است (احراز هویت واگذار شده درواقع همان SSO با تفاوت‌های کمی در تجربۀ کاربری به‌حساب می‌آید). ابزار CAS چند زبانه است و با استفاده از پروتکل مبتنی بر تیکت، خدمات مجوز را ارائه می‌دهد. این نرم‌افزار رایگان، براساس معماری سِرور-کلایِنت ساخته شده است. سرویس احراز هویت مرکزی (CAS) از پروتکل‌های زیادی مانندOpenID ،OAuth ،OpenID Connect ،REST WsFederation و SAML پشتیبانی می‌کند. مهم‌تر از همه اینکه یک سیستم جامع برای ادغام با برنامه‌های شخص ثالث در آن وجود دارد. ابزار CAS به زبان جاوا نوشته شده و کد منبع آن با تمام اسناد مربوط به توسعه و استقرار در ریپازیتوری گیت‌هاب آن موجود است.ابزار Autheliaابزار Authelia یک نرم‌افزار احراز هویت یکپارچه است که دارای ویژگی‌های بسیار غنی و مقیاس‌پذیر می‌باشد. این ابزار امنیت فوق‌العاده‌ای را ارائه می‌دهد و قابلیت‌های تنظیم احراز هویت و ورود به سیستم را فراهم می‌کند. این نرم‌افزار متن‌باز از LDAP و Active Directory نیز پشتیبانی می‌کند. در ابزار Authelia یک رابط کاربری گرافیکی وجود دارد که به کاربران اجازه می‌دهد تا به‌راحتی عملیات مورد نظرشان را انجام دهند و همچنین احراز هویت دو عاملی را بر اساس Google Authenticator OTP ارائه می‌دهد. این نرم‌افزار رایگان بوده و با یک پروکسی معکوس مانند Nginx کار می‌کند. ابزار Authelia به زبان Go نوشته شده و تمام کد منبع آن در ریپازیتوری گیت‌هاب مربوطه موجود است.برای کسب اطلاعات بیشتر راجع به ابزار Authelia می‌توانید به آدرس وبسایت آن مراجعه نمایید.ابزار WSO2ابزار WSO2 یک سیستم مدیریت دسترسی و هویت متن‌باز پرکاربرد است که تقریباً از تمام استانداردهای هویت محبوب برای ارائۀ احراز هویت پشتیبانی می‌کند. این ابزار نقاط انتهایی API برای ادغام با سایر برنامه‌ها دارد و با یک رابط کاربری مطلوب و مفید همراه است که تنظیمات زیادی را در اختیار کاربر قرار می‌دهد. علاوه بر این، ابزار WSO2 احراز هویت دو عاملی را نیز ارائه می‌دهد. این ابزار عمدتاً به زبان جاوا نوشته شده و تمام کد منبع آن با مستندات مربوط به توسعه و استقرار در ریپازیتوری گیت‌هاب مربوطه موجود است.معرفی شرکت های ایرانیدر این قسمت دو شرکت ایرانی که خدمات احراز هویت یکپارچه را ارائه می‌دهند، آورده شده‌اند. البته باید گفت که درحضور سازمان‌های غول‌پیکری مانند گوگل، مایکروسافت، فیسبوک و غیره، رقابت بسیار دشوار است، اما این شرکت‌ها خدمات مناسبی را برای کاربران ایرانی فراهم نموده‌اند.شرکت متن‌باز سامانشرکت متن‌باز سامان (مرکز توسعۀ نرم‌افزارهای باز سامان) در سال ۱۳۸۸ با هدف تولید و توسعۀ نرم‌افزارهای متن‌باز با توجه به نیاز سازمان‌ها، دانشگاه‌ها و شرکت‌های مختلف تأسیس شد. تیم فنی این شرکت، دارای سابقه‌ای طولانی در طراحی نرم‌افزارهای متن‌باز به‌خصوص در زمینه‌ی شبکه، سیستم‌های امنیتی و برنامه‌های تحت شبکه دارد.راه‌حل ارائه شده توسط این شرکت در زمینۀ احراز هویت یکپارچه، سامانۀ مَتین است. این سامانه در واقع یک سیستم SSO با قابلیت‌های استقرار پایدار توزیع شده، پروتکل‌های استاندارد، مدیریت هویت و دسترسی، پروفایل کاربری، سرویس اَبری، احراز هویت دوعاملی، ادغام با LDAP و Active Directory و غیره است.برای کسب اطلاعات بیشتر راجع‌به سامانۀ متین می‌توانید بروشور آن را مطالعه نموده یا به آدرس وبسایت شرکت مراجعه کنید.شرکت فناوران هویت الکترونیکی امن (هویتا)شرکت دانش بنیان فناوران هویت الکترونیکی امن (هویتا)، با هدف توسعه محصولات احراز هویت و هویت‌سنجی دیجیتال و ارائۀ راهکارهای مطمئن جهت تأمین امنیت اطلاعات، ارتباطات و تبادلات الکترونیکی، تشکیل شده است. هستۀ اصلی شرکت هویتا، متشکل از متخصصین حوزۀ امنیت است که فعالیت خود را از سال 1381 آغاز نموده و در زمینۀ طراحی و توسعه محصولات مبتنی بر رمزنگاری، امضای دیجیتال، گواهی‌های الکترونیکی و توکن امضای دیجیتال در سال 1395 به‌عنوان شرکت دانش بنیان ثبت و مستقر گردیده است.راه‌حل ارائه شده توسط این شرکت در زمینۀ احراز هویت یکپارچه، سامانۀ پارس است و سرویس‌های احراز هویت و امضای دیجیتال مبتنی بر PKI را ارائه می‌دهد. همچنین سامانۀ پارس با ارائۀ درگاه امضای دیجیتال، باعث حذف فرایند PK-Enabling در سامانه‌‌های نرم‌افزاری می ‌گردد که منجر به کاهش چشمگیر زمان و هزینه‌‌های سازمان در تجهیز سامانه‌ها به زیرساخت کلید عمومی می‌‌شود.برای کسب اطلاعات بیشتر راجع‌به سامانۀ پارس می‌توانید بروشور آن را مطالعه نموده یا به آدرس وبسایت شرکت مراجعه کنید.سخن پایانیسیستم‌های احراز هویت یکپارچه، راهکارهای مناسبی را برای ایجاد دسترسی آسان‌تر به چندین برنامه با استفاده از تنها یک مجموعه از مجوزها را برای کاربران فراهم می‌کنند. اما بیشتر از آن، این سیستم‌ها امنیت بهتری را برای نرم‌افزارها ایجاد می‌نمایند. در این پست، با نحوۀ کارکرد این سیستم‌ها آشنا شدیم و چند ابزار معروف و کاربردی مرتبط با آن معرفی شدند.پیشنهاد می‌شود برای آشنایی بیشتر با نحوۀ کارکرد این سیستم‌ها و پروتکل‌های مختلف، مطالعۀ بیشتری انجام دهید و به وبسایت‌های مختلف (مثل OAuth) سر بزنید. همچنین یک کتاب سطح مبتدی نوشتۀ جرارد بلوکدیک نیز وجود دارد که مطالعۀ آن خالی از لطف نیست.این مطلب به‌عنوان پاسخ برای بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی نوشته شده است که امیدوارم از آن استفاده برده باشید.مراجع[1] Blokdyk, G. (2017). Single sign-on: Beginner’s Guide. CreateSpace Independent Publishing Platform.[2] Jain, P. (2020, June 15). Single Sign-On(SSO) -SAML Authentication Explained - Connected Lab TechBlog. Medium. https://medium.com/brightlab-techblog/single-sign-on-sso-saml-authentication-explained-1e463b9168cb [3] Lu, D. (2021, July 26). What Is Single Sign-On (SSO) Okta, Inc. https://www.okta.com/blog/2021/02/single-sign-on-sso/ [4] M. (2021, June 21). Top 5 Open Source Single Sign-On Software In the Year 2021. Open Source Software Blog. https://blog.containerize.com/2021/01/29/top-5-open-source-single-sign-on-software-in-the-year-2021/ [5] Rogers, S. (2021, July 5). Single Sign-On: What It Is, How It Works, and Why You Need It. Capterra. https://blog.capterra.com/single-sign-on/ [6] Talic, J. (2018, March 29). Single Sign-on: How it really works? - Ingenuity. Medium. https://medium.com/ingenuity-ph/single-sign-on-how-it-really-works-77444028c682 [7] سامانه احراز هویت متمرکز (Single Sign On) | شرکت متن باز سامان. (2021). شرکت متن باز سامان. https://mbs.co.ir/fa/content/Single-Sign-On [8] شرکت هویتا. (2020). هویتا. https://www.hovita.ir/ علی حنیفی علی حنیفی Sun, 12 Dec 2021 14:48:03 +0330 https://virgool.io/@alihanifi/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%DA%A9%D9%8F%D8%AF-%D8%A7%D8%B3%D8%AA%D8%A7%D8%AA%DB%8C%DA%A9-qeecdwac6zpv هنگام ساخت یک نرم‌افزار، تیم توسعه همواره درنظر دارد که سرعت توسعه بالا برود و همچنین برنامۀ تولید شده از قابلیت اطمینان بالایی برخوردار باشد. برای دستیابی به چنین اهدافی، تست کردن نرم‌افزار ضروریست زیرا تنها با تست کردن است که می‌توان ایرادات برنامه را پیدا کرده و سپس برای برطرف کردن آن‌ها تلاش نمود. برای تست کردن یک نرم‌افزار، روش‌های مختلفی وجود دارند که بهترین آن‌ها تست دستی انتها به انتها و تست خودکار هستند.در روش دستی، مسیرهای متعددی که یک کاربر می‌تواند از آن عبور نماید را به‌عنوان مورد تست درنظر گرفته و سپس برای یافتن خطاها اقدام می‌نماییم. مشخصاً تنظیم کردن موارد تست و نتایج بدست آمده از آن‌ها در اکثر مواقع خسته کننده است و این مسئله باعث کاهش سرعت توسعه می‌شود. در مقابل روش تست خودکار نیز همان رویکرد دستی را به کمک روش‌های خاصی به کامپیوتر سپرده و باعث افزایش سرعت کامپیوتر می‌شود. اما مشکل هزینه و محدودیت‌های خودکارسازی همچنان به قوت خود باقی خواهند ماند.اما روش‌های بهتری هم وجود دارد. در چرخۀ توسعۀ هر محصول نرم‌افزاری، تحلیل کُد استاتیک تست کردن را آسان‌تر می کند. البته نمی‌توان آن را به‌عنوان جایگزینی برای ابزارهای تست انتها به انتها دانست، ولی یک ویژگی بسیار بارِزشان این است که حتی بدون استفاده از آزمایش‌های واقعی، تا حدودی می‌توانند قابلیت اطمینان را بالا ببرند.در این پست قصد داریم تا شما را با روش تحلیل کد استاتیک و ابزارهای متن‌باز مرتبط با آن آشنا کنیم و در نهایت دو شرکت ایرانی که در این زمینه خدمات ارائه می‌دهند را معرفی نماییم.تحلیل کُد استاتیک چیست؟قبل از اینکه وارد این مبحث شویم، اجازه دهید که یک مسئله را روشن کنیم: تحلیل کُد استاتیک (Static Code Analysis) برخلاف روش‌های تست دستی یا اتوماتیک، قبل از ساخت برنامه انجام می‌شود. یعنی تحلیل کُد استاتیک به ما امکان می‌دهد تا باگ‌های احتمالی، کُدهای مشکوک و آسیب‌پذیری‌های امنیتی را حتی قبل از اینکه کُد وارد محیط تولید شود، شناسایی کنیم.به کمک تحلیل کُد استاتیک در واقع سعی داریم تا یک تست جعبه سفید انجام دهیم که در آن بدون توجه به خروجی‌های مورد انتظار، اقدام به بررسی منبع کُد نموده و ایرادات و خطاها را آشکار می‌سازیم. حالا که با این مباحث آشنا شدیم، می‌توانیم تعریف نسبتاً دقیقی از آن ارائه کنیم:تحلیل کُد استاتیک روشی برای رفع اشکال با بررسی کُد منبع قبل از اجرای برنامه است. این کار با تجزیه و تحلیل مجموعه‌ای از کُدها در برابر مجموعه‌ای (یا مجموعه‌های متعدد) از قوانین کُدگذاری انجام می شود.عبارت‌های تحلیل کُد استاتیک و تحلیل استاتیک اغلب به جای یکدیگر، همراه با تجزیه و تحلیل کُد منبع استفاده می‌شوند که همگی معنای یکسانی دارند. این نوع تحلیل، نقاط ضعف در کُد منبع را که ممکن است منجر به آسیب‌پذیری شوند، برطرف می‌کند. البته این امر ممکن است از طریق بررسی کُدهای دستی نیز حاصل شود؛ اما قاعدتاً استفاده از ابزارهای خودکار بسیار مؤثرتر است. تحلیل استاتیک معمولاً برای مطابقت با دستورالعمل‌های کُدگذاری، مانند MISRA و اغلب برای انطباق با استانداردهای صنعتی، مانند ISO 26262 استفاده می‌شود.اما تحلیل استاتیک نمی‌تواند تمام ایرادات یک برنامه را تشخیص دهد. به‌عنوان مثال، تحلیل استاتیک نمی‌تواند تشخیص دهد که آیا نیازمندی‌های نرم‌افزار برآورده شده است یا اینکه یک تابع چگونه اجرا می‌شود؟ همچنین تحلیل استاتیک در برابر مسائل زیر، پاسخی برای ارائه ندارد:عدم وجود درک از مقصود توسعه دهنده: تحلیل استاتیک ممکن است سَرریز احتمالی را در کُد تشخیص دهد؛ اما نمی‌تواند تعیین کند که عملکرد اساساً آنچه را که انتظار می‌رود، انجام می‌دهد یا نه.قوانین به‌طور ایستا قابل اجرا نیستند: برخی از قوانین کُدگذاری به اسناد خارجی دیگری بستگی دارند یا اینکه هر شخصی می‌تواند هرطور که می‌خواهد آن را تفسیر کند.نقص‌های احتمالی منجر به مثبت کاذب و منفی کاذب می‌شوند: در برخی شرایط، تحلیل استاتیک فقط می‌تواند گزارش دهد که یک نقص احتمالی وجود دارد. مثلاً اگر چیزی در مورد تابع جاری یا وابسته ندانیم، نمی‌توانیم بگوییم که متغیر فعلی چه مقداری خواهد داشت. بنابراین نتیجه غیرقابل تصمیم‌گیری است. این بدان معناست که تحلیل استاتیک ممکن است نقص‌هایی را گزارش کند که در واقع وجود ندارند (مثبت کاذب) یا ممکن است نقایص واقعی را گزارش ندهد (منفی کاذب).برای پاسخ به چنین سوالات و چالش‌هایی، باید از رویکرد تست پویا استفاده نمود که از حوصلۀ مبحث فعلی خارج است. به همین دلیل، تحلیل استاتیک و تست پویا مکمل یکدیگر هستند. تحلیل استاتیک، اشکالات در کُد را قبل از ساخت برنامه تشخیص می‌دهد و این تضمین می‌کند که یک محصول با کیفیت بالاتر به مرحلۀ آزمایش می‌رسد و با اطمینان از کارآمدتر بودن فرایندهای آزمایش، توسعۀ نرم‌افزار سرعت بیشتری می‌گیرد.در کنار چنین محدودیت‌هایی، تحلیل استاتیک فواید بسیاری دارد که از جملۀ آن‌ها می‌توان به موارد زیر اشاره نمود:حصول اطمینان از افزایش کیفیت کُدکشف و ارائۀ آسیب‌پذیری‌های امنیتی در وابستگی‌هاداشتن عملکردی همانند ابزارهای تست نرم‌افزار برای کشف خطاهاسریع‌تر بودن در مقایسه با بررسی دستی کُددقت بالاتر در مقایسه با بررسی دستی کُدمعرفی ابزارها و فناوریهای متن بازدر زمینۀ تحلیل استاتیک، ابزارهای بسیار زیادی وجود دارند و انتخاب از میان آن‌ها به ویژگی‌های پروژه از جمله زبان مورد استفاده، نیازمندی‌ها و قابلیت‌های خود ابزار وابسته است. در جدول زیر لیستی از ابزارهای متن‌باز تحلیل استاتیک آورده شده است (لیست کامل را از اینجا ببینید) که از میان آن‌ها به اختصار، سه ابزار برتر در ادامه توضیح داده خواهند شد. همچنین اگر به پیاده‌سازی و کارهای عملی علاقه دارید، یک ریپازیتوری قدرتمند در گیت‌هاب وجود دارد که همۀ ابزارهای تحلیل استاتیک را بر اساس زبان دسته‌بندی نموده است.ابزار SonarQubeابزار SonarQube، یک پلتفرم متن‌باز است که توسط شرکت SonarSource برای بازرسی مداوم کیفیت کُد و انجام بررسی‌های خودکار و تحلیل استاتیک برای شناسایی اشکالات، کُدهای مشکوک و آسیب‌پذیری‌های امنیتی در بیش از 20 زبان برنامه‌نویسی توسعه یافته است. این ابزار ابتدا Sonar نام داشت که بعدها نام آن به SonarQube تغییر پیدا کرد. البته این ابزار در چهار نسخۀ مختلف عرضه می‌شود که فقط نسخۀ Community آن مجانی است.ابزار SonarQube می‌تواند گزارش‌های متنوعی از جمله گزارشات کُدهای تکراری، استانداردهای کُدگذاری، تست‌های واحد، پوشش کُد، پیچیدگی کُد، اشکالات و آسیب‌پذیری‌های امنیتی ارائه دهد. همچنین SonarQube می‌تواند با محیط‌های توسعۀ معروف همانند Eclipse ،Visual Studio ،Visual Studio Code و IntelliJ IDEA از طریق پلاگین SonarLint ادغام شود.برای کسب اطلاعات بیشتر می‌توانید به ریپازیتوری گیت‌هاب SonarQube یا آدرس وبسایت آن مراجعه کنید.ابزار StyleCopابزار StyleCop، یک ابزار تحلیل کُد استاتیک متن‌باز از شرکت مایکروسافت است که کُد زبان #C را برای انطباق با سبک‌های کُدنویسی توصیه شده و زیرمجموعه‌ای از دستورالعمل‌های طراحی چارچوب دات‌نت مایکروسافت بررسی می‌کند. StyleCop کُد منبع را تجزیه و تحلیل نموده و به آن اجازه می‌دهد تا مجموعه قوانین متفاوتی را از FxCop (که به جای کُد منبع، مجموعه‌های کُد مدیریت شدۀ دات‌نت را بررسی می‌کند) اعمال نماید. البته به نظر می‌رسد که این ابزار به پایان عمر خود نزدیک شده و از محیط توسعۀ Visual Studio 2015 به بالاتر، ابزار StyleCopAnalyzer معرفی شده است.برای کسب اطلاعات بیشتر می‌توانید به ریپازیتوری گیت‌هاب StyleCop مراجعه کنید.ابزار Sparseابزار Sparse، نرم‌افزاری است که برای یافتن اشکالات احتمالی کُدنویسی در هستۀ لینوکس طراحی شده است. این ابزار، مشکلات شناخته شده را بررسی نموده و به توسعه دهنده اجازه می‌دهد تا حاشیه‌نویسی‌هایی را در کُد اضافه کند که اطلاعات مربوط به انواع داده‌ها را منتقل می‌کند؛ مانند فضای آدرسی که اشاره‌گرها به آن اشاره می‌کنند و قفل‌هایی که یک تابع ایجاد و یا آزاد می‌کند. لینوس توروالدز نوشتن ابزار Sparse را در سال 2003 آغاز کرد. جاش تریپلِت از سال 2006 پشتیبان اصلی آن بود، نقشی که کریستوفر لی در سال 2009 و لوک وَن اوستِنریک در نوامبر 2018 عهده‌دار شدند. ابزار Sparse تحت مجوز MIT منتشر شده است.برای کسب اطلاعات بیشتر می‌توانید به آدرس وبسایت Sparse مراجعه کنید.معرفی شرکت های ایرانیمتاسفانه در کشور ایران، هنوز فرهنگ تست کردن نرم‌افزار و کیفیت آن در میان جامعۀ توسعه دهندگان رایج نیست. بنابراین شرکت‌های باتجربه در این زمینه اندک هستند. بهرحال در این قسمت دو شرکت ایرانی که خدمات تحلیل استاتیک را ارائه می‌دهند، معرفی شده‌اند.شرکت مهندس پيشگان آزمون افزار ياسشرکت مهندس پيشگان آزمون افزار ياس در زمینۀ تست و تضمین کیفیت نرم‌افزار فعالیت می‌نماید و یکی از قدیم‌ترین شرکت‌ها در ایران است که چنین خدماتی را ارائه می‌دهد. شرکت مهندس پیشگان آزمون افزار یاس یک شرکت دانش بنیان بوده و در شورای عالی انفورماتیک عضویت دارد. از جمله خدماتی که توسط این شرکت ارائه می‌شود می‌توان تست عملکردی، تست بار و فشار، تست امنیت، ممیزی کیفیت نرم افزار، راه اندازی ابزارهای تحلیل استاتیک همچون JTest ،dotTest ،C++Test ،Sonar و Checkmarx نام برد.برای کسب اطلاعات بیشتر راجع به شرکت مهندس پیشگان آزمون افزار یاس به آدرس وبسایت آن مراجعه کنید.شرکت خانۀ تست ایرانشرکت خانۀ تست ایران، در زمینۀ تست نرم‌افزار و بهبود کیفیت آن‌ها و با هدف ارتقای دانش در پلتفرم‌های مختلفی از جملۀ وبسایت‌ها، اپلیکیشن‌های اَندروید، آی او اس و نرم‌افزارهای دسکتاپ فعالیت می‌نماید. این شرکت خدمات زیادی شامل مشاوره در زمینه‌های تست عملکردی و غیرعملکردی، تشکیل تیم تست نرم‌افزار و بهبود فرایند تست نرم‌افزار ارائه می‌دهد. همچنین انجام تست اتوماتیک توسط نرم‌افزارهای متن‌باز و تجاری از جمله خدمات این مجموعه است.برای کسب اطلاعات بیشتر راجع به شرکت خانۀ تست ایران به آدرس وبسایت آن مراجعه کنید.سخن پایانیتحلیل کُد استاتیک یک روش مطلوب جهت تست بهینۀ کُد و همچنین افزایش میزان اطمینان از برنامه است. در این پست مفهوم تحلیل استاتیک به همراه برخی ابزارهای مهم و متن‌باز معرفی شدند. پیشنهاد می‌شود درصورتیکه می‌خواهید مطالعات بیشتری داشته باشید، کتاب برنامه‌نویسی ایمِن با تحلیل استاتیک نوشتۀ جیکوب وِست را مطالعه نمایید. همچنین کتاب تحلیل استاتیک نرم‌افزار: تفسیر انتزاعی نوشتۀ ژان لوئیس بولانگِر نیز تمامی مباحث مرتبط با تحلیل استاتیک را پوشش می‌دهد.این مطلب به‌عنوان پاسخ برای بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی نوشته شده است که امیدوارم از آن استفاده برده باشید.مراجع[1] (2021). GitHub - A curated list of static analysis tools. GitHub. https://github.com/analysis-tools-dev/static-analysis [2] How Static Code Analysis Works. Perforce Software. https://www.perforce.com/blog/qac/how-static-code-analysis-works [3] What Is Static Analysis? Static Code Analysis Overview. Perforce Software. https://www.perforce.com/blog/sca/what-static-analysis [4] Boulanger, J. (2013). Static Analysis of Software: The Abstract Interpretation. Wiley-Iste.[5] Chess, B., & West, J. (2007). Secure Programming with Static Analysis. Pearson Education.[6] Kaharovic, N. (2021, March 10). SonarQube - Get Started with Static Code Analysis! - Maestral. Medium. https://medium.com/maestral-solutions/sonarqube-get-started-with-static-code-analysis-dd0bd16f24e [7] Megida, D. (2020, November 23). A Beginner’s Guide to Static Code Analyzers - Level Up Coding. Medium. https://levelup.gitconnected.com/a-beginners-guide-to-static-code-analyzers-9bf0198f494f [8] N. (2020, June 5). تحلیل ایستا (Static Analysis). خانه تست ایران. http://sqmtest.ir/%d8%aa%d8%ad%d9%84%db%8c%d9%84-%d8%a7%db%8c%d8%b3%d8%aa%d8%a7-static-analysis/ [9] صفحه نخست. (2020). مهندس پیشگان. https://www.mohandespishegan.com/ علی حنیفی علی حنیفی Fri, 10 Dec 2021 19:53:51 +0330 https://virgool.io/@alihanifi/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%AF%D8%B1%DA%AF%D8%A7%D9%87-api-ncf9ms60puno از زمانیکه ساخت و توسعۀ نرم‌افزارها آغاز شده، سال‌های زیادی می‌گذرد و تیم‌های توسعه دهنده همواره در این حرفه پیشرفت نموده و بهتر شده‌اند. فناوری‌ها و الگوهای معماری زیادی در این سال‌ها ظهور نموده‌اند که هرکدام متناسب با انواع خاصی از کاربردها هستند. میکروسرویس، یکی از این الگوهای معماری است که از دنیای طراحی دامنه محور، تحویل مداوم، اتوماسیون پلتفرم و زیرساخت، سیستم‌های مقیاس‌پذیر و برنامه‌نویسی چند زبانه پدید آمده است.آقای رابِرت سی. مارتین در کتاب توسعۀ نرم‌افزار چابک: اصول، الگوها و کاربرد، اصطلاح اصل مسئولیت واحد (Single-responsibility principle) را چنین مطرح می‌کند:چیزهایی را که به دلایل یکسان تغییر می‌کنند را در یکجا جمع‌آوری کنید و چیزهایی را که به دلایل مختلف تغییر می‌کنند از هم جدا کنید.معماری میکروسرویس، در واقع با استفاده از همین رویکرد، آن را به سرویس‌های با کوپلینگ ضعیف گسترش می‌دهد که می‌توانند به‌طور مستقل توسعه، استقرار و نگهداری شوند. هر یک از این سرویس‌ها وظیفه‌ای مجزا را بر عهده داشته و می‌توانند از طریق APIهای ساده با سرویس‌های دیگر ارتباط برقرار کنند تا یک مسئلۀ کسب‌وکار پیچیده‌تر را حل کنند.اما استفاده از معماری میکروسرویس با مشکلات و چالش‌هایی همراه است که از جملۀ آن‌ها می‌توان به عدم هماهنگی سرویس‌ها با پروتکل‌های ارتباطی، نیاز به پیاده‌سازی عملیات درگاهی (مثل ورود، خروج و غیره) در هر سرویس، کاهش سرعت پاسخ و بالارفتن بار سرور اشاره نمود. برای حل این مشکلات، یک لایۀ اضافی بین مشتری و سرور قرار می‌گیرد و به‌عنوان یک پاسخگوی درخواست مسیریابی معکوس از مشتری به سرور عمل می‌کند که به آن درگاه API گفته می‌شود.در این پست قصد داریم تا شما را با درگاه API آشنا کنیم و برخی ابزارهای متن‌باز مرتبط را آن را معرفی نماییم. همچنین برخی شرکت‌های ایرانی ارائه دهندۀ خدمات درگاه API نیز در انتها معرفی خواهند شد.درگاه API چیست؟درگاه API در واقع یک الگوی نرم‌افزاری است که در مقابل یک رابط برنامه‌نویسی نرم‌افزار (API) یا گروهی از زیرسرویس‌ها قرار می‌گیرد تا درخواست‌ها، تحویل دادنی‌ها و خدمات را تسهیل کند. نقش اصلی درگاه API این است که به‌عنوان یک نقطۀ ورودی واحد، تعاملات بین برنامه‌ها، داده‌ها و خدمات سازمان و مشتریان داخلی و خارجی را استانداردسازی نماید. با توضیحاتی که داده شد، شاید کمی بحث پیچیده شده باشد. بگذارید با یک مثال ادامه بدهیم. فرض کنید که می‌خواهید یک نرم‌افزار فروشگاه آنلاین بسازید؛ برنامۀ شما باید ویژگی‌هایی مثل لیست کالاها، سفارش دادن، جزئیات کالاها و غیره داشته باشد. بنابراین چنین برنامه‌ای باید سرویس‌هایی نظیر سرویس کالا، سرویس سفارش، سرویس قیمت‌گذاری، سرویس کاربران و غیره را به همراه خود داشته باشد. به چنین معماری در یک نرم‌افزار، معماری میکروسرویس گفته می‌شود که در آن داده‌ها در چندین سرویس پخش می‌شوند. فرض کنید در این نرم‌افزار، صفحۀ اصلی را باز کرده‌اید و یک کالا را جستجو می‌کنید. رابط کاربری برنامه، لیستی از داده‌های کالاها، داده‌های نظرات مشتریان، داده‌های موجودی و غیره را برای نمایش صفحۀ فهرست کالاها نیاز دارد. بنابراین قطعه کُدی که چنین داده‌هایی را برای کاربر فراهم می‌کند، نیاز دارد تا سرویس‌های مربوطه مثل سرویس کالا، سرویس سفارش و غیره را فراخوانی نماید.اما این نوع معماری، دارای مشکلات متعددی است:تجربۀ کاربری به دلیل درخواست‌های متعدد مشتریان، ضعیف خواهد بود: کاربر باید چندین درخواست برای بازیابی داده‌ها داشته باشد و باید این درخواست‌ها را به‌صورت متوالی اجرا کند. بنابراین کُد نوشته شده تقریبا پیچیده خواهد بود. همچنین برای باز کردن یک صفحۀ معمولی، ممکن است یک درخواست چندین مرتبه به سرور فرستاده شده و پاسخ آن برگشت داده شود. همچنین این قضیه زمانی بدتر می‌شود که سرعت شبکه پایین‌ باشد.پروتکل‌های ارتباطی متنوع هستند: برخی از سرویس‌ها ممکن است از پروتکل پیام‌رسانی gRPC یا AMQP و غیره استفاده کنند. این پروتکل‌ها در خود سرویس به‌خوبی کار می‌کنند، اما ممکن است به‌راحتی توسط سایر سرویس‌ها قابل استفاده نباشند یا ممکن است سازوکار برخی از پروتکل‌ها در برخی از پلتفرم‌های کاربران سخت باشد.نیاز به پیاده‌سازی عملیات‌های سادۀ درگاهی در هر سرویس: برخی عملیات‌های ساده که در همۀ درگاه‌ها استفاده می‌شوند (مثل ورود، خروج، احراز هویت و غیره) باید در هر میکروسرویس پیاده‌سازی شوند که هم باعث کاهش سرعت و هم ایجاد ناهماهنگی و هدر رفتن منابع می‌شود.کپسوله‌سازی (حفاظت) از داده‌ها وجود ندارد: توسعه دهندۀ یک سرویس گاهی اوقات سرویس‌های جدیدی را به نرم‌افزار اضافه می‌کند و حتی ممکن است API را تغییر دهد. اما اگر دانش در مورد سرویس در سمت کاربر تشکیل شده باشد، تغییر API سرویس دشوار است. همچنین ایجاد تغییرات در میکروسرویس‌ها بدون ایجاد اختلال در اتصال کاربر ممکن نیست.برای فهم بهتر درگاه API می‌توان از شکل زیر کمک گرفت. در شکل زیر یک معماری کلی از نرم‌افزاری فرضی نشان داده شده است که در سمت چپ آن کاربران و در سمت راست، سرویس‌های نرم‌افزار نشان داده شده‌اند. میان این دو لایه، یک درگاه API وجود دارد که به‌عنوان یک نقطۀ واحد، به درخواست‌های کاربران پاسخ می‌دهد و پاسخ‌های سرویس‌ها را هدایت می‌نماید.یک درگاه API، انعطاف‌پذیری را برای استفاده از پروتکل‌های کاملاً مستقل فراهم می‌کند و به میکروسرویس‌ها اجازه می‌دهد تا به‌راحتی با یکدیگر ارتباط برقرار کنند. درگاه‌های API به توسعه‌دهندگان اجازه می‌دهند تا به عملکردهای زیرمجموعه‌ای از معماری به روش‌های مختلف دسترسی داشته باشند، بدون اینکه نقاط پایانی را به‌طور عمومی در معرض دید عموم قرار دهند. درگاه‌های API مزایای متعددی دارند که می‌توان از جملۀ آن‌ها به موارد زیر اشاره کرد:از برنامه‌ها و میکروسرویس‌ها حفاظت می‌کنند: از آنجایی که درگاه API بین نرم‌افزار و میکروسرویس‌ها قرار می‌گیرد، به‌عنوان یک مانع امنیتی عمل نموده و اطمینان حاصل می‌نمایند که نقاط انتهایی API حساس در معرض دید قرار نمی‌گیرند. آن‌ها همچنین API را در برابر حملات مخرب مانند حملات DoS، تزریق SQL و غیره محافظت می‌کنند.پیچیدگی‌های میکروسرویس‌ها را کاهش می‌دهند: درگاه API نگرانی‌هایی مانند محدود کردن نرخ، کنترل دسترسی کاربر، مجوز توکن، مقیاس‌بندی در میان سایر موارد را مدیریت می‌کند و به نرم‌فزار کمک می‌کند پیچیدگی را کاهش دهد و به API اجازه می‌دهد تا بر روی کار خودش تمرکز کند. این نوع جداسازی مزیت بی‌سابقه‌ای ایجاد می‌کند زیرا API نیازی به پردازش یا قالب‌بندی پاسخ ندارد.نظارت و تجزیه و تحلیل را فراهم می‌نماید: برخی از درگاه‌های API با ابزارهای نظارتی یا تحلیلی خاصی عرضه می‌شوند که به توسعه‌دهندگان کمک می‌کنند تا بتوان با آن‌ها عملیات اشکال‌زدایی را انجام داد و زیرساخت‌هایی ایجاد کرد که مقیاس‌پذیر باشند. البته این مورد برای ارائه‌دهندگان درگاه API معمول نیست.همچنین استفاده از درگاه API معایبی نیز به‌همراه دارد:یادگیری آن دشوار است: هنگامی که صحبت از معماری نرم‌افزار با دسترسی بالا در مقیاس بزرگ به‌میان می‌آید، یک منحنی یادگیری وجود دارد، یعنی نیاز به تجربۀ بالا، لازم است. این منحنی به‌خصوص جایی که درگاه API تنها نقطه ورودی است، به‌عنوان یک نقطۀ شکست عمل می‌کند.پیکربندی آن دشوار است: پیکربندی برنامه و API برای تعامل از طریق یک درگاه API به هماهنگی بیشتری نیاز دارد که به سطح دشواری برای توسعه‌دهندگان می‌افزاید.همراه با اُفت عملکرد خواهد بود: کاهش عملکرد به دلیل سناریوهای متعددی که درگاه API انجام می‌دهد و می‌تواند بر سرعت و قابلیت اطمینان برنامه تأثیر بگذارد، یک نگرانی است.معرفی ابزارها و فناوریهای متن بازدر این قسمت به چهار ابزار متن‌باز برتر در زمینۀ درگاه API اشاره می‌شود.ابزار Kong Gatewayابزار Kong Gateway محبوب‌ترین درگاه API اَبری متن‌باز است که به زبان Lua نوشته شده و با کمک Nginx اجرا می‌شود. این ابزار در واقع قالبی است که به سرعت بخشیدن به زمان رویداد کمک نموده و تضمین می‌کند که عملکرد تأخیر و مقیاس‌پذیری بی‌نظیری را برای همۀ برنامه‌های میکروسرویس‌ها بدون توجه به مکان اجرا، ارائه دهد.شرکت‌هایی مانند Nasdaq ،Honeywell ،Cisco ،FAB ،Expedia ،Samsung ،Siemens و Yahoo Japan به‌طور گسترده از درگاه API Kong استفاده می‌کنند. برخی از ویژگی‌های ارائه شده توسط Kong عبارتند از: احراز هویت، کنترل ترافیک، تجزیه و تحلیل، ورود به سیستم، قابلیت توسعه با استفاده از معماری پلاگین.برای دریافت اطلاعات بیشتر می‌توانید به قسمت مستندات یا آدرس وبسایت Kong Gateway مراجعه نمایید.ابزار Apache APISIXابزار Apache APISIX ابتدا در شرکت ZhiLiu چین متولد شد و سپس وارد اَنکوباتور Apache شد و تبدیل به یک ابزار متن‌باز گردید. مینگ وِن که معاون این پروژه است، بیان می‌کند که APISIX چالش‌های مختلفی را که توسط سرویس‌های بومی و میکروسرویس اَبری ایجاد می‌شود، حل می‌کند. ابزار Apache APISIX توسط شرکت‌هایی مانند 360، HelloTalk ،NetEase ،TravelSky و بسیاری دیگر استفاده می‌شود.ابزار Apache APISIX مبتنی بر Nginx و etcd و دارای مسیریابی پویا و بارگذاری داغ (Hot Loading) است که مخصوصاً برای مدیریت API تحت سیستم میکروسرویس مناسب است.برای دریافت اطلاعات بیشتر می‌توانید به آدرس وبسایت Apache APISIX مراجعه نمایید.ابزار Ocelotابزار Ocelot یک درگاه API مبتنی بر دات نِت است. هدف این پروژه استفاده از دات نِت و میکروسرویس‌های در حال اجرا یا معماری سرویس‌گرا است که نیاز به یک نقطۀ ورود واحد به سیستم خود دارد. با این حال، با سرویسی که از پروتکل HTTP استفاده نموده و روی هر پلتفرمی که ASP.NET Core پشتیبانی می‌کند، اجرا می‌شود. Ocelot ویژگی‌های استانداردی مانند مسیریابی، احراز هویت، محدود کردن نرخ، حافظۀ پنهان، تعادل بار و غیره را ارائه می‌دهد. همچنین این برنامه از رمزگذاری، ارسال هِدِر میزبان و Swagger پشتیبانی نمی‌کند.برای دریافت اطلاعات بیشتر می‌توانید به دایرکتوری گیت‌هاب ابزار Ocelot مراجعه نمایید.ابزار Gokuابزار Goku در واقع یک زیرمجموعه از پروژۀ EOLINK Inc است. این ابزار یک درگاه میکروسرویس مبتنی بر Golang است که مسیریابی پویا با کارایی بالا، هماهنگی خدمات، کنترل دسترسی API و غیره را امکان پذیر می‌کند. ابزار Goku یک رابط گرافیکی و سیستم پلاگین برای آسان‌تر کردن پیکربندی و توسعۀ راحت‌تر را فراهم می‌کند. جدا از ویژگی‌های استاندارد، Goku ویژگی‌هایی مثل خوشه‌بندی، به‌روزرسانی‌، هشداردهی، گزارش‌گیری و غیره را ارائه می‌دهد.برای دریافت اطلاعات بیشتر می‌توانید به دایرکتوری گیت‌هاب ابزار Goku مراجعه نمایید.معرفی شرکت های ایرانیدر این قسمت دو شرکت ایرانی که خدمات درگاه API را ارائه می‌دهند، آورده شده‌اند.شرکت سیستم خبره دُرسااین شرکت کار خود را از سال 1398 توسط تعدادی از صاحبنظران در حوزۀ رایانش اَبری آغاز نمود و سپس در سال 1400 با نام سیستم خبره درسا به ثبت رسید که نام تجاری آن اَبر درسا است.این شرکت ماموریت خود را تبدیل شدن به پلتفرم اول رایانش ابری در منطقۀ خاورمیانه بیان نموده و سرویس‌های مختلفی از جمله مدیریت و درگاه API را به مشتریان خود ارائه می‌دهد.برای کسب اطلاعات بیشتر راجع به سامانۀ درگاه ابری API و آشنایی بیشتر با شرکت سیستم خبره درسا، می‌توانید به آدرس وبسایت آن مراجعه کنید.شرکت وصلشرکت وصل در سال‌های گذشته تلاش نموده است تا با برنامه­‌ریزی­‌های استراتژیک، بلندمدت و تفکری متفاوت، خود را به‌عنوان یکی از فعالان حوزۀ فناوری اطلاعات کشور معرفی نماید. در این راستا پلتفرم معرفی شده توسط این شرکت، سورِنا نام دارد که خدمات متفاوتی مانند مدیریت چرخۀ APIها، انعطاف‌پذیری و امنیت را برای میکروسرویس‌ها ایجاد می‌نماید.برای کسب اطلاعات بیشتر راجع به سامانۀ سورنا و آشنایی بیشتر با شرکت وصل، می‌توانید به آدرس وبسایت آن مراجعه کنید.سخن پایانیبه‌طور خلاصه، درگاه API یک پروکسی معکوس است که میکروسرویس‌ها را به‌عنوان API ارائه می‌دهد. یک درگاه API همچنین به حداقل‌سازی خطرات احتمالیِ در معرض قرار دادن عمومی خدمات باطنی سرویس‌ها و منابع داده به‌طور مستقیم، کمک می کند. استفاده از درگاه API باعث می‌شود کُد نوشته شده تمیزتر و ساده‌تر باشد، تأخیر به حداقل برسد و احراز هویت و رمزگذاری ساده‌تر شود.درصورتیکه نیاز به اطلاعات بیشتری در این سبک از معماری دارید، می‌توانید کتاب کریس ریچاردسون به نام الگوی میکروسرویس‌ها را مطالعه کنید. همچنین مستندات سرویس‌های اَبری Azure شرکت مایکروسافت نیز حاوی اطلاعات جالب و آموزنده‌ای هستند که پیشنهاد می‌شود آن‌ها را مطالعه نمایید.این مطلب به‌عنوان پاسخ برای بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی نوشته شده است که امیدوارم از آن استفاده برده باشید.مراجع[1] Ali, A. (2021, January 18). 14 Open Source and Managed API Gateway for Modern Applications. Geekflare.[2] H. (2018, June 22). The What, Why, and How of a Microservices Architecture. Medium. https://medium.com/hashmapinc/the-what-why-and-how-of-a-microservices-architecture-4179579423a9 [3] Martin, R. C., Rabaey, J. M., Chandrakasan, A. P., Nikolić, B., Newkirk, J. W., & Koss, R. S. (2003). Agile Software Development. Pearson Education.[4] Montgomery, J. (2021, March 30). API gateway. WhatIs.Com. https://whatis.techtarget.com/definition/API-gateway-application-programming-interface-gateway [5] Nadaduru, L. N. (2021, October 25). What is an API Gateway - FAUN Publication. Medium. https://faun.pub/api-gateway-analysis-74b304f2e145 [6] Schiesser, M. (2019, January 10). What is an API Gateway? - Glasnostic Blog. https://glasnostic.com/blog/what-is-an-api-gateway-aws-express-kong [7] Shah, B. (2021, October 14). Microservices Design - API Gateway Pattern - Dev Genius. Medium. https://blog.devgenius.io/microservices-design-api-gateway-pattern-980e8d02bdd5 [8] Siahaan, J. N. (2019a, September 8). API Gateway Part 1 - Easyread. Medium. https://medium.com/easyread/api-gateway-part-1-7901ba703f9 [9] Siahaan, J. N. (2019b, September 8). API Gateway Part 2 - Easyread. Medium. https://medium.com/easyread/api-gateway-part-2-7264ee5be187 [10] Why Use API Gateway? Pros & Cons | Knowledge Base. (2021, January 13). Dashbird. https://dashbird.io/knowledge-base/api-gateway/pros-and-cons-of-using-an-api-gateway/ [11] ابر درسا. (2021, December 2). سرویس Api Gateway ابری. https://dorsacloud.com/service-post/api-gateway-service/ [12] سورنا (API Management) | شرکت وصل. (2021). شرکت وصل. http://vasl.ir/platform/api-management/ علی حنیفی علی حنیفی Thu, 09 Dec 2021 22:55:35 +0330 https://virgool.io/@alihanifi/hexagonal-architecture-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-suribp6fuagd وقتی در مورد معماری شش ضلعی (Hexagonal Architecture) صحبت می‌شود همگی ذهنشان به سوی موضوعات متفاوت سفر می‌کند؛ اما در این پست قصد داریم نظر شما را به این موضوع جذاب، جلب کنیم. با وجود اینکه سالیان زیادی از معرفی معماری ششی ضلعی گذشته، اما در منابع فارسی کمتر به آن پرداخته شده است؛ پس تا انتهای این پست را با دقت بخوانید.از کجا شروع شد؟معماری شش ضلعی یا Hexagonal Architecture، یک الگوی معماری است که در طراحی نرم‌افزار، به‌دنبال حداقل نمودن وابستگی‌های داخلی کلاس‌ها به یکدیگر است به شکلی که تغییر در یک کلاس نیازی به تغییر در بقیه کلاس‌ها نداشته باشد. به این نوع از طراحی Loose coupling یا وابستگی ضعیف گفته می‌شود که باعث افزایش عمومیت، قابلیت نگهداری و پایداری کل سیستم خواهد شد. به‌طور خلاصه معماری شش ضلعی قابلیت ایجاد تغییرات در کد را افزایش داده و برنامه‌نویسی را ساده‌‌تر می‌کند.معماری شش ضلعی توسط دکتر آلیستِر کاکبِرن ایجاد شده است. دکتر کاکبِرن از سال 1991 در شرکت IBM مشغول به کار بود و برای ایجاد یک متدولوژی جدید و مدرن، شروع به مطالعۀ چگونگی موفقیت تیم‌های برنامه‌نویسی آن زمان کرد. تیم او یکی از معدود تیم‌هایی بود که در اواسط دهۀ 1990 در پروژه‌های تجاری اشیاء-فناوری موفق شد. کتاب او با عنوان دوام آوردن درپروژه‌های شئ‌گرا نشان داد که چگونه این کار را می توان انجام داد. دکتر کاکبِرن در ادامۀ تحقیقات خود، از جمله مشاور ویژۀ بانک مرکزی نروژ در اواخر دهۀ 1990، رویدادی را که صنعت نرم‌افزار را تغییر داد، یعنی نوشتن مانیفست توسعۀ نرم افزار چابک را سازماندهی کرد. او یکی از تاثیرگذارترین افراد در صنعت کامپیوتر و فناوری اطلاعات در دهۀ‌ 1990 بوده است که پیشنهاد می‌شود دربارۀ ایشان بیشتر تحقیق کنید.معماری شش ضلعی چیست؟هدف معماری‌های لایه‌ای سنّتی نرم‌افزار، ایجاد لایه‌‌هایی برای تفکیک نرم‌افزار است. یعنی هر لایه شامل ماژول‌ها و کلاس‌هایی است که مسئولیت‌های مشترک یا مشابهی دارند و برای انجام وظایف خاص با هم کار می‌کنند. انواع مختلفی از معماری‌های لایه‌ای وجود دارند و هیچ قانونی برای تعیین اینکه چند لایه لازم داریم، وجود ندارد. رایج‌ترین الگوی معماری 3 لایه است که در آن برنامه به لایۀ نمایش، لایۀ منطقی و لایۀ داده تقسیم می‌شود.پیروی از معماری لایه‌ای از بسیاری جهات سودمند است که مهم‌ترین آن‌ها تفکیک مشکلات می‌باشد. مثلاً یک توپ نخ را درنظر بگیرید. اگر بخواهید گره‌های آن را از هم جدا و توپ نخی را باز کنید، نمی‌توان همۀ گره‌ها و نخ‌ها را به‌صورت همزمان باز کرد. بلکه باید این گره‌ها و نخ‌ها را به‌صورت تفکیک شده و ترتیبی باز نمود. مشکلات ساخت یک نرم‌افزار هم شبیه به همین توپ نخ است.در سال 2005، دکتر کاکبِرن متوجه شد که تفاوت زیادی بین نحوۀ تعامل رابط کاربری و پایگاه دادۀ یک برنامه وجود ندارد، زیرا هر دو یک بازیگر خارجی هستند که با اجزای مشابهی که به روش‌های مشابه با یک برنامه تعامل دارند، قابل تعویض هستند. با نگاه کردن به این موارد، می‌توان بر روی ناشناس نگه داشتن این بازیگران خارجی تمرکز کرد و به آن‌ها اجازه داد تا از طریق پورت‌ها (درگاه‌ها) و آداپتورها (مقداردهی‌ها) تعامل داشته باشند؛ بنابراین از درهم‌تنیدگی و نَشتِ منطقی بین کسب‌وکار و اجزای خارجی جلوگیری می‌شود.اینجاست که به مفهوم معماری شش ضلعی می‌رسیم. معماری شش ضلعی که به آن معماری پورت‌ها و آداپتورها نیز گفته می‌شود، یک الگوی معماری است که به کاربران یا سیستم‌های خارجی اجازه می‌دهد تا از طریق یک آداپتور وارد برنامه در یک پورت شوند و خروجی برنامه را از طریق یک پورت به خارج ارسال کنند. چنین ساختاری یک لایۀ انتزاعی ایجاد می کند که از هستۀ برنامه محافظت نموده و آن را از ابزارها و فناوری‌های خارجی، و به نوعی نامربوط، جدا می‌کند. در ادامه به تشریح پورت‌ها و آداپتورها می‌پردازیم.پورت‌هامی‌توان به پورت‌ها از دیدگاه یک نقطۀ ورودی فناوری‌شناسی ببینیم؛ یعنی اینکه رابطی را تعیین می‌کند که به بازیگران خارجی اجازه می‌دهد تا با برنامه ارتباط برقرار کنند، صرف‌نظر از اینکه چه کسی یا چه چیزی رابط مذکور را پیاده‌سازی خواهد کرد. همانطور که یک پورت USB به چندین نوع دستگاه اجازه می‌دهد تا به کمک یک آداپتور USB، با یک کامپیوتر ارتباط برقرار کند. همچنین پورت‌ها به برنامه اجازه می‌دهند تا با سیستم‌ها یا خدمات خارجی مانند پایگاه‌های داده، کارگزاران پیام، سایر برنامه‌ها و غیره ارتباط برقرار کند.آداپتورهایک آداپتور تعامل با برنامه را از طریق یک پورت با استفاده از یک فناوری خاص آغاز می‌کند. برای مثال، یک کنترلر REST آداپتوری را نشان می‌دهد که به مشتری اجازه می‌دهد با برنامه ارتباط برقرار کند. در یک معماری می‌توان به تعداد مورد نیاز برای هر پورت، آداپتور درنظر گرفت بدون اینکه خطری برای پورت‌ها یا خود برنامه ایجاد کند.برنامهبرنامه هستۀ سیستم و شامل خدمات کاربردی است که عملکرد یا موارد استفاده را هماهنگ می‌کند. همچنین شامل مدل دامنه است که منطق کسب‌وکار بوده که در موجودیت‌ها، گروه‌های انباشته و غیره تعبیه شده است. همانند شکل زیر، برنامه توسط یک شش ضلعی نمایش داده می‌شود که دستورات یا کوئری‌ها را از پورت‌ها دریافت نموده و درخواست‌ها را از طریق پورت‌ها به دیگر بازیگران خارجی مانند پایگاه‌های داده نیز ارسال می‌کند.ممکن است برخی از خود بپرسند که چرا یک شش ضلعی؟ شاید فکر می‌کنند که تعداد لبه‌ها مهم است؛ جواب منفی است، اصلاً مهم نیست. حتی عدد شش هم مهم نیست. ایدۀ دکتر کاکبِرن از استفاده از یک شش ضلعی برای نمایش این معماری، صرفاً نمایش بصری ترکیبات چند پورت/آداپتور یک نرم‌افزار بوده است و همچنین نشان می‌دهد که چگونه سمت چپ برنامه، یا «محرک»، تعاملات و پیاده‌سازی‌های متفاوتی در مقایسه با سمت راست، یا سمت «متحرک» دارد. علاوه بر این، فضای کافی برای ترسیم پورت‌ها و آداپتورها به تعداد مورد نیاز وجود دارد. همچنین شکل باید عدم تقارن درون/خارجی را به جای بالا/پایین یا چپ/راست تداعی کند. بنابراین یک مربع یا مستطیل مناسب نیست و از طرف دیگر ترسیم پنج ضلعی، هفت ضلعی، هشت ضلعی و غیره خیلی سخت است؛ بنابراین شش ضلعی مناسب‌ترین شکل است.بازیگران محرک (یا اصلی) آن‌هایی هستند که تعامل را آغاز می‌کنند و همیشه در سمت چپ تصویر قرار می‌گیرند. به‌عنوان مثال، یک آداپتور محرک می‌تواند یک کنترل کننده باشد که ورودی (کاربر) را می‌گیرد و آن را از طریق یک پورت به برنامه ارسال می‌کند.بازیگران متحرک (یا ثانویه) آن‌هایی هستند که توسط برنامه وادار به تعامل می‌شوند. به‌عنوان مثال، یک آداپتور پایگاه داده توسط برنامه فراخوانی می‌شود تا مجموعه‌ای از داده‌های خاص را از مخزن واکشی کند.با توجه به چنین ساختاری، توسعه‌دهندگان باید نکات زیر را به هنگام پیاده‌سازی درنظر داشته باشند:پورت‌ها (بیشتر اوقات بسته به زبان منتخب) به‌عنوان رابط در کُد نشان داده می‌شوند.آداپتورهای محرک از یک پورت استفاده می‌کنند و یک سرویس برنامه رابط تعریف‌شده توسط پورت را پیاده‌سازی می‌کنند؛ در این مورد هم رابط پورت و هم پیاده‌سازی داخل شش ضلعی هستند.آداپتورهای هدایت شده، پورت را پیاده‌سازی می‌کنند و یک سرویس برنامه از آن استفاده می‌کند. در این مورد پورت در داخل شش ضلعی بوده اما پیاده‌سازی در آداپتور و بنابراین خارج از شش ضلعی است.از جمله موارد استفاده معماری شش ضلعی می‌توان به برنامۀ هشدار وقایع طبیعی اشاره کرد که معماری آن در شکل زیر آمده است. این برنامه دارای چهار پورت و چندین آداپتور در هر پورت است و وظیفۀ آن، گوش دادن به به هشدارهای خدمات هواشناسی ملی دربارۀ زلزله، گردباد، آتش‌سوزی و سیل و سپس اطلاع‌رسانی از طریق تلفن یا دستگاه‌های منشی تلفنی به مردم است. چرا باید از معماری شش ضلعی استفاده کنیم؟استفاده از معماری شش ضلعی، مزایای زیادی دارد که در ادامه به آن‌ها اشاره می‌شود:تست کردن را بهبود می‌بخشد: یکی از مزایای معماری شش ضلعی این است که می‌توان منطق برنامه و منطق دامنه را به‌صورت کاملاً قابل تست، ایزوله نمود. از آنجایی که این معماری به عوامل خارجی وابسته نیست، تست کردن آن آسان خواهد شد.نگهداری برنامه بهبود می‌یابد: سیستم‌های قابل نگهداری، سیستم‌هایی هستند که به راحتی قابل تغییر باشند. معماری شش ضلعی قابلیت نگهداری را افزایش می‌دهد زیرا جداسازی دغدغه‌ها و جداسازی منطق کسب‌وکار را فراهم می‌نماید که مکان‌یابی کُدی را که می‌خواهیم تغییر دهیم، آسان‌تر می‌شود. قابلیت نگهداری برنامه یک مفهوم بلندمدت مرتبط با بدهی فنی است. هرچه قابلیت نگهداری بیشتر باشد، بدهی فنی خواهد بود. بنابراین، معماری شش ضلعی بدهی فنی را کاهش می‌دهد.انعطاف‌پذیری افزایش می‌یابد: برای یک پورت معین، می‌توان چندین آداپتور داشت که هر کدام از یک فناوری خاص استفاده می‌کنند. برای انتخاب یکی از آن‌ها، فقط باید پیکربندی انجام شود که از کدام آداپتور برای آن پورت استفاده نمود. این پیکربندی می‌تواند به آسانی تغییر یک فایل خصوصیات پیکربندی خارجی باشد؛ یعنی بدون اصلاح کد، بدون کامپایل مجدد و بدون ساخت مجدد. به همین ترتیب، افزودن یک آداپتور فناوری خاص جدید به یک پورت، می‌تواند بدون دست زدن به کُد منبع موجود انجام شود زیرا آداپتور به تنهایی توسعه و کامپایل شده و در زمان اجرا، شناسایی می‌شود و به پورت متصل می‌گردد.برنامه مصون از تکامل فناوری خواهد شد: همواره فناوری بیشتر از منطق کسب‌وکار تکامل می‌یابد. در برنامه‌هایی که منطق کسب‌و‌کار با فناوری گره خورده‌اند، نمی‌توان تغییرات فناوری را بدون اصلاح منطق کسب‌وکار انجام داد. این امر مطلوب نیست، زیرا کسب‌وکار نباید تغییر کند. با معماری شش ضلعی، فناوری که می‌خواهید ارتقا دهید در یک آداپتور خارج از برنامه قرار دارد. پس فقط باید آداپتور را عوض کنید. خود برنامه تغییرناپذیر است زیرا به آداپتورها وابسته نیست.در تصمیم‌گیری‌های فنی تاخیر ایجاد می‌شود: وقتی یک تیم شروع به توسعه و کدنویسی می‌کند، می‌تواند فقط بر منطق کسب‌وکار تمرکز نموده و تصمیم‌گیری دربارۀ چارچوب و فناوری مورد استفاده را به تعویق بیندازد. این یعنی می‌توان بعداً یک فناوری را انتخاب نموده و یک آداپتور برای آن کدنویسی کرد.در مقابل، معماری شش ضلعی معایبی هم به‌همراه دارد که از جملۀ آن‌ها به موارد زیر اشاره کرد:باعث افزایش پیچیدگی می‌شود: یک پروژۀ نرم‌افزاری که معماری شش ضلعی را پیاده‌سازی می‌کند، ساختار پیچیده‌ای دارد که ماژول‌های زیاد و وابستگی‌های صریح بین آن‌ها تعریف شده است. منظور از ماژول ها، زیرپروژه های کُد برای جداسازی فیزیکی عناصر مختلف معماری است. حداقل یک ماژول برای شش ضلعی، یک ماژول برای هر آداپتور و یک ماژول برای راه‌اندازی کل پروژه وجود خواهد داشت. همچنین باید وابستگی‌های بین ماژول‌ها را تعریف شود. اگر زبان برنامه‌نویسی به معماری شش ضلعی اجازه ندهد که فقط پورت‌ها را در معرض دید قرار دهد، ماژول‌های بیشتری نیز وجود خواهند داشت. عملکرد فرایند ساخت ضعیف می‌شود: با توجه به پیچیدگی‌هایی که در قسمت قبلی تشریح شد، اگر پروژه خیلی بزرگ و با آداپتورهای زیاد باشد، فرایند کامپایل، اجرای تست‌ها، ساخت همۀ ماژول‌ها با هم و راه‌اندازی کل پروژه زمان زیادی می‌برد.اما پاسخ به این سوال که چه زمانی باید از معماری شش ضلعی استفاده کرد، همچنان نامشخص است. شاید بتوان گفت که «بستگی دارد». برای پروژه های کوچک، شاید درمان بدتر از بیماری باشد، به‌طوری که حل مشکلات بی‌اهمیت، سزاوار پیچیدگی اضافه شده توسط این معماری نیست و اصطلاحاً باید عطایش را به لقایش بخشید. برای پروژه‌های متوسط/بزرگ، که قرار است چرخۀ عمر طولانی داشته باشند و در طول عمرشان بارها اصلاح شوند، استفاده از معماری شش ضلعی در بلندمدت ارزشش را دارد.سخن پایانیمعماری شش ضلعی یا پورت‌ها و آداپتورها، یک نوش‌دارو برای هر درد و بیماری نیست. این معماری به هنگام پیاده‌سازی سطح معینی از پیچیدگی را به سیستم تحمیل می‌کند که وقتی با دقت از آن استفاده شود، مزایای زیادی برای سیستم را به‌همراه خواهد داشت.وقتی معماری شش ضلعی به درستی پیاده‌سازی شده و با سایر متدولوژی‌ها مانند طراحی دامنه محور ترکیب می‌شود، می‌تواند پایداری و گسترش طولانی‌مدت برنامه را تضمین نموده و ارزش زیادی برای سیستم و شرکت توسعه‌دهنده به ارمغان بیاورد.برای کسب اطلاعات بیشتر راجع به معماری شش ضلعی پیشنهاد می‌شود که مقالۀ اصلی دکتر کاکبِرن را مطالعه کنید. همچنین ایشان در وبسایت خود مطالب جالب و مفیدی قرار داده‌اند که دیدن آن‌ها خالی از لطف نیست.این مطلب به‌عنوان پاسخ برای بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی نوشته شده است که امیدوارم از آن استفاده برده باشید.مراجع[1] Cockburn, A. (1998). Surviving Object-oriented Projects. Addison Wesley.[2] Cockburn, A. (2021). Hexagonal architecture. Alistair Cockburn. https://alistair.cockburn.us/hexagonal-architecture/ [3] Hexagonal Architecture - Ports ans Adapters Pattern. (2021). Hexagonal Me. https://jmgarridopaz.github.io/content/hexagonalarchitecture.html [4] Manifesto for Agile Software Development. (2001). Agile. http://agilemanifesto.org/ [5] Martinez, P. (2021, July 9). Hexagonal Architecture, there are always two sides to every story. Medium. https://medium.com/ssense-tech/hexagonal-architecture-there-are-always-two-sides-to-every-story-bc0780ed7d9c [6] Musib, S. (2019, December 17). A quick introduction to Hexagonal Architecture - Code Fountain. Medium. https://medium.com/thecodefountain/a-quick-introduction-to-hexagonal-architecture-484358c038b8 [7] Wikipedia contributors. (2021, July 26). Hexagonal architecture (software). Wikipedia. https://en.wikipedia.org/wiki/Hexagonal_architecture_(software) علی حنیفی علی حنیفی Sat, 04 Dec 2021 20:34:22 +0330 https://virgool.io/@alihanifi/ddd-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-mti6zzkwisx0 پیچیدگی یک امر ذاتی در نرم‌افزار است؛ چون ذهن انسان ها پیچیده است، این امر طبیعی خواهد بود که ساختۀ ذهن آن‌ها نیز پیچیده باشد. پیچیدگی در نرم‌افزارها چندین منشا دارد؛ اما همۀ آن‌ها به صورت مسئله باز نمی‌گردند و در اصطلاح ذاتی نیستند. به این نوع از پیچیدگی که شامل نحوۀ حل مسئله و ابزارهای مورد استفاده برای دستیابی به آن است، پیچیدگی تصادفی گفته می‌شود. همانطور که میزان حجم یک نرم‌افزار افزایش پیدا می‌کند، پیچیدگی آن نیز اجتناب ناپذیرتر می‌شود و در اینصورت، سازماندهی و ساختاربندی کُد، از آنچه که در ابتدا درنظر گرفته شده بود، دشوارتر خواهد شد. چنین پدیده‌ای به‌عنوان آنتروپی نرم‌افزار شناخته می‌شود. اگر دستورالعمل‌های معماری در طول تکرارهای متعدد و توسعۀ نرم‌افزار اجرا نشوند، حفظ تعادل میان دغدغه‌های کاربران سیستم و جداسازی صحیح کلاس‌ها و ماژول‌ها، چالش‌برانگیزتر می‌شود.در معماری رایج Model View Controller) MVC)، لایۀ مدل، تمام منطق کسب‌وکار را در خود جای می‌دهد، اما قوانین روشنی در مورد چگونگی حفظ مرزهای مسئولیت مناسب ارائه نمی‌دهد. تابه‌حال چندین الگو برای حل این مشکل ارائه شده است، اما همچنان خطر نَشتِ منطق و مسئولیت بین اجزاء وجود دارد که با تکامل مدل، قابلیت نگهداری و پایداری دشوارتر می‌شود.از طرف دیگر، ارتباط با متخصصین کسب‌وکار، جمع‌آوری الزامات و اجماع بین تیم‌های فنی و غیرفنی برای طراحی و پیاده‌سازی صحیح سیستمی که یک مسئلۀ تجاری را حل می‌کند، یک فرایند تکراری ثابت است که در آن مفاهیم و موضوعات می‌توانند نادرست تفسیر شوند و در نهایت پروژه را از مسیر دستیابی به اهداف اصلی خارج کنند.طراحی دامنه محور (DDD) تلاش می‌کند تا با تطبیق نیروهای فنی و غیرفنی که در یک پروژه نرم‌افزاری با هم تلاقی دارند، این چالش‌ها را حل نموده و مجموعه‌ای از الگوها را پیشنهاد دهد که ساختن یک سیستم مطلوب را تسهیل می‌نمایند.طراحی دامنه محور چیست؟قبل از اینکه بخواهیم طراحی دامنه محور (DDD - Domain Driven Desgin) را تعریف کنیم، ابتدا باید بدانیم که «دامنه» چه مفهومی دارد؟ در این زمینه، دامنه را می‌توان بدین شکل تعریف نمود:حوزۀ خاصی از فعالیت یا دانش که مجموعه‌ای از الزامات، اصطلاحات و عملکردهای مشترک را تعریف می‌کند که منطق نرم‌افزار برای حل یک مشکل براساس آن کار می کند.طراحی دامنه محور در واقع رویکردی برای طراحی نرم‌افزار است که پیاده‌سازی سیستم را به یک مدل دائماً در حال تکامل می‌چسباند و جزئیات نامربوط مانند زبان‌های برنامه‌نویسی، فناوری‌های زیرساخت و غیره را کنار می‌گذارد. این رویکرد اولین بار در کتاب آقای اِریک اِوانز به نام طراحی دامنه محور: مقابله با پیچیدگی در قلب نرم‌افزار مطرح شد که مطالعۀ آن خالی از لطف نیست. آقای اِوانز در این کتاب به سه نظم در طراحی دامنه محور به‌صورت زیر اشاره می‌کند:روی دامنۀ اصلی و منطق دامنه تمرکز کنید.طرح‌های پیچیده را بر اساس مدل‌های دامنه قرار دهید.به منظور بهبود مدل برنامه و حل و فصل مشکلات مرتبط با دامنه، پیوسته با متخصصین دامنه همکاری کنید.اگر تاکنون مطالب بالا را به درستی درک نکرده‌اید یا کلمات به‌کار رفته در آن برای شما نامفهوم است، اصلاً نگران نباشد. در مبحث طراحی دامنه محور، عبارات متفاوت و مهمی استفاده می‌شوند که در ادامه به تشریح آن‌ها پرداخته خواهد شد. هرکدام از این عبارات، بخشی از طراحی دامنه محور را تشکیل می‌دهند.منطق دامنهمنطق دامنه در واقع هدف مدل‌سازی را نشان می‌دهد که معمولاً از آن به‌عنوان کسب‌وکار هم یاد می‌شود. به کمک منطق دامنه، نحوه ایجاد، ذخیره و اصلاح داده‌ها مشخص می‌شود.مدل دامنهمدل دامنه شامل ایده‌ها، دانش، داده‌ها، معیارها و اهدافی است که حول آن مسئله ایست که به‌دنیال حل آن هستیم. مدل دامنه شامل تمام قوانین و الگوهایی است که به تیم توسعه کمک می‌کند تا با منطق پیچیدۀ کسب‌وکار مقابله کنند.زیردامنهیک دامنه از چندین زیردامنه تشکیل شده است که به بخش‌های مختلف منطق کسب‌وکار اشاره دارد. به‌عنوان مثال، یک فروشگاه خرده‌فروشی آنلاین می‌تواند کاتالوگ محصول، موجودی کالا و تحویل را به‌عنوان زیردامنه خود داشته باشد.مفاهیم محدودشدههمانطور که پیاده‌سازی و توسعۀ نرم‌افزار در جریان تکرارهای متعدد تکامل و پیچیدگی سیستم به تدریج افزایش می‌یابد، حفظ کنترل می‌تواند چالش برانگیز باشد. بنابراین، یک استراتژی دقیق برای درک و کنترل سیستم‌های بزرگ، مهم و اساسی است. تجزیۀ مدل به مفاهیم محدود شده که با یکدیگر تعامل دارند، راهی موثر برای جلوگیری از مشکلات پیچیدگی است. می‌توان گفت که یک مفهوم محدود شده، مرزی مفهومی در اطراف بخش‌هایی از برنامه و یا پروژه از نظر دامنۀ کسب‌وکار، تیم‌های توسعه و کُد است. یک مفهوم محدود شده، مؤلفه‌ها و مفاهیم مرتبط را گروه‌بندی نموده و از ابهام اجتناب می‌کند؛ زیرا برخی از آن‌ها می‌توانند دارای معانی مشابه و بدون تفاوت آشکاری باشند. مثلاً، اگر مفهوم محدود شده را درنظر نگیریم، یک «حرف» می‌تواند به معنای دو چیز بسیار متفاوت باشد: 1) یکی از حروف الفبا؛ و 2) سخن گفتن انسان‌ها با یکدیگر. اما با تعیین مرز و زمینه، می توان این دو معنا را از یکدیگر تشخیص داد.زبان فراگیرزبان فراگیر نوعی متدولوژی است که به همان زبانی اشاره دارد که کارشناسان و توسعه‌دهندگان زمانی که می‌خواهند دامنه‌ای که روی آن کار می‌کنند را تشریح کنند، از آن استفاده می‌کنند. استفاده از یک زبان فراگیر، امری ضروری است زیرا پروژه‌ها درصورت مواجهه با مشکلات زبانی، می‌توانند مختل شوند و دلیلش آن است که متخصصان دامنه از اصطلاحات مخصوص به خود استفاده می‌کنند درحالیکه متخصصان فناوری از اصطلاحات خود برای صحبت در مورد دامنه استفاده می‌نمایند. بین اصطلاحات مورد استفاده در بحث‌های روزانه و اصطلاحات استفاده شده میان این دو گروه، یک شکاف وجود دارد. به همین دلیل، لازم است مجموعه‌ای از اصطلاحات تعریف شوند که همه از آن استفاده نمایند. به این مجموعه، زبان فراگیر گفته می‌شود.موجودیت‌هاموجودیت‌ها ترکیبی از داده‌ها و رفتار هستند؛ مانند یک کاربر یا یک محصول. موجودیت‌های دارای هستند اما نقاط داده را با رفتار نشان می‌دهند.اشیاء ارزش‌دار و گروه‌های انباشتهاشیاء ارزش‌دار ویژگی و صفات را به‌همراه خود دارند، اما نمی‌توانند به تنهایی وجود داشته باشند. به‌عنوان مثال، آدرس می‌تواند یک شئ ارزش‌دار باشد. سیستم‌های بزرگ و پیچیده دارای موجودیت‌ها و اشیاء ارزش‌دار بی‌شماری هستند. به همین دلیل است که مدل دامنه به نوعی نیازمند ساختار است. به کمک گروه‌های انباشته، مدیریت موجودیت‌ها و اشیاء ارزش‌دار، آسان‌تر است. گروه‌های انباشته، موجودیت‌ها و اشیاء ارزش‌دار را در گروه های منطقی قرار می‌دهد و نحوۀ ارتباط آن‌ها با یکدیگر را نشان می‌دهد.سرویس دامنهسرویس دامنه یک لایۀ اضافی است که دارای منطق دامنه هم هست. این بخشی از مدل دامنه است، درست مانند موجودیت‌ها و اشیاء ارزش‌دار. درعین‌حال، سرویس برنامه یک لایۀ دیگر است که حاوی منطق کسب‌وکار نیست. با این حال، در طراحی دامنه محور جهت هماهنگ کردن فعالیت برنامه در بالای مدل دامنه قرار گرفته می‌گیرد.مخزنالگوی مخزن مجموعه‌ای از نهادهای کسب‌وکار است که زیرساخت داده را ساده می‌کند. این مدل دامنه را از نگرانی‌های زیرساختی رها ساخته و مفهوم لایه‌بندی جداسازی نگرانی‌ها را اعمال می‌نماید.ساختار طراحی دامنه محوردر پاراگراف‌های قبلی، عبارات زیادی تشریح شدند که شاید تجسم نمودن آن‌ها در کنار یکدیگر کمی دشوار باشد. حالا تمامی این مفاهیم را در قالب یک مثال، تشریح خواهیم نمود. اگر یک فروشگاه آنلاین را درنظر بگیریم، دامنۀ کسب‌وکار، شامل پردازش یک سفارش است. وقتی مشتری می‌خواهد سفارشی بدهد، ابتدا باید محصولات را بررسی کند. سپس موارد مورد نظر خود را انتخاب می‌کند، سفارش را تایید می‌کند، نوع ارسال را انتخاب می‌کند و در نهایت پرداخت می‌کند. سپس برنامه، داده‌هایی را که مشتری ارائه می‌دهد پردازش می‌کند. بنابراین باتوجه به آنچه در شکل زیر آمده است، این برنامه از لایه‌های زیر تشکیل می‌شود:لایۀ محیط کاربری: اینجاست که مشتری می‌تواند تمام اطلاعات مورد نیاز برای سفارش را پیدا کند. در مورد فروشگاه آنلاین، محیط کاربری جایی است که محصولات قرار دارند. این لایه اطلاعات را به مشتری ارائه می‌دهد و اقدامات آن‌ها را تفسیر می‌کند.لایۀ برنامه: این لایه حاوی منطق کسب‌وکار نیست بلکه بخشی است که کاربر را از یک صفحه به صفحۀ رابط کاربری دیگر هدایت می‌کند و همچنین با لایه‌های برنامه‌های سیستم‌های دیگر تعامل دارد. این لایه می‌تواند اعتبارسنجی ساده‌ای را انجام دهد اما هیچ منطق یا دسترسی به داده مربوط به دامنه ندارد. هدف این لایه، سازماندهی و واگذاری اشیاء دامنه برای انجام کارشان است. علاوه بر این، لایۀ برنامه تنها لایه‌ای است که برای همۀ مفاهیم محدودشده قابل دسترسی است.لایۀ دامنه: مفاهیم حوزۀ کسب‌و‌کار در این لایه قرار می‌گیرند. این لایه تمام اطلاعات مربوط به پرونده و قوانین کسب‌وکار را دربردارد. این لایه جایی است که موجودیت‌ها در آن قرار می‌گیرند. همانطور که قبلاً اشاره شد، موجودیت‌ها ترکیبی از داده‌ها و رفتار هستند، مانند یک کاربر یا یک محصول.لایۀ زیرساخت: این لایه از ارتباط بین لایه‌های دیگر پشتیبانی می‌کند و می‌تواند شامل کتابخانه‌های پشتیبانی کننده برای لایۀ رابط کاربری باشد.حالا که با طراحی دامنه محور آشنا شدید، به معرفی مزایا و معایب آن خواهیم پرداخت. ابتدا با تشریح مزایای طراحی دامنه محور آغاز خواهیم نمود:ارتباطات را تسهیل می‌کند: با تأکید بر ایجاد یک زبان مشترک و مرتبط با مدل دامنۀ پروژه، تیم‌ها اغلب ارتباط در کل چرخۀ توسعه را بسیار آسان‌تر می‌بینند. به‌طور معمول، طراحی دامنه محور به هنگام بحث در مورد جنبه‌های برنامه به اصطلاحات فنی کمتری نیاز دارد، زیرا زبان فراگیر که در اوایل ایجاد شده، احتمالاً اصطلاحات ساده‌تری را برای اشاره به جنبه‌های فنی‌تر تعریف می‌کند.انعطاف پذیری را بهبود می‌بخشد: از آنجایی که طراحی دامنه محور به شدت بر روی مفاهیم تجزیه و تحلیل و طراحی شئ‌گرا استوار است، تقریباً همه چیز در مدل دامنه، مبتنی بر یک شئ است و بنابراین کاملاً مدولار و محصور می‌شود. این ویژگی به تیم توسعه اجازه می‌دهد تا اجزای مختلف، یا حتی کل سیستم به‌طور منظم و مداوم تغییر و بهبود یابد.بر روی اینتِرفِیس دامنه تاکید می‌کند: از آنجایی که طراحی دامنه محور برابرست با یک تمرین برای ایجاد مفاهیم برروی دامنه، اغلب برنامه‌هایی را تولید می‌کند که برخلاف برنامه‌هایی که UI/UX را در اولویت قرار می‌دهند، دقیقاً برای دامنۀ مورد نظر مناسب هستند. تمرکز بر دامنه به این معنی است که رویکرد طراحی دامنه محور می‌تواند محصولی تولید کند که به خوبی با مخاطبان مرتبط با آن دامنه همراه شود.اما هر رویکرد در دنیای نرم‌افزار، همراه با برخی معایب است. از جمله معایب رویکرد طراحی دامنه محور می‌توان به موارد زیر اشاره نمود:به تخصص قوی در دامنه نیاز دارد: حتی با وجود ماهرترین ذهن‌های فنی که روی توسعۀ نرم‌افزار کار می‌کنند، اگر حداقل یک متخصص دامنه در تیم وجود نداشته باشد که از جزئیات دقیق حوزۀ موضوعی که برنامه برای آن درنظر گرفته شده است مطلع نباشد، همه چیز بیهوده است. در برخی موارد، طراحی دامنه محور ممکن است به ادغام یک یا چند عضو خارجی تیم نیاز داشته باشد که می‌توانند به‌عنوان متخصص دامنه در طول چرخۀ توسعه عمل کنند.تکرار فرایند را تشویق می‌کند: درحالیکه بسیاری این ویژگی را یک مزیت می‌دانند، نمی‌توان انکار کرد که فرایندهای طراحی دامنه محور قویاً بر تکرار ثابت و یکپارچگی مداوم برای ساختن یک پروژه انعطاف‌پذیر است. برخی از سازمان‌ها ممکن است با این شیوه‌ها مشکل داشته باشند، به‌ویژه اگر تجربه گذشتۀ آن‌ها تا حد زیادی با مدل‌های توسعۀ کمتر انعطاف‌پذیر، مانند مدل آبشاری یا موارد مشابه مرتبط باشد.برای پروژه‌های بسیار فنی، مناسب نیست: درحالیکه طراحی دامنه محور برای برنامه‌هایی که پیچیدگی دامنۀ زیادی دارند (که منطق کسب‌وکار نسبتاً پیچیده است) عالی است، اما برای برنامه‌هایی که پیچیدگی فنی زیادی دارند، زیاد مناسب نیست. از آنجایی که طراحی دامنه محور به شدت بر نیاز (و اهمیت) متخصصان دامنه برای تولید زبان مناسب و سپس مدل دامنه ای که پروژه براساس آن استوار است تأکید می کند، پروژه‌ای که از نظر فنی فوق‌العاده پیچیده باشد، ممکن است برای کارشناسان دامنه چالش برانگیز بوده و مشکلات زیادی را ایجاد کند.سخن پایانیطراحی دامنه محور یک رویکرد مهندسی نرم‌افزار برای حل یک مدل دامنه خاص است که در این پست سعی شد تا مفاهیم کلی آن به زبانی ساده بیان شود. برای کسب اطلاعات در این زمینه پیشنهاد می‌شود که دو کتاب مرجع طراحی دامنه محور توسط اِریک اِوانز و پیاده‌سازی طراحی دامنه محور توسط وان وِرنون را مطالعه نمایید.همچنین اگر به مباحث پیاده‌سازی و عملی علاقه دارید، در گیت‌هاب نمونه‌های متعددی را می‌توان یافت که بسیار آموزنده بوده و به کمک آن‌ها می‌توان مفاهیم را بهتر درک نمود.این مطلب به‌عنوان پاسخ برای بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی نوشته شده است که امیدوارم از آن استفاده برده باشید.مراجع[1] Banks, F. (2020, October 16). Domain-Driven Design: What is it and how do you use it? Airbrake. https://airbrake.io/blog/software-design/domain-driven-design [2] Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software (1st ed.). Addison-Wesley Professional.[3] Evans, E. (2014). Domain-Driven Design Reference: Definitions and Pattern Summaries. Dog Ear Publishing.[4] Martinez, P. (2021, July 13). Domain-Driven Design: Everything You Always Wanted to Know | SSENSE-TECH. Medium. https://medium.com/ssense-tech/domain-driven-design-everything-you-always-wanted-to-know-about-it-but-were-afraid-to-ask-a85e7b74497a [5] Miteva, S. (2020, July 3). The Concept of Domain-Driven Design Explained - Microtica. Medium. https://medium.com/microtica/the-concept-of-domain-driven-design-explained-3184c0fd7c3f [6] V. (2020). GitHub - VaughnVernon/IDDD_Samples: These are the sample Bounded Contexts from the book “Implementing Domain-Driven Design” by Vaughn Vernon. GitHub. https://github.com/VaughnVernon/IDDD_Samples [7] Vernon, V. (2013). Implementing Domain-Driven Design (1st ed.). Addison-Wesley Professional.[8] Wikipedia contributors. (2021, November 22). Domain-driven design. Wikipedia.https://en.wikipedia.org/wiki/Domain-driven_design علی حنیفی علی حنیفی Fri, 03 Dec 2021 13:09:44 +0330 https://virgool.io/@alihanifi/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%DA%AF%D8%B0%D8%B1%DA%AF%D8%A7%D9%87-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86%DB%8C-xl2a518k7cnd تحول دیجیتالی برای هر سازمانی که در تلاش است تا ارزش‌های تجاری خود را افزایش دهد، فرصت‌های جدید را کشف کند و از رقبای خود در بازار پیشی بگیرد، ضروری است. از طرف دیگر، در هر سازمانی انتقال داده‌ها میان چندین سیستم برای دستیابی به اهداف تجاری بسیار مهم و همچنین بسیار حیاتی است. سازمان‌ها می‌خواهند اطمینان حاصل نمایند که همه سیستم‌ها در حوزۀ کسب‌وکارشان به‌طور کارآمد یکپارچه شده‌اند و سیستم‌ها می‌توانند با به اشتراک گذاشتن داده‌ها با یکدیگر در صورت تمایل، برای برآوردن نیازهای تجاری بیشتر با یکدیگر همکاری و هماهنگی کنند.رویکردهای معماری متفاوتی برای ادغام سیستم‌ها و برنامه‌هایی که به‌صورت ناهمگن فعالیت می‌کنند، وجود دارد که با گذشت زمان به تکامل خود ادامه می‌دهند. سازمان ها با تغییر از ادغام P2P (نقطه به نقطه) به سمت مدل هاب و اسپیکر و سپس به سمت معماری گذرگاه سرویس سازمانی که موضوع بحث در این پست است، به سمت رویکردهای ادغام پیچیده‌تر و پیچیده‌تر پیشرفت کردند.در این پست به اصول معماری، نحوۀ عملکرد، نحوۀ بهره‌مندی سازمان‌ها، معرفی ابزارها و شرکت‌های مرتبط ایرانی با گذرگاه‌های سرویس سازمانی پرداخته خواهد شد.گذرگاه سرویس سازمانی چیست؟منشا اصلی عبارت گذرگاه سرویس سازمانی (ESB – Enterprise Service Bus) کاملاً مشخص نیست و همواره محل بحث بوده است. برخی آن را به گروه گارتنِر ربط می‌دهند و برخی دیگر عقیده دارند که آقای روی شولت مبدع آن بوده است. آقای شولت در جریان مصاحبه‌ای با CBR آنلاین اعتراف کرده بود که تعیین اینکه چه کسی اولین بار مفهوم پایه ESB را اختراع کرد، بسیار دشوار است و اذعان داشت که اولین محصول با مزمون ESB که طراحی و تولید شد، نرم‌افزار سونیک بود. از آنجایی که این موضوع هنوز مورد بحث است، بیایید با هم توافق کنیم که این مفهوم در ابتدای قرن بیستم میلادی معرفی شده است.اما مهم‌تر از اینکه چه کسی گذرگاه سرویس سازمانی را ابداع کرد و چه زمانی وارد بازار شد، این است که بدانیم مفهوم گذرگاه سرویس سازمانی چیست؟ گذرگاه سرویس سازمانی در واقع یک الگوی معماری است؛ یعنی مجموعه‌ای از قوانین و اصول است که برنامه‌های مختلف را در چارچوب یک گذرگاه، یکپارچه می‌کند. می‌توان گذرگاه سرویس سازمانی را از دیدگاه یک میان‌افزار هوشمند مشاهده کرد که ارتباط بین سیستم‌ها و برنامه‌های مختلف را شبیه به سیستم حمل و نقل اتوبوس شهری، که در آن تمام مناطق مجاور به ایستگاه‌های اتوبوس مرکزی برای انتقال مسافران به مقاصد متصل هستند، امکان‌پذیر می‌کند.ممکن است این سوال برایتان بوجود آمده باشد که میان‌افزار چیست؟ میان‌افزار در واقع نرم‌افزاری است که خدمات و قابلیت‌های مشترکی را برای نرم‌افزارهای خارج از آنچه توسط سیستم عامل ارائه می‌شود، ارائه می‌کند. شاید بهتر باشد که مفهوم گذرگاه سرویس سازمانی را به‌صورت گرافیکی ارائه شود. در شکل زیر، نمای کلی یک گذرگاه سرویس سازمانی ارائه شده است که در آن چندین سیستم و برنامه از طریق یک لولۀ پیام‌رسانی متمرکز (گذرگاه - Bus) یکپارچه می‌شوند. هر سیستم یکپارچه ممکن است به‌عنوان نقش ارائه کننده (سبز) یا مصرف کننده (آبی) و یا هر دو عمل کند. ارائه‌کنندگان در واقع خدمات رویدادها را تولید کرده و در گذرگاه رویداد منتشر می‌کنند. مصرف‌کنندگان نیز خدمات رویدادهایی را مصرف می‌کنند که به آن‌ها علاقه‌مند هستند. بدین‌ترتیب، گذرگاه سرویس سازمانی از جریان رویدادهای همزمان و ناهمزمان پشتیبانی می‌کند.یک گذرگاه سرویس سازمانی در واقع مفهوم طراحی سیستم عامل‌های مدرن را برای سرویس‌های مستقلی که در شبکه‌های کامپیوتری متفاوت و مستقل اجرا می شوند، اعمال می‌کند. همانند سیستم عامل‌ها، یک گذرگاه سرویس سازمانی خدماتی را علاوه بر پذیرش، ترجمه و مسیریابی درخواست‌های مشتری به خدمات پاسخگویی مناسب ارائه می‌دهد.وظایف اصلی یک گذرگاه سرویس سازمانی عبارتند از:مسیریابی پیام ها بین سرویس‌هانظارت و کنترل مسیریابی تبادل پیام بین سرویس‌هاحل نمودن اختلاف بین اجزای سرویسکنترل استقرار خدماتمزایا و معایب گذرگاه سرویس سازمانیهر نرم‌افزار و راهکاری در دنیای فناوری اطلاعات، مزایا و معایب مخصوص به خودش را دارد. در این قسمت به برخی مزایا و معایب گذرگاه سرویس سازمانی اشاره خواهد شد. البته باید درنظر داشت که این ویژگی‌ها به‌صورت کلی بیان شده و منحصر به ابزار خاصی نیستند. از جمله مزایای گذرگاه سرویس سازمانی می‌توان به موارد زیر اشاره کرد:استقلال فناوری: گذرگاه سرویس سازمانی از انواع مختلف پروتکل‌های انتقال اطلاعات مانند HTTP/S، AMQP و MQTT پشتیبانی می‌کند که باعث می‌شود استفاده از سرویس خارجی نگران کننده نباشد. هر سرویسی که بر اساس هر فناوری ساخته شده باشد، تا زمانی‌که بتواند با استفاده از یکی از پروتکل‌های فوق که توسط گذرگاه سرویس سازمانی پشتیبانی می‌شود ارتباط برقرار کند، قابل ادغام است.قابلیت استفاده مجدد از سرویس: هنگامی که سرویس‌ها از طریق گذرگاه سرویس سازمانی به‌عنوان سرویس‌های مجازی در معرض دید قرار می گیرند، بدون درنظر گرفتن محدودیت شبکه‌ها و فناوری‌ها، می‌توانند توسط هر سرویس دیگری استفاده شوند.حاکمیت و نظارت متمرکز: گذرگاه سرویس سازمانی قابلیت ردیابی همه خدمات را دارد و بنابراین می‌تواند یک نقطۀ مرکزی برای کنترل استفاده از خدمات و نظارت بر آمار باشد.قابلیت نگهداری: هیچ اتصال محکمی بین سرویس‌های پایانی وجود ندارد و بنابراین می‌توان آن‌ها را به‌طور مستقل بدون تأثیر بر سایر خدمات به‌روزرسانی کرد. همچنین انواع مختلفی از کنترل را می توان در لایۀ گذرگاه سرویس سازمانی به جای به‌روزرسانی سرویس‌های واقعی اعمال کرد.تحمل خطا: خرابی‌های سرویس و روش‌های بازیابی را می‌توان در گذرگاه سرویس سازمانی مدیریت کرد و بنابراین سرویس‌های پایانی تحت تأثیر قرار نخواهند گرفت. به‌عنوان مثال، اگر سرویسی با شکست مواجه شود، گذرگاه سرویس سازمانی می‌تواند پیام‌ها را تا زمانی که سرویس اصلی زنده شود (مجدداً شروع به‌کار کند)، از طریق نقطۀ پایانی سرویس به سمت شکست آن هدایت کند.از جمله معایب گذرگاه سرویس سازمانی نیز می‌توان به موارد زیر اشاره کرد:تأخیر اضافه شده در رفت و برگشت: لایۀ گذرگاه سرویس سازمانی یک مرحلۀ اضافی در جریان سرویس اضافه می‌کند و در نتیجه یک تأخیر جزئی به زمان پاسخ اضافه خواهد شد. بنابراین، ممکن است عملکرد مانند دسترسی مستقیم به خدمات از طریق اتصال نقطه به نقطه نباشد.الزامات اتصال: همه سرویس‌ها برای تسهیل فراخوانی نیاز به اتصال به گذرگاه سرویس سازماین دارند و این هزینۀ اضافی برای راه‌اندازی VPNها و سایر زیرساخت‌ها متحمل می‌شود.نقطۀ خرابی تکی: اگر همۀ سرویس‌ها از یک مکان واحد هدایت شوند، خطر یک نقطۀ خرابی را به همراه خواهد داشت. با داشتن فِیل‌اُور مناسب و قابلیت‌های بهبود خودکار آخرین پلتفرم‌های میزبانی می‌توان از این امر جلوگیری کرد.پیچیدگی در مقیاس‌پذیری: حتی تنها یک سرویس برای افزایش مقیاس نیاز است، چنین راهی برای افزایش ظرفیت آن سرویس به‌طور مستقل وجود ندارد. در عوض، باید کل گذرگاه سرویس سازماین را با سایر خدمات نیز افزایش داد که این اتلاف منابع و هزینه خواهد بود.معرفی ابزارها و فناوریهای متن بازدر بازار امروز نرم‌افزارها و راه‌حل‌های کامپیوتری، ابزارهای متن‌باز رقابت تنگاتنگی با سیستم‌های تجاری دارند. سامانه‌های گذرگاه سرویس سازمانی نیز از این قاعده مستثنی نیستند. در این قسمت به چهار ابزار متن‌باز برتر در این زمینه اشاره می‌شود.ابزار Red Hat Fuseابزار Red Hat Fuse در واقع نسخۀ توسعه داده شدۀ JBoss ESB است که در سال 2013 به پایان عمر خود رسید و کمپانی تولید کنندۀ آن توسط Red Hat خریداری شده و پس از آن به Red Hat Fuse تبدیل شد. ابزار Red Hat Fuse یک پلتفرم یکپارچه‌سازی توزیع شده است که برای ادغام با گزینه‌های استقرار یکپارچه‌سازی مستقل و اَبری طراحی شده است؛ بنابراین کارشناسان یکپارچه‌سازی، توسعه‌دهندگان نرم‌افزارها و کاربران تجاری می‌توانند به‌طور مستقل پروژه‌های متصل خود را در محیطی که انتخاب می‌کنند، توسعه دهند. پلتفرم یکپارچه به کاربران امکان می‌دهد با یکدیگر همکاری کنند، واحدهای تجاری به خودشان خدمت کنند و سازمان ها از حاکمیت خود اطمینان حاصل نمایند.برای کسب اطلاعات بیشتر راجع به Red Hat Fuse می‌توانید به آدرس وبسایت آن مراجعه نمایید.ابزار OpenESBابزار OpenESB یک گذرگاه سرویس سازمانی متن‌باز برپایۀ جاوا است که می‌توان از آن هم جهت یکپارچه‌سازی نرم‌افزارهای سازمانی و هم معماری برپایۀ سرویس (SOA) استفاده کرد. در ابتدا این ابزار توسط شرکت Sun توسعه داده شده بود که بعدها شرکت Oracle آن را خریداری کرد و هم‌اکنون توسط جامعۀ OpenESB پشتیبانی می‌شود. این ابزار امکان اتصال به سیستم‌های مختلفِ ناهمگن را فراهم نموده و آن‌ها را برای تبادل پیام به روش استاندارد و همکاری یکپارچه با یکدیگر تجمیع می‌کند. این استانداردها به کوتاه کردن یادگیری، توسعه سریع‌تر و سهولت استقرار و مدیریت کمک می‌نمایند.برای کسب اطلاعات بیشتر راجع به OpenESB می‌توانید به آدرس وبسایت آن مراجعه نمایید.ابزار MuleESBمی‌توان ابزار MuleESB را محبوب‌ترین سامانۀ متن‌باز گذرگاه سرویس سازمانی دانست. علت محبوبیت این ابزار، هزینۀ نگهداری پایین، پیکربندی آسان و انعطاف‌پذیری بالا است. این ابزار در ابتدا توسط آقای راس مِیسون توسعه داده شده و هم‌اکنون توسط شرکت MuleSoft پشتیبانی می‌شود.برای کسب اطلاعات بیشتر راجع به MuleESB می‌توانید به آدرس وبسایت آن مراجعه نمایید.ابزار WSO2 ESBابزار WSO2 ESB یک سامانۀ سبک وزن گذرگاه سرویس سازمانی است. برخلاف سایر رقبا که معمولاً از روش‌های سنگین‌وزن استفاده می‌نمایند، این ابزار به مدیران و توسعه‌دهندگان سیستم اجازه می‌دهد تا مسیریابی پیام، هدایت آدرس، تبدیل، ثبت، زمان‌بندی کار، خرابی، تعادل بار و موارد دیگر را به راحتی پیکربندی کنند. می‌توان این ابزار را کامل‌ترین پکیج در مقابل سایر نرم‌افزارهای رقیب متن‌باز دانست که مستندات بسیار قوی نیز دارد.برای کسب اطلاعات بیشتر راجع به WSO2 ESB می‌توانید به آدرس وبسایت آن مراجعه نمایید.معرفی شرکت های ایرانیدر این قسمت دو شرکت ایرانی که خدمات گذرگاه سرویس سازمانی را ارائه می‌دهند، آورده شده‌اند.شرکت پارس تصمیماین شرکت با بیش از 15 سال سابقه، خدمات حرفه‌ای از جمله مشاورۀ مدیریت، یکپارچه‌سازی سیستم‌ها و خدمات پشتیبانی ارائه می‌دهد. شرکت پارس تصمیم‌، یک شرکت دانش بنیان است که به بسیاری از سازمان‌ها و نهادهای خصوصی و دولتی بزرگ، خدمات ارائه می‌دهد. شرکت پارس تصمیم با ارائۀ راه‌حل جامع گذرگاه سرویس سازمانی، مجموعۀ کاملی از الگوهای یکپارچه‌سازی سازمانی (EIP) را مطابق با معماری سرویس‌گرا فراهم کرده که کارشناسان سازمان می‌توانند بدون برنامه نویسی، این الگوها را پیاده نمایند. از جمله خدمات ارائه شده توسط این شرکت عبارتند از: مجازی‌سازی سرویس نهایی، ایجاد دروازۀ پیغام، دروازۀ امنیتی، دروازۀ سرویس و API، مدیریت امنیت،ترکیب یا Orchestration و ارائۀ چند سرویس در قالب یک سرویس، مسیریابی و انتخاب سرویس نهایی براساس محتوای درخواست، تبدیل قالب‌ها و پروتکل‌های پیغام‌رسانی به یکدیگر، اعتبارسنجی درخواست‌ها و پاسخ‌ها، ذخیرۀ درخواست‌ها و پاسخ‌ها به‌منظور ممیزی، تحویل پیغام‌ها در زمان آماده شدن بدون نیاز به انتظار، تحویل تضمین شده پیغام و غیره.برای کسب اطلاعات بیشتر راجع به سامانۀ گذرگاه سرویس سازمانی پارس تصمیم و آشنایی بیشتر با این شرکت، می‌توانید به آدرس وبسایت آن مراجعه کنید.شرکت رسا سامانه افقشرکت رسا سامانه افق از سال 1385 در حوزه فناوری اطلاعات و تولید نرم‌افزار شروع به فعالیت کرده است و تاکنون نرم‌افزار و سیستم‌های تحت شبکۀ متعددی را تولید نموده است. در رابطه با گذرگاه سرویس سازمانی، این شرکت یک راهکار جامع به‌نام وصال ارائه نموده است که در واقع از چهار ماژول تشکیل می‌شود: 1) گذرگاه سرویس که مسئول پاسخ‌گویی و مدیریت فراخوانی سرویس‌هاست؛ 2) داشبورد مدیریت اطلاعات که در آن شاخص‌ها محاسبه و به‌صورت گرافیکی نمایش داده می‌شوند؛ 3) مدیریت یکپارچۀ کاربران که به کمک آن ورود و خروج کاربران به سامانه‌های مختلف کنترل می‌شود؛ و 4) پرتال کارمندی که در آن کلیۀ خدمات مورد نیاز کارمندان تجمیع شده است.برای کسب اطلاعات بیشتر راجع به سامانۀ وصال و آشنایی بیشتر با شرکت رسا سامانه افق، می‌توانید به آدرس وبسایت آن مراجعه کنید.سخن پایانیگذرگاه سرویس سازمانی در واقع یک سیستم ارتباطی بین نرم‌افزارهای ترکیبی را پیاده‌سازی می‌کند که در یک چارچوب سرویس‌گرا با یکدیگر تعامل دارند. گذرگاه سرویس سازمانی یک سیستم مقیاس‌بندی کارآمد است، زیرا وابستگی متقابل برنامه‌ها را حذف می‌کند. ممکن است که پیاده‌سازی این سامانه‌ها پیچیده و دشوار به نظر برسد، اما همچنان یک ابزار بسیار مفید در یک سازمان است.ارائۀ یک تعریف مختصر از آنچه که گذرگاه سرویس سازمانی انجام می‌دهد دشوار است، زیرا ابزاری گسترده است که مزایای متعددی را ارائه می‌دهد. با این حال گذرگاه‌های سرویس سازمانی علیرغم برخی اشکالات، برای تسهیل شفافیت مکان خدمات، به اشتراک گذاری خدمات و فرایندها در سراسر یک شرکت و جداسازی خدمات تجاری از اجرای سرویس، بسیار مفید هستند.این مطلب به‌عنوان پاسخ برای بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی نوشته شده است که امیدوارم از آن استفاده برده باشید.مراجع[1] Abbasi, A. (2021, August 19). ESB Introduction: Enterprise Service Bus Concepts. TutorialsPedia | Step By Step Tutorials. https://tutorialspedia.com/esb-introduction-an-overview-of-esb-concepts-capabilities-benefits-challenges/ [2] Ariyarathne, J. (2019, July 5). What do you really need within your solution: ESB or Microservices? Medium. https://medium.com/@jagathsisira/what-do-you-really-need-within-your-integration-solution-esb-or-microservices-1552d9803cb4 [3] Calderazzo, B. (2019, July 18). Enterprise Service Bus: everything you need to know. Interlogica. https://www.interlogica.it/en/insight-en/enterprise-service-bus-what-you-need-to-know/ [4] Wikipedia contributors. (2021, October 16). Enterprise service bus. Wikipedia. https://en.wikipedia.org/wiki/Enterprise_service_bus [5] پارس تصمیم. (2021). راه حل جامع گذرگاه سرویس سازمانی. شرکت پارس تصمیم. http://www.parstasmim.com/%d8%b1%d8%a7%d9%87-%d8%ad%d9%84-%d8%ac%d8%a7%d9%85%d8%b9-%da%af%d8%b0%d8%b1%da%af%d8%a7%d9%87-%d8%b3%d8%b1%d9%88%db%8c%d8%b3-%d8%b3%d8%a7%d8%b2%d9%85%d8%a7%d9%86%db%8c/ [6] گذرگاه وصال – رسا سامانه افق. (2021). رسا سامانه افق. http://rso-co.ir/%d9%88%d8%b5%d8%a7%d9%84/ علی حنیفی علی حنیفی Fri, 26 Nov 2021 17:17:55 +0330 https://virgool.io/@alihanifi/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%86%DA%AF%D8%A7%D8%B1%D9%87-%D9%87%D8%A7-sdqrmq9vitp2 از زمانیکه بشر توانایی نوشتن را آموخت، بسیاری از پیشرفت‌های انسان‌ها به لطف ثبت و استفاده از اطلاعات بوده است. در اعصار گذشته، یادداشت‌هایی در مورد تولید و جمع‌آوری منابع، تعداد دقیق سربازان در جنگ‌ها و سایر افراد مهم تهیه می‌شد و به‌صورت کاغذی، جمع‌آوری و ذخیره می‌گردید. به دلیل این روش مستندسازی، اطلاعات مهم نیز مستعد جابه‌جایی، گم شدن و یا حتی سوء استفاده بود.امروزه، عملاً هر اقدام مهمی، به‌ویژه آن‌هایی که به‌صورت آنلاین و روی کامپیوترها، تلفن‌های همراه و تبلت‌های ما انجام می‌شوند، در محل خاصی ثبت می‌گردند و بنابراین استفاده از یک راه‌حل مدیریت نگارۀ مناسب، اکنون بیش از هر زمان دیگری حیاتی است.اگر تابه‌حال با برنامه‌نویسی سروکار داشته‌اید یا اینکه برنامه‌نویسی خبره هستید، حتماً مبحث رفع ایرادات و در اصطلاح آزمون نرم‌افزار به گوشتان خورده است. پیدا کردن ریشۀ مشکلات خطاها در یک برنامۀ پیچیده، بسیار دشوار و زمان‌بَر است و لذا روش‌های گوناگونی برای آن پیشنهاد شده‌اند. یکی از این روش‌ها، استفاده از نگاره‌های نرم‌افزار (Software Logs) است.البته نگاره‌ها فقط برای کشف خطاها استفاده نمی‌شود. متخصصین رشته‌های فناوری اطلاعات از نگاره‌ها برای تشخیص و جلوگیری از حملات سایبری به سیستم‌ها استفاده نموده و معماران سازمانی هم از نگاره‌ها برای تشخیص و بهبود فرایندهای سازمانی استفاده می‌کنند. مثال‌ها و کاربردهای بسیار دیگری از این دست نیز می‌توان نام برد.در این پست می‌خواهیم با روش مدیریت نگاره‌ها (Log Management)، ابزارها و فناوری‌های متن‌باز مربوط به آن و معرفی برخی شرکت‌های ایرانی بپردازیم که در این حوزه فعالیت دارند.مدیریت نگاره‌ها چیست؟پرداختن به نگاره‌ها و مدیریت آن‌ها کار ساده‌ای نیست، اما جنبۀ مهمی از هر سیستم نرم‌افزاری است. هنگامیکه تیم توسعه با یک مشکل دشوار روبرو می‌شود، استفاده از ابزار مدیریت نگاره‌ها بسیار ساده‌تر از آن است که بخواهد حلقه‌های بی‌پایان فایل‌های متنی که در سراسر محیط سیستم پخش شده‌اند را بازبینی کند و از آن اطلاعات مورد نظرشان را استخراج نماید.دیگر دوران دردناک مدیریت نگاره‌ها با استفاده از گزارشات متنی گذشته است. اگرچه داده‌های متنی هنوز در موقعیت‌های خاص مفید هستند، ولی زمانیکه بخواهیم تجزیه و تحلیلی گسترده برای جمع‌آوری داده‌های زیرساختی انجام دهیم که نهایتاً منجر به بهبود کیفیت کد می‌شود، سرمایه‌گذاری در ابزارها و سیستم‌های مدیریت نگاره که قابل اعتماد باشند، می‌تواند فرایند کسب‌وکار را تقویت نماید.اما قبل از اینکه بیشتر وارد این مقوله شویم، باید بدانیم که نگاره چیست؟ نگاره (Log) در واقع یک فایل کامپیوتری است که فعالیت‌های درون سیستم عامل یا نرم‌افزارها در آن ثبت شده‌اند. هر نگاره به‌طور خودکار شامل اطلاعاتی است که توسط سازندۀ سیستم تعیین شده‌اند؛ از جمله: پیام‌ها، گزارشات خطا، درخواست انتقال فایل‌ها و غیره. این فعالیت‌ها همگی دارای برچسب زمانی هستند که به متخصص کمک می‌کنند تا زمان دقیق وقوع را متوجه شود و در نتیجه بتواند از آن بهره‌برداری کند.اگر بخواهیم مدیریت نگاره‌ها (Log Management) را دقیقاً تعریف کنیم، می‌توان از مستند شمارۀ SP800-29 متعلق به دپارتمان استاندارد و تکنولوژی از وزارتخانۀ اقتصاد آمریکا کمک گرفت که در آن مدیریت نگاره‌ها بدین‌صورت تعریف شده است: «به فرایند تولید، انتقال، ذخیره، تجزیه و تحلیل و از بین بردن داده‌های امنیت رایانه، مدیریت نگاره‌ها گفته می‌شود». اما در یک دید کلی‌تر، مدیریت نگاره‌ها عبارت است از جمع‌آوری، ذخیره، پردازش، ترکیب و تجزیه و تحلیل داده‌ها از نرم‌افزارهای متفاوت به‌منظور بهینه‌سازی عملکرد سیستم، شناسایی مسائل فنی، مدیریت بهتر منابع، تقویت امنیت و بهبود انطباق با سایر سیستم‌ها.ابزارهای مدیریت نگاره‌ها برای رسیدگی به تمام نگاره‌های تولید شده توسط برنامه‌ها، سیستم‌ها، شبکه‌ها، نرم‌افزارها یا کاربران و برخورد با آن‌ها به هر نحوی که به بهترین وجه با نیازهای یک سازمان سازگار باشد، استفاده می‌شود. مدیریت نگاره‌ها، یک موضوع محبوب نه تنها در بین مدیران سیستم، بلکه در بین توسعه‌دهندگان است؛ زیرا استفاده از نگاره‌ها برای اهداف امنیتی، بهبود عملکرد یا عیب‌یابی در بسیاری از بخش‌های فناوری اطلاعات و نقش‌های شغلی گسترده است.اما ذکر این نکته مهم است که همۀ ابزارهای مدیریت نگاره‌ها شبیه به هم نیستند و هر سیستم باید براساس نیازسنجی‌های سازمان و کسب‌وکار استفاده شود. به‌صورت کلی دو نوع سیستم مدیریت نگاره وجود دارد:سیستم‌های سادۀ جمع‌آوری کنندۀ مرکزی نگاره: این نوع از سیستم‌ها فقط برای جمع‌آوری اطلاعات از منابع مختلف طراحی شده‌اند و هیچ فرایندی برای گزارش‌گیری یا تحلیل داده‌ها در آن‌ها موجود نیست.سیستم‌های اطلاعات امنیتی و مدیریت رویداد (SIEM): این نوع از سیستم‌ها برخلاف نوع قبلی، برای تحلیل داده‌ها مناسب هستند و سرویس‌های مختلفی مانند گزارش‌گیری، هشداردهی و غیره را در اختیار کاربران قرار می‌دهند.و در نهایت به این سوال می‌رسیم که چرا باید از ابزارهای مدیریت نگاره‌ها استفاده کرد؟ پاسخ به این سوال ساده است؛ چون بدون آن، وقتی نوبت به بسیاری از جنبه‌های فناوری اطلاعات می‌رسد، در تاریکی دست و پا می‌زنیم. بدون این سیستم‌ها، اگر خطایی رخ بدهد می‌فهمیم که چیزی اشتباه است، اما نمی‌توانیم دقیقاً بفهمیم چه چیزی اشتباه است، یا حداقل نمی‌توانیم بدون صرف زمان زیادی برای جستجوی مشکل، این کار را انجام دهیم. این زمان تلف شده را همیشه می‌توان به روش‌های بهتر، سازنده‌تر و استراتژیک‌تر سپری کرد. خوشبختانه ابزارهای تخصصی مدیریت نگاره به ما کمک می‌کنند تا آن‌ها را بهتر و با کارایی بیشتر درک و مدیریت کنیم.معرفی ابزارها و فناوریهای متن بازامروزه ابزارهای تجزیه و تحلیل متن باز مختلفی برای مدیریت نگاره‌ها وجود دارند که استفاده از آن‌ها بسیار آسان است. معمولاً جامعۀ نرم‌افزاری رایگان و متن‌باز، طرح‌هایی را ارائه می‌دهد که با انواع پلتفرم‌ها و تقریباً هر سیستم عاملی کار می‌کنند. در این پست، به پنج ابزار مختلف در این زمینه اشاره خواهد شد.ابزار GraylogGraylog در سال 2011 در آلمان شروع به کار کرد و اکنون به‌عنوان یک ابزار متن‌باز یا تجاری ارائه می‌شود. این سیستم به‌عنوان یک سیستم مدیریت نگارۀ متمرکز طراحی شده است که جریان‌های داده را از سرورها یا نقاط پایانی مختلف دریافت کرده و به کاربر امکان می‌دهد تا اطلاعات را به سرعت مرور یا تجزیه و تحلیل کند. به دلیل سهولت در مقیاس‌پذیری، این ابزار شهرت فراوانی در بین مدیران کسب نموده است.مدیران فناوری اطلاعات رابط کاربری Graylog را آسان و عملکرد آن را قوی می‌دانند. Graylog براساس مفهوم داشبورد ساخته شده است، که به کاربر امکان می‌دهد معیارها یا منابع داده را انتخاب کند که ارزشمندتر هستند و به سرعت تِرندها را در طول زمان مشاهده کند.پیشنهاد می‌شود برای کسب اطلاعات بیشتر راجع به Graylog به آدرس وبسایت آن مراجعه نمایید.ابزار Elastic Stack (ELK Stack)Elastic Stack، که اغلب ELK Stack نامیده می‌شود، یکی از محبوب‌ترین ابزارهای متن‌باز در میان سازمان‌هایی است که باید مجموعه‌های بزرگی از داده‌ها را غربال کنند و بتوانند نگاره‌های سیستم خود را درک نمایند. این ابزار در واقع از سه محصول جداگانه تشکیل شده است: Elasticsearch، Kibana و Logstash.Elasticsearch برای کمک به کاربران برای یافتن موارد منطبق در مجموعۀ داده‌ها با استفاده از طیف گسترده‌ای از زبان‌ها و انواع کوئری‌ها طراحی شده است. سرعت بالا، مزیت شمارۀ یک این ابزار است. Kibana در واقع یک ابزار تجسمی است که همراه با Elasticsearch اجرا می‌شود تا به کاربران امکان تجزیه و تحلیل داده‌های خود و ایجاد گزارش‌های قدرتمند را بدهد. در نهایت هم آخرین قطعۀ این ابزار، Logstash است که به‌عنوان یک خط لوله صرفاً سمت سرور در پایگاه داده Elasticsearch عمل می‌کند. کاربر می‌تواند Logstash را با انواع زبان‌های برنامه‌نویسی و API ادغام کند تا اطلاعات وب‌سایت‌ها و برنامه‌های تلفن همراه را مستقیماً به موتور جستجوی قدرتمند Elastic Stalk وارد نماید.پیشنهاد می‌شود برای کسب اطلاعات بیشتر راجع به ELK به آدرس وبسایت آن مراجعه نمایید.ابزار LOGalyzeLOGalyze یک سازمان مستقر در مجارستان است که ابزارهای متن‌باز را برای مدیران سیستم و کارشناسان امنیتی ایجاد می‌کند تا به آن‌ها کمک کند تا نگاره‌های سرور را مدیریت کنند و آن‌ها را به نقاط دادۀ مفید تبدیل نمایند. این ابزار به‌صورت دانلود رایگان برای استفاده شخصی یا تجاری در دسترس است. این ابزار بدین‌منظور طراحی شده است که به‌عنوان یک خط لولۀ عظیم کار کند که در آن چندین سرور، برنامه‌ها و دستگاه‌های شبکه می‌توانند اطلاعات را با استفاده از روش پروتکل دسترسی به اشیاء ساده (SOAP) از آن تغذیه نمایند. این ابزار یک رابط کاربری فراهم می‌کند که در آن مدیران می‌توانند از آن جهت نظارت بر مجموعۀ داده‌ها و تجزیه و تحلیل آن‌ها استفاده کنند. LOGalyze برای تجزیه و تحلیل نگاره‌های سرور و برنامه‌ها ایده‌آل است و آن‌ها را در قالب‌های گزارش مختلف مانند PDF، CSV و HTML ارائه می‌کند.پیشنهاد می‌شود برای کسب اطلاعات بیشتر راجع به LOGalyze به آدرس وبسایت آن مراجعه نمایید.ابزار FluentdFluentd یک نرم‌افزار کِراس‌پلتفرم و ابزار نظارت بر نگاره‌های ‌متن‌باز است که گزارشات و جمع‌آوری داده‌ها را از چندین منبع داده یکپارچه می‌کند. این نرم‌افزار مجموعه‌های داده‌های ساخت‌یافته و نیمه ساخت‌یافته را پردازش نموده و نگاره‌های برنامه‌ها، نگاره‌های رویدادها و جریان‌های کلیک را تجزیه و تحلیل می‌کند و هدفش این است که لایه‌ای یکپارچه بین ورودی‌ها و خروجی‌های نگاره‌ها با انواع مختلف باشد. Fluentd پس از نصب فضای کمی را اِشغال نموده و فشار زیادی بر منابع سیستمی تحمیل نمی‌کند. بنابراین لازم نیست که کاربر نگران تمام شدن حافظه یا استفادۀ بیش از حد از پردازنده باشد. علاوه بر این، دارای یک معماری پلاگین انعطاف‌پذیر است که در آن کاربران می‌توانند از بیش از 500 افزونه برای گسترش عملکرد آن بهره ببرند.پیشنهاد می‌شود برای کسب اطلاعات بیشتر راجع به Fluentd به آدرس وبسایت آن مراجعه نمایید. ابزار NXlogNXlog یک ابزار قدرتمند و همه کاره برای جمع‌آوری و متمرکز کردن نگاره‌‌ها است که به‌صورت چند پلتفرمی کار می‌کند که برای شناسایی موارد نقض Policy، شناسایی خطرات امنیتی و تجزیه و تحلیل مسائل در نگاره‌های سیستمی، برنامه‌ها و سرور طراحی شده است. NXlog قابلیت جمع‌آوری نگاره‌های رویدادها را از نقاط پایانی متعدد در قالب‌های مختلف از جمله Syslog و نگاره‌های رویدادهای ویندوز دارد. این ابزار می‌تواند طیف وسیعی از وظایف مربوط به نگاره‌ها مانند چرخش، بازنویسی و فشرده‌سازی نگاره را انجام دهد. همچنین می‌توان در این ابزار، ارسال هشدار تعریف نمود که کاربر را از وقایع مختلف، مطلع نماید. البته ذکر این نکته مهم است که NXlog در دو نسخه ارائه می‌شود: اولی نسخۀ Community است که مجانی و متن‌باز است و نسخۀ تجاری آن Enterprise نام دارد که مجانی نیست.پیشنهاد می‌شود برای کسب اطلاعات بیشتر راجع به NXlog به آدرس وبسایت آن مراجعه نمایید.معرفی شرکت های ایرانیدر این قسمت دو شرکت ایرانی که خدمات مدیریت نگاره‌ها را ارائه می‌دهند، معرفی شده‌اند.شرکت مهندسی ارتباطی پیام‌ پردازهستۀ این شرکت در سال 1356 در دانشگاه صنعتی اصفهان شکل گرفته و در سال‌های بعد، تبدیل به یک شرکت خصوصی شده است. شرکت پیام پرداز در حال حاضر دارای 150 نفر پرسنل و یکی از با سابقه‌ترین و قدیمی‌ترین شرکت‌های ایرانی در زمینۀ امنیت اطلاعات و ارتباطات فعالیت می‌کند. این شرکت دارای 27 محصول مجزا در زمینه‌های مختلف است که یکی از آن‌ها سامانۀ مدیریت رویدادها و تحلیل ترافیك شبكۀ راوین (Ravin NTLM) نام دارد. اين سامانه، راه‌حل جامع مانیتورینگ كامل سرورها، تجهیزات زیرساخت شبكه، تجهیزات امنیتی، سرویس‌های تحت شبكه، پایگاه‌های داده و کلیه سامانه‌های نرم‌افزاری سازمان است که وقایع سرویس‌ها و شبکه را جمع‌آوری، ثبت، تحلیل و مدیریت می‌نماید و گزارش‌های ارزشمند از روی آن‌ها ارایه می‌کند.برای کسب اطلاعات بیشتر راجع به سامانۀ راوین و آشنایی بیشتر با شرکت پیام پرداز، می‌توانید به وبسایت آن مراجعه کنید.شرکت دانا پردازاین شرکت فعالیت خود را از سال 1385 آغاز نموده و کار اصلی آن تولید محصولات نرم‌افزاری برای کمک به سازمان‌ها و کسب‌وکارها است. شرکت دانا پرداز با بیش از 15 سال سابقه، به بسیاری از سازمان‌های بزرگ دولتی مثل بانک‌ها، وزارتخانه‌ها و نهادها و موسسات کشور در زمینۀ فناوری اطلاعات، خدمات ارائه می‌دهد. یکی از محصولات این شرکت، سامانۀ بینا است که توانایی مانیتورینگ همۀ اجزاء حیاتی شبکه و زیرساخت IT را فراهم می‌نماید. از جمله امکانات سامانۀ بینا می‌توان به این موارد اشاره کرد: مانیتورینگ پایگاه داده، مانیتورینگ تجهیزات شبکه، مانیتورینگ سرورها، مانیتورینگ ایمیل سرور، مانیتورینگ وب‌سایت‌ها، مانیتورینگ سرورهای مجازی، مانیتورینگ دما و رطوبت، مانیتورینگ پهنای باند، مانیتورینگ لینک‌های شبکه، مانیتورینگ نگاره‌های تجهیزات شبکه، مانیتورینگ نگاره‌های سرورهای مایکروسافت و در نهایت مانیتورینگ اکتیو دایرکتوری.برای کسب اطلاعات بیشتر راجع به سامانۀ بینا و آشنایی بیشتر با شرکت دانا پرداز، می‌توانید به وبسایت آن مراجعه کنید.سخن پایانیمدیریت نگاره‌ها در واقع راهکاری برای مدیریت اتفاقات و رخدادهایی است که در سیستم اتفاق می‌افتد. ابزارهای مدیریت نگاره‌ها شامل تمام بخش‌های فرایند مدیریت نگاره‌ها می‌شود و به کاربر امکان می‌دهد تا نحوۀ اجرای آن را کنترل کند. از آنجایی که هیچ دو سیستمی کاملاً شبیه به هم نیستند، هر سیستم مدیریت نگاره به کاربران امکان می‌دهد تا روشی را که می‌خواهند برای ذخیرۀ داده‌های نگاره‌های خود انتخاب نمایند. یکی از بزرگترین مزیت‌های سیستم‌های مدیریت نگاره، آن است که سطح پیشرفته تجزیه و تحلیل و تجسم است که به کاربران اجازه می‌دهد بینش بهتری نسبت به داده‌های خود داشته باشند.این مطلب به‌عنوان پاسخ برای بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی نوشته شده است که امیدوارم از آن استفاده برده باشید.مراجع[1] Altvater, A. (2021, March 30). Best Log Management Tools: Useful Tools for Log Management, Monitoring, Analytics, and More. Stackify. https://stackify.com/best-log-management-tools/ [2] Bocetta Feed, S. (2020). 5 useful open source log analysis tools. Opensource.com. https://opensource.com/article/19/4/log-analysis-tools [3] Kent, K., & Souppaya, M. P. (2006). Guide to computer security log management. Published. https://doi.org/10.6028/nist.sp.800-92[4] R. (2019, June 9). سامانه تحلیل ترافیک، مانیتورینگ و گزارشگیری شبکه، مدیریت لاگ | شرکت مهندسی ارتباطی پیام پرداز. پیام پرداز. https://payampardaz.com/blog/ravin-ntlm/ [5] Torre, D. (2010, October 18). What is log management and how to choose the right tools. CSO Online. https://www.csoonline.com/article/2126060/network-security-what-is-log-management-and-how-to-choose-the-right-tools.html [6] What is Log Management? Importance & Best Practices | Humio. (2021). Humio. https://www.humio.com/glossary/log-management/ [7] Why is Log Management Important? | Graylog. (2021). Graylog. https://www.graylog.org/post/why-is-log-management-important [8] نرم افزار مانیتورینگ شبکه بینا. (2020). دانا پرداز. https://www.danapardaz.net/bina/syslog-monitoring/ علی حنیفی علی حنیفی Tue, 23 Nov 2021 15:29:40 +0330 https://virgool.io/@alihanifi/cqrs-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-deheibe6dxdi اگر در دنیای توسعۀ نرم‌افزارها فعالیت کرده باشید، حتماً گوشتان با عبارت «الگوهای طراحی» آشناست. الگوهای طراحی شامل روش‌هایی تست شده و بدست آمده از طریق تجربه هستند که به کمک آن‌ها می‌توان مسائل طراحی نرم‌افزارها را برطرف نمود. الگوهای طراحی را می‌توان با یک مثال به‌صورت ساده‌تر بیان کرد.مثلاً فرض کنید خیاطی می‌خواهد یک پیراهن بدوزد و ابعاد و اندازه‌ها را در اختیار دارد. اما برای دوختن یقه یا سرآستین و حتی قسمت‌های دیگر، پارچه باید با شرایط خاصی بُریده شود تا هم دورریز آن به حداقل برسد و هم دوخت لباس زیبا باشد. خیاط‌ها این کار را به کمک شابلون‌ها یا الگوهای کاغذی انجام می‌دهند که طی سال‌ها تجربه بدست آمده‌اند.البته در دنیای نرم‌افزارها، موضوع کمی پیچیده‌تر است. الگوهای طراحی یک قطعه کُد و یا حتی یک ماژول و الگوریتم نیستند که بتوان آن را کُپی و پِیست کرد؛ بلکه آن‌ها یک دید کلی و راه‌حل سطح بالا برای حل مسائلی خاص، با شرایط ویژه هستند. توسعه‌دهنده باید ابتدا مسئله و شرایط آن را شناسایی نموده و سپس با الهام گرفتن از این الگوها، نسبت به حل مشکل اقدام نماید.یکی از مسائلی که ذهن توسعه‌دهندگان را به خود مشغول می‌کند، نحوۀ انتقال داده‌ها و کانال‌های آن است. امروزه میلیون‌ها نرم‌افزار وجود دارند که در کانال‌های مختلف و به روش‌های گوناگونی تبادل اطلاعات می‌کنند. یکی از این روش‌ها، CQRS است که رفتار و عملکرد سیستم را به دو قسمت دستور (Command) و کوئِری (Query) تقسیم می‌کند. در ادامه به معرفی این روش خواهیم پرداخت.CQRS چیست؟قبل از اینکه بدانیم CQRS چیست، ابتدا باید با CQS آشنا شویم. CQS در واقع یک الگوی طراحی و مخفف عبارت Command Query Separation است که معادل فارسی آن برابر است با جداسازی دستور و کوئری. این الگوی طراحی، اولین بار توسط آقای بِرتِراند مایِر در کتاب ساخت نرم‌افزار شئ‌گرا معرفی شد که مطالعۀ آن خالی از لطف نیست. او این الگو را در جریان ساخت زبان برنامه‌نویسی ایفِل کشف نمود و در ابتدای صحبت‌هایش می‌گوید که «سوال پرسیدن نباید باعث ایجاد تغییر در پاسخ شود». ایدۀ اصلی پشت CQS آن است که در یک سیستم نرم‌افزاری، دو دسته رخداد وجود دارد: 1) یک دستور که وظیفۀ خاصی را اجرا می‌کند و 2) یک کوئری که اطلاعاتی را بازمی‌گرداند؛ و هیچ تابعی نباید این دو عمل را به‌صورت همزمان انجام دهد و به اصطلاح، این دو نوع رخداد از یکدیگر جدا باشند.با علم به این موضوع، عبارت CQRS (مخفف Command Query Responsibility Segregation) چنین رفتار سیستمی را به حالت کلی‌تر و در سطح معماری منتقل می‌کند. در واقع CQRS یک الگوی معماری نرم‌افزار است که در آن بر جداسازی مسئولیت اجرای دستورات و کوئری‌ها تاکید می‌شود. در حقیقت وقتی از الگوی CQRS استفاده می‌کنیم، منطق نرم‌افزار به‌صورت عمودی به دو قسمت تقسیم می‌شود: اولی مدیریت دستورات و دومی دستیابی به داده‌ها. در حقیقت CQRS را می‌توان یک توسعه از CQS دانست. آقای گِرِگ یانگ که یکی از صاحبنظران در این زمینه است و عبارت CQRS اولین بار توسط ایشان ابداع شده، در این مورد می‌گوید:CQRS همان تعاریف CQS که توسط مایر بیان شده را استفاده کرده و تمامی نماهای آن را حفظ می‌کند. تنها تفاوت این دو مفهوم، آن است که CQRS اشیاء را به دو قسمت تقسیم می‌کند: یکی شامل دستورات و دیگری شامل کوئری‌ها.حالا که با کلیات CQRS آشنا شدید، نوبت به جزئیات می‌رسد. ابتدا باید دانست که دستور و کوئری چه هستند؟دستور در واقع یک امر مستقیم برای اجرای یک وظیفۀ خاص است. بنابراین هر دستور باعث ایجاد تغییری در داده‌ها می‌شود که کاربر آن را درخواست کرده است. آقای مایر دستور را چنین تعریف می‌کند:یک دستور، عملیاتی را انجام می‌دهد اما هیچ چیزی باز نمی‌گرداند.تمامی دستوراتی که در نرم‌افزار وجود دارند، مدل ثبت داده‌ها را تشکیل می‌دهند که این مدل شباهت بسیار زیادی با فرایندهای کسب‌وکار آن سازمان دارد. مدل ثبت دارای دو بُعد است: بُعد فیزیکی شامل اینکه داده‌ها در کجا ذخیره می‌شوند و بُعد منطقی شامل دامنۀ کسب‌وکار که به‌صورت کُد درآمده است.از طرف دیگر کوئری یک درخواست برای جستجوی داده‌هاست. آقای مایر کوئری را چنین تعریف می‌کند:کوئری، کاری را انجام نمی‌دهد (تغییر حالت ایجاد نمی‌کند) ولی نتیجه بازمی‌گرداند.هر کوئری یک درخواست کاربر را بیان می‌کند که می‌خواهد قسمتی از داده‌های ثبت شدۀ قبلی را مشاهده کند. تمامی درخواست‌های از پیش تعریف شده در سیستم، مدل خواندن داده‌ها را تشکیل می‌دهند که این مدل معمولاً از روی مدل ثبت داده‌ها تشکیل می‌شود. البته یکسان بودن مدل‌های ثبت و خواندن الزامی نیست. مدل خواندن داده‌ها همیشه ثابت نیست و همواره می‌توان به‌راحتی و با توجه به نیازها آن را تغییر داد.شرکت مایکروسافت یک مستند در رابطه با CQRS منتشر کرده که مثال‌های زیادی در آن بیان شده‌اند و در اینجا به یکی از آن‌ها اشاره خواهد شد. شکل زیر نشان‌دهنده دو مدل ثبت و خواندن مربوط به یک مدل کلی فرضی است. مثلاً اگر سیستم رزرو پرواز هواپیما را درنظر بگیریم، یک دستور فرضی می‌تواند «رزرو کردن 2 بلیط برای هاوایی» باشد و از طرف دیگر یک کوئری فرضی می‌تواند «رزروهای دو هفتۀ بعدی من را نشانم بده» باشد.وقتی بحث چنین الگویی مطرح می‌شود، ذهن برنامه‌نویسان و توسعه‌دهندگان خودبه‌خود به سمت پایگاه داده‌ها می‌رود؛ اما باید بدانید که الگوی CQRS به هیچ‌وجه دربارۀ ذخیره‌سازی داده‌ها صحبت نمی‌کند. منبع داده می‌تواند یک فایل اکسل، فایل متنی و یا حتی پایگاه داده MySql باشد. مهم آن است که CQRS یک طرز فکر جدید را معرفی می‌کند و در آن مدل ثبت و بازیابی داده‌ها از یکدیگر مستقل هستند. چنین تفکری باعث ایجاد برش عمودی در طراحی سیستم می‌شود. بسیاری از توسعه‌دهندگان فکر می‌کنند که باید دو پایگاه داده برای ثبت و خواندن داده‌ها وجود داشته باشد؛ اما چرا؟ پاسخ آن ساده است؛ CQRS این توانایی را بوجود می‌آورد که مدل خواندن را برای مطابقت با نیازهای مشتری اصلاح کنیم و داشتن یک مدل خواندن اختصاصی برای هر نما، یک امر معمولی است. چنین مدل‌های خواندنی با کوئری‌های SQL کمی متفاوت هستند و طیف متفاوتی از ستون‌ها را از جدول انتخاب می‌کنند. اما آن‌ها همچنین می‌توانند نماها یا جداول جداگانه باشند. ممکن است توسعه‌دهنده این کار را برای بهینه‌سازی عملکرد انجام دهد که در اینصورت، یکی از راه‌حل‌های بالقوه استفاده از جداول یا پایگاه داده‌های مختلف و همگام‌سازی آنها پس از ثبت است. با این‌حال، این یک قانون کلی نیست. توسعه‌دهنده باید استراتژی خود را متناسب با نیاز خودش انتخاب کند.آقای جیمی بوگارد در یکی از پست‌های وبلاگ خود به نام معماری بُرش عمودی، معماری تمیز (یا پوست پیازی، لایه‌ای – که یک روش شناخته شده و معروف است) را با معماری بُرش عمودی مقایسه می‌کند. شکل زیر نشان‌دهندۀ این دو معماری است.در معماری لایه‌ای، زمانی‌که توسعه‌دهنده بخواهد روی هستۀ اصلی یک لایه تغییر ایجاد کند، ممکن است به لایه‌های بعدی و حتی توابع وابسته آسیب بزند. چنین امری ریسک ایجاد تغییرات را بالا برده و در نتیجه رغبت وی برای ایجاد تغییرات بزرگ را از بین می‌برد. اما در معماری بُرش عمودی، مدل و API‌ها همگی به‌صورت عمودی بُرش می‌خورند و بنابراین هر گرداننده (Handler) در یک محیط مجزا قرار می‌گیرد. نتیجۀ چنین معماری، آن است که کوپلینگ (Coupling) میان لایه‌های مختلف کاهش می‌یابد.اما سوال دیگری در ذهن بوجود می‌آید که اگر توسعه‌دهنده بخواهد منبع ذخیره‌سازی داده‌های ثبت شدنی و خواندنی را از یکدیگر جدا کند چه اتفاقی می‌افتد؟ همانطور که در پاراگراف‌های بالاتر بیان شد، ایدۀ CQRS جداسازی منبع ثبت و منبع خواندن اطلاعات است؛ اما CQRS زمانی مفید واقع می‌شود که میان داده‌های ثبت شدنی و خواندنی هماهنگی وجود داشته باشد. اگر اطلاعاتی که ثبت می‌شوند با اطلاعاتی که به کاربران ارسال می‌شوند هماهنگ نباشد، یعنی برنامه وارد حالتی از خطا می‌شود که مطلوب نیست؛ درصورتیکه همۀ این تلاش‌ها برای بهبود عملکرد نرم‌افزار است.پاسخ این سوال که چگونه می‌توان میان منابع مختلف داده‌ها هماهنگی ایجاد کرد، قبلاً پاسخ داده شده است. در مورد CQRS باید به این مسئله بپردازیم که چگونه می‌توان این کار را بهتر انجام داد؟ روش حفظ تداوم داده مبتنی بر رویداد (Event-driven data persistence) تکنیکی است که در آن رویدادها مطابق با هدف یک برنامه خاص مطرح می‌شوند و داده‌های مرتبط با رویداد مورد نظر در اختیار افراد ذینفع قرار می‌گیرند. البته توضیح کامل این مسئله خارج از حوصلۀ مطلب فعلی است.در شکل زیر یک معماری داده را نشان داده شده است که CQRS را با استفاده از الگوی واسطه (Mediator) پیاده‌سازی می‌کند. اولین چیزی که باید به آن توجه کرد این است که همه درخواست‌ها، هم دستورات ثبت و هم کوئری برای خواندن داده‌ها، از وب سرور برنامه به مؤلفه‌ای به نام Mediator منتقل می‌شوند. هدف Mediator تشخیص درخواست‌های ثبت و خواندن و سپس مسیریابی درخواست بر اساس آن است. اگر درخواست یک دستور ثبت باشد، آن داده به مؤلفه‌ای به نام WriteDataManager ارسال می‌شود. اگر درخواست یک کوئری باشد، از مؤلفه‌ای به نامReadDataManager بازیابی می‌شود. در این مرحله، هر دو داده که توسط WriteDataManager و ReadDataManager نشان داده شده‌اند، سازگار هستند. بنابراین، هدف CQRS به گونه‌ای محقق شده است که کوپلینگ آن ضعیف بوده و در عین حال قابل اعتماد و تأیید بین منابع داده است.چه زمانی از CQRS استفاده کنیم؟همانند سایر الگوهای طراحی دیگر، CQRS هم مزایا و معایب مخصوص به خود را دارد. شاید بهتر باشد که برای پاسخ به این سوال، از صاحبنظران این زمینه استفاده کرد. آقای مارتین فاولِر در یکی از پست‌های بلاگ خود (که پیشنهاد می‌شود آن را مطالعه کنید) به این سوال چنین پاسخ می‌دهد که استفاده از CQRS یک چالش بزرگ است و فقط درصورتیکه مزایای آن بیشتر از معایبش باشد، باید از CQRS استفاده نمود. مهم است که بدانیم الگوی CQRS مثل چراغ جادو نیست و نمی‌تواند جوابی برای تمام مشکلات باشد. طبق نظر بسیاری از متخصصین، می‌توان از الگوی CQRS در شرایط زیر استفاده کرد:زمانی‌که نیازمندی‌های کسب‌وکار دائماً در حال تغییر هستند.مشخص نیست که کسب‌وکار دقیقاً به چه سمت و سویی می‌رود.پروژه دارای مشکلات مقیاس‌پذیری است.تیم پروژه با سایر تیم‌های خارجی ارتباط دارد.چندین سرویس با یکدیگر برای تغییر یک منبع رقابت دارند.نرم‌افزار فقط وظیفه ثبت را به‌عهده دارد و سیستم‌های خارجی نیاز به خواندن داده‌های نرم‌افزار دارند.به‌صورت کلی مزایای CQRS را به‌صورت زیر خلاصه نمود:استفاده یک از مدل برای ثبت و یک مدل دیگر برای خواندن، به توسعه‌دهنده اجازه می‌دهد تا تکنولوژی مناسب را برای هر عملیات لحاظ کند. مثلاً از SQL برای ذخیرۀ داده‌ها و NoSQL برای بازیابی داده‌ها استفاده کند.دفعات انجام عملیات خواندن اطلاعات بسیار بیشتر از ثبت آن‌هاست و بنابراین می‌توان با جایگذاری منابع داده در موقعیت‌های جغرافیایی مناسب، زمان تاخیر را کاهش داد.جداسازی عملیات ثبت و خواندن از یکدیگر باعث مقیاس‌پذیری بهتر استفاده از ظرفیت ذخیره‌سازی داده‌ها براساس استفادۀ واقعی می‌شود.همچنین معایب CQRS عبارتست از:پشتیبانی از CQRS نیازمند تخصص بالا در زمینۀ انواع پایگاه‌های داده است.استفاده از CQRS به معنای استفاده از پایگاه‌های دادۀ بیشتری است که در واقع برابر با هزینۀ بیشتر است.استفاده از تعداد پایگاه داده‌های متعدد برابرست با نقاط خرابی بیشتر. بنابراین سازمان‌ها باید یک تیم مجزا برای نظارت بر نقاط حساس تشکیل دهند و جدا از هماهنگی‌ها و تعاریف وظایف این تیم، هزینۀ آن هم مطرح است.با وجود این مزایا، باید در استفاده از CQRS بسیار محتاط بود زیرا بسیاری از سیستم‌های اطلاعاتی با مفهوم پایگاه اطلاعاتی که به همان روشی که خوانده می‌شود به‌روزرسانی می‌شود، به‌خوبی مطابقت دارند، افزودن CQRS به چنین سیستمی می‌تواند پیچیدگی قابل توجهی را اضافه کند. حتی اگر یک تیم توانا و پرتجربه هم در پروژه بکار گرفته شده باشند، ممکن است تاثیر روی کارایی و افزایش ریسک بسیار بالا باشد. استفاده کردن از CQRS همانند داشتن یک جعبه ابزار خوب است، اما باید مراقب بود که استفادۀ مناسب از آن دشوار است و در صورت سوء استفاده، براحتی قطعات مهم از بین خواهند رفت.سخن پایانیالگوی CQRS روشی برای جداسازی رفتار ثبت و رفتار خواندن داده‌ها از یکدیگر است. این روش مناسب سیستم‌هایی است که با تعداد درخواست‌های بسیار زیادی روی پایگاه‌های دادۀ خود مواجه هستند و برای حل مشکل آن حاضرند هزینه پرداخت نمایند. اثبات شده است که CQRS در شرایط مناسب، باعث افزایش کارایی سیستم‌ها می‌شود و آن‌ها را قادر می‌سازد تا مقیاس‌پذیری بسیار بهتری داشته باشند.البته باید گفت که هرچقدر CQRS قدرتمند است، استفاده از آن آسان نیست و نیاز به نیروی متخصص دارد. جداسازی مدل‌های مختلف از یکدیگر به این معنی خواهد بود که همواره یک ریسک برای ایجاد شدن ناهماهنگی میان داده‌ها وجود خواهد داشت. بنابراین شرایط سیستم، هزینه‌ها و نیروی انسانی همگی باید با استفاده از این الگو سنجیده شوند.این مطلب به‌عنوان پاسخ برای بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی نوشته شده است که امیدوارم از آن استفاده برده باشید.مراجع[1] Bogard, J. (2018, April 19). Vertical Slice Architecture. Jimmy Bogard. https://jimmybogard.com/vertical-slice-architecture/ [2] CQRS facts and myths explained - Event-Driven.io. (2021). Lazywill. https://event-driven.io/en/cqrs_facts_and_myths_explained/ [3] Derosiaux, S. (2021, July 11). CQRS: What? Why? How? - Stéphane Derosiaux. Medium. https://sderosiaux.medium.com/cqrs-what-why-how-945543482313 [4] Fowler, M. (2011). bliki: CQRS. Martinfowler.Com. https://martinfowler.com/bliki/CQRS.html [5] Ltd, E. S. (2021). Beginner’s Guide to Event Sourcing | Event Store. Event Store. https://www.eventstore.com/event-sourcing [6] Meyer, B. (1997). Object-oriented Software Construction. Prentice Hall.[7] R. (2021a, October 15). An illustrated guide to CQRS data patterns. Enable Architect. https://www.redhat.com/architect/illustrated-cqrs [8] R. (2021b, October 15). The pros and cons of the CQRS architecture pattern. Enable Architect. https://www.redhat.com/architect/pros-and-cons-cqrs علی حنیفی علی حنیفی Thu, 18 Nov 2021 23:20:56 +0330 https://virgool.io/@alihanifi/c4-documentation-model-impioqs03hvs اگر تابه‌حال در شاخۀ طراحیِ نرم‌افزار، چه به‌صورت انفرادی و چه گروهی فعالیت کرده باشید، حتماً عبارت «معماری نرم‌افزار» به گوشتان خورده است؛ شاید هم به‌صورت آکادمیک با آن آشنا شده باشید. فرقی نمی‌کند که دانش‌آموختۀ رشتۀ کامپیوتر باشید یا به‌صورت خودآموخته به این گرایش روی آورده باشید؛ درهرصورت باید ابزاری را شناخت که به کمکِ آن بتوان با پیچیدگی‌ها و پویایی محیطِ نرم‌افزارها مقابله نمود. امروزه نیازمندی‌های مشتریان دائماً درحال تغییر بوده و تمام افرادی که در طراحی یک نرم‌افزار دخیل هستند، حتی آنان که کدنویسی نمی‌کنند هم باید به معماری نرم‌افزار واقف باشند تا بتوانند به یک دیدگاهِ کلی دست یافته و نکات کلیدیِ آن را متوجه شوند. اینجاست که اهمیتِ دیاگرام‌ها و انتقال مفاهیم از طریق تصویر مشخص می‌شود. در این پست، مدلی به نام C4 معرفی خواهد شد که به کمک آن می‌توان مستندسازی گرافیکی انجام داد.مدلسازی دیداری معماری نرم‌افزارقبل از اینکه به مدل C4 بپردازیم، باید بدانیم که مدلسازی دیداری (گرافیکی) معماری نرم‌افزار چیست و چه کاربردهایی دارد. در ابتدای معرفی، ذکر این نکته ضروریست که در متونِ علمی و به‌خصوص روان‌شناسی اثبات شده است که انتقال اطلاعات به کمک شکل و به‌صورت گرافیکی فواید بسیاری دارد که از حوصلۀ این مطلب خارج است. اگر علاقه دارید که در این زمینه مطالعۀ بیشتری داشته باشید، کتاب جامعه‌شناسی و بازنمایی بصری نوشتۀ الیزابت چاپلین را به شما پیشنهاد می‌کنم.حالا که می‌دانیم انتقال داده‌ها به‌صورت دیداری چه فوایدی دارد، می‌توانیم از آن در معماری نرم‌افزار استفاده کنیم. مدلسازی دیداری معماری نرم‌افزار در واقع یک تکنیک جهت تبدیل ایده‌ها، داده‌ها، نکات کلیدی و دغدغه‌های یک نرم‎افزار به اشکالی است که ساده و قابل فهم باشند. استفاده کردن از این روش فواید متعددی دارد که از جملۀ آن‌ها می‌توان به افزایشِ درکِ مسئله، بهبودِ ارتباطاتِ میانِ افرادِ تیم، تشویق به همکاری و شناسایی حوزه‌های پیشرفت اشاره کرد.اما ترسیم دیاگرام‌ها باید از استانداردهای خاصی پیروی کند. معمولاً یکی از مشکلاتی که گریبان تیم‌های به اصطلاح «چابک» را می‌گیرد، همین عدم توجه به مستندسازی و استانداردها است. این نوع تیم‌ها معمولاً مستندسازی صحیح و کامل را فدای سرعت عمل و درخواست مشتری کرده و به ترسیم چند دیاگرام روی تختۀ وایت‌برد و استفاده از ابزارهایی مثل Visio اکتفا می‌نمایند. آقای ایونات بالوسین یک نوشتۀ مفید به‌نام هنرِ ترسیمِ دیاگرام‌های معماری منتشر نموده است که پیشنهاد می‌کنم در صورت علاقه، آن را مطالعه کنید. اینجاست که باید به روش‌هایی مثل C4 روی بیاوریم.مدل C4 چیست؟اکنون که متوجه شدیم مدلسازی دیداری فواید بسیاری دارد، به معرفی مدل C4 می‌پردازیم. اگر بخواهیم تعریف نسبتاً دقیقی از این مدل بیان کنیم، می‌توان گفت که مدل C4 معماری یک نرم‌افزار را از طریق نمایش چندین دیدگاه مختلف با تجزیۀ سیستم به مولفه‌ها و اِلِمان‌های مختلف و روابط میان آن‌ها، مستندسازی می‌کند. اگر کاملاً متوجه این جمله نشدید، جای نگرانی نیست چون در ادامه این تعریفِ ارائه شده، بیشتر توضیح داده می‌شود.برای ارائۀ تعریفی بهتر از مدل C4، آن را به چندین قسمت تقسیم می‌کنیم:عبارت C4 به چهار عنصر اشاره می‌کند: مفاهیم سیستمی (Context)، مولفه (Component)، کانتینر (Container) و کد (Code).مدل C4، یک ابزار برای مستندسازی معماری نرم‌افزار است؛ یعنی معماری نرم‌افزار را در چهار سطح مختلف تشریح می‌کند.این مدل، مجموعه‌ای از دیاگرام‌ها شامل مفاهیم سیستمی، مولفه‌ها، کانتینرها و کدهای مربوط به یک قسمت از نرم‌افزار را ارائه می‌کند. هر کدام از این دیاگرام‌ها اطلاعات مختلفی را نمایش می‌دهند که متناسب با نقش‌های خاصی در یک تیم است. پس هر کس می‌تواند به اطلاعات مورد نیاز خود دسترسی داشته باشد.می‌توان به مدل C4 از دیدگاه مجموعه‌ای از نقشه‌ها برای طراحی یک نرم‌افزار نگریست که می‌توان روی هرکدام از آن‌ها به اصطلاح Zoom نمود و سطح بیشتری از جزئیات را مشاهده کرد.شاید بهتر است این مدل به‌صورت دیداری نمایش داده شود. شکل زیر تمامی توضیحاتی که در پاراگراف بالا آمده را دربردارد. در ادامه سطوح مدل C4 بیشتر توضیح داده می‌شوند.شکل (1): نمای کلی مدل C4سطوح مدل C4همانطور که در قسمت قبلی ذکر شد، مدل C4 دارای چهار سطح است. هر کدام از این سطوح شامل دیاگرام‌های مختلفی هستند که متناسب با نقش‌های مختلف افراد یک تیم ترسیم می‌شوند. در این قسمت از یک مثال سیستم بانکداری الکترونیکی فرضی استفاده خواهد شد.سطح اول: دیاگرام مفاهیم سیستموقتی نرم‌افزاری طراحی می‌شود، مشخصاً باید ارتباطاتِ آن با سایر سیستم‌ها و افراد مشخص باشد. دیاگرام مفاهیم سیستم شامل چنین اطلاعاتی است. برای درک بهتر به شکل زیر توجه کنید که یک نمونه دیاگرام مفهوم سیستم بانکداری اینترنتی در آن نشان داده شده است. در چنین سیستمی مشتریان بانک با استفاده از بانکداری اینترنتی به اطلاعات خود دسترسی پیدا کرده و اقدام به ارسال یا دریافت پول می‌کنند. از طرف دیگر سیستم بانکداری اینترنتی وابسته به سیستم اصلیِ مستقر در بانک بوده و از سیستم ارسال ایمیل بانک برای اطلاع‌رسانی به مشتریان استفاده می‌کند. رنگ‌بندی عناصر نشان‌دهندۀ وضعیت سیستم‌ها (آبی: درحال ساخت و خاکستری: آماده) است.شکل (2): نمودار سطح اولسطح دوم: دیاگرام کانتینردر سطح دوم، جزئیات بیشتری از یک سیستم و کانتینرهای آن (نرم‌افزارها، پایگاه‌های داده، میکروسرویس‌ها و غیره) در سطح اول نمایش داده می‌شود. تصمیمات مربوط به تکنولوژی‌های مورد استفاده هم قسمتی از این دیاگرام هستند. شکل زیر، همان سیستم قبلی را در سطح دوم نمایش می‌دهد که در آن کل سیستم (داخل مستطیل خط‌چین) به‌صورت تجزیه شده به کانتینرها نمایش داده شده است؛ کانتینرها عبارتند از: نرم‌افزار تحتِ وبِ سرور، نرم‌افزار تک صفحه‌ای کاربر، اپلیکیشن موبایل، نرم‌افزار API سمت سرور و پایگاه داده.شکل (3): دیاگرام سطح دومسطح سوم: دیاگرام مولفهدر سطح سوم، جزئیات بیشتری از یک کانتینر نمایش داده می‌شود. منظور از جزئیات بیشتر، مولفه‌های واقعی هستند که گروهی از کدها در نرم‌افزار را نشان می‌دهند. شکل زیر یک دیاگرام مولفه مربوط به همان مثال قبلی را نشان می‌دهد که در آن نرم‌افزار API سمتِ سرور، به چهار مولفه تجزیه شده است. هرکدام از این مولفه‌ها، کنترل قسمتی از سیستم را برعهده دارند.شکل (4): دیاگرام سطح سومسطح چهارم: دیاگرام کدنهایتاً در سطح چهارم، جزئیات بیشتری از یک مولفه نمایش داده می‌شود. این دیاگرام نشان‌دهندۀ نحوۀ پیاده‌سازی (اینترفیس‌ها و کلاس‌ها) یک مولفۀ خاص است. مثلاً در شکل زیر، دیاگرام مثال قبلی مربوط به مولفۀ محیط بصری سیستم بانکداری اصلی را نشان می‌دهد.شکل (5): دیاگرام سطح پنجمنشانه‌گذاری مدل C4مدل C4 نشانه‌گذاری خاصی را پیشنهاد نمی‌دهد؛ یعنی برای ترسیم عناصر مختلف، معمار سیستم آزاد است تا از اشکال مختلفی استفاده کند. دیاگرام‌های نمونه‌ای که در بالا مشاهده کردید، همگی دارای نشانه‌گذاری فرضی بودند که هر کس می‌تواند آن‌ها را توسط ابزارهای مختلف، از کاغذ و قلم گرفته تا نرم‌افزارهای مختلف ترسیم کند. حتی می‌توان از نشانه‌گذاری‌های UML برای ترسیم دیاگرام‌های مدل C4 استفاده کرد.تنها استاندارد توصیه شده در مورد نشانه‌گذاری این مدل، ارائۀ یک نام، نوع عنصر، نوع تکنولوژی و توضیح کوتاه روی هر عنصر است. شاید عجیب به‌نظر برسد که این حجم از نوشته روی عناصر دیاگرام موجود باشد، اما وجود آن ضروری است؛ زیرا باعث رفع ابهام در مورد رفتار دیاگرام می‌شود. نکتۀ دیگری که در این مدل توصیه شده، وجود باکس راهنمای اشکال (شامل رنگ، نوع خطوط و غیره)، یکپارچگی اشکال در همۀ دیاگرام‌ها و وجود عنوان برای هر دیاگرام است.سخن پایانیمدل C4 یک روش ساده برای انتقال مفاهیم معماری نرم‌افزار در سطوحِ تجریدِ مختلف است که به کمک آن می‌توان مفاهیم متناسب با هر گروه از افراد را به آنان منتقل کرد. همچنین به دلیل سبک‌وزن بودن آن، می‌تواند ابزاری جهت شناسایی و یا طراحی مدل‌های معماری برای تیم‌های توسعۀ نرم‌افزاری با اهداف و دیدگاه‌های مختلف باشد.این مدل توسط آقای سایمون بروان توسعه داده شده که دو کتاب ارزشمند (مراجع 2 و 3) در این زمینه منتشر کرده است. اگر علاقه‌مند به کسب اطلاعات بیشتر در این زمینه هستید، پیشنهاد می‌کنم این کتاب‌ها را مطالعه کنید. همچنین با یک جستجوی ساده در سطح اینترنت یا مراجعه به وبسایت مدل C4، می‌توانید اطلاعات بیشتری راجع‌به سوالات مرتبط، چک لیست‌ها و سایر موارد مرتبط کسب کنید.این مطلب به‌عنوان پاسخ برای بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی نوشته شده است که امیدوارم از آن استفاده برده باشید.مراجع[1] Balosin, I. (2017, August 4). The Art of Crafting Architectural Diagrams. InfoQ. https://www.infoq.com/articles/crafting-architectural-diagrams/ [2] Brown, S. (2018). Technical leadership and the balance with agility Software Architecture for Developers - Volume 1. LearnPub.[3] Brown, S. (2021). Visualize, document and explore your software architecture Software Architecture for Developers - Volume 2. LearnPub.[4] The C4 model for visualizing software architecture. (2021). Simon Brown. https://c4model.com/ [5] Chaplin, E. (1994). Sociology and Visual Representation (1st ed.). Routledge. Kang, J. (2021, March 18).[6] Diagramming software architecture using C4 model and C4-PlantUML. LINE ENGINEERING. https://engineering.linecorp.com/en/blog/diagramming-software-architecture-using-c4-model-and-c4-plantuml/ [7] What is a C4 Model? How to Make C4 Software Architecture Diagrams. (2021, June 21). Gliffy by Perforce. https://www.gliffy.com/blog/c4-model [8] Wikipedia contributors. (2021, July 9). C4 model. Wikipedia. https://en.wikipedia.org/wiki/C4_model علی حنیفی علی حنیفی Thu, 11 Nov 2021 23:11:28 +0330