https://virgool.io/feed/@m_50577917 fa 2026-06-16 21:25:49 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@m_50577917 https://virgool.io/@m_50577917/%D8%AA%D8%A8%DB%8C%DB%8C%D9%86-%D8%A7%D9%84%D8%B2%D8%A7%D9%85%D8%A7%D8%AA-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%C2%AD%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D9%88-%D9%85%D8%B9%DB%8C%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D8%A7%D8%B1%D8%B2%DB%8C%D8%A7%D8%A8%DB%8C-%D8%A2%D9%86%D9%87%D8%A7-txzk3hfv7nts عنوان تحقیق: تبیین الزامات معماری نرم­ افزار و معیارهای ارزیابی آنها در محورهای مختلف معماری جهت استفاده به منظور نظارت بر پیمانکاران نرم ­افزاری در سازمان­ های بزرگچکیده:ارزیابی معماری نرم افزار به یک روش آشنا در جامعه مهندسی نرم افزار جهت توسعه­ ی نرم افزاری با کیفیت تبدیل شده است. ارزیابی معماری تلاش و هزینه‌های توسعه نرم‌افزار را کاهش می‌دهد و کیفیت نرم‌افزار را با توجه به نیازمندی­ های کیفی و شناسایی خطرات احتمالی، افزایش می‌دهد. ارزیابی معماری نرم افزار این اطمینان را به توسعه دهندگان نرم افزار می­ دهد که معماری انتخابی آنها هم نیازمندی­ های عملکردی و هم نیازمندی های غیرعملکردی و کیفی را برآورده می کند. این مقاله بحثی را در مورد روش‌ها و تکنیک‌های مختلف ارزیابی معماری نرم‌افزار ارائه می‌کند و همچنین بر روی خلاصه‌ای از اهمیت روش‌های مختلف ارزیابی زودهنگام و دیرهنگام معماری، شباهت‌ها و تفاوت‌های بین آنها، کاربرد، نقاط قوت و ضعف آنها تمرکز می‌کند و از آنجایی که اهداف كسب­ و كار مبنايي برای تحلیل، توجیه و ارزیابی سیستم ­های نرم­ افزاری می باشند، در انتها نیز به بررسی اهداف کسب و کار که بر ارزیابی و تحلیل معماری تاثیر می گذارند، پرداخته می شود. سیستم­ های نرم افزاری برای تحقق اهداف كسب­ و كار یا ماموریتی ساخته می­ شوند. اهداف كسب و كار زیربنای بسیاری از متدها برای طراحی و تحلیل معماری نرم افزار هستند. با این حال، استخراج دقیق و تعيين اهداف كسب­ و كار همیشه مشکل­ ساز بوده است چرا که اهداف کسب و کار در اشکال مختلف و در سطوح مختلف انتزاعی وجود دارند و ذینفعان سیستم معمولاً عادت ندارند اهداف را به صورت واضح بیان کنند. 1. مقدمهارزیابی معماری نرم ­افزار تکنیک یا روشی است که ویژگی­ ها، نقاط قوت و ضعف معماری نرم ­افزار، سبک معماری نرم­ افزار یا الگوی طراحی را تعیین می­ کند. ارزیابی معماری نرم­ افزار به توسعه ­دهندگان اطمینان می­ دهد که معماری انتخابی آنها هم نیازمندی­ های عملکردی و هم غیرعملکردی و کیفی را برآورده می ­کند. یک ارزیابی معماری باید مزایای بیشتری نسبت به هزینه­ ی انجام آن داشته باشد. ارزیابی معماری نرم­ افزار افزایش درک از سیستم و مستندسازی آن، تشخیص مشکلات موجود در معماری و یادگیری سازمانی را تضمین می­ کند. چندین روش و تکنیک برای ارزیابی معماری نرم افزار پیشنهاد شده است. در میان آنها، رویکردهای مبتنی بر سناریو کاملاً بالغ در نظر گرفته می شوند. همچنین روش های دیگری بر مبنای مدل ویژگی و مدل های کمی برای ارزیابی معماری نرم افزار نیز وجود دارند و روش‌های دیگری برای توجیه سیستماتیک ویژگی‌های سبک‌های معماری و الگوهای طراحی ایجاد شده‌اند. 2. آشنایی با برخی نیازمندی های معمارانه مهمتعیین اینکه کدام نیازمندی ها دارای اهمیت معمارانه هستند بسیار حائز اهمیت است. برای هر سیستم خاص، نیازمندی های معمارانه مهم باید با اهداف کسب و کار و مأموریت سیستم همسو باشند. برخی از ویژگی­ های سیستم (ها) علاوه بر جنبه ­ی عملکردی سیستم باید از نظر معماری نیز اهمیت داشته باشند. نیازمندی های معمارانه­ مهم اغلب از موارد زیر نشات می­ گیرند:ویژگی­ های کیفی (Quality Attributes) امنیت(Security)، کارایی (Performance) ، قابلیت اطمینان (Reliability)، قابلیت تغییر (Modifiablity) و ... همه ویژگی‌های کیفیتی هستند که ممکن است بر ساختار سیستم تأثیر بگذارند. هر ویژگی کیفی دارای مجموعه­ای از تکنیک‌های ساختاری است (به عنوان مثال، تاکتیک‌های معمارانه ذکر شده در کتاب Bus) که برای دستیابی به این ویژگی­ ها به کار می ­روند. حجم عملکرد (volume of functionality):هر عملکرد خاص بر ساختار معماری تأثیری نخواهد داشت، اما مجموعه های بزرگی از عملکردهای مشابه تأثیرگذار خواهند بود. یکی از نمونه‌های مربوط به تأثیر ساختاری، شکستن عملکرد است تا بتوان آن را به موقع اجرا کرد. مثال دیگر شناسایی اشتراکات در عملکرد برای کاهش زمان اجرا و نگهداری می­ باشد. معماری برای گروهی از سیستم های مرتبط:هنگامی که نیازمندی های مجموعه‌ای از سیستم‌های مشابه مانند خط تولید نرم‌افزار جمع‌آوری می‌شوند، اشتراکات و تغییرات در آن سیستم‌ها ممکن است از نظر معماری قابل توجه باشند.انتخاب تکنولوژی­ ها:ممکن است نیاز به استفاده از یک فناوری خاص برای یک سیستم، مانند NET. یا J2EE (Java 2 Enterprise Edition) وجود داشته باشد. این نیازمندی ها احتمالا از نظر معماری مهم هستند، زیرا بسیاری از تصمیمات بعدی با به کاربردن فناوری­ های خاص محدود می­ شوند.استقرار و عملیات: نیازمندی هایی که استراتژی های مربوط به استقرار پیش‌بینی‌شده و نحوه­ ی عملکرد سیستم را توصیف می‌کنند، از نظر معماری مهم هستند زیرا ممکن است موجودیت‌های ساختاری، ملزم به حمایت از استقرار یا ملاحظات عملیاتی باشند. 3. متدهای ارزیابی معماری در چرخه عمر نرم افزارتعدادی از روش های ارزیابی معماری که در مراحل مختلف چرخه توسعه نرم افزار قابل اجرا هستند، توسعه یافته اند. در برخی از این متدها دو فرصت اصلی برای ارزیابی معماری قبل و بعد از اجرا وجود دارد. روش­ های ارزیابی زودهنگام پیش از اجرا در معماری نرم­ افزار اعمال می­ شوند. در صورتی که معماری نرم­ افزار با توجه به نیازمندی­ های کیفی خاص آن در مراحل اولیه­ توسعه نرم ­افزار ارزیابی شود، می­ توان به اهداف کیفی دست یافت. روش‌های ارزیابی دیرهنگام نیز تفاوت بین معماری واقعی و معماری برنامه‌ریزی شده را مشخص می‌کنند. این روش­ ها دستورالعمل­ های مفیدی را در مورد چگونگی بازسازی معماری واقعی ارائه می­ دهند تا با معماری برنامه ریزی شده مطابقت داشته باشد.3.1 روش­ های ارزیابی زودهنگام معماری نرم افزارارزیابی زودهنگام معماری نرم افزار را می­ توان بر اساس مشخصه­ ها و توصیف معماری نرم­ افزار انجام داد. این ارزیابی به این صورت است که در رویکردهای مبتنی بر سناریو انعطاف‌پذیری و سادگی دیده می شود. تکنیک‌های ارزیابی مبتنی بر مدل ریاضی برای ارزیابی ویژگی‌های کیفی عملیاتی، مانند قابلیت اطمینان (reliability) و کارایی (performance) به‌ویژه در سیستم‌های نرم‌افزاری بلادرنگ ،به‌خوبی به کار می روند. 3.1.1 روش های ارزیابی معماری نرم افزار مبتنی بر سناریوروش‌های ارزیابی مبتنی بر سناریو، توانایی معماری نرم‌افزار را با توجه به مجموعه‌ای از سناریوهای مورد علاقه ارزیابی می­ کنند. سناریو شرح مختصری از یک تعامل واحد بین یک ذینفع با یک سیستم است. روش­ های ارزیابی مبتنی بر سناریو ابزاری سیستماتیک برای بررسی نرم افزار و معماری با استفاده از سناریوها ارائه می ­دهد. این روش­ ها تعیین می­ کنند که آیا معماری نرم ­افزار می­ تواند یک سناریو را اجرا کند یا خیر. تیم ارزیابی سناریو را بر روی معماری نرم‌افزار کاوش یا نگاشت می‌کند تا مولفه های معماری مورد نظر و تعاملات بین آنها را که می‌تواند وظایف بیان شده از طریق سناریو را انجام دهد، پیدا کند. در صورتی که معماری نرم ­افزار نتواند سناریو را اجرا کند، این رویکرد تغییرات مورد نیاز معماری نرم­ افزار را جهت پشتیبانی از سناریو فهرست کرده و هزینه انجام تغییرات را تخمین می­ زند. روش­ های ارزیابی مبتنی بر سناریو مستلزم حضور ذی­نفعان مربوطه برای استخراج سناریوها بر اساس نیازمندی ­های آنها می­ باشد. روش‌های مبتنی بر سناریو می‌توانند کشف مشکلات در معماری نرم‌افزار را از دیدگاه‌های مختلف با درگیر کردن ذینفعان متعدد در طول فرآیند استخراج سناریو تضمین کنند، کاربر نهایی نیز می‌تواند مسائل مربوط به کارایی (performance) را نشان دهد. در زیر مجموعه ای از روش های ارزیابی مبتنی بر سناریو آمده است:SAAM (Scenario-based Software Architecture Analysis Method)ATAM (Architecture based Tradeoff Analysis Method)ALPSM (Architecture-Level Prediction of Software Maintenance) and ALMA (Architecture-Level Modifiability Analysis)CBAM (Cost-Benefit Analysis Method)FAAM (Family-Architecture Assessment Method)SALUTA (Scenario-based Architecture Level UsabiliTy Analysis)SBAR (Scenario-Based Architecture Reengineering)SAAMCS (SAAM for Complex Scenarios)ESAAMI (Extending SAAM by Integration in the Domain)ASAAM (Aspectual Software Architecture Analysis Method)SACAM (Software Architecture Comparison Analysis Method) and DoSAM (Domain Specific Software Architecture Comparison Model)شکل - 1: رفتار رایج در روش های ارزیابی مبتنی بر سناریو3.1.1.1. مقایسه روش ­های مختلف ارزیابی مبتنی بر سناریومتد ارزیابی: SAAMهدف اصلی: تحلیل تناسب معماری و ریسکمراحل ارزیابی: شامل شش فعالیت است که برخی از فعالیت­ ها به صورت موازی انجام می­شوند- شامل هیچگونه فعالیت آماده سازی نیست.طبقه­ بندی سناریو و تحلیل تاثیر: به سناریوهای مستقیم و غیرمستقیم طبقه بندی می شوند. تعداد مؤلفه­ هایی را که تحت تأثیر سناریوها قرار می­گیرند، شمارش می­ کند. رویکردهای مورد استفاده: استخراج سناریو از طریق برگزاری طوفان فکری با ذینفعان. نگاشت سناریوها روی SAها برای تأیید عملکرد یا برآورد هزینه تغییراهداف آنالیز شده: اسناد معماری، به ویژه، نمایش نماهای منطقیتضمین کیفیت (QAهای آدرس داده شده): عمدتاً قابل تغییر است اما می­ توان آن را تطبیق داد.متد ارزیابی: ATAMهدف اصلی: آنالیز حساسیت و برآورد کردن (Tradeoff)مراحل ارزیابی: شامل نه فعالیت می باشد، برخی از فعالیت ­ها به صورت موازی انجام می­ شوند. فعالیت­ های آماده سازی را شامل می شود. طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای مورد کاربردی، رشد و کاوش نقاط حساسیت و نقاط برآورد (Tradeoff) را می­ شمارد.رویکردهای مورد استفاده: ایجاد درخت سودمندی برای استخراج سناریوها. تحلیل رویکردهای معماری با استفاده از مدل­ های تحلیلی برای شناسایی نقاط و برآورد کردن (Tradeoff) ریسک­ هااهداف آنالیز شده: رویکردها یا سبک­ های معماری؛ اسناد معماری عمدتاً 1+4 Kurcten را نشان می­ دهد.تضمین کیفیت (QAهای آدرس داده شده): QAs چندگانهمتد ارزیابی: ALMAهدف اصلی: پیش بینی هزینه تعمیر و نگهداری، ارزیابی ریسک، مقایسه معماریمراحل ارزیابی: شامل پنج فعالیت است، همچنین فعالیت استخراج سناریو شامل شش فعالیت است که به صورت متوالی اجرا می شوند. به هیچ فعالیت آماده سازی نیاز نیست.طبقه­ بندی سناریو و تحلیل تاثیر: تغییر سناریو. تخمین تغییر اندازه هر مولفه رویکردهای مورد استفاده: استخراج سناریو بر اساس اهداف ارزیابی. نگاشت سناریوها بر روی SAها برای برآورد هزینه تعمیر و نگهداری با در نظر گرفتن اثرات ریپل.اهداف آنالیز شده: مستندات معماری، در مورد ساختار سیستم نیز شامل مولفه­ ها و اتصالات (مانند نمای منطقی) است.تضمین کیفیت (QAهای آدرس داده شده):قابلیت استفاده مجدد (Reusability)متد ارزیابی: CBAMهدف اصلی: ارائه معیارهای کسب و کار برای تغییرات سیستمی خاص . عدم قطعیت مربوط به تخمین ها را صراحتا بیان می کند.مراحل ارزیابی: شامل شش مرحله اصلی، کمّی سازی مزایای کیفیت، هزینه و زمان بندی مفاهیم مربوط به استراتژی های معماری است. طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای مستقیم، غیرمستقیم و کاوشی. زمان و هزینه استفاده شده توسط سناریوها را محاسبه می کند.رویکردهای مورد استفاده:آنالیز مزایای مربوط به استراتژی های مختلف معماری، ارزیابی کیفیت، و محاسبه مطلوبیت با توجه به هزینه و عامل زمان.اهداف آنالیز شده: زمان و هزینه دخیل در تحلیل عوامل کیفی و مستندات معماریتضمین کیفیت (QAهای آدرس داده شده):هزینه ها، مزایا، و پیامدهای برنامه ریزیمتد ارزیابی: FAAMهدف اصلی: تاکید بر توانمندسازی تیم ها در به کارگیری نشست FAAMمراحل ارزیابی: شامل شش مرحله اصلی است، این مراحل باید در پاسخ به تجربه ارزیابی کلی معماری سازمان تطبیق داده شوند.طبقه­ بندی سناریو و تحلیل تاثیر: تمرکز بر سناریوهای قابل تعامل. فرآیند ارزیابی کلی برای حوزه سیستم های اطلاعاتی طراحی شده است.رویکردهای مورد استفاده:ایجاد رهنمودها و الگوها در ایجاد تغییر، راهنماها و الگوها و معیارهای رتبه­ بندی نیازمندی ها.اهداف آنالیز شده: اسناد معماری، به ویژه، نشان دادن نماهای منطقیتضمین کیفیت (QAهای آدرس داده شده):تعامل پذیری و توسعه پذیریمتد ارزیابی:SALUTAهدف اصلی: آنالیز قابلیت استفاده (Usability) مراحل ارزیابی: شامل چهار مرحله اصلی است که به صورت متوالی اجرا می شود- هیچگونه فعالیت آماده سازی نیاز نیست.طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای استفاده و تحلیل کیفیرویکردهای مورد استفاده: به کار گیری پروفایل ها برای بیان نیازمندی قابلیت استفاده. پیش‌بینی سناریو برای آنالیز ویژگی‌ها و الگوهای قابلیت استفاده استخراج‌شده.اهداف آنالیز شده: الگوهای قابلیت استفاده، ویژگی های قابلیت استفادهتضمین کیفیت (QAهای آدرس داده شده):نمای خاصی توصیه نمی شود. متد ارزیابی:SBARهدف اصلی: مهندسی مجدد SA برای دستیابی به QAsمراحل ارزیابی: شامل سه مرحله است که بارها و بارها اجرا شده اند. هیچ فعالیت آماده سازی نیاز ندارد.طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای توسعه و عملیاتی و تحلیل کیفیرویکردهای مورد استفاده: ارزیابی کیفیت با استفاده از یکی از چهار تکنیک و تحول معماریاهداف آنالیز شده: در ابتدا اسناد معماری ایجاد شد. نمای خاصی توصیه نمی شود.تضمین کیفیت (QAهای آدرس داده شده):QAs چندگانهمتد ارزیابی:SAAMCSهدف اصلی: توسعه سناریوهای پیچیده برای دستیابی به انعطاف پذیری خاصی از دامنهمراحل ارزیابی: شامل سه مرحله است که دو مرحله آن به صورت موازی اجرا می شوند. هیچ فعالیت آماده سازی ندارد.طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای پیچیده. همان SAAM است اما چهار سطح تأثیر را تعریف می کند.رویکردهای مورد استفاده: تجزیه و تحلیل SAs برای تعیین مقادیر سه عاملی که سناریوها را پیچیده می کنند.اهداف آنالیز شده: مستندات معماری خرد و کلانتضمین کیفیت (QAهای آدرس داده شده):انعطاف پذیریمتد ارزیابی:ESAAMIهدف اصلی: ادغام SAAM در فرآیند توسعه مبتنی بر استفاده مجدد از دامنه خاصمراحل ارزیابی: مانند SAAM اما وجود پایگاه دانش قابل استفاده مجدد را در نظر می گیرد.طبقه­ بندی سناریو و تحلیل تاثیر: مشابه SAAMرویکردهای مورد استفاده: فرمولاسیون یک الگوی تحلیل برای جمع آوری محصولاتی با قابلیت استفاده مجدداهداف آنالیز شده: اسناد معماری نرم افزار با قابلیت استفاده مجددتضمین کیفیت (QAهای آدرس داده شده):قابلیت تغییر(Modifiability)متد ارزیابی:ASAAMهدف اصلی: تحلیل جنبه های معماریمراحل ارزیابی: مشابه SAAM اما شامل جنبه های معماری و شناسایی مولفه های درهم نیز است.طبقه­ بندی سناریو و تحلیل تاثیر: سناریوهای مستقیم، غیرمستقیم و جنبه ای و تحلیل کیفیرویکردهای مورد استفاده: شناسایی جنبه های معماری از سناریوهای مستقیم و غیرمستقیم. تعامل سناریوهای جنبه ای برای شناسایی مولفه های مختلف، مانند مولفه های درهم و بد تعریف شدهاهداف آنالیز شده: مشابه SAAMتضمین کیفیت (QAهای آدرس داده شده):قابلیت تغییر(Modifiability)متد ارزیابی:SACAMهدف اصلی: مقایسه معماری نرم افزار از منظر حوزه های مختلفمراحل ارزیابی: شامل شش فعالیت است که به صورت مکرر اجرا می شود. شامل فعالیت های آماده سازی می باشد.طبقه­ بندی سناریو و تحلیل تاثیر: مشابه ATAM است.معیارها را تعیین می کند.رویکردهای مورد استفاده: گردآوری معیارهای مقایسه ای که SAهای کاندید را در یک نمای معماری مشترک ارائه می دهد، و تناسب SAs w.r.t. به معیارها را تحلیل می کند.اهداف آنالیز شده: مشابه ATAMتضمین کیفیت (QAهای آدرس داده شده):QAs چندگانهمتد ارزیابی:DoSAMهدف اصلی: مقایسه معماری نرم افزار از منظر یک دامنه خاصمراحل ارزیابی: شامل شش فعالیت است که به صورت متوالی اجرا می شوند. هیچ فعالیت آماده سازی نیاز ندارد.طبقه­ بندی سناریو و تحلیل تاثیر: اجرا نشده است.مشابه SCAMرویکردهای مورد استفاده: نگاشت معماری های کاندید به DACF، ارزیابی QA ها با استفاده از معیارها و مقایسه معماری ها بر اساس مقادیر متریک QAsاهداف آنالیز شده: مستندات معماری. نمای خاصی توصیه نمی شود.تضمین کیفیت (QAهای آدرس داده شده):QAs چندگانه3.1.2. ارزیابی معماری نرم ­افزار مبتنی بر مدل ریاضیاکثر روش‌های ارزیابی معماری نرم‌افزار مبتنی بر سناریو (به استثنای ATAM و SBAR) از استدلال­ های کیفی برای ارزیابی ویژگی‌های کیفی در زمان توسعه، استفاده می‌کنند. با این حال، برای اندازه‌گیری تناسب سیستم‌های نرم‌افزاری حیاتی، مانند نرم افزارهای حوزه ­های پزشکی، هواپیما، و مأموریت­ های فضایی، ارزیابی کمی ویژگی‌های کیفی عملیاتی نیز مهم است. بنابراین، تعدادی از روش‌های ارزیابی معماری نرم‌افزار مبتنی بر مدل ریاضی ایجاد شده‌اند. این روش ­ها معماری نرم­ افزار را با استفاده از معادلات ریاضی شناخته شده مدل می­ کنند. این روش ­ها از مدل­ ها برای به دست آوردن آمار و ارقام معماری، به عنوان مثال، میانگین زمان اجرای یک مولفه استفاده می­ کنند. این آمارهای معماری برای برآورد ویژگی­ های کیفی عملیاتی استفاده می­ شوند. Reliability و performance دو ویژگی کیفی مهم عملیاتی هستند. برای ارزیابی این دو ویژگی کیفی، طیف وسیعی از مدل‌های ریاضی ایجاد شده‌اند. دو رویکرد مختلف برای ارزیابی Reliability معماری نرم ­افزار به کار می­ رود که مبتنی بر مسیر و حالت هستند. SPE، WS، PASA، CM، BIM، ABI، AABI نیز رویکردهایی برای پیش‌بینی کارایی در سطح معماری می­ باشند.شکل - 2: تجزیه کارایی (performance) مبتنی بر معماری نرم افزار3.2. متدهای ارزیابی دیرهنگامسیستم های نرم افزاری برای رفع مشکلات و سازگاری با نیازهای جدید، به صورت مداوم اصلاح می شوند. توسعه دهندگانی که تحت فشار زمانی شدید و بار کاری سنگین فعالیت می کنند، همیشه نمی توانند بهترین راه را برای اعمال تغییرات دنبال کنند. در نتیجه معماری واقعی ممکن است نسبت به معماری برنامه ریزی شده دچار انحراف شود. روش‌های ارزیابی معماری نرم‌افزار دیرهنگام دستورالعمل­ های مفیدی را در مورد چگونگی بازسازی معماری واقعی ارائه می دهند تا با معماری برنامه­ ریزی شده مطابقت داشته باشد. در طول مرحله تست، روش‌های ارزیابی دیرهنگام معماری نرم‌افزار نیز برای بررسی انطباق کد منبع با طراحی برنامه‌ریزی شده اعمال می‌شوند. اقتصادی بودن فرآیند تأیید انطباق کد طراحی نه تنها باعث صرفه جویی در زمان به روز رسانی طرح ها می شود، بلکه مصنوعات طراحی و همچنین فرآیندهای توسعه و نگهداری نرم افزار را بهبود می بخشد. ارزیابی دیرهنگام معماری نرم ­افزار می­ تواند از داده­ های اندازه­ گیری شده در اجرای معماری نرم­ افزار استفاده کند. معیارها را می توان برای بازسازی معماری واقعی نرم افزار مورد استفاده قرار داد و به آن اجازه داد تا با معماری برنامه ریزی شده مقایسه شوند. شکل - 3: فعالیت های مربوط به ارزیابی دیرهنگام معماری نرم افزار3.2.1. مقایسه روش ­های مختلف ارزیابی دیرهنگام معمارینام رویکرد: رویکرد Tvedt و همکارانهدف اصلی: جلوگیری از انحطاط سیستم با شناسایی فعال و سیستماتیک و اصلاح انحرافات معماری واقعی نرم افزار از معماری برنامه ریزی شده.رویکرد مورد استفاده: بررسی نیازمندی­ های عملکردی و غیر عملکردیمراحل در ارزیابی دیرهنگام: شناسایی معماری واقعی، بررسی انحراف معماری واقعی نسبت به معماری برنامه ریزی شده، در نظر گرفتن توصیه های مربوط به تغییرات.تخلف شناسایی شده: الگوی طراحی، کلاس های نامناسب و تخلفات جزئینام رویکرد: رویکرد لیندوال و همکارانهدف اصلی: شناسایی مشکلات نگهداری در سیستم نرم افزاری و سیستمی که به عنوان سیستم مبتنی بر مولفه بازسازی شده است، استفاده از الگوی طراحی جدید.رویکرد مورد استفاده: طراحی یک سیستم مبتنی بر مؤلفه (EMS) برای رسیدگی به مشکلات قابلیت نگهداری در سیستم نرم افزاریمراحل در ارزیابی دیرهنگام: معماری واقعی جدید را با معماری واقعی قبلی و معماری واقعی برنامه ریزی شده مقایسه کنید.تخلف شناسایی شده: نقض اتصال بین ماژولینام رویکرد: رویکرد Fiutem و Antoniol (مبتنی بر ابزار)هدف اصلی: تعیین ناهماهنگیرویکرد مورد استفاده: طراحی بازیابی شده را با طراحی برنامه ریزی شده مقایسه می کند.مراحل در ارزیابی دیرهنگام: مقایسه و تعیین ناسازگاری هاتخلف شناسایی شده: برخی موارد نقض کدنام رویکرد: رویکرد Murphy و همکاران (مبتنی بر ابزار)هدف اصلی: به منظور بررسی انطباق کد منبع با معماری برنامه ریزی شده.رویکرد مورد استفاده: به کار بردن دنباله ای از مدل های بازتابی برای مقایسه طراحی معماری لایه.مراحل در ارزیابی دیرهنگام: بررسی اینکه آیا مدل سطح بالا با کد منبع موافق است یا مخالف. نگاشت اعلامی بین دو مدل را بررسی می کند.تخلف شناسایی شده: نقض فراخوانی بین ماژول هانام رویکرد: رویکرد Sefika و همکاران (مبتنی بر ابزار)هدف اصلی: تعیین همخوانی طراحی و اجرا در سطوح مختلف انتزاع. یک رویکرد ترکیبی است که تجسم های استاتیک و پویا مبتنی بر منطق را یکپارچه می کند.رویکرد مورد استفاده: رویکرد هیبریدمراحل در ارزیابی دیرهنگام: تجسم های منطقی، ایستا و پویا را یکپارچه می کند.تخلف شناسایی شده: نقض الگوی طراحی3.3. مباحثه در مورد روش های ارزیابی معماری گفته شده در این مقالهاکثر روش های مبتنی بر سناریو در سطوح درشت دانه مشابه هستند. اما تفاوت های قابل توجهی در سطوح ریز دانه­ تر بین آنها وجود دارد. روش های مختلف، سناریوها را به صورت متفاوت طبقه بندی می کنند. برخی از روش ها سناریوها را به صورت مستقیم و غیرمستقیم طبقه بندی می کنند، در حالی که برخی دیگر از سناریوهای مورد کاربرد یا سناریوهای رشد استفاده می کنند. یک روش ممکن است تعداد مؤلفه های تحت تأثیر یک سناریوی خاص را شمارش کند، در حالی که دیگری ممکن است از معیارها برای هر ویژگی کیفی استفاده نماید. از تحلیل تطبیقی چنین برداشت می شود کهبرخی از روش های مبتنی بر سناریو، به ویژه SAAM، ATAM و ALMA، با موفقیت در محیط های مختلف صنعتی به کار گرفته شده اند. روش‌های ارزیابی مبتنی بر سناریو اساساً از سناریوهای تغییر و سناریو تعاملات برای افشای مناطق مربوط به مشکل در معماری استفاده می‌کنند.این روش ها خطرات یک سیستم نرم افزاری را با تخمین درجه تغییراتی که معماری نرم افزار برای اجرای یک سناریو نیاز دارد، اندازه گیری می کنند.در روش های مبتنی بر سناریو، ارزیابی پوشش سناریو دشوار است. توسعه یک چارچوب یا روش‌شناسی به تعیین پوشش سناریو کمک می‌کند.رویکرد SAAMCS گام خوبی به سمت چارچوب است.تعداد بسیار کمی از روش‌های مبتنی بر سناریو توسط ابزار پشتیبانی می‌شوند. به عنوان مثال، فقط فعالیت های SAAM و ATAM تا حدی توسط ابزار پشتیبانی می شوند.به نظر می رسد رویکردهای ارزیابی مبتنی بر Performance نسبت به reliability ، بالغ تر هستند.رویکردهای مبتنی بر Performance عمدتاً بوسیله­ ی ابزار پشتیبانی می‌شوند، اگرچه هیچ یک از ابزارها نمی‌توانند فرآیند تحلیل کامل معماری را پشتیبانی کنند.رویکردهای ارزیابی مبتنی بر Performance رفتار همزمان و غیر قطعی مولفه­ های نرم افزار را در نظر می گیرند.رویکردهای ارزیابی مبتنی بر reliability از پشتیبانی ابزار چندانی برخوردار نیستند و این روش‌ها هنوز برای حمایت از رفتارهای همزمان و غیر قطعی مولفه­ های نرم‌افزار در حال تکامل هستند. ارزیابی مبتنی بر مدل ریاضی برای سیستم نرم افزاری مبتنی بر مولفه مناسب هستند.تبدیل معماری نرم افزار به یک مدل ریاضی دشوار است و استفاده از روش های ارزیابی معماری مبتنی بر مدل ریاضی نسبتاً کمتر از روش های ارزیابی مبتنی بر سناریو هستند.در ارزیابی معماری نرم‌افزار دیرهنگام، هدف اصلی ارائه ابزاری ارزان و سریع برای تشخیص تخلفات در معماری نرم‌افزار با تکامل سیستم‌های نرم‌افزاری است. بنابراین، این روش‌های ارزیابی بیشتر با ابزار پشتیبانی می‌شوند. رویکردهای مبتنی بر معیارها تنها برای ارزیابی معماری نرم‌افزار با توجه به دیدگاه قابلیت نگهداری استفاده شده‌اند. ارزیابی دیرهنگام معماری نرم افزار تا حد زیادی به تحلیل سازگاری طراحی-کد می پردازد.ارزیابی دیرهنگام معماری نرم‌افزار فاقد چارچوب رسمی و طبقه‌بندی شده برای تحلیل ناهماهنگی‌های طراحی و کد و اولویت‌بندی مداخلات برای طراحی است.4. دسته بندی اهداف کسب و کارهمانطور که در شکل 3 نشان داده شده است، پنج طبقه­ بندي برای اهداف کسب و کار براساس منبع [7] وجود دارد: (1) کاهش کل هزینه مالکیت(2) بهبود قابلیت/کیفیت سیستم(3) بهبود موقعیت بازار(4) پشتیبانی از فرآیندهای بهبود یافته كسب­ و كار (5) افزایش اعتماد و درک سیستم. شکل 4: طبقه ندي اهداف كسب وكار 4.1. کاهش کل هزینه مالکیت کاهش هزینه­ ها یکي از اهداف كسب ­وكار است که اغلب در ارزیابی­ های ATAM ذکر مي­ گردد. در برخی موارد کاهش هزینه به عنوان یک هدف کلی ذکر مي­ شود. در موارد دیگر، کاهش هزینه در بخش خاصی از چرخه عمر شناسایی مي­ گردد. در دسته بندی ارائه شده در منبع [7] این گروه بندی از اهداف تحت عنوان کاهش کل هزینه مالکیت نام گذاری شده و شامل زیر گروه های زیر می باشد:کاهش هزینه های توسعه کاهش هزینه های استقرار و عملیاتکاهش هزینه های نگهداری کاهش هزینه های بازنشستگی / انتقال به یک سیستم جدید انواع اهداف كسب­ و كاري که این گروه ­ها را تشکیل می دهند به شرح زیر می باشند:کاهش هزینه های توسعه- مديريت انعطاف­ پذیری- توسعه توزیع شده- قابل حمل بودن- سیستم ­ها/استانداردهای باز- تست­ پذیری- خطوط تولید- قابلیت یکپارچگی- تعامل­ پذیریکاهش هزینه استقرار و عملیات- سهولت نصب- سهولت تعمیر کاهش هزینه ­های نگهداری- انعطاف­ پذیری/قابلیت پیکربندیکاهش هزینه بازنشستگی / انتقال به یک سیستم جدید- بازنشستگی سیستم­ ها- انتقال تدریجی به سیستم ­های بعدی- جایگزین کردن سیستم­ های قدیمیتوجه داشته باشید که بسیاری از این اهداف تجاری ویژگی ­های کیفی هستند [8]. همه ویژگی ­های کیفی به طور بالقوه اهداف کسب­ و کار هستند، اما همه اهداف کسب­ و کار ویژگی­ های کیفیت محسوب نمی­شوند [7]­.4.2. بهبود قابلیت/کیفیت سیستمبهبود قابلیت/ کیفیت سیستم گروه دیگری از اهداف کسب ­و کار هستند که اغلب به بهبود قابلیت یا کیفیت یک سیستم در مقایسه با نسخه های قبلی همان سیستم یا در تضاد با سیستم(های) در حال جایگزینی اشاره دارند. گاهی اوقات اهداف کسب­ و کار فقط نیازمندی­ های سیستم فعلی را بدون ارجاع به سیستم های قبلی مشخص می کند. این طبقه­ بندی به شرح زیر است:کارایی (performance)قابلیت اطمینان/در دسترس بودنخطوط تولید سهولت استفاده امنیت (security) ایمنی (safety)مقیاس پذیری/توسعه پذیری (scalability/extendibility) عملکرد (functionality) محدودیت­ های سیستمبین­ المللی شدن (internationalization)4.3. بهبود موقعیت بازاربرخی از اهداف تجاری که از ارزیابی های تجاری ATAM به وجود آمده اند، با موقعیت یا زمان بندی بازار مرتبط هستند. زیرگروه های اهداف زیربنایی این دسته به شرح زیر است:گسترش یا حفظ سهم بازارحفظ یا بهبود اعتبارورود به بازارهای جدیدکاهش زمان ورود به بازار4.4. پشتیبانی از فرآیندهای کسب ­و کار بهبود یافتهدسته قابل توجه دیگری از اهداف کسب و کار مربوط به بهبود فرآیندهای داخلی کسب و کار و ساختار سازمان است. زیر گروه های اساسی اهداف به شرح زیر است:پشتیبانی از توسعه توزیع شدهحفظ مشاغل نیروی کار در سیستم های قدیمی4.5. بهبود اعتماد و درک سیستمدسته نهایی شامل اهدافی است که برای ارتقای اعتبار سازمان در حال توسعه در نظر گرفته شده است. یک زیر گروه از اهداف در این دسته بیشتر وجود ندارد: حفظ/ گسترش اعتبار5. کاربرد دسته بندی اهداف کسب و کاردر مجموعه اهداف کسب­ و کار استخراج شده از ارزیابی‌های گذشته ATAM، سازمان‌ها معمولاً در ایجاد درخت سودمندی سطح بالا و ارائه اهداف کسب­ و کار با مشکل مواجه بودند. علاوه بر این، اهداف کسب­ و کاری که آنها ارائه می­ کردند کیفیت های بسیار متفاوتی داشت. اغلب، سازمان ها به سادگی یک ارائه موجود را بهبود می بخشیدند. این ارائه معمولاً به خوبی با نیازهای ATAM تنظیم نشده بود و از این رو نتایج ضعیفی به همراه داشت. در نتیجه در منبع [5] دو کاربرد اساسی و مهم برای دسته بندی اهداف کسب و کار معرفی گردید: سازمان ها را قادر می سازد تا اهداف کسب­ و کار خود را متمرکزتر و کامل تر ارائه دهند: یک سازمان می‌تواند با استفاده از این طبقه‌بندی، اطمینان حاصل کند که مجموعه کامل و جامعی از اهداف کسب­ و کار را ایجاد کرده است. ساده سازی تولید درخت سودمندی از طریق درج اهداف کسب­ و کار در سطوح بالاتر درخت و ارائه سناریوهای نمونه برای هر هدف کسب­ و کار: درخت مطلوبیت یک ابزار استخراج و ساختاردهی مفید بالا به پایین است که سال‌ها با موفقیت در ارزیابی‌های ATAM استفاده می­شد. با این حال، معمولاً ذینفعان در شروع فرآیند با مشکل مواجه می شدند. داشتن اهداف کسب ­و کار نمونه برای نمایش به ذینفعان، همراه با سناریوهای نمونه ای که برگرفته از این اهداف هستند، شروع فرآیند را تسهیل می­ بخشد. از منظر ارزیابی ATAM، اهدف کسب‌وکار دو جنبه دارد: 1. منتهی به سناریوهای ویژگی کیفی شود و 2. مضامین ریسک از نظر تهدیدات اهداف کسب­ و کار را بیان کند. در ادامه سناریوهای منتهی به ویژگی های کیفی را برای هر یک از طبقه بندی های ارائه شده برای اهداف کسب و کار و زیر گروه های آنها ارائه می کنیم: کاهش هزینه توسعه- هدف کسب و کار: مدیریت انعطاف پذیری- سناریو ویژگی ­های کیفی: یک پارامتر اضافی به سیستم اضافه می شود. مقدار این پارامتر برای سازگاری و مقادیر نادرست احتمالی در عرض 10 دقیقه بررسی می شود.- هدف کسب و کار: توسعه توزیع شده- سناریو ویژگی ­های کیفی: مؤلفه A در مکان X و مؤلفه B در مکان Y در حال توسعه هستند. یک ضرب­ العجل (deadline) برای هر دو مؤلفه A و B تعیین می شود. علت ضرب­ العجل مشخص می شود و راه حلی در عرض دو نفر-روز پیشنهاد می شود.- هدف کسب و کار: قابل حمل بودن (portability)- سناریو ویژگی ­های کیفی: سیستم A از پلتفرم B به پلتفرم C بدون از دست دادن عملکرد در عرض دو نفر-هفته منتقل می شود.- هدف کسب و کار: سیستم­ ها/استانداردهای باز- سناریو ویژگی ­های کیفی:مولفه­ای که به استاندارد X پایبند است طی دو نفر-روز در سیستم یکپارچه می­شود.- هدف کسب و کار: تست­ پذیر بودن- سناریو ویژگی ­های کیفی: یک تغییر در یک ویژگی به صورت کامل در عرض دو نفر-روز تست می­شود.- هدف کسب و کار: خطوط تولید- سناریو ویژگی ­های کیفی: محصول جدید تولید می­شود. این محصول باید از بیش از 80 درصد از دارایی های اصلی مجدداً استفاده کند و تکمیل آن بیش از هشت نفر سال طول نمی کشد.- هدف کسب و کار: یکپارچگی- سناریو ویژگی ­های کیفی: یکپارچگی زیرسیستم های A، B، و C در مدت دو نفر-ماه تکمیل می شود.- هدف کسب و کار: تعامل پذیری- سناریو ویژگی ­های کیفی: در صورت استقرار، سیستم A می‌تواند با سیستم‌های B و C موجود با استفاده از پروتکل D بدون تغییر زیادی کار کند. کاهش هزینه استقرار و عملیات- هدف کسب و کار: سهولت نصب و تعمیر- سناریو ویژگی ­های کیفی: نسخه جدید سیستم A را می توان در عرض دو روز بر روی دسکتاپ همه کاربران نصب و مستقر کرد.- سناریو ویژگی ­های کیفی: تعداد اپراتورهای مورد نیاز برای راه اندازی سیستم A نصف تعداد مورد نیاز برای راه اندازی سیستم B موجود خواهد بود. کاهش هزینه تعمیر و نگهداری- هدف کسب و کار: انعطاف پذیری/پیکربندی- سناریو ویژگی ­های کیفی: یک ویژگی جدید را می توان در عرض دو روز به سیستم A اضافه کرد. کاهش هزینه بازنشستگی/ انتقال به سیستم جدید- هدف کسب و کار: بازنشستگی سیستم ­ها، انتقال تدریجی به سیستم ­های بعدی و جایگزینی سیستم ­های قدیمی- سناریو ویژگی ­های کیفی: در پایان عمر مفید، سیستم A را می توان بازنشسته کرد و عملکردهای آن را می توان در عرض دو نفر روز به یک سیستم جدید منتقل کرد، به استثنای تغییرات سخت افزاری. بهبود قابلیت/کیفیت سیستم- هدف کسب و کار: کارایی (performance)- سناریو ویژگی ­های کیفی: کاربر یک درخواست یک نقشه را از طریق اینترنت در طول عملیات عادی وارد می کند و نقشه کامل در عرض دو ثانیه برای کاربر ارسال می شود.- هدف کسب و کار: قابلیت اطمینان/در دسترس بودن- سناریو ویژگی ­های کیفی:هنگامی که یک سنسور پاسخگو نیست، سیستم حسگر معیوب را تشخیص می دهد، وضعیت آن را به در دسترس نیستتنظیم می­کند و وضعیت را در عرض 100 میلی ثانیه به اپراتور گزارش می دهد.- هدف کسب و کار: خطوط تولید- سناریو ویژگی ­های کیفی: محصول جدید تولید می شود. این محصول باید بیش از 80 درصد از دارایی های اصلی را مجدداً استفاده کند و تکمیل آن بیش از هشت نفر سال طول نمی کشد.- هدف کسب و کار: سهولت استفاده- سناریو ویژگی ­های کیفی: بدون آموزش، یک کاربر تازه کار می تواند با استفاده از ابزار ترسیم یک ترسیم ساده ایجاد کند.- هدف کسب و کار: امنیت- سناریو ویژگی ­های کیفی: هنگامی که یک کاربر نهایی سعی می کند با پیمایش مستقیم به یک صفحه وب غیرمجاز بدون ورود به سیستم، دسترسی پیدا کند، دسترسی رد می شود و تلاشش ثبت می شود.- هدف کسب و کار: ایمنی- سناریو ویژگی ­های کیفی: یک خلبان سعی می کند یک هواپیما را بدون پایین آوردن ارابه فرود فرود آورد. سیستم به خلبان هشدار می دهد و اقدامات اصلاحی انجام می شود.- هدف کسب و کار: مقیاس پذیری/توسعه پذیری- سناریو ویژگی ­های کیفی: دو سرور داده جدید را می توان در دو نفر روز به سیستم اضافه کرد، بدون اینکه سیستم از کار بیفتد.- هدف کسب و کار: عملکرد (functionality)- سناریو ویژگی ­های کیفی: اضافه کردن قابلیت هایی جدید به یک وب سایت، مانند توانایی کاربران نهایی برای محاسبه زمان­بندی استهلاک شخصی.- هدف کسب و کار: محدودیت­ های سیستم- سناریو ویژگی ­های کیفی: این سیستم با استفاده از PHP 5، MySQL 4.1 و Apache 2.0 پیاده سازی خواهد شد.- هدف کسب و کار: بین المللی شدن- سناریو ویژگی ­های کیفی: با این فرض که فایل‌های رشته متنی قبلا ترجمه شده‌اند، سیستم با یک نفر روز تلاش برای توسعه به یک زبان جدید منتقل می‌شود. بهبود موقعیت بازار- هدف کسب و کار: گسترش یا حفظ سهم بازار- سناریو ویژگی ­های کیفی: سیستم A را می توان در عرض یک نفر هفته به پلتفرم B منتقل کرد.- هدف کسب و کار: حفظ یا بهبود اعتبار- سناریو ویژگی ­های کیفی: سیستم A بیست درصد زمان پاسخ بهتری را در مورد کاربری X با 10٪ خطاهای کمتر نسبت به رقبای خود ارائه می دهد.- هدف کسب و کار: ورود بازارهای جدید- سناریو ویژگی ­های کیفی: سیستم A سازمان B را قادر می سازد تا محصولات را در بازار جدید C بفروشد.- هدف کسب و کار: کاهش ورود به بازار- سناریو ویژگی ­های کیفی: سیستم A ظرف دو سال تکمیل خواهد شد. پشتیبانی از فرآیندهای کسب­وکار بهبود یافته- هدف کسب و کار: توسعه­ ی توزیع شده- سناریو ویژگی ­های کیفی: سیستم A به صورت مشترک توسط تیم‌هایی در مکان‌های B، C و D در مدت 20 نفر سال و ظرف شش ماه توسعه می‌یابد.- هدف کسب و کار: حفظ مشاغل نیروی کار در سیستم های قدیمی- سناریو ویژگی ­های کیفی: سیستم A توسط تیم های موجود در مکان های A و B برای دو سال آینده نگهداری می شود. بهبود اعتماد و درک سیستم- هدف کسب و کار: حفظ یا بهبود اعتبار- سناریو ویژگی ­های کیفی: سیستم A بیست درصد زمان پاسخ بهتری را در مورد کاربری X با 10٪ خطاهای کمتر نسبت به رقبای خود ارائه می دهد. 6. نتیجه گیریارزیابی معماری نرم افزار یکی از مهم ترین شیوه های توسعه یک نرم افزار با کیفیت می باشد. ارزیابی معماری تلاش و هزینه‌های توسعه نرم‌افزار را کاهش می‌دهد و کیفیت نرم‌افزار را با در نظر گرفتن نیازمندی­ های کیفی و شناسایی خطرات احتمالی افزایش می‌دهد و همچنین این اطمینان را به توسعه دهندگان می­دهد که معماری انتخابی آنها هم نیازمندی­های عملکردی و هم غیرعملکردی و کیفی را برآورده می کند. این مقاله مروری بر روش‌ها و تکنیک‌های مختلف ارزیابی معماری نرم‌افزار ارائه نمود و بر خلاصه‌ای از اهمیت روش‌های مختلف ارزیابی زودهنگام و دیرهنگام، شباهت‌ها و تفاوت‌های بین آنها، کاربرد، نقاط قوت و ضعف آنها تمرکز داشت. همچنین با توجه به اهمیت شناخت اهداف کسب و کار و نقش و ماموریت آنها در تحلیل، توجیه و ارزیابی معماری نرم افزار در سازمان ها، در بخش پایانی این تحقیق به طبقه بندی این اهداف پرداختیم و برای هر طبقه بندی سناریویی مبتنی بر ویژگی های کیفی ارائه نمودیم. همچنین ذکر کردیم که این طبقه بندی ها به دو شیوه به ارزیابی معماری کمک می کنند: 1. سازمان ها را قادر می سازد تا اهداف کسب­ وکار خود را متمرکزتر و کامل تر ارائه دهند. 2. ساده سازی تولید درخت سودمندی از طریق درج اهداف کسب­ وکار در سطوح بالاتر درخت و ارائه سناریوهای نمونه برای هر هدف کسب­ وکار منابع:[1] L. Bass, J. Bergey, P. Clements, P. Merson, I. Ozkaya, and R. Sangwan, "A Comparison of Requirements Specification Methods from a Software Architecture Perspective," SEI CMU, Pittsburgh, Technical Report CMU/SEI-2006-TR-013, 2006.[2] R. Kazman and L. Bass, "Categorizing Business Goals for Software Architectures", 2005.[3] A. Patidar, U. Suman, A Survey on Software Architecture Evaluation Methods, 49(2015) , pp. 967–972. (Accessed July 5, 2016) http://ieeexplore.ieee.org/xpls/ abs_all.jsp?arnumber=7100391.[4] S Kadri, S Aouag, D Hedjazi, , "MS-QuAAF: A generic evaluation framework for monitoring software architecture quality", Information and Software Technology, 2021 – Elsevier.[5] Kilova K, Lazarova V, Kitova T, Bakova D, Kirkova-Bogdanova A. Modern Models and Approaches for Design of Architecture of a Software Application for Monitoring and Quality Assessment in Higher Education. CBU International Conference Proceedings: Innovations in Science and Education. 2017, vol.5.[6] Shanmugapriya, P., and R. M. Suresh. "Software architecture evaluation methods-a survey." International Journal of Computer Applications 49.16 (2012).[7] Kazman, Rick, and Len Bass. Categorizing business goals for software architectures. CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST, 2005.[8] Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003 (ISBN 0-321-15495-9).(این مطلب، بخشی از تمرین های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است) نیوشا شفیعی نیوشا شفیعی Wed, 09 Feb 2022 23:54:46 +0330 https://virgool.io/@m_50577917/%D9%85%D9%82%D8%AF%D9%85%D9%87-%D8%A7%DB%8C-%D8%A8%D8%B1-log-management-tools-such-as-elk-zpapkgvxuipq منظور از Log Management چیست؟مفهوم Log management عبارت است از جمع‌آوری، ذخیره، پردازش، ترکیب و تجزیه و تحلیل داده‌ها از برنامه‌ها و اپلیکیشن های متفاوت به منظور بهینه‌سازی عملکرد سیستم، شناسایی مسائل فنی، مدیریت بهتر منابع، تقویت امنیت و بهبود انطباق.لاگ (Log) یک فایل کامپیوتری است که فعالیت های درون سیستم عامل یا برنامه های نرم افزاری را ثبت می کند. یک فایل لاگ به صورت خودکار هر گونه اطلاعات طراحی شده توسط مدیران سیستم را مستند می کند، از جمله: پیام ها، گزارش های خطا، درخواست ها و انتقال فایل. چنین فعالیتی همچنین دارای timestamped است که به متخصصان فناوری اطلاعات و توسعه دهندگان کمک می کند تا بفهمند چه اتفاقی افتاده و چه زمانی اتفاق افتاده است.مفهوم Log management معمولاً به دسته بندی های اصلی زیر تقسیم می‌شود:1. مجموعه (Collection)ابزاری برای Log management که داده ها را از سیستم عامل، برنامه ها، سرورها، کاربران، نقاط پایانی یا هر منبع مرتبط دیگری در سازمان جمع آوری می کند.2. نظارت (Monitoring)ابزارهای نظارت بر Log management، رویدادها، فعالیت ها و همچنین زمان وقوع آنها را ردیابی می کنند.3. تجزیه و تحلیل (analysis)ابزارهای تجزیه و تحلیل Log مجموعه گزارش‌هایی را از سرور Log مرور می‌کند تا فعالانه باگ‌ها، تهدیدات امنیتی یا سایر مسائل را شناسایی کند.4. نگهداری (retention)ابزاری که تعیین می‌کند داده‌های Log چه مدت باید در فایل Log نگهداری شوند.5. شاخص گذاری یا جست و جو (Indexing or search)ابزاری برای Log management که به سازمان های فناوری اطلاعات کمک می‌کند تا داده‌ها را در همه ی Log ها فیلتر، مرتب ‌سازی، تجزیه و تحلیل یا جستجو کنند.6. گزارش نویسی (reporting)ابزار پیشرفته‌ای که گزارش‌دهی از Log های حسابرسی را در ارتباط با عملکرد عملیاتی، تخصیص منابع، امنیت یا انطباق با مقررات، خودکار می‌کند.سیستم های Log management چگونه می توانند کمک کننده باشند؟سیستم Log management (LMS) راه حلی نرم افزاری است که داده های Log و Log های رویدادها را از منابع مختلف در یک مکان متمرکز جمع آوری، مرتب و ذخیره سازی می کند. سیستم‌های Log management به تیم‌ های فناوری اطلاعات، متخصصان DevOps و SecOps اجازه می‌دهند تا یک نقطه واحد را ایجاد کنند تا از آنجا به تمام داده‌های مربوط به شبکه و برنامه دسترسی داشته باشند. به طور معمول، این فایل Log کاملا ایندکس شده و قابل جستجو است، به این معنی که تیم فناوری اطلاعات می تواند به راحتی به داده هایی که برای تصمیم گیری در مورد سلامت شبکه، تخصیص منابع یا امنیت نیاز دارند دسترسی داشته باشند. ابزارهای Log management به منظور کمک به سازمان در جهت مدیریت حجم بالای داده های Log تولید شده در سراسر سازمان به کار می روند. این ابزارها به تعیین موارد زیر کمک می کنند:· چه داده ها و اطلاعاتی باید Log شوند.· قالبی که باید در آن Log شوند.· دوره زمانی که داده های Log باید ذخیره شوند.· داده ها زمانی که دیگر مورد نیاز نیستند چگونه باید دور ریخته شوند یا از بین بروند.اهمیت Log managementیک سیستم و استراتژی Log management کارآمد، فهم real-time بودن را در مورد سلامت و عملیات سیستم امکان پذیر می کند. یک راه حل موثر Log management موارد زیر را به سازمان ها ارائه می دهد:· ذخیره سازی یکپارچه داده از طریق تجمیع متمرکز Log ها· بهبود امنیت از طریق کاهش سطح حمله، نظارت در زمان واقعی و بهبود زمان تشخیص و پاسخ· بهبود قابلیت مشاهده و دید در سراسر سازمان از طریق یک Log رویداد مشترک· افزایش تجربه مشتری از طریق تجزیه و تحلیل داده های Log و مدل سازی پیش بینی· قابلیت‌ های عیب‌یابی سریع ‌تر و دقیق‌تر از طریق تجزیه و تحلیل شبکه پیشرفتهمنظور از Log management متمرکز چیست؟منظور از Log management عمل جمع آوری تمام داده های Log در یک مکان واحد و قالب مشترک است. از آنجایی که داده ها از منابع مختلفی از جمله سیستم عامل، برنامه های کاربردی، سرورها و هاست ها به دست می آیند، قبل از اینکه سازمان بتواند مفهوم معناداری ایجاد کند، همه ورودی ها باید تلفیق و استاندارد شوند. متمرکز بودن Log management ها فرآیند تجزیه و تحلیل را ساده می کند و سرعت استفاده از داده ها را در سراسر کسب و کار افزایش می دهد.مفهوم Log management در مقابل SIEMهم اطلاعات امنیتی و مدیریت رویداد (SIEM) و هم نرم افزار Log management، جهت بهبود امنیت (با کاهش سطح حمله، شناسایی تهدیدات و بهبود زمان پاسخ در صورت بروز یک حادثه امنیتی)، از فایل Log یا event log استفاده می کنند. با این حال، تفاوت اصلی بین این دو مفهوم در این است که سیستم SIEM همراه با مفهوم امنیت به عنوان عملکرد اصلی آن ساخته شده است، در حالی که سیستم های Log management می توانند به طور گسترده تر برای مدیریت منابع، عیب یابی قطعی شبکه یا برنامه ها و حفظ انطباق استفاده گردند.چهار چالش های رایج در Log managementانفجار داده‌ها، که ناشی از تکثیر دستگاه‌های متصل، و همچنین حرکت به سمت ابر است، برای بسیاری از سازمان‌ها پیچیدگی Log management را افزایش داده است. یک راه حل مدرن و موثر Log management باید چالش های اصلی زیر را برطرف کند:· استانداردسازی:از آنجایی که Log management داده‌ها را از برنامه‌ ها، سیستم‌ ها، ابزارها و میزبان ‌های مختلف استخراج می‌کند، همه ی داده‌ها باید در یک سیستم واحد که از قالب یکسانی پیروی می‌کنند، تلفیق شوند. این فایلLog به متخصصان فناوری اطلاعات و امنیت اطلاعات کمک می ‌کند تا به‌طور مؤثر داده‌های Log را تجزیه و تحلیل کنند و مفاهیمی را تولید کنند که برای انجام خدمات حیاتی کسب و کار، به کار می روند.· حجم:داده ها با سرعت باورنکردنی تولید می شوند. برای بسیاری از سازمان‌ها، حجم داده‌هایی که به‌طور مداوم توسط برنامه‌ها و سیستم‌ها تولید می‌شوند، نیازمند تلاش زیادی برای جمع‌آوری، قالب‌بندی، تجزیه و تحلیل و ذخیره‌سازی مؤثر می باشند. یک سیستم Log management باید به منظور مدیریت حجم بسیار زیادی از داده ها و ارائه ی مفهومی به موقع طراحی شود.· تاخیر:شاخص گذاری در فایل log می تواند یک فعالیت محاسباتی بسیار پرهزینه باشد که باعث تاخیر داده هایی که وارد سیستم می شوند و سپس نتایج جستجو و visualization های گنجانده شده، گردد.· بار مسئولیتی بالای ITمساله ی Log management هنگامی که به صورت دستی انجام می شود، فوق العاده وقت گیر و پر هزینه است. ابزارهای مربوط به Log management به خودکارسازی برخی از این فعالیت ‌ها و همچنین کاهش فشار مسئولیتی بر روی متخصصان فناوری اطلاعات کمک می‌کنند.چهار مورد از به روش (Best Practices)های Log managementبا توجه به حجم انبوه داده هایی که در دنیای دیجیتال امروز ایجاد می شوند، برای متخصصان فناوری اطلاعات مدیریت دستی و تجزیه و تحلیل Log ها در یک محیط فناوری گسترده غیرممکن شده است. به این ترتیب، آنها به یک سیستم Log management پیشرفته و ابزارهایی نیاز دارند تا جنبه‌های کلیدی فرآیندهای جمع‌آوری، فرمت بندی و تجزیه و تحلیل داده‌ها را خودکارسازی کند. در ادامه به برخی از ملاحظات کلیدی که سازمان‌های فناوری اطلاعات باید هنگام سرمایه‌گذاری در یک سیستم Log management در نظر بگیرند، اشاره شده است:1. اولویت بندی ابزارهای خودکارسازی برای کاهش بار IT: مدیریت Log فرآیندی زمان بر است که می تواند منابع را از سازمان فناوری اطلاعات استخراج کند. بسیاری از وظایف تکراری مربوط به جمع آوری و تجزیه و تحلیل داده ها را می توان با استفاده از ابزارهای پیشرفته خودکارسازی کرد. سازمان‌ها باید قابلیت‌های خودکارسازی را در هر ابزار Log management جدید اولویت ‌بندی کنند و به‌روزرسانی راه‌حل‌های قدیمی را برای کاهش تلاش های دستی در طول این فرآیند در نظر بگیرند.2. استفاده از یک سیستم متمرکز برای دسترسی بهتر و بهبود امنیت: مدیریت متمرکز Log تنها دسترسی به داده ها را بهبود نمی بخشد، بلکه به طور چشمگیری قابلیت های امنیتی سازمان را نیز تقویت می کند. ذخیره و اتصال داده ها در یک مکان متمرکز به سازمان ها کمک می کند تا سریعتر آنومالی ها را شناسایی کرده و به آنها پاسخ دهند. به این ترتیب، یک سیستم مدیریت لاگ متمرکز می تواند به کاهش زمان شکست یا پنجره بحرانی که در آن هکرها می توانند به صورت جانبی در سایر قسمت های سیستم حرکت کنند، کمک کند.3. ایجاد یک خط مشی نظارت و نگهداری برای مدیریت بهتر حجم داده: با توجه به حجم داده‌های ایجاد شده، سازمان‌ها باید تشخیص دهند که چه اطلاعاتی را جمع‌آوری و چه مدت از آنها نگهداری کنند. سازمان‌ها باید آنالیزی در سطح سازمان انجام دهند تا تعیین کنند چه ورودی‌هایی برای هر عملکرد حیاتی می باشند.4. استفاده از ابر برای مقیاس پذیری و انعطاف پذیری بیشتر: با توجه به چشم انداز داده های در حال توسعه، سازمان ها باید سرمایه گذاری بر روی راه حل مدرن و مبتنی بر ابر را برای سیستم مدیریت Log خود در نظر بگیرند. استفاده از ابر انعطاف‌پذیری و مقیاس‌پذیری را افزایش می‌دهد و به راحتی به سازمان‌ها اجازه می‌دهد تا ظرفیت پردازش و ذخیره‌سازی خود را بر اساس نیازهای متغیر گسترش یا کاهش دهند.معرفی برخی از ابزار متن باز به منظور مدیریت لاگ:· ابزار Elasticsearch، Logstash و Kibana (ELK stack or Elastic Stack)پشته ELK (ELK stack) شامل اکثر ابزارهای مورد نیاز برای راهکار log management است که به برخی از آنها در زیر اشاره شده است:· ارسال کننده ی log مانند Logstash و Filebeat· ابزار Elasticsearch به عنوان یک موتور جستجوی مقیاس پذیر· ابزار Kibana به عنوان رابط کاربری برای جستجوی log ها یا ایجاد visualizations· ابزار Elasticsearch هر فیلد را به طور پیش فرض شاخص گذاری می کند و به جست و جوها سرعت می بخشد.· ایجاد Real-time visualizations از طریق API و Kibana· تجزیه و تحلیل داده ها و غنی سازی آنها پیش از شاخص گذاری· دارای موتور جستجوی مقیاس پذیر به منظور ذخیره سازی log ها· ارسال کننده ی بالغ log های مربوطه· دارای رابط کاربری وب و visualizations در کیبانا· در نسخه منبع باز ELK Stack برخی از ویژگی ها مانند کنترل دسترسی مبتنی بر نقش و هشدار را از دست می دهد. می‌توان این ویژگی‌ها را از طریق « Elastic Stack Features» یا جایگزین‌های آن و یا Open Distro visa برای Elasticsearch دریافت کرد.پشته ELK (ELK stack) جهت متمرکز کردن log ها ابزار بسیار محبوبی است و آموزش های زیادی در مورد نحوه استفاده از آن در سراسر وب وجود دارد. همچنین اکوسیستم وسیعی از ابزارها وجود دارد که می‌توان از آنها در بالای تنظیمات اولیه خود استفاده کرد تا با هشدار، کنترل دسترسی مبتنی بر نقش و موارد دیگر، آن را تقویت نمود.ابزار ELK stack رایگان و متن باز است و برخی از شرکت ها اشکالی از میزبانی ELK را ارائه می دهند. همچنین ابزاری به نام Elastic Cloud وجود دارد که شکل نابی از ELK در فضای ابری است، که مدیریت آن بیشتر با خودتان است.· ابزار Graylogمانند پشته ELK، Graylog نیز یک ابزار مدیریت لاگ منبع باز است که از Elasticsearch برای ذخیره سازی خود استفاده می کند. برخلاف پشته ELK که از مولفه های مجزا (Elasticsearch، Logstash، Kibana) ساخته شده است، Graylog به صورت یک بسته کامل ساخته شده است که می تواند همه کارها را انجام دهد.ویژگی های کلیدی ابزار Graylog:· شامل یک بسته ی کامل با تمام ملزومات پردازش لاگ شامل جمع آوری، تجزیه، بافر، فهرست، جستجو و آنالیز است.· همچنین شامل ویژگی‌های اضافی که توسط پشته ی منبع باز ELK نمی شود، مانند کنترل دسترسی مبتنی بر نقش و هشدارها، نیز می باشد.· این ابزار منبع باز و رایگان است، اگرچه نسخه سازمانی آن نیز وجود دارد.· متناسب با نیازهای اکثر موارد کاربرد مدیریت لاگ متمرکز در یک بسته می باشد.· به راحتی هم فضای ذخیره سازی (Elasticsearch) و هم خط لوله ingestion را مقیاس بندی می کند.· در مقایسه با Kibana ELK، قابلیت های Visualization محدودی دارد.· از آنجایی که نمی‌توان از کل اکوسیستم ELK به دلیل نبود دسترسی مستقیم به API Elasticsearch استفاده کرد، Graylog API جایگزین خوبی خواهد بود.معرفی یک شرکت ایرانی ارائه دهنده ی محصولات مربوط به مدیریت لاگ:شرکت دانش بنیان آتین آتیه اندیش، مستقر در پارک علم و فناوری دانشگاه تهران، در سال 1396 فعالیت خود را به طور تخصصی درحوزه ارائه خدمات احراز هویت آغاز کرد. این شرکت با بررسی نمونه های مشابه خارجی و بر اساس نیازهای داخلی کشور درحوزه احراز هویت، اقدام به توسعه سامانه مدیریت هویت و دسترسی نموده است. تیم فنی آتین از فارغ التحصیلان دانشگاه های برتر کشور در حوزه نرم افزار و امنیت اطلاعات و با پشتوانه سابقه چندین ساله در حوزه احراز هویت و کنترل دسترسی تشکیل شده است.در واقع آتین یک سرویس مدیریت هویت و دسترسی است که با تمرکز ویژه بر رضایت مشتری بر بستر زیرساخت ابری توسعه یافته است. با استفاده از سامانه آتین مراکز و سرویس دهنده های فناوری اطلاعات به راحتی می توانند دسترسی دستگاه های مختلف داخل سازمان یا اشخاصی از جمله کارمندان، شرکای تجاری و مشتریان را به تمامی سامانه ها به صورت متمرکز مدیریت نمایند. آتین تضمین می کند که دسترسی همه کاربران بر اساس سیاست واحد صورت گیرد و تمامی افراد و سرویس ها، احراز هویت، مجوزدهی و نظارت شوند. در زیر به چند نمونه از محصولات این شرکت اشاره شده است: · احراز هویت و ورود یکپارچه مرکزی· احراز هویت چند عاملی· مدیریت دسترسی به API ها· مدیریت لاگ و ممیزیمنابع:https://www.humio.com/glossary/log-management/https://sematext.com/blog/best-log-management-tools/https://authin.ir/ نیوشا شفیعی نیوشا شفیعی Fri, 24 Dec 2021 22:56:57 +0330 https://virgool.io/@m_50577917/%D9%85%D9%82%D8%AF%D9%85%D9%87-%D8%A7%DB%8C-%D8%A8%D8%B1-brms-hmm0garqq9yh سیستم BRMS به فرآیند و تعریف رسمی عملکرد قوانین کسب و کار، اجرا، مدیریت و به کارگیری خودکار آنها اشاره دارد. تعاریف BRMS :سیستم نرم افزاری BRMS یا سیستم مدیریت قوانین کسب و کار سیستمی نرم افزاری است که برای تعریف، استقرار، اجرا، نظارت و حفظ تنوع و پیچیدگی منطق تصمیم گیری که توسط سیستم های عملیاتی در یک سازمان یا شرکت استفاده می شود، به کار می رود. این منطق که به آن قوانین کسب و کار نیز گفته می شود، شامل سیاست ها، الزامات و عبارات مشروط است که برای تعیین اقدامات تاکتیکی که در برنامه ها و سیستم ها انجام می شود، استفاده می گردد.سیستم BRMS به فرآیند و تعریف رسمی عملکرد قوانین کسب و کار، اجرا، مدیریت و به کارگیری خودکار آنها اشاره دارد. در واقع سیستم مدیریت قوانین کسب و کار (BRMS) یک بستر فناوری است که از طریق آن این فرآیند انجام می شود. یک BRMS ابزارهایی را برای تسهیل کل چرخه حیات قوانین تجاری، از تعریف و ذخیره قوانین به عنوان منطق رسمی کسب و کار گرفته تا ممیزی قوانین موجود و مدیریت منطق تصمیم گیری فراگیر که اتوماسیون را در کل اکوسیستم فناوری سازمانی هدایت می کند، ارائه می دهد.اجزای BRMS:· یک مخزن که به منطق تصمیم اجازه ی استفاده از کد برنامه اصلی را می دهد.· ابزارهایی که به توسعه دهندگان فنی و کارشناسان کسب و کار اجازه می دهند تا منطق تصمیم را تعریف و مدیریت کنند.· یک محیط Run Time که به برنامه ‌ها اجازه می ‌دهد تا منطق تصمیم‌ گیری مدیریت شده در BRMS را فراخوانی کرده و آن را با استفاده از موتور قوانین کسب و کار اجرا نمایند.مزایای سیستم مدیریت قوانین کسب و کار (BRMS):با یک BRMS، قوانین در یک مخزن مرکزی جدا از کدهای برنامه ذخیره می شوند. مخزن یک منبع واحد از واقعیت ها را برای قوانین کسب و کار ایجاد می کند تا برای همه ی برنامه های کاربردی سراسر سازمان قابل دسترسی باشد. در نتیجه، قوانین کسب و کار مقیاس پذیر هستند و تصمیمات کسب و کار همواره به روز، سازگار و قابل اعتماد می باشند.اتوماسیون کارآمدBRMS ها:اتوماسیون کارآمد گردش کار برای سازمان ها ضروری هستند. چندین گردش کار را می توان با استفاده از یک مخزن مجزای منطق تصمیم گیری در سطح شرکت خودکار سازی کرد. به این ترتیب، IT مجبور نیست برای هر برنامه برنامه ریزی منطقی تصمیم گیری متفاوتی را در نظر بگیرد.نتایج منسجم تر:وقتی تصمیمات کسب و کار بر اساس سیستمی مجموعه ای از قوانین کسب و کار در سطح سازمانی خودکار سازی گردند، همه ی تصمیمات بر اساس منطقی یکسان گرفته می شوند. این امر منجر به نتایج منسجم‌تری می گردد، زیرا تصمیمات کسب و کار دیگر تحت تأثیر اختیارات انسانی قرار نمی‌گیرد مگر در موارد ضروری.کاهش پیچیدگی:هنگام مواجهه با تصمیمات کسب و کار، کارگران انسانی مجبور نیستند چندین فاکتور را بسنجند یا مطمئن شوند که از قوانین پیروی می کنند. در عوض، برنامه ها می توانند با BRMS بررسی کنند، که آیا از پایگاه داده ی قوانین کسب و کار برای تعیین نتیجه ی مناسب استفاده می کنند یا نه. تصمیم‌گیری ‌ها سریع‌ تر اتفاق می‌افتند و کارمندان وقت بیشتری پیدا می کنند تا کارهایی با ارزش بیشتری را انجام دهند.کاهش وابستگی به فناوری اطلاعات:ابزارهای بدون کد در BRMS به تحلیلگران کسب و کار و سایر کارکنان غیر فنی اجازه می دهد تا قوانین کسب و کار را با استفاده از واژگان تجاری خود ایجاد نمایند. این بدان معناست که تیم ‌ها می ‌توانند در صورت نیاز قوانینی را ایجاد و تنظیم کنند و نیازی به دخالت فناوری اطلاعات در هر به ‌روز رسانی نداشته باشند.تصمیمات پاسخگوتر:قوانین را می توان به راحتی در مخزنBRMS به روز کرد زیرا مدیریت قوانین نیازی به تغییر کد برنامه های موجود ندارد. بنابراین، قوانین را می توان به راحتی در پاسخ به مقررات جدید، تحولات بازار، تقاضای مشتری و سایر عوامل تغییر داد.انطباق خودکار:خط‌مشی‌ ها و مقررات مربوطه را می‌توان در قوانین کسب‌ و کار گنجاند و اطمینان حاصل کرد که تصمیم ‌گیرندگان خودکار از همه ی قوانین و دستورالعمل‌ های مرتبط پیروی می ‌کنند. با این کار همچنین یک مسیر حسابرسی ایجاد می شود، زیرا قوانین منتهی به هر تصمیم کسب و کار خاص همیشه قابل بررسی خواهند بود.قوانین کسب و کاری که به طور کلی بهتر هستند:به لطف توانایی اجرای برنامه های شبیه ‌ساز پیش‌ بینی قوانین پیش از اجرای آن ‌ها، تیم ‌ها می‌ توانند اطمینان حاصل کنند که قوانین کسب و کاری که ایجاد می‌کنند، نتایجی را که می‌خواهند، قبل از اجرا در دست دارند.ابزارهای BRMS عبارتند از:ابزار Red Hat® Decision Manager:پلتفرمی برای توسعه میکروسرویس ها و برنامه های کاربردی است که تصمیمات تجاری را خودکار سازی می کند. Decision Manager شامل مدیریت قوانین کسب و کار، پردازش رویدادهای پیچیده و فناوری ‌های بهینه‌سازی منابع است. سازمان ‌ها می‌ توانند منطق تصمیم‌گیری پیچیده را در برنامه ‌های کاربردی کسب و کار بگنجانند و با تغییر شرایط بازار به سرعت قوانین اساسی کسب‌وکار را به‌روزرسانی کنند.ابزار SAS Business Rules Manager:با استفاده از این ابزار می توان خطر تصمیم گیری عملیاتی تدریجی و موقتی را با استفاده از قوانین کسب و کار که به صورت تحلیلی اتخاذ شده اند برای خودکارسازی و بهبود تصمیمات در سراسر سازمان خود حذف کرد. SAS Business Rules Manager یک مخزن قوانین مرکزی، یک پلت فرم مشترک برای مدیریت توسعه و استقرار قوانین، و اتوماسیون گردش کار در سرتاسر سازمان ارائه می کند.· راه حل Drools:ابزار Drools یک راه حل سیستم مدیریت قوانین کسب و کار (BRMS) است که به نوعی موتور قواعد اصلی کسب و کار (BRE)، نوشتن برنامه وب، مدیریت قوانین (Drools Workbench) و یک پلاگین Eclipse IDE برای توسعه ی هسته ارائه می کند. Drools Fusion ویژگی های پیچیده پردازش رویداد را ارائه می دهد.· ابزار rulerz - پیاده سازی قدرتمند الگوی Specification در PHPایده اصلی Specification تفکیک عبارت مربوط به نحوه ی تطبیق یک کاندیدا از شی کاندید دیگر است که با آن مطابقت دارد. قوانین کسب و کار را می توان با استفاده از یک زبان اختصاصی که بسیار نزدیک به SQL است به صورت متنی نوشت. در این صورت به آنها به عنوان قوانین اشاره می شود و یا می توان آنها را در کلاس های مجزا کپسوله سازی کرد و تحت عنوان Specification از آنها یاد کرد.· ابزار NValid - یک کتابخانه اعتبارسنجی سلیس برای منطق کسب و کار NET.ابزار NValid یک کتابخانه اعتبارسنجی #C سبک وزن برای NET. است و به راحتی با منطق اعتبارسنجی سفارشی پروژه ی شما گسترش می یابد!· ابزار CslaGenForkتولید کننده ی کد O/RM برای CSLA.NET 4.3 که رویه های ذخیره شده، لایه ی کسب و کار و کد لایه دسترسی به داده را برای فرم های ویندوز، ASP.NET، WPF و Silverlight ایجاد می کند.· ابزار Jetfire - Workflow DSLابزار Jetfire (jetfire.ca) یک اکوسیستم منبع باز و شی گرا است که توسعه ی قوانین کسب و کار (Business Rule Engine)، برنامه های مداوم و گردش کار را بسیار آسان می کند. زبان پویای Jetfire ، سی شارپ را با قوانین، نقش‌ها، جریان داده، تداوم، نسخه‌سازی، امنیت... گسترش می‌دهد.· ابزار CSLA .NET Contribمشارکت‌های عمومی پیرامون چارچوب Rockford Lhotka's CSLA .NET شامل ابزارها، فریمورک ‌های الحاقی، ابزارها و نمونه ‌ها می باشد.· ابزار Rules Engineابزار Rules Engine یک پروژه #C است که به توسعه دهندگان کمک می کند تا قوانین کسب و کار را بر روی اشیاء دامنه بدون اتصال شی دامنه با قانون کسب و کار تعریف کنند. موتور قواعد از اعتبارسنجی cross-field و اعتبار سنجی شرطی پشتیبانی می کند. همچنین قوانین مبتنی بر رابط هستند.شرکت های ایرانی که ازسامانه‌های BRMS استفاده می‌کنند عبارتند از سامانه پردازشگر اسناد پزشکی، سامانه درمان بیمه تکمیلی (رسا) از این رویه استفاده می‌کنند و جز زیر گروه آوای اطلاعات آریا هستند که این سیستم زیرمجموعه ای از شرکت داتیس می‌باشد.· ابزار rules-runner - Business Rules Engine for Nodeیک موتور قوانین کسب و کار JS برای گره است.· ابزار roulette- موتور قوانین مبتنی بر متن/الگویک پکیج مبتنی بر متن/الگو است که فعالیت ها را از قوانین تعریف شده در یک فایل xml فعال می کند. از این پکیج جهت فعال کردن فعالیت های کسب و کار مبتنی بر درخت تصمیم متنی استفاده می شود. از ساختارهای کنترل قدرتمند در متن/قالب و تجزیه xml از encoding/xml برای ساخت درخت از یک فایل roulette xml استفاده می کند.-ابزار Plastic- این پروژه شامل مواردی مانند دامنه، قوانین برنامه و قوانین یا منطق کسب و کار در برنامه است.این پروژه شامل مواردی مانند Domain، Application Rules، Business Rules یا Business Logic در برنامه می‌شود. برای این منظور از الگوی Command استفاده می شود. تمامی اپلیکیشن ها مانند اپلیکیشن وب، CLI، GUI می توانند از این پروژه استفاده کنند. این می تواند بخشی از لایه Usecase، لایه سرویس دامنه یا CQRS باشد.معرفي برخي از شركت هايي ايراني كه از سامانه هاي BRMS استفاده مي كنند:از جمله شرکت های ایرانی که ازسامانه‌های BRMS استفاده می‌کنند مي توان به سامانه پردازشگر اسناد پزشکی، سامانه درمان بیمه تکمیلی (رسا) كه از این رویه استفاده می‌کنند و جز زیر گروه آوای اطلاعات آریا هستند و زیر مجموعه ای از شرکت داتیس می‌ باشند، اشاره كرد. برخي از نمونه هاي تجاري BRMS :راه حل Actico Platformراه حل FICO Blaze Advisorراه حل IBM Operational Decision Managerراه حل SAP BRFplus/Decision Service Managerراه حل Sparkling Logic SMARTSنمونه هايي از BRMS های Open Source:راه حل JBoss Droolsراه حل Open Rulesراه حل Red Hat JBoss BRMSجمع بندي:سیستم مدیریت قوانین کسب و کار یا BRMS مجموعه کاملی از اجزای نرم افزاری برای ایجاد، تست، مدیریت، استقرار و نگهداری مداوم قوانین کسب و کار در یک محیط تولیدي و عملي است. BRMS ها مزایای زیادی نسبت به کدهای سنتی دارند. یک BRMS به عناصر زیر نیاز دارد: مخزن قوانین کلاس هاي سازمانی با مسیرهای حسابرسی و نسخه سازیابزارهای طراحی که به کاربران فنی اجازه می دهد قوانین كسب و كار را با بقیه محیط یکپارچه کنند.برنامه های کاربردی نگهداری قوانین قابل درك برای کاربران كسب و كارابزارهای تأیید و اعتبارسنجی برای کاربران فنی و كسب و كارابزارهای تست و شبیه سازیابزارهای استقرار که از چندین پلتفرم پشتیبانی می کنندموتور قوانین کسب و کار با کارایی بالایک BRMS به کاربران كسب و كار و تحلیلگران این توانایی را می دهد که تغییرات و به روز رسانی های معمولی را در سیستم های كسب و كار حياتي ایجاد کنند و در عین حال منابع فناوری اطلاعات را برای تمرکز بر روي پروژه هايي با ارزش افزوده ي بالاتر آزادسازي نمايند.منابع: 1.https://www.progress.com/faqs/corticon-faqs/what-is-a-business-rules-management-system 2.https://www.ibm.com/cloud/blog/business-rules-management-systems-101 3.https://www.processmaker.com/blog/what-is-a-business-rules-management-system-brms/ 4.https://www.trustradius.com/business-rules-management-brm5.https://sourceforge.net/software/business-rules-management-systems-brms/6.https://decisionmanagementsolutions.com/what-is-brms/ نیوشا شفیعی نیوشا شفیعی Fri, 24 Dec 2021 22:53:35 +0330 https://virgool.io/@m_50577917/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-bpms-business-process-management-system-wyovjjcv5ubo منظور از BPMS (Business Process Management System) چيست؟عبارت BPMS مخفف "Business Process Management Software" یا "Business Process Management System" مي باشد. BPMS ابزاری برای اجرای متدولوژی های مدیریتی جهت بهبود فرآیندهای کسب و کار سازمان از طریق شناسایی، مدل‌سازی، خودکارسازی، تحلیل و اندازه‌گیری عملکرد (performance) است. مزیت کلیدی BPMS این است که کاربران آن این فرصت را دارند که فعالانه در بهبود فرآیندهای کسب و کار از طریق ابزارهای ساده و عینی مشارکت داشته باشند. همه ی این مزایا در نتیجه ی 3 مولفه زیر ایجاد می شوند:- ابزارهای ساخت- اجرا (پلتفرم)- مانیتورینگ (کتابخانه فرآیند) فرآیندها.ابزار BPMS چگونه کار می کند؟1. تعریف و تجزیه و تحلیل فرآیندبه دنباله ای از فعالیت ها که برای دستیابی به نتیجه ای خاص اجرا می شوند، فرآیند گفته می شود. پیش از خودکارسازی گردش کار، فرآیندها نیازمند مستندات هستند. مستندسازی فرآیند مستلزم همکاری و برنامه ریزی بین ذینفعان برای تعیین کارآمدترین و مناسب ترین اقدامات جهت انجام یک وظیفه است. آنگاه جریان های فرآیند کسب و کار را می توان در یک سیستم مدیریت فرآیند کسب و کار بازآفرینی و توسط پرسنل مربوطه بازبینی کرد تا اطمینان حاصل شود که تصویر موثری از فرآیند به دست می آید.2. طراحی یا توسعه ی فرآیندبرای ساخت فرآیندها در یک سیستم (به عنوان مثال سیستم Creatio)، کاربر نیازمند ابزار "طراح فرآیند" است. ابزارهای استفاده شده توسط طراح برای مدلسازی فرآیندهای کسب و کار در قالب فلوچارت و نمودار ارائه شده اند. مجموعه قوانین و عناصری که برای مدل سازی فرآیند استفاده می شود، آن را انعطاف پذیر می سازد. مزیت غیرقابل انکار مدل سازی فرآیندهای کسب و کار شرکت در سیستم های BPM این است که این فرآیندها اگر چه به سادگی مستند نشده، اما امتحان شده اند. این امر کمک می کند که پیش از اجرای واقعی در سازمان، نقاط ضعف کشف شده اصلاح گردد.3. خودکارسازیخودکارسازی شیوه ای است که به وسیله آن یک فرآیند با کمترین مداخله انجام می شود. خودکارسازی گردش کار به کسب و کارها کمک می کند تا فرآیندهای خود را بهتر مدیریت و بهینه نمایند. ایجاد خودکارسازی شامل جمع آوری اکشن ها و وارد کردن مکانیسم های مورد نیاز برای شبیه سازی رفتار و نتیجه ی یک فرآیند است. وظایفی که به احتمال زیاد خودکارسازی می شوند شامل وظایفی هستند که به صورت مکرر تکرار می شوند و همچنین وظایف روتین و معمولی که در عملکردهای روزانه کارکنان وجود دارند و از طریق یک فرآیند خودکار سریعتر تکمیل می شوند.4. تجزیه و تحلیلابزارهای سیستم BPM سطوح متعددی از گزارش یا توانایی یکپارچه سازی با ابزارهای گزارش دهی را برای ارائه ی آنالیزهایی در ارتباط با عملکرد فرآیند، ارائه می دهند. گزارش‌ها به شاخص‌های کلیدی عملکرد (KPIها) مرتبط هستند و داده‌هایی را در مورد اثربخشی فرآیندها، اعضای تیم، تیم‌ها و غیره ارائه می ‌دهند. تجزیه و تحلیل داده ها می تواند به تعیین ناکارآمدی های عملیاتی در جهت بهبود عملیاتی و مداوم فرآیند کمک کند.یک BPMS خوب چه ویژگی هایی باید داشته باشد؟1. ویژگی Visual Process Diagramming Tool:مهم ترین چیزی که باید در مورد BPM در نظر گرفت، نمودار جریان فرآیند است. چهار دسته از شیوه های مدل‌سازی فرآیند در میان ابزارهای BPM وجود دارد:بدون ابزار مدلسازی (No Modeling Tool)– در این شیوه از کدگذاری به عنوان راهی برای پیاده سازی فرآیند استفاده می شود.داده‌های جمع‌آوری‌شده از طریق فرم‌های رابط کاربری (Data Collected Through UI Forms )– در این شیوه اطلاعات مربوط به فرآیند کسب‌وکار از طریق فرم‌ها جمع‌آوری می ‌شود.رابط بصری بر اساس فعالیت (Visual Interface Based on Activity)- این گزینه کل فرآیند از جمله رسیدگی به عدم پذیرش ها و استثناها در هر مرحله را مدیریت می کند.رابط بصری بر اساس مراحل کسب و کار (Visual Interface Based on Business Steps)- این ابزار شبیه به ابزار دسته سوم است، با این تفاوت که کاربر را با موارد کوچکی که در گوشه ها نمایش داده می شوند، اذیت نمی کند. در عوض، به کاربر این امکان را می دهد که روی مسیر اصلی فرآیند کسب و کار تمرکز کند و نرم افزار نیز به طور خودکار مسیرهای استثنا هنگام کار را کنترل می کند.2. ویژگی Drag and Drop Form Designer: فرآیند بدون داده مانند قطار بدون مسافر است. هر فرآیند کسب و کار به راهی برای حمل بار در طول فرآیند نیاز دارد. اکثر سیستم های BPM از یک فرم به عنوان راهی برای جمع آوری و ویرایش داده ها در طول فرآیند استفاده می کنند. ابزارهای مدیریت فرآیند کسب و کار باید انتخاب کنند که آیا به کاربر مبتدی خدمات می دهند یا کاربر حرفه ای. کاربران تازه کار به ابزاری ساده و واضح نیاز دارند در حالی که کاربران قدرتمند باید بتوانند یک فرم را سفارشی سازی کنند و همان چیزی را که دقیقا می‌خواهند ایجاد نمایند. اگر از form designer بسیار ساده ای استفاده کنید، احتمالا خارج شدن از چنین سیستمی کار دشواری باشد و در عین حال اگر از form designer بسیار دشواری استفاده کنید، احتمالا کاربران شما نتوانند با آن سازگار شوند.3. ویژگی Role-Based Access Control:اگر داده‌های موجود در فرم‌ها و فیلدهای شما حساس هستند، سیستم BPM ای می‌خواهید که بتواند از اطلاعات مهم‌ شما محافظت کند. دسترسی در این سیستم ها ممکن است شامل ایجاد یک فیلد قابل ویرایش، فقط خواندنی یا کاملاً پنهان باشد. بیشتر ابزارهای BPM نوعی کنترل دسترسی را در فرم ارائه می دهند. شرایط زیر را در نظر بگیرید:- محدود کردن دسترسی به بخش خاصی از فرم فقط به افراد خاص.- محدود کردن دسترسی به بخش خاصی از فرم به گروهی از افراد بدون نیاز به وارد کردن نام آنها.- نمایش فیلدهای خاص تنها بر اساس داده های نشان داده شده در فیلدهای دیگر- دستیابی به تمام موارد فوق در مراحل یا گام های مختلف فرآیند کسب و کار.در نتیجه مجموعه BPM ای که انتخاب می‌کنید باید بتواند به راحتی تمام این شرایط را مدیریت نماید.4. ویژگی Mobile Support:اگر سیستم BPM مورد ارزیابی شما حداقل از پلتفرم های اندروید و iOS پشتیبانی نمی‌کند، باید فوراً آن را ترک کنید. فرآیندهای کسب و کار روز به روز موبایل محورتر می‌شوند زیرا نشستن پشت میز برای دسترسی به فرآیندها از حوصله ی کاربران جدید خارج است. در نتیجه تلاش کنید که از یک سیستم BPM ابری استفاده کنید که عملکردهای کاملی برای کاربران تلفن همراه ارائه می کنند و از آنها پشتیبانی می نمایند.5. ویژگی های قدرتمند مدیریتی (Powerful Administrator Features):حتی بهترین نرم‌افزارهای BPM نیز به دلیل برخی اقدامات عجیب و غریب کاربران، گاهی اوقات گیر می افتند. در نتیجه این نرم افزارها باید راهی برای مدیریت و ویرایش فرآیند داشته باشند تا هر بار نیازمند کمک گرفتن از یک مشاور گران قیمت نباشند. این نرم افزارها باید بتوانند وظایف مجزا یا انبوه را مجدداً تخصیص دهند، برخی آیتم ها را حذف کنند و یا به حالت کامل منتقل نمایند و همچنین فرم‌ها در صورت نیاز فرآیند کسب‌وکار را ویرایش کنند.6. ویژگی Single Sign-On (SSO):اگر عضو یک شرکت در سطح سازمانی هستید، single sign-on ممکن است یک ویژگی اجباری برای نرم افزار های مبتنی بر سیاست های IT سازمان شما باشد. SSO به کاربر این امکان را می دهد که با مجموعه ای از اعتبارنامه ها از طریق پلت فرم های مختلف نرم افزاری مستقل، وارد سیستم شوند. این امر به تیم‌های IT کمک می‌کند تا قابلیت دسترسی داشته باشند و بتوانند فعالیت‌ها را پیگیری کنند.7. ویژگی یکپارچه سازی با سیستم های نرم افزاری موجود:تعداد اندکی از شرکت ها که نمی توانند با سایر سیستم های نرم افزاری اصلی ارتباط برقرار کنند، از راه حل BPM استفاده می کنند. بدون توانایی یکپارچه سازی، تعداد بسیاری انتقال دستی داده باید انجام دهید که به طور موثر فایده ی خودکارسازی را از بین می برد. بدون وجود ابزار یکپارچگی قدرتمند، ابزارهای مدیریت فرآیند کسب و کار یک شکست کامل تلقی می شوند. این یکپارچگی ها باید شامل پشتیبانی دقیق API، webhooks، REST API و ... باشند.8. ویژگی گزارش ها و تحلیل هابدون ویژگی گزارش گیری قوی، یک سیستم BPM فقط یک ابزار گردش کار خواهد بود. با این حال، بسیاری از ابزارهای BPM حالت یا معیارهای فرآیند ready-to-use را ارائه نمی دهند. همچنین گزارش روی داده های فرم باید قدرتمند و قابل سفارشی سازی باشد. باید بتوانید گزارش هایی تولید کنید که به شما موارد زیر را اطلاع دهد:- میانگین زمانی که برای تکمیل مراحل مجزا و همچنین کل آیتم ها طول می‌کشد.- یک اسنپ شات از همه آیتم های open- هر چند وقت یکبار یک آیتم رد یا تغییر مسیر داده می شود.گزارش ‌ها باید بیشتر از فایل‌های CSV صادر شده باشند.9. عملکرد نرم افزار برای پایگاه بزرگی از کاربران (Performance for Large User Bases):ما در دوره‌ای زندگی می کنیم که یک تیم کوچک متشکل از 3-4 مهندس می‌توانند محصولی را گرد هم بیاورند و آن را «بهترین سیستم BPM » در وب‌سایت خود بنامند. حتی اگر همه ویژگی‌های دیگری را که در مورد آنها بحث کردیم نیز ایجاد کرده باشند، عملکرد نرم‌افزار هنگامی که 100 کاربر داشته باشد با حالتی که 1 میلیون کاربر دارد، متفاوت خواهد بود. در هنگام انتخاب نرم افزار BPM حتما تحقیق کنید که چه تعداد کاربر دارد. توسعه دهندگان محصولشان را بر اساس چه سیستم هایی ساخته اند؟ آیا می توانند با افزایش پایگاه کاربران خود مقیاس پذیر باشند؟10. معیارهای عملکرد فرآیند (Process Performance Metrics):همه فرآیندهای کسب و کار دارای deadline هستند، اما همه آنها انتظارات مربوط به معیار "به هنگام بودن" را برآورده نمی کنند. در چنین موقعیت‌هایی رهبران کسب‌وکار باید چیزی که موجب تاخیر می‌شود و چگونگی بهبود آن را شناسایی کنند.معیارهای عملکرد فرآیند ابزارهایی هستند که به سازمان ها کمک می‌کنند تا مسائل مربوط به یک فرآیند را شناسایی کنند و تصمیمات معنی‌داری جهت بهبود فرآیندهای ناکارآمد بگیرند. در BPM، معیارهای عملکرد فرآیند به‌طور خودکار داده‌های سیستم را جمع‌آوری می‌کنند تا توسط مدیر فرآیند ارزیابی شده و مشخص شود که آیا مشکل بوجود آمده در نتیجه موارد زیر است یا خیر:- مدل سازی ضعیف فرآیند- اجرای ضعیف فرآیند11. ویژگی همکاری (Collaboration):فرآیندها اغلب به بحث‌های متنی (contextual discussions)، به اشتراک گذاشتن یادداشت‌های جلسه (sharing meeting notes) و سایر ارتباطات نیاز دارند که باید در همان مکانی که کار شما رخ داده، اتفاق بیفتند.ویژگی همکاری، مکالمات را فشرده و متمرکز نگه می‌دارد و به کل تیم شما اجازه می‌دهد تا در مورد بهبود فرآیند و بهینه‌سازی، اطلاعاتی ارائه نمایید.معرفی چند راه حل BPM رایگان و Open Source:1. نرم افزار Adobe LiveCycleاین نرم افزار با Adobe Cloud و Adobe LiveCycle Enterprise Suite 4 سازگار است و یک نرم افزار BPM سطح بالاتر محسوب می شود که مفاهیم فرم پلت فرم و اسناد سازمانی را یکپارچه سازی می کند. از جمله اهداف برآورده شده توسط این نرم افزار، پردازش اطلاعات، تحویل ارتباطات شخصی و حفاظت موثر از اطلاعات حساس می باشد. LiveCycle ES4 فرآیندهای کسب و کار را میان نیروی کار سیار و مشتریان خود گسترش داده و بهره وری را افزایش می دهد و در عین حال دسترسی به خدمات را برای کاربران مجهز به کامپیوترهای دسکتاپ، تلفن هوشمند یا تبلت افزایش می دهد. این نرم افزار در گذشته با Adobe LiveCycle شناخته می شد و به عنوان یک ایستگاه کاری مرکزی عمل می کرد که فرآیندهای کاری موجود را به هم متصل کرده و تحویل مدیاها را به سایر تیم ها ساده می نمود. این نرم افزار همچنین یک پورتال ارتباط اجتماعی و یک پلت فرم تعامل اجتماعی را ارائه می دهد.2. نرم افزار Alfrescoنرم افزار Alfresco Process Services (طراحی شده توسط Activiti) یک راه حل BPM سازمانی است که افراد کسب و کار و توسعه دهندگان را مورد هدف قرار داده است. Alfresco Process Services یک برنامه ی سبک وزن است که دارای یک موتور پردازش فوق سریع BPMN 2.0 برای جاوا می باشد. در هسته ی این برنامه یک موتور فرآیند کسب و کار منبع باز با کارایی بالای مبتنی بر Activiti که انعطاف پذیری و مقیاس پذیری بسیار خوبی برای مدیریت طیف گسترده ای از فرآیندهای حیاتی دارد، موجود است. Alfresco Process Services مجموعه ای از ابزارهای کاربر نهایی (end-user) قوی را ارائه می دهد و با طیف وسیعی از سیستم های سازمانی از جمله سرویس های محتوای Alfresco، Box و Google Drive یکپارچه می گردد. Activiti برای رسیدگی به جنبه‌های فنی و غیر فنی، یعنی تجزیه و تحلیل، مدل‌سازی، تولید سازگاری فرآیند کسب‌وکار و ایجاد و پشتیبانی نرم‌افزار شدیدا بهینه شده است.3. برنامه ی ARIS Expressبرنامه ی ARIS Express، یک نرم افزار مدل سازی رایگان می باشد که برای کاربران مبتدی در فضای BPM ایده آل می باشد. به کمک یک رابط کاربری بصری، مدل‌سازان می‌توانند از آخرین پیشرفت‌ها در زمینه ی مدل‌سازی که دست یابی به نتایج فوری را امکان‌پذیر می‌کنند، استفاده نمایند. همچنین آموزش های رایگانی نیز در انجمن ARIS در دسترس است که شامل مدل هایی برای ساختارهای سازمانی، فرآیندها، سیستم های کاربردی، داده ها و غیره می باشد. ARIS Express مبتنی بر روش اثبات شده ی ARIS است. این نسخه یک گزینه ی خوب برای کار و آموزش دانشجویان می باشد. ARIS Express نسخه ای آزمایشی یا محدود نیست، بلکه نرم‌افزار مدل‌سازی رایگانی می باشد که جایگزین معقولی برای سایر ابزارهای طراحی به حساب می آید.معرفی برخی شرکت های ایرانی ارائه دهنده ی BPMS:با توجه به رشد روز‌افزون حوزه مدیریت فرایندهای کسب‌وکار در ایران، شرکت‌های متعددی اقدام به ارائه سیستم‌های جامع مدیریت فرایندهای کسب‌وکار(BPMS) نموده‌اند. شرکت‌های فعال ارایه دهنده نرم‌افزار BPMS در ایران به سه گروه ذیل تقسیم می‌شوند:۱) نمایندگی‌های شرکت‌های خارجی ارائه دهنده BPMS: عمدتا شرکت‌های خارجی به دلیل تحریم ایران، به صورت غیر مستقیم و با واسطه، راهکار خود را به دست مشتریان می‌رسانند.۲) شرکت‌های توسعه‌دهنده BPMS‌های متن‌باز: شرکت‌هایی که در بستر راهکارهای متن باز خارجی و با توسعه و بومی‌سازی آن‌ها، BPMS خود را توسعه داده‌ و ارائه نموده‌اند.۳) شرکت‌های تولیدکننده BPMS: شرکت‌هایی که با استفاده از توانمندی داخلی و بدون بهره‌گیری از راهکارهای خارجی، BPMS کاملا ایرانی ارائه داده‌اند.در جدوال زیر برخی از این شرکت ها ارائه شده است:منابع:https://kissflow.com/workflow/bpm/business-process-management-systems-top-features/https://www.creatio.com/page/bpmshttps://solutionsreview.com/business-process-management/the-top-15-free-and-open-source-bpm-software/https://ebpm.ir/10242 نیوشا شفیعی نیوشا شفیعی Thu, 23 Dec 2021 13:28:49 +0330 https://virgool.io/@m_50577917/esb-glggjyv2xckx در یک جمله گذرگاه سرویس سازمانی (ESB) یک معماری است. در حقیقت ESB مجموعه ای از قوانین و اصول برای یکپارچگی برنامه های کاربردی متعدد بر روی یک زیرساخت گذرگاه مانند است. محصولات ESB کاربران را قادر می‌سازد تا این نوع معماری را ایجاد کنند، اما در نحوه ی انجام آن و قابلیت‌هایی که ارائه می‌دهند، متفاوت هستند. مفهوم اصلی معماری ESB این است که برنامه های مختلف را با قرار دادن یک گذرگاه ارتباطی یکپارچه کرد و سپس هر برنامه را قادر ساخت تا با این گذرگاه تعامل برقرار کند. این معماری سیستم‌ها را از یکدیگر جدا می‌کند و به آن‌ها اجازه می‌دهد بدون وابستگی یا آگاهی از وجود سیستم‌های دیگر بتوانند در گذرگاه ارتباط برقرار کنند. مفهوم ESB در نتیجه ­ی نیاز به فاصله گرفتن از شیوه ی یکپارچگی point-to-point که مدیریت آن به مرور زمان دشوار می­شد، متولد گردید. یکپارچگی point-to-point منجر به گسترش کد یکپارچه سازی سفارشی در بین برنامه ها بدون وجود هیچ راه مرکزی برای نظارت یا عیب یابی می شد. این موضوع اغلب تحت عنوان "کد اسپاگتی" شناخته می شود و قابل مقیاس نمی باشد زیرا موجب وابستگی شدید بین برنامه ها می گردد.جایگاه ESB (گذرگاه خدمات سازمانی) در معماری زیر ساخت سازمان بدین صورت است که بعنوان یک واسط، بین وب سرویس‌های سازمان و سرویس گیرندگان قرار می‌گیرد (سرویس گیرندگان می‌تواند داخل یا خارج سازمان باشند) و از ارتباط point-to-point که عامل بسیاری از مشکلات است جلوگیری می‌کند. البته این جداسازی به معنای دور کردن سامانه‌ها از حالت یکپارچه نیست و اتفاقاً ESB باعث تسهیل فرآیند یکپارچه‌سازی سامانه‌ها و مستحکم ‌سازی معماری سازمان می‌شود.پس از استقرار ESB یا همان گذرگاه سرویس‌های سازمانی، فراخوانی کلیه وب سرویس‌ها و سرویس گیرندگان از طریق ESB انجام می‌شود و کلیه درخواست‌ها به ESB زده می‌شود و ESB درخواست‌ها را به منبع انتقال داده و پاسخ  آنها را پس از دریافت به سرویس گیرندگان تحویل می‌دهد.چرا از ESB استفاده می کنیم؟افزایش چابکی سازمانی یکی از رایج ترین شیوه­ هایی است که در نتیجه ی آن شرکت ها ESB را به عنوان ستون فقرات زیرساخت فناوری اطلاعات خود پیاده سازی می کنند. معماری ESB با ارائه یک سیستم ساده، به خوبی تعریف شده و "قابل اتصال" که مقیاس بسیار خوبی دارد، این امر را تسهیل می بخشد. علاوه بر این، یک ESB با استفاده از قابلیت‌های ارتباطی و تبدیلی خود، راهی برای استفاده از سیستم‌های موجود و قرار دادن آنها در معرض برنامه‌های جدید فراهم می سازد.پیاده سازیمعماری ESB دارای اصول کلیدی است که امکان چابکی و مقیاس را در کسب و کارها فراهم می کند. تمرکز اصلی در این معماری بر روی این موضوع است که در حالی که به سیستم ها اجازه می دهیم به روشی سازگار و قابل مدیریت با یکدیگر در ارتباط و تعامل باشند، آنها را از هم جدا کنیم.· مفهوم "گذرگاه" برنامه ها را از یکدیگر جدا می کند. این امر معمولاً با استفاده از یک سرور پیام رسان مانند JMS یا AMQP به دست می آید.· داده هایی که در گذرگاه جابجا می شوند دارای فرمت متعارف و معمولا XML هستند.· یک "آداپتور" بین برنامه کاربردی و گذرگاه وجود دارد که داده ها را بین دو طرف تنظیم می کند.· آداپتور مسئول تعامل با برنامه کاربردی و تبدیل داده ها از فرمت برنامه به فرمت گذرگاه است. آداپتور همچنین می تواند مجموعه ای از فعالیت های دیگر مانند مدیریت تراکنش مسیریابی پیام، امنیت، نظارت، رسیدگی به خطا و غیره را انجام دهد.· ESB ها عموماً stateless هستند. وضعیت در پیام هایی که از گذرگاه عبور می کنند تعبیه شده است. فرمت استاندارد پیام قراردادی بین سیستم ها است. فرمت استاندارد به این معنی است که یک فرمت ثابت پیام در گذرگاه وجود دارد که به موجب آن برنامه ها در گذرگاه می توانند با یکدیگر ارتباط برقرار کنند.معرفی دو ابزار Open Source در زمینه ­ی ESB:1. Mule:بیایید نگاهی به نحوه نگاشت معماری ESB به پنج قاعده­ ی اصلی یکپارچه سازی شرکت Mule بیندازیم: Orchestration: تلفیق چندین مولفه ی ریزدانه ی موجود در یک سرویس ترکیبی با مرتبه ی بالاتر است. از این کار می توان برای دستیابی به "دانه دانه کردن" مناسب سرویس ها و ترویج راهکاراستفاده مجدد و مدیریت مولفه های اساسی استفاده کرد. Transformation: تبدیل داده بین فرمت های داده استاندارد و فرمت های داده خاص نیازمند کانکتور ESB است. یک مثال از این موضوع می تواند تبدیل بین فرمت های CSV، Cobol copybook یا EDI به SOAP/XML یا JSON باشد. فرمت‌های داده ی استاندارد می‌توانند الزامات تبدیل های مربوط به پیاده‌سازی بزرگ ESB را که مصرف کنندگان و ارائه دهندگان زیادی که هر کدام فرمت ها و تعاریف داده خاص خود را دارند، تا حد زیادی ساده‌سازی کنند. Transportation: مذاکره ی پروتکل Transport بین چندین فرمت (مانند HTTP، JMS، JDBC). توجه: Mule با تبدیل کردن JDBC به transport (یا endpoint) دیگری که در آن می توان به داده ها دسترسی داشت، با پایگاه داده مانند یک «سرویس» دیگر رفتار می کند. Mediation: ارائه چندین رابط به منظور الف) پشتیبانی از چندین نسخه از یک سرویس برای سازگاری به عقب یا به طور متناوب، ب) اجازه دادن به چندین کانال برای اجرای یک مؤلفه اجرایی. نیاز دوم ممکن است شامل ارائه چندین رابط برای یک مؤلفه، یک رابط قدیمی (flat file) و یک رابط سازگار با استانداردها (SOAP/XML) باشد. Non-functional consistency: شامل سازگاری در مورد نحوه اعمال و اجرای سیاست های امنیتی و نظارتی می­باشد. علاوه بر این، اهداف مقیاس‌پذیری و دسترسی پذیری را می‌توان با استفاده از نمونه‌های متعدد یک ESB جهت افزایش توان عملیاتی (مقیاس‌پذیری) و حذف تک‌نقطه‌های شکست (SPOFs)، که هدف کلیدی سیستم‌های بسیار در دسترس است، به دست آورد.انتخاب پلت فرم ESBپلتفرم های ESB زیادی از فروشندگان بزرگ اختصاصی گرفته تا فروشندگان داخلی و منبع باز، وجود دارد. در این قسمت نکاتی را ذکر می­کنیم که باید هنگام انتخاب ESB در نظر گرفت:سبک وزنMule سبک‌ترین پلتفرم یکپارچه‌سازی موجود است که توزیع کامل بارگذاری شده ی آن 40 مگابایت وزن دارد. از نظر طراحی ماژولار است، بنابراین در صورت نیاز به کاهش footprint، می توان ماژول های ناخواسته را حذف نمود. همچنین هزینه ی ایجاد تغییرات، در یکپارچگی های موجود وهمچنین مقدار سنگینی که برای ایجاد تغییرات باید اعمال کرد، می باشد. Mule run-time ماژولارسازی و استقرار سریع و همچنین یک مدل پیکربندی را ارائه می دهد که سفارش مجدد و اضافه یا تغییر functionality را آسان می کند.فقط یک واسط نیست!اکثر فروشندگان ESB را صرفاً واسطی بین سیستم ها می دانند و محصولات جداگانه ای برای میزبانی منطق کسب و کار و سرویس ها ارائه می کنند. شرکت Mule این امر را یک پیچیدگی غیر ضروری می داند. Mule یک کانتینر سرویس مقیاس پذیر و سبک برای انتشار سرویس های REST و SOAP ارائه می دهد. از آنجایی که Mule به خوبی با Spring یکپارچه می شود، در نتیجه توسعه دهندگان می توانند از قابلیت های Spring برای پیاده سازی منطق کسب و کار استفاده کنند.قابل دسترسی - هر توسعه دهنده ای می تواند Mule را یاد بگیرد!Mule از ابزارهای رایجی استفاده می کند که همه توسعه دهندگان جاوا با آن آشنا هستند، از جمله Maven، Eclipse، JUnit و Spring. Mule از یک مدل پیکربندی XML (شبیه به Spring) برای تعریف منطق استفاده می کند که کد سفارشی را می توان به زبان های مختلفی از جمله جاوا، Groovy، JavaScript، Ruby یا Python نوشت. همچنین، Anypoint Studio به توسعه دهندگان جدید کمک می کند تا در یک محیط توسعه گرافیکی به سرعت پیش بروند.افزایش مقیاس، کاهش مقیاسMule برای مقیاس افقی در سخت افزار طراحی شده است. زمان اجرا Mule به راحتی در یک برنامه تعبیه می شود. همچنین می تواند در سرور برنامه مانند Tomcat، JBoss یا WAS و هم می تواند مستقیماً در خود برنامه تعبیه شود. مهمتر از آن، Mule پشتیبانی JUnit را فراهم می کند تا بتوان آن را در مورد آزمون JUnit تعبیه نمود. این بدین معناست که می توان تست‌های واحد تکرار شونده را برای یکپارچه سازی هایی که روی لپ‌تاپ فرد توسعه‌دهنده اجرا می‌شوند و قادر هستند در یک ساخت پیوسته تعبیه شوند، ایجاد کرد.پیام آگنوستیکیکی از ویژگی های قدرتمند Mule این است که کانتینر پیام آگنوستیک است. این بدان معناست که پیام های XML را به کاربران خود تحمیل نمی کند. در حالی که XML فرمت رایجی است، سناریوهای زیادی وجود دارد که می توان از JSON، flat files، Cobol Copybooks، پیوست‌های باینری و فایل، جریان‌ها و اشیاء جاوا استفاده کرد. Mule streaming به توسعه دهندگان اجازه می دهد تا پیام های بزرگ را به شکل موثری پردازش کنند.2. wso2موتور زمان اجرا یکپارچگی WSO2 قادر است که نقش های متعددی را در معماری سازمانی ایفا کند. WSO2 می­تواند به عنوان یک ESB یا یکپارچه کننده ی میکروسرویس عمل کند. هنگامی که به عنوان یک ESB مستقر می شود، به مسیریابی پیام، تبدیل، واسطه گری پیام، هماهنگ سازی سرویس، و همچنین نیازهای مربوط به میزبانی سرویس و API پاسخ می دهد.مسیریابی، واسطه و تبدیل داده ها· مسیریابی مبتنی بر Header، content، rule و اولویت‌· پیاده سازی الگوهای یکپارچه سازی سازمانی (EIP)، یکپارچه سازی پایگاه داده، یکپارچه سازی جریان رویداد· تبدیل پیام ها با XSLT 1.0/2.0، XPath، XQuery و Smooks· نگاشت داده های بصری· کانکتورهای تبدیل CSV، JSON و XMLساخت و یکپارچه سازی سرویس ها و API ها بر اساس استانداردها و پروتکل های باز· ایجاد API با Open API (Swagger)· پشتیبانی HTTP، HTTPS، WebSocket، POP، IMAP، SMTP و موارد دیگر· فرمت های داده مانند JSON، XML، SOAP، EDIFACT، FHIR، ISO 8583 و FIX· آداپتورهای داخلی برای سیستم‌های COTS مانند SAP، IBM MQ، Oracle AQ، MSMQ و Office 365هر پایگاه داده را به عنوان یک سرویس متصل کرده و در معرض دید قرار می دهد· از هر صفحه گسترده RDBMS، CSV، Excel، ODS، Cassandra و Google پشتیبانی می کند.· از پروتکل OData v4 برای هر منبع داده RDBMS و Cassandra پشتیبانی می کند.· پشتیبانی از MSSQL، DB2، Oracle، OpenEdge، TerraData، MySQL، PostgreSQL/EnterpriseDB، H2، Derby یا هر پایگاه داده با درایور JDBC· پشتیبانی از پرس و جوهای تو در تو در میان منابع داده· پیکربندی مبتنی بر XMLاتصال یک چیز به چیز دیگر· اتصال دهنده ها در دسته های مختلف، مانند پرداخت ها، CRM، ERP، شبکه های اجتماعی یا سیستم های قدیمی می باشند.· اتصالات تبدیل داده برای CSV، JSON، و XML و موارد دیگرقابلیت‌های ردیابی و مانیتورینگ End to End· یکپارچگی با مانیتورینگ مبتنی بر Prometheus، Grafana، Jaeger، Fluentbit· لاگینگ متمرکز با ELK Stack· مجموعه داخلی و نظارت بر دسترسی، performance و آمار استاندارد برای همه ی انواع مصنوعات· پشتیبانی از یکپارچگی با enterprise logging systemsگزینه های استقرار Hybrid· یکپارچه سازی بومی با Docker، Kubernetes، و انواع دیگر پلتفرم‌های مدیریت کانتینر· استقرار بر روی VM یا bare metalشرکت های ایرانی ارائه دهنده ی ERPشرکت پلتکوپلتکو یک شرکت ایرانی ارائه دهنده ی انواعسرویس ‌های سازمانی، خدمات یکپارچه سازی و مدیریت وب سرویس مانند ESB و API MANAGER و ... می باشد که محور فعالیت های آنها در تصویر زیر خلاصه شده است:شرکت داده پرداز پویای شریفپلتفرم ESB داده پرداز یکی از راهکارهای یکپارچه سازی انواع سرویس‌ها در سازمان‌های بزرگ و مدیریت نمودن جریان اطلاعات در آنهاست. پلتفرم ESB داده‌پرداز تا به امروز در سامانه‌های بزرگی همچون سامانه فروش بلیط بن ریل، اپلیکیشن خدمت در محل همراه یار، پورتال دولت الکترونیک و ... به کاربرده شده و ویژگی اصلی آن، توانایی برقراری ارتباط با ماکروسرویس‌های بزرگ و برقراری جریان امنیت اطلاعات و مدیریت آنهاست.ویژگی‌های پلتفرم ESB داده‌پرداز· توسعه پذیری و چابکی· کاهش هزینه های توسعه و پشتیبانی نرم افزارها· افزایش بهره وری سامانه ها· امکان اتصال به انواع وب سرویس ها و پایگاه های داده· دارای زیرساخت توسعه پذیر· پشتیبانی از تعداد زیاد کاربر به صورت همزمان· ایجاد ارتباط و بهینه سازی سیستم هاجمع بندیگذرگاه سرویس سازمانی (ESB) لایه ای انتزاعی است، که به عنوان “یک مترجم سراسری” در حوزه وب سرویس‌ها عمل می‌کند و برقراری ارتباط بین چندین سیستم را ممکن می‌سازد دارد که با “زبان” متفاوت صحبت می‌کنند. هنگامی که یک سیستم پیامی برای انتقال دارد ، گذرگاه خدمات سازمانی این پیام را ترجمه کرده و به گیرنده صحیح هدایت می‌کند. این قابلیت مهم باعث می‌شود که سازمان‌ها به راحتی بتوانند وب سرویس‌های قدیمی (legacy) خود را بدون نیاز به توسعه‌ی سامانه‌های قدیمی به شکل استاندارد و مطلوب خود درآورده و در اختیار سرویس ‌گیرندگان قرار دهند. گذرگاه خدمات سازمانی به طور چشمگیری فرآیند یکپارچه‌سازی چندین محیط و سیستم ناهمگن را ساده می کند.منابع:https://www.mulesoft.com/resources/esb/what-esbhttps://platco.ir/services/integration-web-services/enterprise-service-bus/https://wso2.com/products/enterprise-service-bus/https://dadehpardaz.com/esb نیوشا شفیعی نیوشا شفیعی Mon, 20 Dec 2021 01:59:43 +0330 https://virgool.io/@m_50577917/event-sourcing-tbm1jfgvm9fs Event sourcing می توان گفت که Event Sourcing یک راه حل جایگزین برای داده های ماندگار است. برخلاف state-oriented persistence که تنها آخرین نسخه از حالت موجودیت را نگه می دارد، Event Sourcing هر جهش حالت را به عنوان یک رکورد جداگانه تحت عنوان رویداد ذخیره می کند. State-oriented persistenceتمام سیستم های real-life داده ها را ذخیره می کنند. شمار بسیاری از انواع مختلف ذخیره سازی داده وجود دارد، اما معمولاً توسعه دهندگان از پایگاه های داده برای ایمن نگه داشتن داده ها استفاده می کنند. پایگاه های داده کامپیوتری درست پس از ورود کامپیوترها به دنیای کسب و کار ظهور کردند. پایگاه داده های سلسله مراتبی به سرعت توسط پایگاه های داده رابطه ای که از دهه ی 1970 به بعد رشد کردند یعنی زمانی که اولین زبان های پرس و جو نویسی به نام های QUEL و SEQUEL ظاهر شدند، از بین رفتند. از دهه 1980، زمانی که SQL به زبان پرس و جوی استاندارد برای پایگاه های داده رابطه ای و RDBMS های مختلف مانند Oracle تبدیل شد، IBM DB/2 و Microsoft SQL Server رفته رفته بر دنیای پایداری داده ها مسلط شدند. با این حال، با ظهور برنامه نویسی شی گرا، که در اواخر دهه 1990 به جریان اصلی تبدیل شد، توسعه دهندگان شروع به مبارزه برای ماندگاری اشیاء در پایگاه داده های رابطه ای کردند. این مبارزه ای "عدم تطابق امپدانس شی-رابطه ای" نام گرفت. خانواده‌های جایگزین پایگاه‌های داده، از پایگاه‌های داده قدیمی‌تر اشیاء تا پایگاه‌های داده اسناد مدرن‌تر، در طول دهه ‌ها برای رسیدگی به مسائل عدم تطابق ظهور پیدا کردند.اگرچه اهمیتی نداردکه برنامه از چه نوع پایگاه داده ای استفاده می کند، با این حال تنها چیزی که در پایگاه داده ذخیره می شود وضعیت فعلی سیستم است. اساساً، همه DMBS ها از چهار عملیات اساسی برای ماندگاری پشتیبانی می کنند - ایجاد، خواندن، به روز رسانی و حذف (CRUD).اشیاء سیستم معمولاً به عنوان رکوردهای پایگاه داده – در ردیف هایی در جداول یا اسناد باقی می مانند. به این معنی که هنگامی که شی تغییر می کند، و تغییر نیاز به ماندگاری دارد، رکورد پایگاه داده با یک رکورد جدید که حاوی مقادیر به روز شده است، جایگزین می شود.تاریخچه رکوردنگهداری تاریخچهاغلب تنها حفظ وضعیت فعلی یک موجودیت کافی نیست. هنگامی که چنین نیازی وجود دارد، توسعه دهندگان اغلب انتخاب می کنند که تاریخچه به روز رسانی خاصی را در یک جدول یا مجموعه اسناد جداگانه ذخیره کنند. با این حال، چنین تاریخچه ای فقط به یک مورد کاربردی خاص می پردازد و باید از قبل ساخته شود.حتی زمانی که چنین راه‌حلی پیاده‌سازی و اجرا می‌شود، هیچ تضمینی وجود ندارد که فردا یا سال آینده، کسب ‌وکار نیازی به نگه‌داشتن سابقه تغییرات وضعیت های دیگر نداشته باشد. باز هم، تمام تاریخچه قبل از تغییری که چنین رکوردی را حفظ می کرد، از بین خواهد رفت. مسئله دیگری که فقط در مورد حفظ وضعیت فعلی موجود است این است که تمام تغییراتی که در پایگاه داده رخ می دهد، طبیعتاً ضمنی هستند.Eric Evans در کتاب Domain-Driven Design معتقد است که تاریخچه تغییرات موجودیت ها می تواند اجازه دسترسی به حالت های قبلی را بدهد، اما معنای آن تغییرات را نادیده می گیرد، به طوری که هرگونه دستکاری اطلاعات رویه ای است و اغلب از لایه دامنه خارج می شود.هر تغییری در یک موجودیت ماندگار شده فقط یک به روز رسانی دیگر است که از همه به روز رسانی های دیگر قابل تشخیص نیست. برای مثال، وقتی به موجودیت Order و ویژگی Status آن نگاه می کنیم، اگر به Paid یا Shipped به روز شود، می توانیم (به طور ضمنی) بفهمیم که چه اتفاقی افتاده است. با این حال، در صورتی که مقدار ویژگی Total تغییر کند، چگونه می توانیم تشخیص دهیم چه چیزی باعث این تغییر شده است؟جهش های صریح به عنوان رویدادهنگام استفاده از رویدادهای دامنه، که به نوبه خود از اصطلاحات دامنه (Ubiquitous Language) برای توصیف تغییرات حالت استفاده می کنند، توضیح صریحی از تغییر داریم.مورد پرداخت ممکن است برای افشای تفاوت کمی ساده باشد، بنابراین، بیایید از مثال دیگری استفاده کنیم. تصور کنید که مبلغ کل سفارش به دلیل دیگری تغییر می کند. اگر فقط حالت موجودیت را حفظ کنیم، این تغییر به صورت زیر انجام می شود: در اینجا یک به‌روزرسانی ضمنی برای وضعیت موجود اعمال شده است، و تنها راه برای اینکه بفهمیم چه اتفاقی افتاده است، نگاه کردن به نوع مسیر حسابرسی یا حتی گزارش برنامه است. وقتی تغییرات حالت را به عنوان رویدادهای دامنه مدل می کنیم، می توانیم آن تغییرات را تصریح کنیم و از زبان دامنه برای توصیف تغییر استفاده کنیم. در زیر مشاهده می کنید که اگر فقط به وضعیت نهایی نگاه کنیم، دو عملیات کاملاً متفاوت ممکن است اتفاق بیفتد که دقیقاً به یک نتیجه منجر شود.هنگامی که تخفیف برای سفارش اعمال می شود، مبلغ کل تغییر می کند. مجدداً، کل مبلغ ممکن است به دلایل دیگری مانند حذف یک مورد سفارش نیز تغییر کند.رویداد دامنه در کد (Domain event in code)یک رویداد دامنه زمانی که در کد پیاده سازی می شود چگونه به نظر می رسد؟ در واقع مثل یک کیسه از دارایی های ساده است. باید اطمینان حاصل کنیم که می‌توانیم آن را جهت ماندگاری سریال‌سازی کنیم، همچنین می‌توانیم هنگامی که زمان خواندن رویداد از پایگاه داده می‌رسد، آن را غیر سریال‌سازی کنیم.لازم به ذکر است که Eric Evans در کتاب Domain-Driven Design معتقد است که رویداد دامنه بخش کاملی از مدل دامنه و نمایش چیزی که در دامنه اتفاق افتاده می باشد. موجودیت ها به عنوان جریان رویدادبنابراین، Event Sourcing مکانیسم ماندگاری است که در آن هر انتقال حالت برای یک موجودیت معین به عنوان یک رویداد دامنه نشان داده می‌شود که به پایگاه داده رویداد (مخزن رویداد) تداوم می‌یابد. هنگامی که حالت موجودیت جهش می یابد، یک رویداد جدید تولید و ذخیره می شود. هنگامی که نیاز به بازیابی حالت موجودیت داریم، همه ی رویدادها را برای آن موجودیت می خوانیم و هر رویداد را برای تغییر وضعیت اعمال می کنیم، زمانی که همه رویدادهای موجود خوانده و اعمال شدند، به وضعیت نهایی و صحیح موجودیت می رسیم. جریان رسیدگی به فرمان (Command handling flow)از آنجایی که قبلاً از مثال سفارش در این بخش استفاده کرده‌ایم، می‌توانیم موجودی را بسازیم که یک سفارش را نشان می‌دهد: در این مثال، ما از الگوی Domain Model استفاده می‌کنیم، بنابراین موجودیت دارای حالت و رفتار است. انتقال حالت زمانی اتفاق می‌افتد که متدهای موجودیت را فراخوانی می‌کنیم. در نتیجه جریان اجرای هر عملیاتی به شکل زیر است: اگر برنامه ما از معماری پورت ها و آداپتورها استفاده می کند، یک سرویس کاربردی خواهیم داشت که دستور زیر را انجام می دهد: همچنین یک آداپتور لبه مانند HTTP خواهیم داشت که دستورات دنیای بیرون را می‌پذیرد، اما بحث آن خارج از محدوده ی این مقاله است. موجودیت مبتنی بر رویداداکنون، بیایید بررسی کنیم که چه چیزی باید تغییر کند تا برنامه ما از Event Sourcing استفاده کند:رویداد به عنوان کددر ابتدا، ما به یک رویداد نیاز داریم که انتقال حالت را نشان دهد: این رویداد اکنون رفتار دامنه خاصی را توصیف می کند و حاوی اطلاعات کافی برای تغییر وضعیت موجودیت Order است. تولید رویدادهاسپس، باید کد موجودیت را تغییر دهیم، بنابراین یک رویداد ایجاد می شود: در این مرحله، متد AddItem مستقیماً وضعیت موجودیت را تغییر نمی دهد، بلکه یک رویداد تولید می کند پس از متد Apply استفاده می کند که هنوز در کلاس Order وجود ندارد، بنابراین باید آن را پیاده سازی کنیم. جمع آوری تغییرات هر رویداد جدید یک تغییر است. کلاس Order باید تمام تغییراتی را که در جریان اجرای دستور اتفاق می‌افتد پیگیری کند، بنابراین ما می‌توانیم آن تغییرات را در کنترل‌کننده فرمان ادامه دهیم. چنین رفتاری عمومی است و منحصر به کلاس Order نیست، بنابراین می‌توانیم یک کلاس انتزاعی برای جداسازی کار فنی در آن بسازیم: اکنون می توانیم کلاس Order را به منظور ارث بردن از کلاس Entity تغییر دهیم و کد کامپایل خواهد شد. با این حال، توجه داشته باشید که وقتی یک رویداد جدید تولید می کنیم، وضعیت موجودیت تغییر نمی کند. اگر هنگام رسیدگی به یک فرمان فقط یک رویداد تولید کنیم، ممکن است مشکلی نباشد، اما همیشه اینطور نیست. به عنوان مثال، هنگام اضافه کردن یک آیتم جدید، می‌توانیم دو رویداد تولید کنیم: ItemAdded و TotalUpdated تا تغییرات حالت واضح تر و اتمی تر شود. در برخی موارد، کدی که رویدادهای متعاقب را تولید می کند، اما همچنان در همان تراکنش است، نیاز به دانستن وضعیت موجودیت جدید دارد که با رویداد قبلی تغییر کرده است. بنابراین، زمانی که هر رویداد را اعمال می کنیم، باید حالت در فرآیند را جهش دهیم. استفاده از رویدادها برای جهش وضعیتبیایید ابتدا روشی را پیاده سازی کنیم که با استفاده از رویدادها حالت موجودیت را تغییر می دهد. معمولاً این روش را When می نامند. می‌توانیم یک متد انتزاعی را به کلاس پایه اضافه کنیم و اطمینان حاصل کنیم که وقتی رویدادهای جدید را به لیست تغییرات اضافه می‌کنیم فراخوانی می‌شود: اکنون می توانیم متد When را در کلاس Order پیاده سازی کنیم: اساساً برای بازیابی حالت موجودیت از رویدادها، باید فولد سمت چپ را روی همه رویدادهای جریان موجودیت اعمال کنیم. با تمام این تغییرات، API عمومی کلاس Order تغییری نکرده است. همچنان متد AddItem را نشان می دهد و فقط اجرای داخلی متفاوت است. استفاده از رویدادها برای ماندگاریحال، بیایید به جریان اصلی رسیدگی فرمان بازگردیم و ببینیم از زمان استفاده از رویدادها تا الان، چگونه تغییر کرده اند. در واقع، جریان کلی یکسان است، کد سرویس برنامه نیز یکسان است. تنها تغییر نحوه ی عملکرد آداپتور EntityStore است. برای state-oriented persistence، شبیه به قرار دادن حالت موجودیت در یک سند، سریال سازی و ذخیره در یک پایگاه داده سند، و سپس خواندن آن است. وقتی یک موجودیت event-sourced داریم چگونه به نظر می رسد؟ ما از همان پورت استفاده می کنیم، بنابراین API تغییر نمی کند. باید یک آداپتور را پیاده سازی کنیم که بتواند از یک پایگاه داده رویدادگرا مانند Event Store استفاده کند. از نظر اشیاء ماندگار، مورد کاربردی اصلی برای پایگاه داده رویداد این است که بتواند رویدادها را برای یک شی یا موجودیت واحد با استفاده از شناسه موجودیت ذخیره و بارگذاری کند. تفاوت اصلی این است که وقتی از یک پایگاه داده رابطه‌ای یا سندی استفاده کرده و شناسه موجودیت برای دریافت داده‌ها را به کار می گیرید، رکورد واحدی را دریافت می‌کنید که مستقیماً وضعیت موجودیت فعلی را نشان می‌دهد. در مقابل، هنگامی که یک موجودیت را از پایگاه داده رویداد بازیابی می کنید، چندین رکورد برای یک شناسه دریافت می کنید و هر رکورد در مجموعه یک رویداد است. بنابراین، کل مجموعه رویدادهایی که یک موجودیت واحد را نشان می دهند، دارای یک شناسه منحصر به فرد هستند. از آنجایی که ما یک رکورد واحد نداریم که به آن شناسه اختصاص داده شده باشد، آن مجموعه رویداد را یک جریان می نامیم. جریان مجموعه ای مرتب از رویدادها برای یک شی واحد در سیستم است. شناسه شی همراه با نوع شی اغلب به عنوان نام جریان به کار می رود. وقتی همه رویدادها را از یک جریان واحد می‌خوانیم، می‌توانیم وضعیت فعلی را با فراخوانی متد When برای همه رویدادها به ترتیب بازسازی کنیم. با یک پایگاه داده انتزاعی رویداد گرا، آداپتور EntityStore شبیه کد زیر است: نکته مهمی که در اینجا باید ذکر شود این است که کدی که بر اساس اطلاعات ذخیره شده در رویدادها حالت موجودیت را تغییر می دهد، نباید منطق یا محاسبات پیشرفته ای داشته باشد. ترجیحاً رویداد از قبل حاوی تمام اطلاعات مورد نیاز باشد. بنابراین متد When می‌تواند مستقیماً از آن برای تغییر ویژگی‌های حالت موجودیت استفاده کند. با پیروی از این الگو، مطمئن خواهید شد که انتقال های حالت ماندگار هستند و وضعیت موجودیت فعلی همیشه قابل پیش بینی خواهد بود. منبع مورد استفاده:https://www.eventstore.com/blog/what-is-event-sourcingاین مطلب بخشی از تمرین درس معماری نرم افزار در دانشگاه شهید بهشتی می باشد. نیوشا شفیعی نیوشا شفیعی Thu, 09 Dec 2021 23:45:57 +0330 https://virgool.io/@m_50577917/domain-driven-design-ddd-gs7ft6dyvhyk Domain Driven Design (DDD) این مفهوم به ایجاد نگاشت بین مفاهیم موجود در کسب‌وکار و مصنوعات معماری می‌پردازد. این رویکرد از این رو صورت می‌گیرد که نرم‌افزار مطابقت بیشتری با خواسته‌ی ذینفعان داشته باشد همچنین درک بهتری از نیاز ذینفعان برای معماران نرم‌افزار ایجاد شود. نکته‌ی قابل توجه این است که DDD را نمی‌توان معماری به حساب آورد. رویکرد DDD را می توان در چهار بخش مورد بررسی قرار داد:· مفاهیم: در این بخش اصطلاحاتی که در آن کسب‌وکار موجود است و معانی آن‌ها مورد بررسی قرار می‌گیرد.· طراحی استراتژیک: این بخش به بررسی هدف‌های اصلی پروژه و زمینه‌های آن و محدوده‌ی کار به همراه کل ذینفعان می پردازد.· طراحی تاکتیکی: بخشی از DDD که به بررسی موجودیت‌ها، خدمات و ماژول‌های لازم در پروژه با توجه به موارد قبلی می‌پردازد.· طراحی معماری: به سبک معماری که می‌تواند در DDD استفاده شود و معماری‌هایی مانند هگزاگونال، لایه‌ای، CQRS و... اشاره دارد.مفاهیم سطح بالایی که در این مدل استفاده می‌شوند به شرح زیر است:· موجودیت (Entity): شی که با رشته پیوستگی آن تعریف می‌شود برخلاف اشیاء سنتی که با ویژگی‌هایشان مشخص می‌شوند.· شی‌ارزشی (Value Object): شی تغییرناپذیری که دارای صفات است، اما هویت جداگانه ندارد.· رویداد دامنه (Domain Event): شی که برای ردیابی رویدادهایی که کارشناسان دامنه به آن اهمیت می‌دهند استفاده می‌شود.· خوشه‌ای(Aggregate): به مجموعه‌ای از موجودیت‌ها و اشیا ارزشی با مرزهای مشخص در اطراف گروه که به جای اینکه به هر موجویت یا شی مقداری داده شود تا کاری را انجام دهد به مجموعه‌ای از اقلام خوشه مقدار اختصاص داده شده است. هم‌اکنون اشیا خارجی به شی داخلی دسترسی ندارند بلکه به آیتم ریشه‌ی مجموع دسترسی خواهند داشت.· خدمات(service.):به عملیاتی از منطق کسب و کار گفته می‌شود که هدف مشخصی را دارد و در قلمروی اشیا نیستند.· مخازن(Repositories): سرویسی است که از یک رابط جهانی برای دسترسی به تمام موجودیت ها و اشیاء ارزشی که در یک مجموعه خوشه‌ی خاص هستند استفاده می کند. روش‌هایی باید تعریف شوند تا امکان ایجاد، اصلاح و حذف اشیاء در مجموعه را فراهم کنند. با این حال، با استفاده از این سرویس مخزن پرس و جوهای داده ایجاد می‌شود . هدف حذف چنین پرس‌وجوهایی می‌باشد همچنین نباید آن را با مخازن رایج کنترل اشتباه گرفت.· کارخانه(Factories): DDD استفاده از یک کارخانه را پیشنهاد می‌کند که منطق ایجاد اشیاء و مصالح پیچیده را در بر می‌گیرد و تضمین می‌کند که مشتری از عملکرد درونی دستکاری اشیا اطلاعی ندارد.مزایای طراحی دامنه محورارتباطات را آسان می کند: با تأکید اولیه بر ایجاد یک زبان مشترک و همه جا حاضر مرتبط با مدل دامنه پروژه، تیم ها اغلب ارتباط در کل چرخه عمر توسعه را بسیار آسان تر می بینند. به طور معمول، DDD هنگام بحث در مورد جنبه های برنامه به اصطلاحات فنی کمتری نیاز دارد، زیرا زبان فراگیر احتمالاً اصطلاحات ساده تری را برای اشاره به جنبه های فنی تر تعریف می کند.انعطاف‌پذیری را بهبود می‌بخشد: از آنجایی که DDD به شدت حول مفاهیم تحلیل و طراحی شی گرا است، تقریباً همه چیز در مدل دامنه مبتنی بر یک شی خواهد بود و بنابراین کاملاً ماژولار و محصور شده است و اجازه می دهد تا اجزای مختلف، یا حتی کل سیستم به عنوان یک کل، به طور منظم و مداوم تغییر و بهبود یابد.بر روی اینترفیس دامنه تاکید می کند: از آنجایی که DDD بر ایجاد مفاهیم دامنه و آنچه متخصصان دامنه در پروژه توصیه می کنند است، در نتیجه برخلاف برنامه هایی که در درجه اول بر UI/UX تاکید دارند، اغلب برنامه هایی را تولید می کند که دقیقاً برای دامنه مورد نظر مناسب و نماینده آن هستند. در حالی که یک تعادل آشکار مورد نیاز است، تمرکز بر دامنه به این معنی است که یک رویکرد DDD می تواند محصولی تولید کند که به خوبی با مخاطبان مرتبط با آن دامنه ارتباط برقرار کند.معایب طراحی دامنه محور:به تخصص قدرتمند دامنه نیاز دارد: حتی با وجود ماهرترین ذهن‌های فنی که روی توسعه کار می‌کنند، اگر حداقل یک متخصص دامنه در تیم وجود نداشته باشد که از جزئیات دقیق حوزه ی موضوعی که برنامه در نظر گرفته شده است مطلع نباشد، همه چیز بیهوده است. در برخی موارد، طراحی دامنه محور ممکن است به ادغام یک یا چند عضو تیم خارجی نیاز داشته باشد که می توانند به عنوان متخصص دامنه در طول چرخه عمر توسعه عمل کنند.تمرین‌های تکراری را تشویق می‌کند: در حالی که بسیاری این را یک مزیت می‌دانند، نمی‌توان انکار کرد که تمرین‌های DDD قویاً بر تکرار ثابت و یکپارچگی مداوم برای ساختن یک پروژه انعطاف‌پذیر است که می‌تواند در صورت لزوم خود را تنظیم کند. برخی از سازمان‌ها ممکن است با این شیوه‌ها مشکل داشته باشند، به‌ویژه اگر تجربه گذشته آنها تا حد زیادی با مدل‌های توسعه کمتر انعطاف‌پذیر، مانند مدل آبشاری یا موارد مشابه مرتبط باشد.برای پروژه های بسیار فنی مناسب نیست: در حالی که DDD برای برنامه هایی که پیچیدگی دامنه زیادی دارند (که منطق کسب و کار نسبتاً پیچیده است) عالی است، DDD برای برنامه هایی که پیچیدگی دامنه حاشیه ای دارند اما برعکس پیچیدگی فنی زیادی دارند چندان مناسب نیست. از آنجایی که DDD به شدت بر نیاز (و اهمیت) متخصصان دامنه برای تولید زبان مناسب فراگیر و مدل دامنه ای که پروژه بر اساس آن استوار است تأکید می کند، پروژه ای که از نظر فنی فوق العاده پیچیده باشد ممکن است برای کارشناسان دامنه چالش برانگیز بوده و مشکلاتی را ایجاد کند. منابع:[1]: https://www.infoq.com/articles/ddd-in-practice/[2]: https://thedomaindrivendesign.io/what-is-ddd/این مطلب بخشی از تمرین درس معماری نرم افزار در دانشگاه شهید بهشتی می باشد. نیوشا شفیعی نیوشا شفیعی Thu, 09 Dec 2021 23:23:08 +0330 https://virgool.io/@m_50577917/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%B4%D8%B4-%D8%B6%D9%84%D8%B9%DB%8C-hexagonal-architecture-lwdsqpax6fls معماری شش ضلعی (Hexagonal Architecture)این تصویر توسط Giovanni C. Garnica در Unsplash ثبت شده است.هدف معماری لایه‌ای سنتی، تفکیک یک اپلیکیشن به لایه‌های مختلف است، به گونه­ای که هر لایه شامل ماژول‌ها و کلاس‌هایی باشد که مسئولیت‌ های مشترک یا مشابهی دارند و برای انجام وظایف خاص با هم کار می‌کنند.انواع مختلفی از معماری های لایه ای موجود است و هیچ قانونی وجود ندارد که بخواهد تعیین کند چه تعداد لایه باید وجود داشته باشد. رایج ترین الگو، معماری 3 لایه است که در آن اپلیکیشن به لایه­های ارائه (Presentation Layer)، لایه منطقی (Logic Layer) و لایه داده (Data Layer) تقسیم می شود.در کتاب Domain-Driven Design، Eric Evans برای مقابله با پیچیدگی در قلب نرم‌افزار، یک معماری 4 لایه را پیشنهاد می‌کند تا بین لایه دامنه که منطق کسب‌وکار را نگه می‌دارد، و 3 لایه پشتیبان دیگر، امکان جداسازی ایجاد شود: رابط کاربری (User Interface)، برنامه کاربردی (Application) و زیرساخت (Infrastructure).پیروی از معماری لایه­ای از بسیاری جهات سودمند است، یکی از مهمترین این جهات، تفکیک دغدغه ها (separation of concerns) است. اما همیشه یک ریسک وجود دارد. از آنجایی که هیچ مکانیسم طبیعی برای تشخیص ریزش منطق بین لایه‌ ها وجود ندارد، ممکن است - و احتمالاً - با ریزش منطق کسب و کار در رابط کاربری یا دغدغه های زیرساخت که در منطق کسب و کار تلفیق شده‌اند، مواجه شویم.در سال 2005، Alistair Cockburn متوجه شد که تفاوت زیادی بین نحوه تعامل رابط کاربری یا پایگاه داده با یک برنامه وجود ندارد. چرا که آنها هر دو کنشگر خارجی (external actors) هستند که با اجزای مشابه قابل تعویض می باشند و از طریق روش ‌هایی معادل با یک برنامه کاربردی تعامل برقرار می کنند. با مشاهده به این شیوه، می توان بر روی ناشناس نگه داشتن برنامه کاربردی این کنشگرهای خارجی تمرکز داشت و به آنها اجازه داد که از طریق پورت ها و آداپتورها تعامل داشته باشند. در نتیجه از درهم تنیدگی و ریزش منطق بین منطق کسب و کار و مولفه های خارجی جلوگیری می شود.در این مقاله تلاش شده که روی مفاهیم اصلی معماری Hexagonal، مزایا و هشدارهای مربوط به آن صحبت شود تا به شکلی ساده نحوه­ ی بهره بردن از این الگو در پروژه‌ها درک گردد.معماری Hexagonal که از آن تحت عنوان پورت ها و آداپتورها نیز یاد می شود، الگوی معماری است که به کاربران یا سیستم های خارجی اجازه می دهد تا وارد برنامه در یک پورت از طریق یک آداپتور شوند. این معماری اجازه می دهد تا خروجی از برنامه به وسیله­ ی پورت به آداپتور ارسال گردد. این نوع معماری یک لایه انتزاعی ایجاد می کند که از هسته برنامه محافظت کرده و آن را از ابزارها و تکنولوژی های خارجی - و به نوعی نامربوط - جدا کند.پورت ها (Ports)می‌توانیم یک پورت را به ‌عنوان یک نقطه ورودی تکنولوژی-آگنوستیک ببینیم، که رابطی را که به کنش گرهای خارجی اجازه می‌دهد با برنامه، صرف نظر از اینکه چه کسی یا چه چیزی رابط مذکور را پیاده‌سازی کرده، ارتباط برقرار کنند را تعیین نماید. درست مثل یک پورت USB که به دستگاه های مختلف اجازه می دهد که اگر یک آداپتور USB دارند، با یک کامپیوتر ارتباط برقرار کنند. پورت ها همچنین به اپلیکیشن اجازه می­دهند تا با سیستم ها یا خدمات خارجی مانند پایگاه های داده، کارگزاران پیام (message brokers)، سایر اپلیکیشن ها و ... ارتباط برقرار کنند.نکته: یک پورت همیشه باید دو آیتم به آن متصل باشد، که یکی از آنها همواره تست است.آداپتورها (Adapters)یک آداپتور با استفاده از یک فناوری خاص، تعامل با برنامه را از طریق یک پورت آغاز می کند. به عنوان مثال، کنترلر REST یک آداپتور را نشان می دهد که به مشتری اجازه می دهد با برنامه ارتباط برقرار کند. می‌توان به تعداد مورد نیاز برای هر پورت آداپتور وجود داشته باشد بدون اینکه خطری برای پورت‌ها یا خود برنامه ایجاد کند.اپلیکیشناپلیکیشن هسته ی سیستم است و شامل خدمات کاربردی است که عملکرد یا موارد استفاده را هماهنگ می­کند. همچنین شامل مدل دامنه (Domain Model) ، که منطق کسب و کار در Aggregates، Entities و Value Objects تعبیه شده است، می باشد. این برنامه توسط یک شش ضلعی نمایش داده می شود که دستورات یا کوئری ها را از پورت ها دریافت کرده و درخواست ها را از طریق پورت ها به دیگر کنش گرهای خارجی مانند پایگاه های داده ارسال می کند. هنگامی که با طراحی دامنه محور جفت می شود، برنامه یا شش ضلعی شامل لایه های برنامه و دامنه می باشد و لایه های رابط کاربری و زیرساخت را بیرون می گذارد.چرا شش ضلعی؟ایده ی Alistair برای استفاده از شش ضلعی صرفاً نمایش تصویری از ترکیبات چند پورت/آداپتور یک اپلیکیشن و همچنین به تصویر کشیدن چگونگی تعاملات و پیاده سازی های متفاوت سمت چپ برنامه، یا "سمت driving "، نسبت به سمت راست یا "سمت driven " است.سمت Driving در مقابل سمت Drivenکنشگرهای driving (یا اصلی) آنهایی هستند که تعامل را آغاز می کنند و همیشه در سمت چپ تصویر می شوند. به عنوان مثال، یک آداپتور driving می تواند یک کنترل کننده باشد که ورودی (کاربر) را می گیرد و آن را از طریق یک پورت به برنامه ارسال می کند.کنشگر driven (یا ثانویه) آنهایی می باشند که توسط برنامه behavior را به کار می اندازند. به عنوان مثال، یک آداپتور پایگاه داده توسط اپلیکیشن به منظور واکشی یک مجموعه داده خاص، فراخوانی می شود.هنگامی که نوبت به اجرا می رسد، چند نکته مهم وجود دارد که نباید از آنها غافل شد:· پورت ها (بیشتر اوقات، بسته به زبانی که انتخاب می کنید) به عنوان رابط در کد نشان داده می شوند.· آداپتورهای driving از یک پورت استفاده می‌کنند و یک سرویس برنامه رابط تعریف ‌شده توسط پورت را پیاده‌سازی می‌کند، در این مورد هم رابط پورت و هم پیاده‌سازی آن در داخل شش‌ضلعی هستند.· آداپتورهای Driven پورت را پیاده سازی می کنند و یک سرویس برنامه از آن استفاده می کند، در این مورد پورت در داخل شش ضلعی است، اما پیاده سازی در آداپتور و در نتیجه خارج از شش ضلعی است.وابستگی معکوس (Dependency Inversion) در در زمینه معماری شش ضلعیاصل Dependency Inversion یکی از 5 اصلی است که توسط (عمو) باب مارتین در Paper OO Design Quality Metrics و بعداً در کتاب Agile Software Development Principles, Patterns and Practices ابداع شده و به شرح زیر تعریف می شود:· ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشند بلکه هر دو باید به انتزاعات وابسته باشند.· انتزاعات نباید به جزئیات وابستگی داشته باشند. بلکه جزئیات باید به انتزاعات وابسته باشند.همانطور که قبلا ذکر شد، سمت چپ و راست شش ضلعی شامل 2 نوع مختلف کنشگر است، Driving و Driven که در آن هر دوی پورت و آداپتور وجود دارند.در سمت Driving، آداپتور وابسته به پورتی است که توسط Application Service پیاده‌سازی می‌شود، بنابراین آداپتور نمی‌داند چه کسی به فراخوانی ‌های آن واکنش نشان خواهد داد. بلکه فقط می داند چه متدهایی تضمین شده که در دسترس باشند، بنابراین به یک انتزاع وابسته است.در سمت Driven، Application Service وابسته به پورت است و آداپتور آن رابط پورت را پیاده‌سازی کرده و به طور موثر وابستگی را معکوس می‌کند، زیرا آداپتور «سطح پایین» مجبور به پیاده‌سازی انتزاع تعریف ‌شده در هسته برنامه، که "سطح بالاتر" است، می باشد.چرا باید از پورت ها و آداپتورها استفاده کرد؟استفاده از معماری پورت ها و آداپتورها مزایای زیادی دارد، یکی از آنها این است که بتوانید منطق برنامه و منطق دامنه خود را به صورت کاملاً آزمایشی جداسازی کنید. از آنجایی که به عوامل خارجی وابسته نیست، تست آن طبیعی می شود. همچنین به شما این امکان را می‌دهد که تمام رابط‌های سیستم خود را «بر اساس هدف» و نه با تکنولوژی طراحی کنید، از قفل شدن شما جلوگیری می‌کند، و توسعه ی پشته تکنولوژی برنامه‌تان را با گذشت زمان آسان‌تر می‌کند. اگر نیاز به تغییر لایه persistence دارید، این کار را انجام دهید. اگر باید اجازه دهید برنامه شما به جای انسان توسط ربات های Slack فراخوانی شود، معطل نکنید! تنها کاری که باید انجام دهید این است که آداپتورهای جدید را پیاده سازی کنید. فقط مراقب ریزش بین لایه های Application و Domain باشید.ساختار بندی برنامه و نمونه کددر این بخش، نسخه بسیار ساده‌ شده‌ای از یک سرویس را پیاده‌سازی می‌کنیم که درخواست‌های ایجاد سفارش برای یک اپلیکیشن تجارت الکترونیک ساختگی را پردازش می‌کند. لطفاً توجه داشته باشید که نمونه‌ها آگاهانه بخش‌های خاصی را حذف کرده اند و جنبه‌های مهمی از کدهای به خوبی نوشته شده، مانند مدیریت خطا و نام‌گذاری مناسب را نادیده می‌گیرند تا بر مفاهیم اساسی پیاده‌سازی پورت‌ها و آداپتورها تمرکز کنند. مهم است که تاکید کنیم که تمام لایه‌های معماری لایه‌ای Domain-Driven Design هنوز در هنگام ساختاربندی یک برنامه کاربردی بر اساس پورت‌ها و آداپتورها مناسب هستند، زیرا تفکیک ایده‌آلی برای همه مولفه ها فراهم می‌کنند. در برنامه ساختگی ما، کنترلر آداپتور Driving است که از پورت Driving استفاده می کند.پورت Driving یک رابط در لایه برنامه یا شش ضلعی خواهد بود. سرویس اپلیکیشن پورت Driving را پیاده سازی می کند.همانطور که می بینید، Application Service که مولفه ی هماهنگ کننده است، از پورت Driven استفاده می کند. در نهایت، پورت Driven توسط آداپتور Driven پیاده سازی می شود. نتیجه گیری:معماری شش ضلعی یا پورت ها و آداپتورها، گلوله نقره ای برای همه ی برنامه ها نیست. این معماری شامل سطح معینی از پیچیدگی است، که وقتی با دقت از آن استفاده شود، مزایای زیادی برای سیستم شما به همراه خواهد داشت.پورت ها و آداپتورها هنگامی که به درستی پیاده سازی و با سایر متدولوژی ها، مانند Domain-Driven Design، جفت شوند، می توانند پایداری و توسعه پذیری طولانی مدت برنامه را تضمین کنند و ارزش زیادی برای سیستم و سازمان به ارمغان بیاورند.این مطلب یکی از تمرینات درس #معماری_نرم_افزار در #دانشگاه_شهید_بهشتی تهران می باشد. منابع:https://medium.com/ssense-tech/hexagonal-architecture-there-are-always-two-sides-to-every-story-bc0780ed7d9cAlistair Cockburn’s original paper on Hexagonal ArchitectureAwesome read on Domain-Driven Design: Everything You Always Wanted to Know About it, But Were Afraid to AskEric Evans’ Domain-Driven Design: Tackling Complexity in the Heart of SoftwareBob Martin’s OO Design Quality MetricsBob Martin’s Agile Software Development Principles, Patterns and Practices نیوشا شفیعی نیوشا شفیعی Thu, 09 Dec 2021 23:16:10 +0330 https://virgool.io/@m_50577917/%D9%85%D8%AF%D9%84-c4-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%D8%AC%D8%B3%D9%85-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-u0qz8z7zwtht مدل C4 برای تجسم معماری نرم افزاربرای رسیدن به پیشرفت در یک هدف مشخص، یک تیم کاری نیازمند برقراری "ارتباطات خوب و موثر" است. در حیطه­ ی مهندسی نرم افزار مخاطبان و ذی نفعان مختلفی با تمایلات متفاوتی وجود دارد. این ذی نفعان می­توانند افرادی از جمله معماران نرم افزار، توسعه دهندگان، افراد فعال در حوزه­ ی عملیات و پشتیبانی، تسترها، مالک محصول، مدیران پروژه، کاربران، مشتریان، اسکرام مسترها و ... باشند. با وجود چنین ذی نفعان مختلفی، داشتن مجموعه­ ای از انتزاعات نسبت به استفاده از یک Notation رایج، اهمیت بیشتری دارد.یک سیستم نرم افزاری از یک یا چند Container ایجاد شده است که در هر Container یک یا چند Component وجود دارد که هر یک بوسیله ­ی عناصر کد پیاده سازی شده اند. مجموعه­ ی این توضیحات، ما را به سمت شناخت بیشتر مدل C4 سوق می­دهد. پس با ما تا انتهای این مطلب همراه باشید تا با اطلاعات و مثال­ های مختلفی از این مدل آشنا شویم:Context, Containers, Components, and Codeمزایا و کاربرد:مدل C4 رویکردی ساده برای آموزش دیاگرام سازی معماری نرم‌افزار، به توسعه‌دهندگان است. دیاگرام­ های خوب در معماری نرم‌افزار به ارتباطات داخلی یا خارجی تیم‌های توسعه نرم‌افزار یا محصول، استقرار کارآمد کارکنان جدید، بررسی‌ها و ارزیابی‌های معماری، شناسایی ریسک (مثلاً طوفان ریسک)، مدل‌سازی تهدید (مانند STRIDE/LINDDUN) و غیره کمک می‌کنند.مقدمه:اگر از کسی با صنعت ساختمان سر و کار دارد بخواهید که به صورت بصری با معماری یک ساختمان ارتباط برقرار کرده و از آن صحبت کند، نقشه های سایت، پلان های طبقه، نمای ارتفاعات، نماهای مقطعی و نقشه های جزئیات را به شما ارائه می دهد. در مقابل، اگر از یک توسعه‌دهنده نرم‌افزار بخواهید که معماری نرم‌افزار یک سیستم نرم‌افزاری را با استفاده از دیاگرام­ ها به اشتراک بگذارد، احتمالاً با جعبه‌ها و خطوط گیج‌کننده‌ای مواجه خواهید شد... مثل Notation های ناسازگار (کدگذاری رنگی، اشکال، لاین استایل ها و غیره)، نام‌گذاری­ های مبهم، روابط بدون برچسب (Label)، اصطلاحات عمومی، انتخاب‌هایی از تکنولوژی از دست رفته، انتزاعات ترکیبی و غیره. اگر حرف ما را باور ندارید شما را به دیدن چند تصویر بعدی دعوت می­کنم!در بحث نرم افزار به عنوان یک صنعت، ما زبان مدلسازی یکپارچه (UML)، ArchiMate و SysML را داریم، اما این پرسش که آیا این نمودارها راه مؤثری برای برقراری ارتباط با معماری نرم‌افزار ارائه می‌دهند یا خیر اغلب بی پاسخ خواهد بود چرا که بسیاری از تیم‌ها قبلاً آنها را به نفع نمودارهای «جعبه‌ها و خطوط» کنار گذاشته‌اند. کنار گذاشتن زبان‌های مدل‌سازی یک مساله است، و از دست دادن توانایی برقراری ارتباط بصری در رقابت برای چابکی (agility) توسط بسیاری از تیم‌های توسعه نرم‌افزار مساله­ای دیگر.نقشه های کدمدل C4 به عنوان راهی برای کمک به تیم های توسعه نرم افزار در توصیف معماری نرم افزار و برقراری ارتباط، هم در طول جلسات طراحی اولیه و هم هنگام مستندسازی گذشته نگر از یک پایگاه کد موجود، ایجاد شده است. مدل C4 شیوه ­ای برای ایجاد نقشه هایی از کد، در سطوح مختلفی از جزئیات، درست مثل آنچه که ابزاری مانند Google Maps ارائه می­کنند، است. همانطور که احتمالا می­دانید ابزارهای Google Maps قادر هستند با بزرگنمایی منطقه­ ای خاص جزئیات بیشتری را به نمایش بگذارند.نمایی از یک خیابان که توسط Google Maps ارائه شده است. این نما درست مانند کد منبع (source code)، یک نمای بسیار low-level و دقیق از یک مکان را ارائه می دهد.اگر روی تصویر زوم کنید، پیمایش در یک محیط نا مشخص، آسان تر می شود.اگر کمی زوم تصویر را کم کنیم، زمینه دیگری فراهم می شود که ممکن است از آن بی اطلاع باشید.سطوح مختلف زوم به شما این امکان را می دهد که داستان های مختلفی را برای مخاطبان مختلف تعریف کنید.اگرچه مدل C4 در درجه اول معماران و توسعه دهندگان نرم افزار را مورد هدف قرار می­دهد، با این حال این مدل امکانی را برای تیم‌های توسعه نرم‌افزار فراهم می‌کند تا به طور کارآمد و مؤثر معماری نرم‌افزار خود را در سطوح مختلفی از جزئیات، ارائه­ ی داستان‌های مختلف برای انواع مختلفی از مخاطبان، هنگام انجام طراحی قبلی یا مستندسازی گذشته‌نگر یک پایگاه کد موجود، به اشتراک بگذارند.سطح 1: نمودار زمینه سیستم (System Context)، نقطه شروعی را ارائه می‌کند، که نشان می‌دهد چگونه سیستم نرم‌افزاری از نظر وسعت با دنیای اطرافش تناسب دارد.سطح 2: Container diagram سیستم نرم افزاری را بزرگنمایی می کند و سازه بلوک های فنی سطح بالا (high-level) را نشان می دهد.سطح 3: Component diagram در یک Container جداگانه زوم می کند و مولفه­ های داخل آن را نشان می دهد.سطح 4: نمودار کد (مثلاً کلاس UML) را می توان برای بزرگنمایی یک مؤلفه جداگانه به کار برد و نحوه پیاده سازی آن مؤلفه را نشان داد.سطوح مختلف بزرگنمایی به شما این امکان را می دهد که داستان های مختلفی را برای مخاطبان مختلف تعریف کنید. مدل C4 یک رویکرد "اول انتزاعی" (abstraction-first) برای نمودارسازی معماری نرم افزار است. این مدل بر اساس آن دسته از انتزاع هایی است که نشان می دهد معماران و توسعه دهندگان نرم افزار چگونه در مورد نرم افزار فکر می کنند و آن را می سازند. مجموعه کوچکی از انتزاعات و انواع نمودارها، یادگیری و استفاده از مدل C4 را ساده می کند. لطفاً توجه داشته باشید که نیازی به استفاده از هر 4 سطح دیاگرام نیست بلکه فقط دیاگرام­هایی که ارزشی را اضافه می کنند - نمودارهای System Context و Container برای بسیاری از تیم های توسعه نرم افزار کافی است.انتزاعاتبرای ایجاد نقشه‌هایی از کد، ابتدا به مجموعه‌ای از انتزاعات مشترک به منظور ایجاد زبانی فراگیر که بتوانیم از آن برای توصیف ساختار ایستا یک سیستم نرم‌افزاری استفاده کنیم، نیاز داریم. مدل C4 ساختارهای ایستا یک سیستم نرم افزاری را از نظر containerها ، componentها و code در نظر می گیرد. و مردم از سیستم های نرم افزاری که ما می سازیم استفاده می کنند.یک سیستم نرم افزاری از یک یا چند container (برنامه های کاربردی وب، برنامه های تلفن همراه، برنامه های کاربردی دسکتاپ، پایگاه های داده، سیستم های فایل و غیره) تشکیل شده است که هر کدام شامل یک یا چند مولفه هستند که به نوبه خود توسط یک یا چند عنصر کد (مانند کلاس ها، رابط ها، اشیاء، توابع و غیره) پیاده سازی می شوند.Personیک person نمایانگر یکی از کاربران انسانی سیستم نرم افزاری شما (به عنوان مثال بازیگران، نقش ها، شخصیت ها و غیره) است.Software System (سیستم نرم افزاری)یک سیستم نرم‌افزاری بالاترین سطح از انتزاع است و توصیف کننده ­ی ارزشی است که به کاربران خود، چه انسان باشند یا نه، ارائه می‌کند. این سیستم، شامل سیستم نرم افزاری است که مدل سازی می کنید و همچنین سایر سیستم های نرم افزاری که سیستم نرم افزاری شما به آنها وابسته است (یا برعکس). در بسیاری از موارد، یک سیستم نرم افزاری متعلق به یک تیم توسعه نرم افزار می­باشد.Container (applications and data stores)در مدل C4، یک Container ، یک application یا یک data store را نشان می دهد. Container باید در حال اجرا باشد تا کل سیستم نرم افزاری کار کند. در شرایط واقعی، یک Container شبیه به موارد زیر است:· برنامه وب سرویس سمت سرور (Server-side web application): برنامه وب Java EE که روی Apache Tomcat اجرا می شود، برنامه ASP.NET MVC که روی Microsoft IIS اجرا می شود، برنامه Ruby on Rails که روی WEBrick اجرا می شود، برنامه Node.js و غیره.· برنامه وب سمت کلاینت (Client-side web application): برنامه جاوا اسکریپت که در یک مرورگر وب با استفاده از Angular، Backbone.JS، jQuery و غیره اجرا می شود.· اپلیکیشن دسکتاپ سمت کلاینت (Client-side desktop application): برنامه دسکتاپ ویندوز که با استفاده از WPF نوشته شده است، برنامه دسکتاپ OS X که با استفاده از Objective-C نوشته شده است، برنامه دسکتاپ cross-platform که با استفاده از JavaFX نوشته شده است و غیره.· اپلیکیشن موبایل (Mobile app): برنامه Apple iOS، یک برنامه اندروید، برنامه Microsoft Windows Phone و غیره.· برنامه کنسول سمت سرور(Server-side console application):A standalone (e.g. "public static void main") application، فرآیند دسته ای و غیره.· تابع بدون سرور (Serverless function): یک تابع بدون سرور واحد (مانند Amazon Lambda، Azure Function و غیره).· پایگاه داده (Database): اسکیمای (schema) یا پایگاه داده در یک سیستم مدیریت پایگاه داده رابطه ای، ذخیره اسناد، پایگاه داده گراف و غیره مانند MySQL، Microsoft SQL Server، Oracle Database، MongoDB، Riak، Cassandra، Neo4j و غیره.·حباب یا Blob or content store: یک blob store (مانند Amazon S3، Microsoft Azure Blob Storage، و غیره) یا شبکه تحویل محتوا (مانند Akamai، Amazon CloudFront و غیره).· فایل سیستم: یک File system محلی کامل یا بخشی از یک File system شبکه بزرگتر (مانند SAN، NAS، و غیره).اسکریپت پوسته (Shell script): یک اسکریپت تک پوسته نوشته شده در Bash و غیره.· وغیرهیک container در اصل یک زمینه یا مرز است که در داخل آن برخی از کدها اجرا شده یا برخی از داده ها ذخیره می شوند. هر container یک شی یا محیط runtime مجزای قابل استقرار یا قابل اجرا است که معمولاً (اما نه همیشه) در فضای فرآیند خود اجرا می شود. به همین دلیل، ارتباط بین container ها معمولاً به صورت ارتباط بین فرآیندی است.مولفه (Component):کلمه "کامپوننت" یک اصطلاح بسیار پرکاربرد در صنعت توسعه نرم افزار است، اما در این مطلب، یک مولفه مجموعه ای از عملکردهای مرتبط است که در پشت یک رابط به خوبی تعریف شده، محصورسازی شده است. اگر از زبانی مانند جاوا یا سی شارپ استفاده می کنید، ساده ترین راه برای فکر کردن به یک کامپوننت مجموعه ­ای از کلاس های پیاده سازی در پشت یک رابط می­باشد. جنبه‌هایی مانند نحوه ­ی پکیج بندی مؤلفه‌ها (مثلاً یک مؤلفه در مقابل بسیاری از مؤلفه‌ها در هر فایل JAR، DLL، کتابخانه مشترک و غیره) یک دغدغه ­ی مجزا و متعامد است. نکته مهمی که در اینجا باید به آن توجه کرد این است که همه اجزای داخل یک container معمولاً در یک فضای پردازش یکسان اجرا می شوند. در مدل C4، مولفه­ ها واحدهای قابل استقرار مجزایی نیستند.دیاگرام ­های اصلی (Core diagrams)تجسم چنین سلسله مراتبی از انتزاعات با ایجاد مجموعه ای از نمودارهای Context ، Container ، Component و (به صورت اختیاری) Code (به عنوان مثال کلاس UML) صورت می­گیرد. به همین دلیل این مدل C4 نام گرفته است.سطح 1: System Context diagramدیاگرام Context سیستم نقطه شروع خوبی برای ترسیم دیاگرام و مستندسازی یک سیستم نرم افزاری است و به شما این امکان را می دهد که به عقب برگردید و تصویر بزرگتر را هم ببینید. این دیاگرام باید به گونه ای ترسیم شود که سیستم شما را به صورت جعبه ای در مرکز که توسط کاربران و سایر سیستم هایی که با آنها در تعامل می­باشد، احاطه کند.جزئیات در این دیاگرام اهمیتی ندارد زیرا این دیاگرام تصویر بزرگ شده ای است که چشم انداز سیستم را نشان می دهد. در این دیاگرام تمرکز باید بر روی افراد (بازیگران، نقش ها، شخصیت ها و غیره) و سیستم های نرم افزاری باشد تا فناوری ها، پروتکل ها و سایر جزئیات سطح پایین (low level). دیاگرام Context سیستم نموداری است که می توانید به افراد غیر فنی نیز ارائه دهید.محدوده: یک سیستم نرم افزاری واحد.عناصر اولیه: سیستم نرم افزاری در محدوده.عناصر پشتیبان: افراد (به عنوان مثال کاربران، بازیگران، نقش‌ها یا شخصیت‌ها) و سیستم‌های نرم‌افزاری (وابستگی‌های خارجی) که به طور مستقیم به سیستم نرم‌افزاری از نظر محدوده متصل هستند. معمولاً سیستم‌های نرم‌افزاری دیگر خارج از محدوده یا مرز سیستم نرم‌افزاری شما قرار دارند و مسئولیت یا مالکیت آنها با شما نیست.مخاطبان از پیش تعیین شده: همه افراد، اعم از افراد فنی و غیر فنی، در داخل و خارج از تیم توسعه نرم افزار.برای اکثر تیم ها توصیه می شود: بله.سطح 2: Container diagramهنگامی که متوجه شدید که سیستم شما چگونه با کل محیط IT تطابق دارد، گام مفید بعدی این است که به وسیله­ی نمودار Container، مرز سیستم را بزرگنمایی کنید. یک " Container" چیزی مانند یک برنامه وب سمت سرور، برنامه تک صفحه ای، برنامه دسکتاپ، برنامه تلفن همراه، اسکیمای پایگاه داده، سیستم فایل و غیره است. اساساً یک Container یک واحد قابل اجرا یا قابل استقرار جداگانه می­باشد (به عنوان مثال یک فضای پردازش جداگانه) که کد را اجرا می کند یا داده ها را ذخیره می کند. دیاگرام Container شکل سطح بالایی (high-level) از معماری نرم افزار و نحوه توزیع مسئولیت ها در آن را نشان می دهد. همچنین انتخاب های اصلی تکنولوژی و نحوه ارتباط Container ها با یکدیگر را نشان می دهد. Container یک دیاگرام ساده و متمرکز بر فناوری سطح بالا است که برای توسعه دهندگان نرم افزار و کارکنان پشتیبانی/عملیات به طور یکسان مفید می باشد. محدوده: یک سیستم نرم افزاری واحد.عناصر اولیه: Container درون سیستم نرم افزار در محدوده.عناصر پشتیبانی: افراد و سیستم های نرم افزاری به طور مستقیم به Container ها متصل می شوند.مخاطبان از پیش تعیین شده: افراد فنی داخل و خارج از تیم توسعه نرم افزار. از جمله معماران نرم افزار، توسعه دهندگان و کارکنان عملیات/پشتیبانی.برای اکثر تیم ها توصیه می شود: بله.نکته: این نمودار چیزی در مورد سناریوهای استقرار، خوشه بندی، تکرار، شکست و غیره نمی گوید.سطح 3: نمودار مؤلفه (Component diagram)در مرحله بعد می‌توانید در هر Container زوم کرده و آن را بیشتر تجزیه کنید تا سازه بلوک های اصلی و تعاملات آن‌ها را شناسایی نمایید. نمودار کامپوننت نشان می دهد که چگونه یک Container از تعدادی "مولفه" تشکیل شده است، هر یک از آن مولفه­ ها چه چیزی هستند و مسئولیت های آنها و جزئیات تکنولوژی یا اجرای آنها چگونه می­باشد.محدوده: یک Container واحد.عناصر اولیه: مولفه­های درون Container در محدوده.عناصر پشتیبان: Container ها (در محدوده سیستم نرم افزاری) به اضافه­ی افراد و سیستم های نرم افزاری که مستقیماً به مولفه­ها متصل هستند.مخاطبان از پیش تعیین شده: معماران و توسعه دهندگان نرم افزار.برای اکثر تیم‌ها توصیه می‌شود: خیر، فقط در صورتی که احساس می‌کنید دیاگرام­های مولفه ارزش افزوده دارند، آنها را ایجاد کنید و ایجاد خودکار آن‌ها را برای مستندسازی طولانی‌مدت در نظر بگیرید.سطح 4: کد (Code)در نهایت، می‌توانید روی هر کامپوننت زوم کنید تا نحوه پیاده‌سازی آن را به صورت کد با استفاده از دیاگرام­ های کلاس UML، دیاگرام­ های رابطه­­ای موجودیت یا موارد مشابه. ببینید. کد یک سطح اختیاری از جزئیات است و اغلب بر اساس درخواست ابزارهایی مانند IDE در دسترس می­باشد. در حالت ایده آل، این نمودار به طور خودکار با استفاده از ابزار (به عنوان مثال یک ابزار مدل سازی IDE یا UML) تولید می شود. باید در نظر داشته باشید که فقط آن دسته از ویژگی ها و روش هایی را نشان دهید که به شما امکان می دهد داستانی را که قصد دارید بیان کنید را شرح دهید. این سطح از جزئیات برای هیچ چیز به غیر از مهم ترین یا پیچیده ترین مولفه­ ها توصیه نمی شود.محدوده: یک کامپوننت واحدعناصر اولیه: عناصر کد (مانند کلاس ها، رابط ها، اشیاء، توابع، جداول پایگاه داده و غیره) درون کامپوننت موجود در محدوده.مخاطب از پیش تعیین شده: معماران و توسعه دهندگان نرم افزار.برای اکثر تیم ها توصیه می شود: خیر، برای اسناد طولانی مدت، اکثر IDE ها می توانند این سطح از جزئیات را در صورت تقاضا ایجاد کنند.برای شفافیت بیشتر در ارتباط با آنچه که گفته شد، در ادامه به بررسی مثالی از یک سیستم بانکداری فرضی می­ پردازیم:سطح 1: این مثال بیانگر یک نمونه System Context diagram برای یک سیستم بانکداری اینترنتی فرضی است و افرادی که از آن استفاده می کنند و همچنین سایر سیستم های نرم افزاری که سیستم بانکداری اینترنتی با آنها ارتباط دارد را نشان می دهد. مشتریان بانک از سامانه بانکداری اینترنتی برای مشاهده اطلاعات حساب های بانکی خود و انجام پرداخت ها استفاده می کنند. خود سیستم بانکداری اینترنتی از سیستم بانکداری مرکزی موجود (Mainframe Banking System) بانک برای انجام این کار بهره می­برند و از سیستم ایمیل بانک برای ارسال ایمیل به مشتریان استفاده می نمایند.نمایش مرز سازمان: در این مثال، خط چین مرز بانک را نشان می‌دهد و برای نشان دادن آنچه در داخل و خارج از بانک است استفاده می‌شود. سطح 2: دیاگرام Containerاین سطح شامل یک نمونه دیاگرام Container برای یک سیستم بانکداری اینترنتی فرضی است که نشان می دهد سیستم بانکداری اینترنتی (جعبه خط چین دار) از پنج Container تشکیل شده است: یک برنامه وب سمت سرور (a server-side Web Application)، یک برنامه کاربردی تک صفحه ای (a Single-Page Application)، یک برنامه موبایل(a Mobile App)، یک برنامه API سمت سرور (a server-side API Application) و یک پایگاه داده (Database). Web Application یک برنامه وب Java/Spring MVC است که به سادگی محتوای استاتیک (HTML، CSS و جاوا اسکریپت)، از جمله محتوایی که برنامه تک صفحه ای را تشکیل می دهد را ارائه می کند. اپلیکیشن Single-Page یک برنامه Angular است که در مرورگر وب مشتری اجرا می شود و تمام ویژگی های بانکداری اینترنتی را ارائه می دهد. از طرف دیگر، مشتریان می‌توانند از اپلیکیشن موبایل Xamarin برای دسترسی به زیرمجموعه‌ای از functionality بانکداری اینترنتی استفاده کنند.هم اپلیکیشن Single-Page و هم اپلیکیشن موبایل از یک API JSON/HTTPS استفاده می کنند که توسط برنامه Java/Spring MVC دیگری که روی سرور اجرا می شود ارائه می شود. برنامه API اطلاعات کاربر را از پایگاه داده (اسکیمای یک پایگاه داده رابطه ای) دریافت می کند. برنامه API همچنین با استفاده از رابط اختصاصی XML/HTTPS با سیستم بانکداری اصلی (Mainframe Banking System) موجود ارتباط برقرار می‌کند تا اطلاعاتی در مورد حساب‌های بانکی دریافت کند یا به انجام تراکنش‌ها بپردازد. API Application همچنین در صورت نیاز به ارسال ایمیل به مشتریان از سیستم ایمیل موجود استفاده می کند.ن نشان دهنده مرز سیستم بانکداری اینترنتی است که کانتینر (آبی روشن) داخل آن را نشان می دهد. همچنین از یک شکل استوانه ای برای نشان دادن پایگاه داده استفاده شده است.سطح 3: نمودار مؤلفه (Component diagram)شکل زیر نمونه ای از نمودار مؤلفه برای یک سیستم بانکداری اینترنتی فرضی است که فقط برخی از (به جای همه) مولفه­ های داخل برنامه API را نشان می دهد. در اینجا، سه Spring MVC Rest Controller وجود دارد که نقاط دسترسی را برای JSON/HTTPS API فراهم می‌کند و به وسیله ­ی هر کنترل‌کننده متعاقباً از مولفه­ های دیگر برای دسترسی به داده‌های پایگاه داده و سیستم بانکی مرکزی (Mainframe Banking System) یا ارسال ایمیل استفاده می‌کند.خط چین نشان دهنده مرز API Application است که مولفه ­های داخل آن (آبی روشن) را نشان می دهد. سطح 4: کدشکل زیر یک نمونه­ ی جزئی از نمودار کلاس UML برای یک سیستم بانکداری اینترنتی فرضی به همراه عناصر کد (رابط ها و کلاس ها) را نشان می دهد که مؤلفه ­ی نمای بیروی سیستم بانکی مرکزی (Mainframe Banking System) را ایجاد می­کند. این شکل نشان می دهد که کامپوننت از تعدادی کلاس تشکیل شده است که جزئیات پیاده سازی کد را به صورت مستقیم منعکس می کند.این مطلب بخشی از تمرین­های درس #معماری_نرم‌افزار_در_دانشگاه_شهیدبهشتی است که امید داریم برای شما موثر واقع شده باشد.#معماری_نرم‌افزار_بهشتی نیوشا شفیعی نیوشا شفیعی Fri, 19 Nov 2021 18:39:54 +0330