<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های محمد ربانی بیدگلی</title>
        <link>https://virgool.io/feed/@rabbani_mohammad</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-06-16 16:02:16</pubDate>
        <image>
            <url>https://static.virgool.io/images/default-avatar.jpg</url>
            <title>محمد ربانی بیدگلی</title>
            <link>https://virgool.io/@rabbani_mohammad</link>
        </image>

                    <item>
                <title>معماری در ERP مبتنی بر وب و سرویس در فضای ابر</title>
                <link>https://virgool.io/@rabbani_mohammad/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%AF%D8%B1-erp-%D9%85%D8%A8%D8%AA%D9%86%DB%8C-%D8%A8%D8%B1-%D9%88%D8%A8-%D9%88-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D8%AF%D8%B1-%D9%81%D8%B6%D8%A7%DB%8C-%D8%A7%D8%A8%D8%B1-x5sqheasln2t</link>
                <description>چکیدهبرنامه‌ریزی منابع سازمانی (ERP) یکی از مهم‌ترین سیستم‌هایی است که سازمان‌های کوچک و بزرگ از مدت‌ها پیش آن را در سازمان خود پیاده‌سازی کرده‌اند یا به دنبال پیاده‌سازی آن هستند. ERP یک سیستم نرم‌افزاری است و در هنگام انتخاب و پیاده‌سازی آن به یکی از مواردی که باید توجه کرد نوع معماری و ساختار سیستم است. امروزه با توجه به وجود فضای ‌ابری و سرویس‌هایی که در اختیار کاربران قرار می‌دهد‌، سیستم‌های ERP به گونه‌ای پیاده‌سازی می‌شوند که معماری آن‌ها سازگار با فضای ابری باشد و شرکت‌هایی که به تازگی می‌خواهند از ERP استفاده کنند می‌توانند از این نوع سیستم خریداری نمایند. اما سازمان‌هایی که در گذشته نسخه‌های قدیمی یک سیستم ERP مبتنی بر وب یا سرویس را خریداری و درون سازمان خود مستقر کردند برای آن که بتوانند از فضای ابری و امکانات آن بهره ببرد باید با استفاده از روش‌های مهاجرت برنامه‌ها به فضای ابر سیستم خود را به فضای ابر منتقل نمایند تا بتوانند از برخی امکانات آن استفاده کنند. روش‌های مهاجرتی، روش‌هایی هستند که به کمک آن‌ها می‌توان برنامه‌هایی که در فضای ابری مستقر نیستند و امکان استفاده از سرویس‌های ابری را ندارند به فضای ابری برد. در این مقاله هدف توضیح این روش‌ها و بررسی موردی سازمان‌هایی است که با موفقیت توانستند سیستم ERP مبتنی بر وب یا سرویس خود را با روش‌های مهاجرتی به فضای ابری منتقل کنند.مقدمهامروزه بسیار از شرکت‌ها برای کنترل و مدیریت فرایندهای خود و دسترسی به اطلاعات متمرکز به سمت استفاده از سیستم‌های برنامه‌زیری منابع سازمانی (Enterprise Resource Planning (ERP)) می‌روند. سیستم ERP را از سه دیدگاه مدیریتی، نرم‌افزاری و عملیاتی می‌توان تعریف و بررسی کرد. در این تحقیق هدف بررسی این سیستم از دید نرم‌افزاری است و معماری و زیرساخت این سیستم بررسی می‌شود. از دید نرم‌افزاری ERP یک مجموعه‌ای از ماژول‌های یکپارچه‌ی آماده راه‌اندازی از پیش طراحی شده و از پیش مهندسی شده است که تمام فرایندهای کسب و کار را پوشش می‌دهد. هر سیستم نرم‌افزاری نیز از یک معماری مشخصی پیروی می‌کند و برپایه‌ی آن توسعه می‌یابد. برای سامانه‌های ERP نیز معماری‌هایی ارائه شده است که هر سازمانی می‌تواند متناسب با نیازهایی که دارد از آن‌ها استفاده کند. از جمله نیازهای تعیین کننده در انتخاب معماری، استفاده از فناوری‌های موجود است و سازمان باید زمینه را برای استفاده از آن فناوری خاص فراهم نماید. یکی از فناوری‌های مهمی که نظرات را به سمت خود جلب کرده است و بسیاری ترقیب شده‌اند که به سمت آن بروند، محاسبات و فضای ابری است. فضای ابری این امکان را فراهم می‌کند افراد و سازمان‌ها بتوانند دسترسی آسان و نامحدودی به مجموعه‌ی مشترکی از منابع محاسباتی داشته باشند. فضای ابری برای سازمان‌ها مزایا بسیاری به همراه دارد و به کمک آن شرکت‌های ارائه دهنده‌ی فضای ابر می‌توانند در سه سطح زیرساخت، سکو و نرم‌افزار سرویس ارائه دهند و همچنین این فناوری سبب می‌شود تا در منابع مالی و انسانی و زمان سازمان‌ها صرفه جویی شود و برای سازمان‌های کوچک و متوسط (Small and Mudium Enterprises(SME)) استفاده از این فناوری بصرفه خواهد بود. بنابراین بسیاری از سازمان‌هایی که می‌خواهند از ERP استفاده کنند یا از آن در حال استفاده هستند به سمت فضای ابری باید بروند. برای آن‌که یک سازمان بتواند از فضای ابری و امکاناتی که دارد استفاده نماید باید یک معماری را استفاده کند که در آن اجزای تشکیل‌دهنده‌ی سیستم ERP امکان استفاده از آن را فراهم نماید. بسیاری از شرکت‌ها که از ERP استفاده می‌کنند معماری آن‌ سیستم‌ها مبتنی بر وب یا سرویس‌ است و در خود سازمان به صورت محیطی (in-house) بنا شده‌اند و برای آن که بتوانند از فضای ابری استفاده نمایند باید کارهایی انجام دهند. در این تحقیق هدف بررسی راه‌ حل‌های موجود برای سیستم‌های ERP مبتنی بر وب و سرویس‌ است تا بتوانند از امکانات فضای ابری استفاده کنند.ساختار این تحقیق به این صورت است: در بخش دو به معرفی و معماری‌های رایج سیستم‌های ERP پرداخته می‌شود. در بخش سه فضای ابر توضیح داده می‌شود تا با امکانات و مزایای آن و دلیل رفتن بسیاری از سازمان‌ها سمت آن مشخص شود. سپس در بخش چهار راه‌ حل‌های موجود برای آن که بتوان سیستم‌های ERP مبتنی بر وب و سرویس را جهت استفاده از امکانات فضای ابری آماده کرد، معرفی و بررسی می‌گردند. در بخش پنج به بررسی چند مورد از سازمان‌ها پرداخته می‌شود که توانستند با موفقیت سیستم ERP خود که مبتنی بر وب یا سرویس بود را در فضای ابر مستقر نمایند. همچنین در این بخش نگاهی به یکی از شرکت‌های ارائه‌ دهنده‌ی سیستم ERP در ایران پرداخته می‌شود تا با سرویس ERP ابری که در اختیار کاربران می‌گذار و سازمان‌هایی که به سمت این سیستم مهاجرت کردند آشنا شویم. در بخش شش نیز به جمع بندی و نتیجه‌ی حاصل از این تحقیق پرداخته می‌شود.معماری‌های رایج در سیستم‌های ERPدر هر سیستم نرم‌افزاری معماری یکی از مهم‌ترین کارهایی است که باید در همان ابتدای پیاده‌سازی برنامه انجام شود تا زیرساخت و اساس آن سیستم به درستی ایجاد شود و نیازهای مورد انتظار از آن سیستم را بتوان سازمانی دهی کرد. درواقع معماری در یک سیستم نر‌م‌افزاری یک دید کلی نسبت به آن سیستم و شناسایی اجزای تشکیل دهنده‌، ارتباط میان آن اجزا و انتخاب فناوری‌های لازم است. در یک سیستم ERP اجزای تشکیل دهنده آن می‌تواند واسط‌های کاربری، پایگاه داده جهت ذخیره سازی اطلاعات، نحوه‌ی ذخیره‌ی اطلاعات، شبکه‌ ارتباطی و غیره دانست. معماری در سیستم ERP به ما کمک می‌کند تا تیم‌های پیاده‌سازی و مدیریت بتوانند پیچیدگی و اجزای سیستم سازمان را بفهمند، تصویری روشنی از واسط‌های پیچیده در مورد پایگاه‌های داده،‌ سیستم‌های عامل، شبکه و برنامه‌های ERPارائه می‌دهد و باعث توسعه‌ی بهتر برنامه‌ی فناوری اطلاعات توسط تیم مدیریت در صورت شفاف بودن نیازمندی‌های فرایندی و ساختاری می‌شود. در ادامه به بررسی معماری‌های رایجی پرداخته می‌شود که در سیستم‌های ERPمورد استفاده قرار می‌گیرد[1].معماری سه لایهمعماری سه لایه یکی از ابتدایی‌ترین معماری‌های معرفی شده برای سیستم‌های ERP است. این معماری تعمیم یافته‌ی معماری دو لایه و یک لایه است. در معماری یک لایه از مدل یکپارچه (Monolith) استفاده شده است و تمام سیستم را به صورت یک بخش در نظر گرفته است. در این معماری اطلاعات نیز برروی یک سرور فایل مرکزی ذخیره می‌شد. در معماری دو لایه، معماری از حالت یکپارچه خارج می‌شود و عملکرد سیستم به دو لایه‌ی پایگاه داده (یا به اختصار داده) و مشتری تقسیم می‌شود. به لایه‌ی مشتری، لایه‌ی نمایش نیز گفته می‌شود. از خوبی‌های این معماری آن است که بروزرسانی و دسترسی به داده راحت‌تر انجام می‌شود اما بروزرسانی منطق برنامه و توسعه‌ی آن دشوار است و تغییرات برروی تمام سیستم‌ کاربران به صورت تکی باید انجام شود. بنابراین به سراغ معماری سه لایه رفتند و میان لایه‌ی داده و نمایش یک لایه‌ی دیگر به نام حرفه اضافه شد. در لایه‌ی حرفه درواقع منطق برنامه و کسب و کار و در لایه‌ی نمایش تنها ظاهر برنامه است و اطلاعات به مشتری نمایش داده و دریافت می‌شود و عملیات و پردازش‌های برنامه در لایه‌ی منطق انجام می‌شود. همچنین لایه‌ی منطق داده‌های مورد نیاز برای پردازش را از لایه‌ی داده می‌گیرد و در آن‌جا نیز داده‌ها را ذخیره می‌کند. از مزایای این معماری می‌توان به افزایش مقیاس‌پذیری، امنیت و اطمینان‌پذیری، نگهداری راحت‌تر از نرم‌افزار اشاره کرد. هنگامی که برنامه دچار تغییر می‌شود تنها کافی است که تغییرات انجام شده در لایه‌ی منطق پیاده‌سازی شوند و دیگر نیازی نیست که به سراغ تمام سیستم‌های کاربران موجود در سازمان رفت. اما در این معماری به منابع زیاد، چه مالی و چه انسانی، نیاز است، محیط توسعه‌ی پیچیده‌ای دارد و امکان ارتباط با جهان بیرون سازمان را نیز فراهم نمی‌کند. در تصویر ۱ سه معماری ذکر شده و تفاوت میانشان نشان داده شده است.تصویر ۱- معماری یک لایه، دو لایه و سه لایهمعماری مبتنی بر وبمعماری مبتنی بر وب به درواقع می‌توان گفت که توسعه‌یافته‌ی معماری سه لایه‌ است تا یکی از ضعف‌های این معماری را برطرف نماید. در این معماری دو لایه‌ی داده و منطق همانند معماری سه لایه وجود دارد. اما لایه‌‌ی نمایش، همان گونه که در تصویر ۲ نشان داده‌ شده است، خود به دو بخش تقسیم می‌شود، سرویس‌های وب و مرورگر وب. این تقسیم بندی به منظور آن است تا کاربران از دستگاه‌های مختلف بتوانند از مکان‌های مختلفی در خارج از سازمان به سیستم ERP دسترسی داشته باشند. در این معماری ارتباط میان مشتری و لایه‌ی منطق از طریق سرویس‌های وب موجود در لایه‌ی نمایش صورت می‌گیرد. هدف از این معماری آن است که به کاربران اجازه دهد تا بتوانند از راه دور و بدون حضور در سازمان به سیستم ERP دسترسی داشته باشند و بدین صورت یکی از ضعف‌های معماری سه لایه که همان ارتباط با جهان بیرون بود را برطرف نماید. دسترسی راحت به اطلاعات، اختلال کمتر برای عملیات کسب و کار، یکپارچه‌سازی راحت می‌توانند از جمله مزایای این معماری باشند.  همچنین در این معماری امکان استفاده از منابع خارج سازمان نیز فراهم می‌شود. به عنوان یک سازمان فضا و نیروی‌ لازم جهت توسعه‌ی زیرساخت و افزودن سرور وجود ندارد‌، به همین جهت سازمان می‌تواند از یک شرکت ارائه دهنده‌ی خدمات شبکه و میزبان استفاده کند و در مراکز داده‌ی آن‌ شرکت سرورهای خود را قرار دهد. در کنار این مزیت‌ها، این معماری معایبی مانند وابسته بودن به پروتکل و استاندارهای‌ وب و افزایش پیچیدگی در فرایند توسعه نیز می‌توانند را به همراه دارد.تصویر ۲- معماری مبتنی بر اینترنتمعماری مبتنی بر سرویس معماری مبتنی بر سرویس روشی است که در آن هر خدمتی که توسط سیستم ارائه داده می‌شود به عنوان یک سرویس در نظر گرفته می‌شود. منظور از سرویس‌ها، اجزای کوچکی هستند که هر کدام یک وظیفه را برعهده دارند درون خود یک عملکرد کامل حرفه را دارند. همچنین سرویس‌ها می‌توانند به طور غیرمستقیم با هم در ارتباط باشند و تشکیل یک سیستم بزرگ‌تر را بدهند. اجزا نیز اتصال سست با یکدیگر دارند و ارتباط میان آن‌ها از طریق پروتکل‌ها استاندارد صورت می‌گیرد[2].تصویر ۳- عملکرد معماری مبتنی بر سرویسشیوه عملکرد این معماری به صورت درخواست و پاسخ است. در تصویر ۳ مشتری یک سرویسی را درخواست می‌دهد و سرویس دهنده به آن درخواست پاسخ مناسب را برمی‌گرداند. شیوه‌ی ارسال درخواست به  این صورت است که گیرنده درخواست خود را ابتدا به یک درگاه از طریق سرویس‌های وب ارسال می‌کند. سپس آن درگاه بررسی می‌کند که آیا درخواست ارسال شده قانونی و ارائه دهنده‌ی چنین سرویس درخواستی وجود دارد. در صورتی که درخواست قانونی و ارائه دهنده نیز وجود داشته باشد آنگاه درخواست به سمت سرویس مورد نظر ارسال می‌گردد و ارائه‌ دهنده نیز پس از انجام عملیات و پردازش‌های لازم پاسخ مناسب را به درگاه و آن نیز پاسخ را به گیرنده ارسال می‌کند.  در این معماری گذرگاه سرویس سازمان (Enterprise Service Bus(ESB)) به عنوان درگاه تبادل داده نقش بسیار مهمی را ایفا می‌کند، به گونه‌ای که اگر وجود نداشته باشد دیگر به این معماری، یک معماری مبتنی بر سرویس نمی‌توان گفت. ESB درواقع خود یک معماری و مجموعه‌ای از قوانین و مفاهیم برای یکپارچه‌سازی چندین برنامه با یکدیگر از طریق یک زیرساخت گذرگاه است[3]. ESB امکان انتقال داده در لحظه میان سیستم‌ها را فراهم می‌کند، برای درخواست داده و تحویل آن از برنامه‌های واسط مانند SOAP یا REST استفاده می‌کند، به کمک آن می‌توان متناسب با نیاز ساختار داده‌ها را تغییر داد و دسترسی امن به سرویس‌ها و مسیریابی هوشمند داده میان مسیر‌های مورد نظر را کنترل می‌کند.   در تصاویر ۴ الف و ب کارایی و اهمیت وجود یک ESB نشان داده شده است. در این تصاویر فرض شده است که چند برنامه وجود دارند و نیاز است تا این برنامه‌ها با یکدیگر در ارتباط باشند. هر کدام از این برنامه نیز به صورت همزمان یا در فواصل زمانی کمی با یکدیگر تولید نشدند و با فناوری‌های یکسانی هم ممکن است که توسعه داده نشده باشند. در تصویر ۴-الف این شش برنامه به صورت مستقیم به یکدیگر وصل شده‌اند و ارتباط بسیار پیچیده‌ای میان آن‌ها شکل گرفته است. از طرفی برقراری ارتباط میان این برنامه کار ساده‌ای نیست زیرا ساختار یکسانی ندارند و در هر کدام نیاز به تغییرات بسیاری می‌باشد تا بتوان آن‌ها را با یکدیگر متصل کرد و به یکدیگر شناساند. بنابراین اتصال مستقیم چندین برنامه به یکدیگر کار خوب و منطقی بنظر نمی‌آید. از این رو برای ارتباط میان برنامه‌ها از ESB استفاده می‌کنند. در تصویر ۴-ب نشان داده شده است که ارتباط میان برنامه از طریق ESB بسیار منظم‌ شکل گرفته است و همچنین قابلیت توسعه‌پذیری و نگهداری آن نیز ساده‌تر شده است.تصویر ۴-الف: ارتباط چندین برنامه به طور مستقیم با یکدیگرتصویر ۴-ب: ارتباط چندین برنامه از طریق ESB با یکدیگرگذرگاه سرویس سازمان توسط شرکت‌هایی ارائه می‌شود و سازمان‌ها می‌توانند از این شرکت‌ها خدمات مربوط به ESB را دریافت کنند. از جمله شرکت‌های معروف می‌توان به MuleSoft، Oracel و IBM اشاره کرد.مزایایی که سرویس‌گرایی در ERP ایجاد می‌کند می‌توان به افزایش مقیاس‌پذیری، انعطاف‌پذیری، کاهش هزینه‌ی یکپارچه‌سازی و افزایش قابلیت استفاده‌ی مجدد سرویس‌ها اشاره کرد. همچنین هزینه‌ی بالای پیاده‌سازی و سربار اضافی برای کنترل سرویس‌ها را می‌توان از معایب آن دانست.معماری مبتنی بر ابرمعماری مبتنی بر ابر را می‌توان جدید‌ترین معماری معرفی شده دانست و بسیاری از سازمان‌های ارائه دهنده‌ی ERP امروزه به سمت این معماری رفته‌اند و در کنار ارائه‌ی سیستم‌های مبتنی بر وب و سرویس، حتما یک سیستم ERP مبتنی بر ابر نیز راه ‌اندازی کرده‌اند. در معماری مبتنی بر ابر در محیط سازمان زیرساخت سخت افزاری و نرم‌افزاری دیگر وجود ندارد و تمام بخش‌های مربوط به سیستم ERP برروی بستر شرکت ارائه‌دهنده‌ی خدمات ابری است و سازمان دیگر خود را درگیر راه‌اندازی یک سیستم ERP نمی‌کند و تنها کافی است که اشتراک استفاده از یک برنامه‌ی ERP را بخرد و سپس می‌تواند از هر جا و در هر لحظه از طریق اینترنت به این سیستم دسترسی داشته باشد. مانند تصویر ۵ که کاربران درون سازمان از طریق اینترنت به یک سیستم ERP متصل هستند که تمام زیرساخت آن در خارج از سازمان می‌باشد و توسط یک شرکت ارائه دهنده‌ی سرویس‌های ابری نگهداری می‌گردد. مزایای این معماری افزایش مقیاس‌پذیری، اطمنیان و امنیت، نگهداری راحت‌تر نرم‌افزار و دسترسی راحت به اطلاعات است. اما مالکیت داده و هزینه‌ای که به صورت ماهیانه یا سالیانه باید پرداخت شود را می‌توان جز معایب این نوع معماری دانست. در بخش بعدی به آشنایی با فضای ابری پرداخته می‌شود تا مشاهده شود که چه امکاناتی را در اختیار کاربران می‌گذارد و دلیل رفتن سازمان‌های ارائه‌دهنده و استفاده کننده‌ی ERP به سمت این فناوری مشخص شود.تصویر ۵- معماری مبتنی بر ابرفضای ابریفضای ابری یک مدل برای ایجاد دسترسی همگانی، راحت‌تر و براساس تقاضا به یک مجموعه‌ی مشترکی از منابع محاسباتی قابل تنظیم است. طبق تعریف NISTفضای ابری دارای ۵ مشخصه‌ی اصلی است و در سه سطح سرویس می‌دهد [4]. ۵ مشخصه‌ی اصلی عبارت‌اند از:خود خدمتی مبتنی بر تقاضا: یک مصرف کننده می‌تواند بر حسب تقاضا به خدمات پردازشی بدون نیاز به تعامل با انسان یا تامین کننده، دسترسی داشته باشد دسترسی سریع به شبکه: قابلیت‌های رایانشی برروی شبکه و از طریق سازوکارهای استاندارد دردسترس است. سکو‌های مختلف غیرهمگون از جمله تلفن همراه، تبلت، ایستگاه‌های کاری، لپتاپ‌ها و غیره همگی می‌توانند به این خدمات دسترسی داشته باشند انعطاف‌پذیری سریع: قابلیت‌ها باید به صورت منعطف توسعه یافته و به سرعت براساس تقاضا گسترش یابند یا محدود شوند. از سوی مصرف کننده، قابلیت‌ها نامحدود است به گونه‌ای که براساس تقاضای جدید به سرعت مقیاس‌پذیر و قابل توسعه خواهند بودخدمات اندازه‌گیری شده:‌ سیستم‌های ابری به صورت خودکار منابع را کنترل نموده و بهینه‌سازی می‌کنند. این امکان از طریق اعمال قابلیت‌ اندازه‌گیری میسر می‌شود. مصرف منابع سنجش و پایش می‌شوند تا طرفین اطلاعات شفافی را در این خصوص داشته باشندمخزن منابع: منابعی توسط تامین کننده فراهم می‌شود توسط چندین مصرف کننده براساس مدل‌های مختلف استفاده می‌شوند. این منابع ممکن است فیزیکی یا مجازی باشند و به صورت پویا براساس تقاضای مصرف کنندگان به آن‌ها تخصیص داده می‌شود. در این مدل مصرف کننده هیچ اطلاعاتی در خصوص محل فیزیکی ارائه‌ی خدمت ندارد. به عبارت دیگر خدمات مستقل از محل فیزیکی است و نوعی انتزاع برای مصرف کننده ایجاد می‌شودهمچنین سه سرویس که فضای ابری ارائه می‌دهد عبارت است از: زیرساخت به عنوان سرویس (Infrastructure as a Service (IaaS)): در این نوع سرویس منابع سخت افزاری به صورت مجازی در اختیار سازمان قرار می‌گیرد. در تصویر ۶ نشان داده شده است که در این سطح سرویس‌هایی مانند شبکه، سرور‌ها، مجازی‌سازی و ذخیره‌سازی انجام می‌گیرد.سکو به عنوان سرویس (Platform as a Service (PaaS)): یک چارچوب برای تولید برنامه‌های سفارشی در اختیار توسعه‌دهنده قرار می‌دهد مانند سیستم‌ عامل، میان‌افزارها و امکانات زمان اجرا که در تصویر ۶ نشان داده شده.نرم‌افزار به عنوان سرویس (Software as a Service (SaaS)): در این سطح یک نرم‌افزار ابری که توسط یک شرکت ارائه‌ دهنده‌ی فضای ابری میزبانی می‌شود و کاربران با خرید اشتراک می‌توانند از آن استفاده کنند. در این سطح علاوه بر سرویس‌هایی که در دو سطح قبلی ارائه می‌شود، سرویس‌های مربوط به داده و برنامه‌ها نیز در ارائه می‌گردد. همچنین یک سطح سرویس دیگر نیز به عنوان همه‌ چیز به عنوان سرویس(Anythin as a Service (XaaS)) نیز توسط فضای ابر ارائه می‌شود که در آن تاکید بر ارائه‌ی هر نوع سرویسی بر بستر ابر است مانند: شبکه به عنوان سرویس(Network as a Service (NaaS))، پایگاه داده به عنوان سرویس(Data Base as a Service(DBaaS)).تصویر ۶- سطوح ارائه‌ی سرویس در فضای ابرسازمان‌ها با خرید هر کدام از سه سرویس SaaS، PaaS و IaaS قسمتی از وظایف خود را در بخش مدیریت برنامه، زیرساخت و میان‌افزارها برعهده‌ی ارائه دهندگان سرویس‌های ابری می‌گذارند. در تصویر ۷ نشان‌ داده شده است که اگر یک سیستم به صورت درون سازمانی پیاده‌سازی شود کنترل و مدیریت تمام بخش‌های مختلف آن برعهده‌ی خود سازمان است اما در صورتی که سازمان بخواهد از سطوح سرویس فضای ابری که توسط ارائه دهنده‌ی سرویس ابری ارائه می‌شود استفاده کند آنگاه قسمتی از وظایف خود را به آن‌ها محول می‌کند. به عنوان مثال اگر سازمان از IaaS استفاده کند آنگاه مدیریت قسمت‌های سخت افزاری برعهده‌ی ارائه دهنده‌ی سرویس قرار می‌گیرد. در سطح PaaS کنترل و مدیریت ماشین‌های مجازی و سیستم‌های عامل و میان‌افزارهای برعهده‌ی ارائه دهنده‌ی سرویس است و در نهایت در سطح SaaS نیز تمام قسمت مربوط به یک برنامه به عهده‌ی ارائه دهنده‌ی سرویس قرار می‌گیرد و سازمان تنها انجام تنظیمات و پیکربندی مربوط به برنامه را برعهده دارد.تصویر ۷- سهم سازمان و  ارائه دهندگان سرویس‌های ابری در کنترل و مدیریت بخش‌های مختلف یک سیستمدر فضای ابری با توجه به اینکه یک محیط اشتراکی است و مالکیت داده و زیرساخت مطرح نیست، بنابراین امکان استفاده از فضای ابر برای سازمان‌هایی که اطلاعات مهم و محرمانه‌ای دارند مانند بانک‌ها وجود نخواهد داشت اما به دلیل وجود چنین سازمان‌هایی و اهمیت اطلاعات، برای فضای ابری سطوح دسترسی مختلفی نیز تعریف شده‌ است که شامل سه سطح ابر عمومی، ابر اختصاصی و ابر ترکیبی است.در ابر عمومی منابع ابری به یک شرکت ارائه دهنده‌ی سرویس ابری تعلق دارد و توسط آن‌ها اداره می‌شود و از طریق اینترنت سرویس ابری ارائه می‌شود و تمام سخت‌افزارها، نرم‌افزارها و زیرساخت‌ها توسط شرکت ارائه دهنده‌ی ابر نگهداری و مدیریت می‌گردد. در ابر اختصاصی، منابع ابری به صورت مشخصی فقط توسط یک کسب و کار یا سازمان استفاده می‌شود. ابر اختصاصی به صورت فیزیکی در محیط داخلی سازمان می‌تواند برپا شود یا در یک شرکت جانبی. در ابر اختصاصی سرویس‌ها و زیرساخت‌ها همیشه برروی شبکه‌ی خصوصی نگهداری می‌شود و سخت‌افزارها و نرم‌افزارها نیز مختص یک سازمان است. بنابراین سازمان‌هایی مانند بانک‌ها که با داده‌های با اهمیت و محرمانه‌ای سر و کار دارند می‌توانند از این سطح دسترسی به سرویس استفاده کنند. ابر ترکیبی را نیز می‌توان ترکیبی از دو ابر عمومی و خصوصی دانست. در این سطح از دسترسی سازمان می‌توان یک از یک ابر اختصاصی برای ذخیره داده‌هایی که از اهمیت زیادی دارند استفاده کنند و برای سایر داده‌های کم اهمیت نیز از ابر عمومی. همچنین این سطح، این امکان را فراهم می‌کند تا داده و برنامه‌ها بین این دو محیط جابجا شوند و با هم در ارتباط باشند.بنابراین مزایای فراوانی را فضای ابری می‌توان فراهم کند. از جمله‌ی مزایای آن می‌تواند اشتراک راحت‌تر داده و دسترسی به مخاطبان بیشتری باشد، زیرا دسترسی به اطلاعات و برنامه آسان و سریع است. مزیت دیگر آن کاهش هزینه‌های مالی و صرفه‌جویی در زمان است. برای راه‌اندازی یک برنامه نیاز است که زیرساخت‌های آن‌ را فراهم کرد و نیروی انسانی مورد نیاز را هم استخدام کرد. از این روی دیگر نیاز به صرف زمان و هزینه برای خرید سخت‌افزار مناسب و استخدام نیروی متخصص نیست زیرا تمام خدمات زیرساختی و کاربردی توسط شرکت ارائه دهنده‌ی فضای ابری تامین می‌شود. رشد و توسعه‌ی سریع نیز دیگر مزیت این فناوری به حساب می‌آید که در صورت نیاز به راحتی می‌توان سخت‌افزاری را به سیستم موجود اضافه یا از آن حذف کرد یا نرم‌افزاری را در کمترین زمان بروزرسانی نمود به گونه‌ای که تغییرات اعمال شده برروی سیستم تمام کاربران انجام شود. همچنین منابع سخت‌افزاری و نرم‌افزاری همیشه بروز هستند زیرا بروز بودن آن‌ها یکی از نگرانی و دغدغه‌های اصلی ارائه دهندگان سرویس‌های ابری است و در صورتی عدم بروزرسانی ممکن است که دچار مشکلات امنیتی و خرابی سخت‌افزارها شوند.پس رفتن به سمت فضای ابر را می‌توان یک امر اجتناب ناپذیر دانست. شرکت‌هایی هم که امروزه در حوزه‌ی تولید سیستم ERP فعالیت می‌کنند، ساختار سیستم‌های خود را به گونه‌ای تغییر دادند که امروزه امکان استفاده از فضای ابر را داشته باشند. به عنوان مثال شرکت SAP یکی از محصولات خود که Business Oneنام دارد و بر ترکیب دو معماری مبتنی بر سرویس با سه لایه ایجاد شده بود، نسخه‌ی مبتنی بر ابر آن را نیز تولید کرده است تا سازمان‌هایی که می‌خواهند به تازگی از سیستم‌های ERP و امکانات فضای ابر استفاده کنند محصول Business One مبتنی بر ابر را خریداری نمایند . سازمان‌هایی نیز که از نسخه‌های قدیمی سیستم‌های ERP که مبتنی بر وب یا مبتنی بر سرویس استفاده می‌کنند نیز با توجه به مزایای ذکر شده تصمیم به استفاده از سیستم‌های مبتنی بر فضای ابر شده‌اند اما نمی‌توانند به یکباره تمام سیستم قبلی و اطلاعات موجود برروی آن را کنار گذاشت و از یک سیستم جدید مبتنی بر ابر استفاده کنند. از این رو برخی از شرکت‌های ارائه دهنده‌ی خدمات ERP روش‌هایی را برای استفاده از امکانات فضای ابر به سازمان‌هایی که معماری سیستم‌های ERP آن‌ها مبتنی بر وب یا سرویس است پیشنهاد داده‌اند. در بخش بعد به معرفی روش‌هایی پرداخته می‌شود که این امکان را برای سیستم‌های ERP مبتنی بر وب و سرویس فراهم می‌کنند تا سازمان‌هایی که از این نوع سیستم‌ها استفاده می‌کنند نیز بتوانند از برخی امکانات فضای ابر استفاده نمایند.روش‌های مهاجرت به فضای ابربرای سازمان‌هایی که از سیستم‌های ERP مبتنی بر وب و سرویس‌ استفاده می‌کنند روش‌های مهاجرتی به فضای ابر پیشنهاد شده است که امکان استفاده از برخی امکانات فضای ابر را فراهم می‌سازد. ۶ روش مهاجرت توسط آمازون موسوم به 6Rs معرفی شده است[5]. این ۶ روش برگرفته از مدل 5Rs گروه‌ گارنتر است و عبارت‌اند از [6]:خرید مجدد: به این روش بنداز و بخر هم می‌گویند. در این روش برنامه به طور کلی کنار گذاشته می‌شود و یک نسخه‌ی مبتنی بر ابر آن خریداری می‌گردد. درواقع شما می‌توانید از برنامه مشابه به عنوان یک سرویس ابری به جای استفاده از برنامه‌‌ی سنتی که درون سازمان مستقرر می‌شد استفاده نمایید. از مزایای این روش می‌توان به مهاجرت سریع و آسان به سمت فضای ابر اشاره کرد. به عنوان مثال شرکت‌هایی که از Business Oneقدیمی که مبتنی بر سرویس و معماری سه لایه بود می‌توانند نسخه‌ی جدید آن که مبتنی بر ابر است را خریداری نمایند. چون توسعه‌ دهنده و ارائه دهنده‌ی و این محصول شرکت SAP است می‌تواند داده‌های سازمان را به نسخه‌ی جدید نرم‌افزار منتقل نماید. اما در صورتی این روش کاربرد دارد که شما به زیرساخت‌های قبلی نیازی نداشته باشید. به همین جهت برخی از سازمان‌ها ممکن است به زیرساخت‌های قبلی به دلیل هزینه‌هایی که کرده‌اند یا دلایل امنیتی نیاز داشته باشند به همین جهت روش‌های دیگری مانند میزبانی مجدد، سکوی مجدد و معمارای مجدد ارائه شده است که در ادامه این دو روش نیز معرفی می‌شوند. میزبانی مجدد: این روش به بلند کردن و انتقال دادن نیز معروف است. در میزبانی مجدد برنامه‌ها از محیط داخلی سازمان بدون هیچ تغییری منتقل می‌شود. این روش برای مهاجرت برنامه‌های قدیمی مقیاس بزرگ خوب است و ضمن اینکه ساده‌ترین روش مهاجرت نیز به حساب می‌آید. اما در این روش چون مبتنی بر فضای ابر طراحی نشده است و صرفا برروی فضای ابر قرار می‌گیرد از بسیار امکانات فضای ابری محروم خواهد بود. به عنوان مثال در تصویر ۸ ابتدا معماری اولیه سیستم موجود در سازمان را نشان‌ داده شده است که در محیط داخلی سازمان پیاده‌سازی شده. هنگامی که سازمان تصمیم می‌گیرد که به محیط ابری مهاجرت کند باز همان ساختار حفظ شده و بدون تغییر در فضای ابر مستقر شده است.تصویر ۸- مهاجرت به روش میزبانی مجددسکوی مجدد: این روش به بلند کردن، تعمیر کردن و انتقال دادن معروف می‌باشد و مانند روش میزبانی مجدد است با این تفاوت که در این روش برخی اجزا تغییر می‌کنند و جایگزین می‌شوند تا بتوان از امکانات فضای ابری بیشتر بهره برد. مدت زمان و هزینه‌ی مهاجرت با این روش بیشتر از میزبانی مجدد است و زحمت بیشتری دارد اما این زمینه را می‌توان به کمک این روش فراهم کرد تا از امکانات فضای ابری استفاده کرد. در تصویر ۹ ساختار سیستم ERP موجود پس از مهاجرت به محیط ابری تغییراتی در آن ایجاد شده است. درواقع یک نسخه‌ی مشابه ساختار فعلی ایجاد شده و در کنار ساختار اصلی قرار گرفته تا سیستم بتواند از امکاناتی مانند تعادل بار و پایگاه داده‌ی پشتیبان استفاده کند.تصویر ۹- مهاجرت به روش سکوی مجددبازسازی/معماری مجدد: این روش پرهزینه‌ و زمان‌برترین روش مهاجرت است که در آن تغییرات اساسی و کامل یک برنامه به منظور انطباق آن با فضای ابر انجام می‌گیرد تا برنامه بتواند از تمام امکانات موجود در فضای ابر استفاده کند. درواقع یک بار دیگر برنامه پیاده‌سازی می‌شود و منجر می‌شود تا برنامه به سرویس‌های مستقل شکسته شود. در این روش نیاز است تا ابتدا برنامه‌، میان‌افزار و نیازمندی‌های سیستم ERP و همچنین محصولات، سرویس‌ها و ابزارهای در دسترس از سمت ارائه دهنده‌ی ابر شناسایی و بررسی شوند. درواقع پروژه‌ی مهاجرت با ارزیابی برنامه شروع می‌شود سپس فازهای طراحی، معماری، استقرار و تست از دستورالعمل‌ها و اهداف تعیین شده در ارزیابی پیروی می‌کنند. در تصویر ۱۰ معماری سیستم موجود پس از آن که به فضای ابر مهاجرت کرد دیگر از پایگاه داده‌ی قبلی که یک پایگاه داده‌ی رابطه‌ای بود استفاده نکرد بلکه از سرویس پایگاه داده‌ای که توسط خود ارائه‌ دهنده‌ی فضای ابر ارائه می‌شد استفاده نمود و آن را جایگزین پایگاه داده‌ی قبلی نمود. نکته‌ی دیگری که باید به آن اشاره کرد آن است که این روش زمانی مفید است که سازمان نیاز شدیدی به استفاده از ویژگی‌های فضای ابری احساس نماید.تصویر ۱۰- مهاجرت به روش معماری مجددبازنشستگی و نگهداشت: این دو روش به این منظور با هم ذکر شده‌اند که جزو روش‌های منفعل هستند و در آن‌ها هیچ‌گونه عملیات خاصی جهت بردن برنامه به سمت فضای ابری صورت نمی‌گیرد. برخی برنامه‌ها در زمان مهاجرت ممکن است تکراری به نظر بیایند و اضافه باشند و می‌توان کلا آن برنامه ‌ها را حذف کرد یا یک برنامه دیگر پاسخگوی نیاز سازمان نیست و باید کامل کنار گذاشته شود و اصلاحا آن‌ها را بازنشسته کرد. همچنین برخی سازمان‌ها برای راه‌اندازی برنامه هزینه‌های بسیاری کرده‌اند، از نظر مالی، زمانی، منابع انسانی و زیرساخت یا در صورت مهاجرت مزیت رقابتی که در بازار دارند را از دست خواهند داد، از این رو ممکن است که مهاجرت به فضای ابر برای آن‌ها مفید نباشد و تصمیم به حفظ برنامه‌ و ساختار موجود می‌کنند و اصطلاحا از آن‌ برنامه نگهداری می‌کنند. بنابراین سازمان‌هایی که قصد دارند تا از فضای ابر استفاده نمایند می‌توانند با استفاده از روش‌های مهاجرت میزبانی مجدد، سکوی مجدد و بازسازی مجدد سیستم فعلی خود را که مبتنی بر وب یا سرویس است برروی فضای ابر راه‌اندازی نمایند. استفاده از هر کدام از روش‌های مهاجرتی بستگی به نیازهای سازمان دارد که تا چه حد می‌خواهد از ویژگی‌های فضای ابری استفاده نماید و همچنین به هزینه‌های مالی و زمانی که سازمان در اختیار دارد نیز بستگی دارد. در ادامه به بررسی چند سازمان پرداخته می‌شود که یک سیستم ERP مبتنی بر وب یا سرویس داشته‌اند و بنا به دلیلی که ذکر خواهد شد تصمیم گرفتند که تا به فضای ابری مهاجرت کنندمهاجرت‌های موفقدر این بخش ۳ سازمان مورد بررسی قرار گرفته‌اند که دو مورد از آن‌ها با سیستم ERP مبتنی بر وب و دو دیگر با سیستم ERP مبتنی بر سرویس کار می‌کردند و با توجه به شرایط و نیازهایی که پیش ‌آمد مجبور به مهاجرت به سمت فضای ابر شدند. در ادامه به بررسی هر کدام از سازمان‌ها پرداخته می‌شود و علت و روش مهاجرت آن‌ها توضیح داده می‌شود.دانشگاه ایالت کانزاس [7]دانشگاه کانزاس در سال ۱۸۶۳ به عنوان اولین دانشگاه اعطایی زمین عملیاتی ملی و اولین مؤسسه‌ی آموزش عالی دولتی تاسیس شد. این دانشگاه بیش از ۱۵۰ سال علوم نظامی، کشاورزی و مهندسی را آموزش می‌دهد. دانشگاه کانزاس در منهتن ایالت کانزاس کشور آمریکا واقع شده است و نزدیک به ۲۴۰۰۰ دانشجو و۴۵۰۰ هیات علمی دارد. این دانشگاه برای مدیریت و کنترل امور مربوط به منابع انسانی خود از ماژول سیستم ERP استفاده می‌کند. سیستم ERP این دانشگاه PeopleSoft نام دارد که برای شرکت Oracel می‌باشد و برخی شرکت‌ها مانند Sierra-Cedar، آن را پیاده‌سازی و پشتیبانی می‌کنند و به گونه‌ای با Oracel همکاری می‌کنند. همچنین معماری این برنامه مبتنی بر وب می‌باشد ]۱۲[ و معماری آن در تصویر ۱۱ آمده است. اجزای تشکیل دهنده‌ی این سیستم مرورگر وب، سرویس‌های وب، سرور زمان‌بندی فرایند، سرور برنامه و سیستم مدیریت پایگاه داده رابطه‌ای()(Relational Data Base Management System&#40;RDBMS&#41;) است. عملکرد این سیستم به این صورت است که کاربر از طریق مرورگر یک درخواستی را در سیستم ثبت می‌کند. این درخواست از طریق سرویس‌های وب به سرور برنامه ارسال می‌گردد. سرور برنامه هسته‌ی مرکزی این معماری به شمار می‌رود، زیرا مسئول اجرای منطق برنامه‌ است و پردازش‌های اصلی در آن صورت می‌گیرد. پس از آن‌ که پردازش لازم برروی داده‌های موجود در RDBMS توسط منطق برنامه‌ انجام شد پاسخ مناسب از طریق سرویس وب سمت مرورگر ارسال می‌گردد تا نتیجه به کاربر نمایش داده شود. سرور زمان‌بندی فرایند نیز شامل برنامه‌هایی است که مانند فایل‌های Batch عمل می‌کنند و به صورت خودکار در زمان‌های مشخصی یک عملیات را انجام می‌دهند. به عنوان مثال عملیات بررسی تراکنش‌ها توسط سرورهای بانک که به صورت خودکار در ساعتی از شب یک گزارش از تمام تراکنش‌های آن روز را بدون دستور و دخالت انسانی آماده می‌کنند.تصویر ۱۱- معماری سیستم PeopleSoftسیستم ERP ابتدا در خود سازمان قرار گرفته بود. طی یک حادثه‌ای در تاریخ ۲۲ مِی ۲۰۱۸ کتابخانه‌ی دانشگاه دچار آتش سوزی‌ می‌شود و از آنجایی که اتاق مرکز داده در زیرزمین کتابخانه قرار داشت این آتش سوزی سبب شد تا زیرساخت‌های آن‌جا به واسطه‌ی دود و آب زیاد آسیب ببینند و مرکز داده پس از مهار آتش به طور کامل خاموش شوند. راه‌اندازی مجدد آن بسیار زمان‌بر و هزینه‌بر بود و باید یک بار دیگر کارهایی را از اول برای راه‌اندازی مجدد سیستم‌ها انجام می‌دادند. با توجه به آن که مهلت محاسبه‌ی حقوق و دستمزدها و پرداخت ‌آن‌ها نزدیک بود بنابراین زمان کافی و راه‌اندازی مجدد به صورت درون محیطی را نداشتند به همین جهت تصمیم گرفتند به سمت استفاده از فضای ابری بروند. به همین دلیل چون دانشگاه می‌خواست که در کمترین زمان ممکن با داده‌ها و برنامه‌های موجود سیستم خود را در فضای ابری راه‌اندازی کند از این رو متخصصین شرکت Sierra-Cedarروش مهاجرت میزبانی مجدد را پیشنهاد دادند. با استفاده از این روش به مدت ۴۸ ساعت تمام برنامه‌ها و اطلاعات با همان ساختار و معماری که داشتند به فضای ابری AWS (Amazon Web Services) متنقل شدند. این مهاجرت ضمن آن که کمک کرد تا واحد منابع انسانی دانشگاه به هدفش برسد و در مهلت‌های تعیین شده محاسبه و پراخت حقوق و دستمزد را انجام دهند، باعث شد تا امنیت افزایش پیدا کند و پردازش تراکنش برخط(Online Transaction Processing(OLTP)) نیز بهبود یافت. OLTP یک سیستم عملیاتی است که برنامه‌های مبتنی بر تراکنش را در یک معماری سه لایه پشتیبانی می‌کند. این سیستم تراکنش‌های روزانه‌‌ی سازمان را اداره می‌کند و اساسا برروی پردازش پرس‌وجو، حفظ یکپارچگی داده در محیط‌های چند دسترسی و اثر بخشی که توسط تعداد کل تراکنش‌ها در ثانیه اندازه‌گیری می‌شود، تمرکز دارد.شرکت حمل و نقل املاک [۸]مورد بعدی، شرکتی است که در زمینه‌ی حمل و نقل املاک و مستغلات فعالیت می‌کند و یک رهبر جهانی در حمل و نقل املاک محسوب می‌شود. این شرکت در شهر سن فرانسیسکو کشور آمریکا واقع شده است و حدود ۱۷۰۰ کارمند دارد. همچنین دارای سرمایه‌گذاری در املاک و پروژه‌های توسعه در ۱۹ کشور است.  این شرکت برای انجام کارهای مالی خود از ماژول سیستم مالی نرم‌افزار PeopleSoft استفاده می‌کند و تصمیم گرفت تا سیستم ERP موجود را برفضای ابر ببرد تا بتواند از اکثر سرویس‌های فضای ابری بهره ببرد. با توجه به آن که این شرکت هدفش استفاده از امکانات زیرساختی فضای ابر، استفاده از امکانات گزارش‌گیری و افزایش امنیت بود، شرکت Sierra-Cedar روش مهاجرت بازسازی مجدد را پیشنهاد داد و آن را پیاده‌سازی نمود. این مهاجرت نزدیک به ۷ ماه به طول انجامید تا سیستم قبلی بازسازی مجدد گردد و برروی فضای ابری قرار گیرد. پروژه‌ی مهاجرت راه‌حل معماری مجدد شده از ارائه دهنده‌ی میزبان سنتی موجود به AWS در سپتامبر ۲۰۱۹ آغاز شد و در طول بازسازی سایر برنامه‌های سازمان مانند برنامه‌های مالی کمکی شامل Canon OCR و Marketbridge می‌شدند، نیز به فضای ابر منتقل شدند. این رفتن به فضای ابر سبب شد تا قابلیت گزارش‌دهی بهبود یابد، پروتکل‌های سخت امنیتی اجرا شد و یکپارچه‌سازی فنی، امنیتی و کاربردی نیز پیاده‌سازی شد.سازمان کشتیرانی ایران [۹]سازمان کشتیرانی ایران، یک شرکت ترابری دریایی و کشتیرانی ایرانی است که در سال ۱۳۴۷ تاسیس شد و هم اکنون با دراختیار داشتن ناوگانی از ۱۷۰ فروند کشتی، به عنوان بزرگ‌ترین شرکت خدمات کشتیرانی خاورمیانه محسوب می‌شود. این سازمان از ERP مبتنی بر سرویس استفاده می‌کرده و به دلیل امکان اشتراک راحت‌تر اطلاعات و دسترسی برخی ماژول‌ها برای سازمان‌های زی‌ربط و همچنین استفاده از زیرساخت‌های ابری تصمیم گرفتند که به سمت فضای ابر بروند و ERP خود را در فضای ابر مستقر کنند. در این مهاجرت مواردی مانند ارتباط سازمان با سایر محیط‌های ابری، امکان ارتباط دو طرفه با سایر سازمان‌های بیرونی مانند اداره‌ی بنادر و سازمان بین‌المللی دریانوردی و جلوگیری از پاک شدن داده‌ها بسیار اهمیت داشت که باید در نظر گرفته می‌شد. از آنجایی که سیستم ERP موجود در آن زمان مبتنی بر سرویس بود بنابراین از ESB نیز برخوردار بود. ESB کمک می‌کند تا مهاجرت راحت‌تر صورت گیرد و به دلیل ساختار سرویس‌گرایی که خود فضای ابری دارد کمی آسان‌تر بتوان یک سیستم ERP را برروی فضای ابر قرار داد. در روشی که برای مهاجرت سیستم ERP مبتنی بر سرویس پیشنهاد شد مشابه روش مهاجرت سکوی مجدد است و بیشتر تغییرات جهت سازگاری با محیط ابری برروی ESB انجام می‌گیرد. در روش پیشنهادی برای سازمان کشتیرانی، مهم‌ترین قسمت ESB واسط محاسبات ابری باز        (Open Cloud Computing Interface(OCCI)) است. این قسمت وظیفه‌ی ارزیابی و مدیریت ارتباطات ورودی اولیه از سیستم‌های خارجی به ماژول‌های ERP و بالعکس است را برعهده دارد. در اولین گام، این لایه بررسی می‌کند که درخواست ارتباطی که از سمت سازمان‌های دیگر با ماژول ERP آمده است اولین ارتباط است یا خیر. در صورتی که این درخواست ارتباط برای اولین بار بود برخی اطلاعات مانند نوع سازمان، شناسه‌ی ارتباطی، زمان ارتباط، منبع و مقصد ارتباط جمع می‌شوند. همچنین در این لایه برخی اطلاعات در مورد سازمان‌ها و نوع ارتباط اجازه داده شده برای برقراری ارتباط بعدی نگهداری خواهد شد. این کار سرعت برقراری ارتباط را افزایش می‌دهد. همچنین سطح خطر و امنیت ارتباط را نیز بهبود می‌بخشد. پس از برقراری ارتباط میان دو طرف، سازمان درخواست دهنده و ماژول ERP، داده دریافت می‌شود و بین داده‌های دریافتی و مدل داده‌ی سیستم ممکن است که ناسازگاری وجود داشته باشد. بنابراین داده‌ها به یک لایه‌ی دیگر به نام هستان‌شناسی(Ontology) ارسال می‌گردد. این لایه اطلاعات دریافتی را با مدل داده‌ی سیستم ERP از سه جنبه‌ی ارتباطی، داده‌ای و ذخیره مطابقت می‌دهد. پس از استانداردسازی داده با توجه به استانداردهای فضای ابری و سیستم ERP اطلاعات توسط ESB به ماژول مورد نظر ارسال و سپس پاسخ مناسب سمت سازمان درخواست دهنده برگردانده می‌شود. ساختار روش پیشنهادی برای سازمان کشتیرانی در تصویر ۱۱ آمده است.این روش مهاجرت و پیاده‌سازی ERP در فضای ابری ضمن اینکه امکان برقرار با سایر فضاهای ابری را فراهم کرد سبب شد تا از سایر امکانات موجود در فضای ابر و مزیت‌های آن استفاده کنند. یکی از این امکانات، استفاده از سرویس‌های امنیتی آن بود و آن‌ها را در ERP تعبیه نمودند. به عنوان مثال توانستند از مدل امنیتی AAA (احراز هویت (Authorization)، کنترل دسترسی(Authentication) و حسابرسی (Accounting)) استفاده کنند. مدل امنیتی AAA، درواقع یک چارچوب است که دسترسی‌ به منابع کامپیوتری‌ را کنترل، سیاست‌های را اجرا و استفاده را ممیزی می‌کند. این مدل نقش اصلی در مدیریت شبکه و امنیت سایبری را به وسیله‌ی نظارت کاربران و ردیابی فعالیت‌های ‌آنان در زمانی که متصل هستند به شبکه، ایفا می‌کند.تصویر ۱۲- قرار گیری سیستم ERP در فضای ابری و ارتباط آن با سایر سامانه‌هادستاورد دیگری که در روش پیشنهادی حاصل شد مدیریت و توزیع بهتر پایگاه‌های داده است، همچنین زیرساخت را برای ایجاد سیستم پردازش تحلیلی برخط (Online Analytics Processing(OLAP)) آماده کردند. OLAP یک فناوری است که سامان‌ دادن حجم وسیع پایگاه‌های داده‌ی حرفه استفاده می‌شود و از هوش تجاری پیشتیبانی می‌کند. یکی دیگر از مزیت‌ها افزایش دسترس‌پذیری بود که با توجه به کارهای انجام شده سایر سازمان‌ها و افراد سازمان در صورت داشتن مجوز می‌توانند به سیستم و داده‌ها سریع و آسان دسترسی داشته باشند. همچنین متخصصانی که این روش را ارائه دادند به منظور مشاهده‌ی تاثیر این کار و میزان رضایت کاربران، یک نظر سنجی نیز در سازمان انجام دادند. برای ارزیابی معماری سیستم از روش ATAM  (Architecture Tradeoff Analysis Method) استفاده نمودند. این روش برای ارزیابی ویژگی‌های کیفی معماری‌های نرم‌افزاری استفاده می‌شود. این روش به استخراج مجموعه‌ای از نیازمندی‌های کیفی همراه چند بعد، تحلیل اثرات هر نیازمندی به تنهایی و سپس فهم تعامل این نیازمندی‌ها با یکدیگر کمک می‌کند. در تصویر ۱۲ درختی نمایش داده می‌شود که ویژگی‌های کیفی سیستم ERPمورد نظر است. در این درخت دو ویژگی‌ است مد نظر است: یکپارچگی و نگهداری. هر کدام از این دو ویژگی خود با چند پارامتر دیگر سنجیده می‌شوند که در تصویر آمده است. در گره‌های برگ نیز معیارهایی نمایش داده شده است هر زیرویژگی‌ را تعریف می‌کنند. هر   معیار از دو جنبه‌ی اولویت و سختی استفاده مورد بررسی قرار می‌گیرد.تصویر ۱۳- درخت ویژگی‌های کیفی معماری پیشنهادیموارد موجود در درخت تصویر ۱۲، درواقع حاصل ایده‌ی متخصصان حوزه در صنعت حمل و نقل است. سپس یک پرسشنامه براساس درخت ساخته شده تهیه کردند و در اختیار متخصصان گذاشتند و نظر هر کدام را پرسیدند. پس از جمع‌آوری پرسشنامه‌ها، پاسخ‌ها را با استفاده از روش TOPSIS تحلیل کردند. نتیجه‌ی این تحلیل در تصویر ۱۳ نشان داده شده است. در این جدول ستون‌های افقی کم رنگ معیار اول و ستون‌های افقی پررنگ معیار دوم از هر زیرویژگی را نشان می‌دهند. خروجی حاصل از این تحلیل آن شد که روش پیشنهادی تاثیر زیادی بر افزایش سرعت تعامل و همکاری میان سیستم ERP سازمان کشتیرانی با سیستم‌های نرم‌افزاری که مستقل از این سازمان‌اند، دارد. همچنین در تعامل با آن‌ها امنیت و دسترس‌پذیری نیز افزایش می‌یابد.تصویر ۱۴- نتیجه‌ی تحلیل پاسخ‌های پرسشنامه‌ی ارزیابی روش پیشنهادیهمکاران سیستم، ارائه‌ دهنده‌ی ERP ابری در ایران [۱۰]در ایران نیز شرکت همکاران سیستم که در حوزه‌ی تولید سیستم ERP بسیار فعال است و مدت‌ها است که در این حوزه فعالیت می‌کند، سیستمی به نام راهکاران ابری را معرفی نموده و در حال حاضر شرکت‌هایی مانند دنا بهریز، سرام آرا در حال استفاده از این سیستم هستند. شرکت دنا بهریز در سال ۱۳۹۵ در منطقه‌ی تاکستان قزوین و با هدف تولید انواع سرسیلندر خورد به روش ریخته‌گری و ماشین‌کاری آغاز کرد. این شرکت در سال ۱۳۹۶ با توجه به رشدی که داشت و تثبیت آن در بازار تصمیم گرفت که به سمت استفاده از سیستم ERP برود و در سال ۱۳۹۷ اقدام به خرید سیستم ERP راهکاران ابری نمود و دلیل خرید چنین محصولی پوشش جغرافیایی وسیع میان کارخانه و دفتر مرکزی (واقع در تهران) و کاهش هزینه زیرساخت بود. شرکت دیگری که به سمت ERP ابری شرکت همکاران سیستم رفت شرکت سرام آرا بود. این شرکت یکی از بزرگ‌ترین شرکت‌های تولید کننده کاشی و سرامیک در کشور است و در سال ۱۳۸۲ در این زمینه فعالیت می‌کند و در حال حاضر ۱۶۰ نفر کارمند دارد. این شرکت از ماژول حسابداری همکاران استفاده می‌کند و تجربه‌ی کار با اولین نسل‌های نرم‌افزار ERP شرکت همکاران سیستم را دارد و نرم‌افزار‌های دلفی همکاران سیستم مدت‌ها پاسخگوی نیازها این مجموعه بوده است. طبق گفته‌ی مدیر مالی شرکت، به دلیل پیچیدگی‌های نگهداری از زیرساخت و بروزرسانی آن تصمیم به استفاده از سیستم راهکاران ابری گرفتند. از مزایایی که این سیستم برای شرکت به همراه داشته است می‌توان به موضوع کاهش هزینه‌های تجهیز و نگهداری زیرساخت اشاره کرد که این مسئولیت به طور کامل به عهده‌ی شرکت همکاران سیستم قرار گرفته است. همچنین استفاده از این سیستم سبب شد تا دسترس‌پذیری بیشتری را تجربه کنند و مدیریت حتی در زمانی که مرخصی است بتواند موضوعات کاری را کنترل نماید و این ویژگی در شرایط کرونایی بسیار به این شرکت کمک کرد.با توجه به دو شرکت بررسی شده که به سمت سیستم راهکاران ابری رفتند، بنظر می‌رسد که شرکت‌هایی که به تازگی به سمت استفاده از سیستم ERP می‌روند از همان ابتدا محصول ابری راهکاران را خریداری می‌کنند و شرکت‌هایی که از سرویس‌های قدیمی همکاران سیستم که مبتنی بر وب یا سرویس باشد نیز محصول قبلی را کنار می‌گذارند و به سراغ محصول جدید که مبتنی بر ابر است می‌روند و نسخه‌ی ابری همان محصول را استفاده می‌کنند. درواقع به نوعی از روش مهاجرت خرید مجدد استفاده می‌کنند و از آن‌جایی که سیستم ERP قبلی نیز برای خود همکاران سیستم می‌باشد بنابراین تمام اطلاعات و داده‌های آن شرکت بدون مشکل به سیستم جدید منتقل می‌شود و از بابت انتقال داده نگرانی نخواهند داشت. اما در موارد بررسی شده اشاره‌ای به سایر روش‌های مهاجرتی مانند روش معماری مجدد، سکوی مجدد و میزبانی مجدد دیده نشد. البته شرکت‌هایی مانند شرکت گوهر شفا هستند که از نرم‌افزارهای ERPخارجی استفاده می‌کردند و به دلایل شرایط تحریم مجبور به تغییر سیستم خود شدند و از این رو سیستم ERP راهکاران ابری را انتخاب نمودند و در داستان موفقیت این شرکت اشاره به روش مهاجرت به فضای ابر نشد و بنظر می‌رسد که این شرکت نیز تنها از داده‌ها و اطلاعات خود پشتیبان گرفته و در اختیار متخصصان همکاران سیستم قرار داده است تا آن‌ها را به سیستم راهکاران ابری منتقل نمایند.بنابراین می‌توان گفت که شرکت‌های کوچک و متوسطی که از نرم‌افزارهای ERP مبتنی بر وب یا سرویس که در محیط داخلی سازمان قرار دارند، بخواهند به سمت فضای ابر بروند راه‌حلی که دارند تنها خرید مجدد یک محصول مبتنی بر ابر می‌باشد.با توجه به این شرایط می‌توان شرکت‌های پشتیبانی از محصول‌ ERP ایجاد شوند تا وظیفه‌ی مهاجرت سیستم با معماری و ساختار فعلی بر فضای ابر را برعهده‌ی آنان گذاشت. البته این کار نیازمند آماده بودن شرایط و امکانات ارا‌ئه دهنده‌ی خدمات ابری نیز می‌باشد. همانگونه که شرکت Sierra-Cedar با شرکت Oracel در پشتیبانی و توسعه‌‌ی محصول PeopleSoft همکاری می‌کند و در صورت نیاز یکی از سازمان‌های این نرم‌افزار را برروی یکی از فضاهای ابری AWS یا Oracel با توجه به امکاناتی که این فضاهای ابری می‌دهد بنا کند. در ایران یک شرکت یا حتی خود مجموعه‌ی همکاران سیستم می‌تواند وظیفه‌ی پشتیبانی از محصول ERP ارائه شده را برعهده بگیرد و آن را در صورت نیاز سازمان به فضای ابری خود همکاران سیستم به یکی از روش‌های سکوی مجدد، معماری مجدد یا میزبانی مجدد انتقال دهند. البته در مورد فضای ابری شرکت ابرآروان نیز می‌تواند گزینه‌ی مناسبی باشد البته به شرط آنکه امکانات و ابزار مورد نیاز برای انتقال را فراهم نماید همانگونه که AWS به واسطه‌ی امکاناتی که در اختیار توسعه‌ دهندگان قرار می‌دهد فرایند مهاجرت را بسیار ساده و قسمتی از کارها را خودکار کرده است.نتیجه‌گیریبسیاری از سازمان‌ها به واسطه‌ی پیچیدگی فرایند‌ها موجود در سازمان، کنترل و مدیریت آن‌ها به سمت استفاده سیستم‌های ERP رفته‌اند. سیستم‌های ERPنیز، سیستم‌های نرم‌افزاری هستند که ساختار و معماری خاصی دارند و متناسب با نیازمندی‌ها و فناوری‌های مورد نیاز سیستم معماری آن انتخاب شود. امروزه فناوری محاسبات ابری بسیار مورد توجه قرار گرفته است و اکثر سازمان‌ها به سمت استفاده آن به واسطه‌ی مزیت‌هایی مانند کاهش هزینه‌ی‌های زیرساختی، عدم درگیر شدن با پیچیدگی‌های راه‌اندازی، توسعه و نگهداشت زیرساخت، توسعه‌ی سریع سیستم و دسترسی سریع و آسان به نرم‌افزار و اطلاعات سوق پیدا کرده‌اند. از این رو شرکت‌های ارائه دهنده خدمات ERP نیز معماری مبتنی بر فضای ابری را برای سیستم‌های ERP خود بکار برده‌اند تا بتوانند از تمام امکانات فضای ابری استفاده کنند. اما شرکت‌هایی که از گذشته از سیستم‌های ERP استفاده می‌کردند که معماری آن‌ها مبتنی بر وب یا سرویس بود و در محیط داخلی خود سازمان آن را مستقر کرده بودند، برای آن که بخواهند از امکانات فضای ابری استفاده کنند لازم است تا از روش‌های مهاجرتی برنامه‌ها به فضای ابری استفاده کنند. این روش‌ها شامل خرید مجدد، میزبانی مجدد، سکوی مجدد و معماری مجدد می‌باشد. در خرید مجدد محصول قدیمی به طور کلی کنار گذاشته می‌شود و نسخه‌ی جدید همان محصول که مبتنی بر ابر است خریداری می‌گردد. در میزبانی مجدد، معماری برنامه‌ی موجود حفظ می‌شود و بدون تغییر در محیط ابری مستقر می‌گردد. سکوی مجدد نیز همانند میزبانی مجدد است اما برای استفاده از برخی ویژگی‌ها و سرویس‌های ابری در معماری سیستم موجود تغییراتی انجام می‌شود. در معماری مجدد نیز معماری برنامه‌ی موجود به طور کلی تغییر می‌کند و با توجه به نیازهای برنامه و امکاناتی که ارائه‌ دهنده‌ی سرویس‌های ابری ارائه می‌کند معماری برنامه تبیین می‌شود. نکته‌ای که در استفاده از روش‌های مهاجرتی تعیین کننده است، میزان نیاز سازمان به امکانات فضای ابری و همچنین زمان و هزینه‌ای است که می‌خواهد صرف انتقال برنامه‌ی موجود در سازمان به فضای ابری نماید.در مهاجرت سیستم‌های ERP مبتنی بر وب برای آنکه بتوان آن را با امکانات فضای ابری منطبق کرد باید از روش سکوی مجدد یا معماری مجدد استفاده کرد و نسبت به مهاجرت سیستم‌های ERP مبتنی بر سرویس زحمت بیشتری می‌توان گفت که دارد. به طور کلی انتقال سیستم از یک محیط داخلی به فضای ابر بسیار پر زحمت و زمان‌بر است اما این مورد در ERP مبتنی بر وب نسبت به مبتنی بر سرویس بنظر بیشتر می‌آید. دلیل آن هم، ساختار معماری سرویس‌گرا است و ساختار فضای ابری می‌باشد. فضای ابری خود از یک معماری مانند معماری سرویس‌گرا پیروی می‌کند و در آن هر خدمت به صورت سرویس ارائه می‌شود و در ERP مبتنی بر سرویس نیز به کمک وجود ESB سرویس مورد نیاز را می‌توان از سرویس دهنده‌ی فضای ابری تقاضا کرد و آن را در سیستم خود بکار برد.در تمامی کارهای بررسی شده که سیستم ERP مبتنی بر وب یا سرویس خود را با موفقیت در فضای ابری مستقر کردند، سازمان‌ها بسیار راضی بودند و در تمامی موارد مشاهده شد که هزینه‌ها کاهش یافته و دسترسی‌پذیری و امنیت افزایش یافته است. بنابراین به دلیل مزایا و فرصت‌هایی که فضای ابری برای کاربران و سازمان‌ها فراهم می‌کند مهاجرت به این فضا را می‌توان امری ضروری دانست.مراجع[1] Habadi, Assma, et al. &quot;An introduction to erp systems: Architecture, implementation and impacts.&quot; International Journal of Computer Applications 167.9 (2017): 1-4[2] https://www.geeksforgeeks.org/service-oriented-architecture[3] https://www.mulesoft.com/resources/esb/what-esb[4] Mell, Peter, and Tim Grance. &quot;The NIST definition of cloud computing.&quot; (2011) / https://faculty.winthrop.edu/domanm/csci411/Handouts/NIST.pdf[5] https://cloud.netapp.com/blog/aws-migration-strategy-the-6-rs-in-depth (last update: 2/4/2022)[6] https://www.sierra-cedar.com/2019/04/23/the-cloud-understood-part-5/ (last update: 2/4/2022)[7] https://www.sierra-cedar.com/wp-content/uploads/2021/06/CSS-KSU.pdf  (last update: 2/4/2022)[8] https://www.sierra-cedar.com/wp-content/uploads/2021/07/CSS-Real-Estate-Client.pdf ( last update: 2/4/2022)[9] Asosheh, Abbas, Yaghoub Farjami, and Arash Afshinfar. &quot;An ERP Framework Based on ServiceOriented Architecture and Cloud Computing Environment Case: IRISL Container Department.&quot; International Journal of Information &amp; Communication Technology Research, vol. 10, no. 3 (2018): 60-68[10]https://www.systemgroup.net/products/%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1D8%A7%D9%86-%D8%A7%D8%A8%D8%B1%DB%8C (last update: 2/4/2022)[11] Amini Valashani, Mohammad, and Arnold Mashud Abukari. &quot;ERP Systems Architecture for themodern age: A review of the state of the art Technologies.&quot; Journal of Applied Intelligent Systems and Information Sciences, vol. 1, no. 2 (2020): 70-90[12]https://docs.oracle.com/cd/E92519_02/pt856pbr3/eng/pt/tsvt/task_PeopleSoftArchitectureFundamentals-d27b40.html?pli=ul_d96e35_tsvt</description>
                <category>محمد ربانی بیدگلی</category>
                <author>محمد ربانی بیدگلی</author>
                <pubDate>Mon, 25 Jul 2022 00:18:51 +0430</pubDate>
            </item>
                    <item>
                <title>خط تولید نرم‌افزار</title>
                <link>https://virgool.io/@rabbani_mohammad/%D8%AE%D8%B7-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-xrtqyacpy0i6</link>
                <description>چکیدهبرای تولید یک نرم‌افزار لازم است تا تمام اجزای اصلی آن شناسایی شوند، سپس طراحی و پیاده‌سازی شوند. هنگامی که چندین نرم‌افزار قرار باشد که توسعه و تولید شوند و تمام این نرم‌افزارها از یک خانواده و عملکردی مشابه هم دیگر داشته باشند، مانند سیستم‌های مدیریت محتوا یا سیستم‌های تجارت الکترونیک، دیگر انجام مراحل تولید یک نرم‌افزار به ازای هر کدام از آن محصولات کار به صرفه‌ای نیست و منابع و زمان زیاد به هدر خواهد رفت. از این رو مفهومی به نام خط تولید نرم‌افزار مطرح شد. مفهوم خط تولید در به تنهای در بسیار از صنایع مانند صنعت خودرو سازی وجود دارد و چنین مفهوم در مهندسی نرم‌افزار نیز معرفی شد. در خط تولید نرم‌افزار اجزا و دارایی‌های ثابتی که ممکن است برای تمام نرم‌افزارهایی که از یک خانواده هستند استفاده شود، نگهداری می‌شوند و در سایر سیستم‌ها استفاده می‌گردد و به این صورت دیگر نیاز به ساخت اجزایی که از قبل برای یک نرم‌افزار مشابه ساخته شده بود نیست و بدین صورت زمان تولید نرم‌افزار افزایش می‌یابد و در مصرف منابع نیز صرفه‌جویی می‌گردد. در این مقاله به توضیح مفهوم خط تولید نرم‌افزار و روش‌های توسعه‌ی آن پرداخته می‌شودمقدمه   یک شرکت خودرو سازی را در نظر بگیرید.این شرکت ماشین‌هایی در مدل‌های مختلف تولید می‌کند. یک ماشین برای آن‌ که به دست مشتری برسد باید یک سری ویژگی‌های مشخصی داشته باشد، به عنوان مثال باید رنگ شده باشد، شیشه و چراغ داشته باشند. بنابراین شرکت سازنده‌ی خودرو برای تولید محصولات خود باید یک سری کار تکراری را انجام دهند و آن کار نیاز به زیرساخت‌ها و لوازمی دارد. به همین جهت شرکت خودرو‌سازی به جای آن که به ‌ازای هر مدل خودرو لوازم و زیرساخت‌های مربوط به آن مراحل ثابت، مانند نصب در و کاپوت خودرو، رنگ کردن ماشین و غیره را از صفر بسازند و فراهم کنند، یک خط تولید درست می‌کنند که دارای مراحلی است و در هر مرحله یک کاری انجام می‌شود. به عنوان مثال در ابتدا اجزای بدنه‌ی خودرو سر هم می‌شوند، در مرحله‌ی بعدی شیشه‌ی ماشین نصب می‌شود و در انتها ماشین وارد قسمت رنگ ‌آمیزی می‌گردد. هر مدل از ماشین ویژگی‌های خاص خود را دارند و برخی از مدل‌ها ممکن است که امکانات یک مدل دیگر را نداشته باشند بنابراین خط تولید را می‌توان تغییر داد و برخی مراحل را حذف یا اضافه کرد. از طرفی در مراحل مشترک ممکن است که مواد و طرح فرق کنند، مانند نوع رنگی که در مرحله‌ی رنگ آمیزی می‌تواند متفاوت باشد. بنابراین خط تولید یک محصول دارای ویژگی‌های ثابت و متغیر می‌باشد که در نیازهای متغیر متناسب با نیازهای هر مدل تغییر می‌کند.   چنین مفهومی در تولید سیستم‌های نرم‌افزاری نیز وجود دارد و می‌توان برای محصولات نرم‌افزاری که از یک خانواده هستند از چیزی به نام خط تولید نرم‌افزار استفاده نمود. خط تولید نرم‌افزار، ابزار و روش‌هایی است برای ایجاد مجموعه‌ای از سیستم‌های نرم‌افزار مشابه، از یک مجموعه دارایی‌های نرم‌افزاری مشترک با استفاده از ابزار تولید رایج. درواقع به کمک خط تولید نرم‌افزار می‌توانید از اجزای موجود از پیش ساخته شده برای نرم‌افزارهای مختلفی که از اجزای استفاده می‌کنند، بهره ببرید. ایجاد خط تولید نرم‌افزار کار ساده‌ای نیست و پیچیدگی‌های خاص خود را دارد و در مقایسه با تولید یک محصول نرم‌افزاری سخت‌تر به بنظر می‌آید. برای ایجاد خط تولید نرم‌افزار روش‌هایی وجود دارد و باید مراحلی طی شود تا آن را ساخت. همچنین از ابزارهای مناسب خط تولید نرم‌افزار برای تولید نرم‌افزار می‌توان کمک گرفت. در این مقاله هدف بررسی مفهوم خط تولید نرم‌افزار، چند روش رایج برای ایجاد آن و ابزارهایی که می‌توان برای ایجاد آن استفاده کرد، پرداخته می‌شود. ساختار مقاله به این صورت است که در بخش دو بتدا مفهوم خط تولید نرم‌افزار و مزایای آن توضیح داده می‌شود. در بخش سوم و چهارم سه روش رایج وابزارهای موجود برای ایجاد خط تولید نرم‌افزار بررسی می‌شود. در بخش پنجم به بررسی دو مورد از خطوط تولیدی نرم‌افزار که برای تولید محصولات نرم‌افزاری در دنیای واقعی راه‌اندازی شده‌اند پرداخته می‌شود و در بخش ششم نیز جمع و نتیجه‌گیری حاصل از این تحقیق گفته می‌شود.خط تولید نرم‌افزار      خط تولید نرم‌افزار را طبق تعریفی که توسط موسسه‌ی نرم‌افزاری Carnegie Mellon ارائه شده است، می‌توان به صورت زیر توصیف کرد:یک مجموعه‌ای از سیستم‌های نرم‌افزاری فشرده است که مجموعه‌ای رایج و مدیریت شده از ویژگی‌هایی که نیازهای مشخصی از یک بخش بازار یا ماموریت را به اشتراک می‌گذارد و از یک مجموعه‌ی مشترکی از دارایی‌های اصلی به روش تجویز شده توسعه می‌یابد.   درواقع خط تولید نرم‌افزار یکی از روش‌های مهندسی نرم‌افزار، ابزار و تکنیک‌هایی برای ایجاد یک مجموعه‌ای از سیستم‌های نرم‌افزاری مشابه از مجموعه‌ای از دارایی‌های نرم‌افزار است که برای تولید نرم‌افزار استفاده می‌شود. در اینجا منظور از دارایی‌های سیستم‌های نرم‌افزاری می‌تواند نیازمند‌ی‌ها، معماری، کد و موارد تست باشند. هدف از ایجاد یک خط تولید نر‌م‌افزار آن است که بتوان روند توسعه‌ی نرم‌افزار را تسهیل کرد و در عین حال به صنعتی شدن آن کمک نمود. همچنین مجموعه‌ای از اجزای نرم‌افزاری با قابلیت‌ استفاده‌ی مجدد به منظور تولید سریع یک خانواده از سیستم‌های نرم‌افزار ساخت. هنگامی که از خانواده در نرم‌افزار صحبت می‌کنیم منظور سیستم‌هایی هستند که کارایی مشابه‌ای دارند و هدفشان یکی است، مانند نرم‌افزارهای تجارت الکترونیک (e-commerce). استفاده از خط تولید می‌توان مزایای زیادی به همراه داشته باشد. از جمله‌ی این مزایا می‌توان به موارد زیر اشاره نمود:کاهش زمان عرضه به بازار: به واسطه‌ی توسعه‌ی سریع‌تر محصولات نرم‌افزاری از یک خانواده به وسیله‌ی خط تولید، زمان ساخت و ارائه‌ی محصول به بازار کم‌تر از زمانی خواهد بود که تمام اجزای یک محصول از صفر ساخته می‌شوند.افزایش کیفیت محصول: برای ایجاد یک خط تولید نرم‌افزار دقت زیادی می‌شود و به جوانب زیادی باید توجه شود و تست‌های زیادی برای اطمینان از صحت عملکرد خط تولید انجام شود. یکی از دلایل افزایش کیفیت محصول می‌تواند رفع اشکالاتی باشد که در طول ساخت محصول و پس از ساخت آن پیدا می‌شوند.کاهش ریسک و خطرات تولید: به واسطه‌ی دقت زیاد و آزمون‌هایی که انجام می‌شود، ریسک و خطرات تولید کاهش می‌یابد. همچنین به ازای هر محصول نرم‌افزاری که تولید می‌گردد اطمینان از عملکرد خط تولید، در صورتی که تغییر بنیادی در آن صورت نگرفته باشد، افزایش می‌یابد.افزایش رضایت مشتری: طبیعتا افزایش کیفیت محصول و کاهش زمان عرضه به بازار رضایت مشتری را به همراه خواهد داشت.استفاده موثرتر از منابع: از منابع و دارایی‌هایی که در اختیار است می‌توان به صورت مجدد استفاده کرد و نیازی نیست که پس از ساخت یک محصول به طور کامل کنار گذاشته شوند و حساب شده و متناسب با ویژگی‌های محصول درخواستی می‌توان از آن‌ها استفاده نمودتوانایی پیکربندی و شخصی سازی سریع: هر محصول نرم‌افزار متناسب با درخواست و نیازمندی‌های مشتری توسعه داده می‌شود و نیازهای مشتریان، تقریبا در اکثر موارد، مشابه یکدیگر نیستند. خط تولید نرم‌افزار این امکان را فراهم می‌کند تا محصولاتی که از یک خانواده هستند را بتوان متناسب با نیازهای مشتری تغییر داد و شخصی‌سازی نمود بدون آن که نیاز باشد از صفر تمام اجزا را طراحی و پیاده‌سازی نمود.   ایجاد و نگهداری یک خط تولید نرم‌افزار کار ساده‌ای نیست و در کنار مزایای فراوانی که دارد، دارای چالش‌هایی نیز می‌باشد که باید به آن‌ها توجه شود. از جمله‌ی چالش‌های مهم می‌توان به موارد زیر اشاره کرد:هزینه‌ی توسعه‌ی خط محصول اولیه زیادتر از یک محصول به تنهایی استبرنامه‌ریزی انتشار سخت‌تر می‌شود، زیرا اولویت‌های رقابتی میان برنامه‌ها متفاوت استپشتیبانی از خط تولید برای سالیان طولانی نیازمند توانایی نگهداشتن اجزای اصلی برای بازگرداندن یک سری تغییرات ایجاد شده توسط مشتری‌ها به هسته‌ی اصلی است    بنابراین برای ایجاد یک خط تولید محصول نرم‌افزاری لازم است تا به بسیار از جوانب توجه شود و نسبت به توسعه‌ی یک محصول نرم‌افزاری به تنهایی زمان زیاد‌تر و حتی نیروی انسانی بیشتری جهت بررسی و مهندسی اجزا و دارایی‌های مشترک و متغیر تشکیل دهنده‌ی نرم‌افزارهایی از یک خانواده صرف شود.    پیش از آن که روش‌های ایجاد خط تولید معرفی شوند، لازم است تا مفهومی به نام مهندسی خط تولید نرم‌افزار توضیح داده شود. مهندسی خط تولید نرم‌افزار دروافع روشی است برای ساخت یک مجموعه‌ای از سیستم‌های نرم‌افزاری متمرکز که مجموعه‌ای از ویژگی‌های مشترکی که می‌توانند سفارشی‌سازی شوند با توجه به نیازهای ذینفعان در یک محدوده‌ی مشخص استفاده می‌شود. به کمک مهندسی خط تولید می‌توان ویژگی‌های مشتری و متغیر یک خط تولید سیستم‌های نرم‌افزاری را شناخت و از آن‌ها به منظور استخراج حداکثر استفاده مجدد بهره برد. همچنین مهندسی خط تولید شامل دو فرایند است: مهندسی دامنه و مهندسی برنامه. در مهندسی دامنه محدوده کاری خط تولید و نیازهایی که دارد تعیین و اجزای آن‌ پیاده‌سازی می‌شود. نکته‌ای که مهم می‌باشد آن است که عامل کلیدی موفقیت توسعه‌ی یک خط تولید، ایجاد تمرکز مناسب برروی یک دامنه مشخص، به خوبی تعریف شده و با محدوده‌ی مناسب است. یک دامنه ناحیه‌ای از دانش است که:هدف آن به حداکثر رساندن رضایت از نیازهای ذینفعان استشامل مجموعه‌ای از مفاهیم و اصطلاحات است که توسط متخصصان آن ناحیه درک می‌شودشامل دانش چگونگی ساخت سیستم‌های نرم‌افزاری (یا بخش‌هایی از آن‌ها) در آن ناحیه می‌باشدبنابراین مرحله‌ی مهندسی دامنه بسیار مهم می‌باشد و به گونه‌ای آن را سنگ بنای ایجاد یک خط تولید نر‌م‌افزار مناسب می توان دانست. در مورد مهندسی برنامه نیز می‌توان گفت که مربوط به ترکیب اجزای ساخته شده در مهندسی دامنه و ساخت اجزای جدید برای رفع نیازهایی است که توسط مشتری مطرح شده‌اند. حل با توجه به آشنایی با مفهوم مهندسی خط تولید و فرایند‌های آن در ادامه به معرفی روش‌های تولید خط تولید نرم‌افزار پرداخته می‌شود.روش‌های ایجاد خط تولید نرم‌افزار در این بخش به معرفی سه روش ساخت خط تولید نرم‌افزار پرداخته می‌شود که هر سه از الگوهای معروف برنامه‌نویسی هستند این سه روش عبارت‌اند از برنامه ‌نویسی مبتنی بر ویژگی (Feature Oriented Programming یا به اختصار FOP)، برنامه نویسی مبتنی بر جنبه (Aspect Oriented Programming یا به اختصار AOP) و برنامه نویسی مبتنی بر شکست (Fragment Oriented Programming یا به اختصار FragOP) که در ادامه به بررسی بیشتر هر کدام از این روش‌های پرداخته می‌شود.برنامه نویسی مبتنی بر ویژگی (FOP)ایده‌ی اصلی FOP تجزیه‌ی طراحی یک سیستم و کد با توجه به ویژگی‌هایی است که ارائه می دهد و هدف اصلی خط تولید مبتنی بر ویژگی نیز استخراج محصول را به طور کامل خودکار کند. خط تولید مبتنی بر ویژگی شامل ۴ فرایند است که دو فرایند اول مربوط به مهندسی دامنه و دو فرایند دیگر نیز مربوط به مهندسی برنامه هستند و این ۴ فرایند عبارت‌اند از:تحلیل دامنه: نوعی از تحلیل نیازها برای تمام خط تولید است و شامل ۲ مرحله‌ می‌باشد. مرحله‌ی اول محدوده‌ی دامنه نام دارد. این مرحله مربوط به فرایند تصمیم‌گیری در مورد بازه یا وسعت خط تولید است و معمولا مدیران تصمیم می‌گیرند که کدام نیازمندی‌های ایجاد شده در دامنه باید در نظر گرفته شوند. مرحله‌ی دوم طراحی دامنه است. درواقع طراحی دامنه اشتراک‌ها و متغیرهای دامنه‌ی محدود شده را ضبط و مستند می‌کند.تحلیل نیازمندی‌ها: در این فرایند تیم توسعه تلاش می‌کند تا نیازمند‌های مشتری را با آن نیازمندی‌هایی که در طول تحلیل دامنه شناخته شد، نگاشت کنند. در صورتی که یکی از نیازمندی‌های مشتری با ویژگی‌ها و نیازهای دامنه مطابق نباشد سه حالت رخ می‌دهد:                  -  آن نیازمندی خارج از محدوده‌ی خط تولید باشد و نمی‌توان ویژگی یا محصول متناظر را ارائه داد                  -  می‌توان محصول را با ویژگی‌ها و نیازمندی‌های موجود توسعه داد و تولید کرد. در انتها به صورت                      دستی آن را گشترش داد و افزونه‌ها و پلاگین‌هایی به آن اضافه نمود                  -  آخرین را نیز آن است که این نیازمندی را به عنوان یکی از نیازهای خود دامنه و خط تولید در نظر                      گرفته شود و محدوده‌ی خط تولید را تغییر دهیم که در این صورت لازم است دوباره از ابتدا و فرایند                      تحلیل دامنه شروع کنیم.پیاده‌سازی دامنه: پس از شناسایی و نگاشت نیازمندی‌ها نوبت به پیاده‌سازی آن‌ها به شکلی می‌رسد که قابلیت استفاده مجدد را داشته باشند. در این فرایند از کلمات توسعه‌دهندگان برای پیاده‌سازی راه‌حل‌ها نیازمندی‌های یک مشتری استفاده می‌شود. در این فرایند دو کار انجام می‌شود. ابتدا یک چارچوبی انتخاب می‌شود که قابلیت استفاده مجدد را فراهم نماید. سپس با توجه به چارچوب و راهبرد انتخاب شده ممکن است که نیاز به آماده‌سازی طراحی و کد به گونه‌ای باشد که بتوان پیاده‌سازی را تکرار کرد. به عنوان مثال ما طراحی می‌کنیم چگونه اجزای مشترک پیاده‌سازی ساختار بندی شوند و نقاط گسترش در کجا قرار گیرند و ویژگی‌های گسترش‌ها چگونه فعال و غیرفعال شوند.استخراج محصول: در این فرایند نیز یک محصول با توجه به ویژگی‌های انتخاب شده در مرحله‌ی تحلیل نیازمندی‌ها می‌تواند تولید یا ترکیب شود با استفاده از اجزا و خروجی‌های توسعه‌داده شده در فرایند پیاده‌سازی دامنه.بنابراین به کمک این ۴ فرایند می‌توان یک خط تولید مبتنی برروش FOP راه‌اندازی نمود.برنامه نویسی مبتنی بر جنبه (AOP)برنامه نویسی مبتنی بر جنبه یک روشی است که دغدغه‌های مقطعی را به وسیله‌ی معرفی یکی واحد ماژول‌سازی جدید به نام جنبه تقسیم می‌کند و هر جنبه نیز برروی یک ویژگی دغدغه‌ی مقطعی مشخصی تمرکز دارد. درواقع AOP اجازه می‌دهد تا برنامه را به قسمت‌های متفاوتی تقسیم کنیم که هر کدام یک دغدغه محسوب می‌شوند. در این روش ویژگی‌های مشترک به عنوان ماژول‌های اصلی در نظر گرفته می‌شوند و ویژگی‌های متغیر به عنوان جنبه‌ها پیاده‌سازی می‌شوند. در روش‌های سنتی و رسمی این ویژگی‌ها به عنوان ماژول‌های برنامه پیاده‌سازی می‌شوند و اگر یک ویژگی با سایر ویژگی‌ها بخواهد در ارتباط باشد با یک فراخوانی API توسط هر کدام از ویژگی‌ها به ویژگی مربوطه اتفاق بیفتد. به عنوان مثال در تصویر ۱ تمام ماژول‌ها نیاز دارند که بررسی کنند که آیا کاربر وارد حساب کاربر خود شده است یا خیر.تصویر ۱- ارتباط ماژول‌ها در روش‌ سنتیبه همین منظور تمام ماژول‌های اصلی، سبد خرید و حساب من باید یک فراخوانی API به ماژول Login انجام دهند. در نتیجه کدها مربوط به فراخوانی API تنها در یک ماژول اجرا نمی‌شود بلکه در چندین ماژول اجرا می‌شوند، بنابراین در صورت نیاز به تغییر در کد فراخوانی API نیاز است تا تغییرات متعددی در سایر ماژول‌ها نیز انجام گیرد. اما به کمک روش AOP این تغییرات کاهش می‌یابد. در این روش در صورتی که ماژول‌هایی وجود داشته باشند تا بخواهند با هم در ارتباط باشند نیاز به انجام فراخوانی توسط ماژول‌های نیازمند نیست. به عنوان مثال در همان مورد بررسی احراز هویت دیگر نیازی به فراخوانی API توسط هر کدام از سه ماژول ذکر شده نیست و وظیفه‌ی بررسی احراز هویت تنها بردوش جنبه‌ی Login است و این جنبه بدون ماژول‌ها یا جنبه‌هایی که در کد برنامه تغییرات ایجاد می‌کنند این فرایند را کنترل می‌کند. در تصویر ۲ این مورد نشان داده شده است همچنین نام ماژول‌ها نیز به جنبه تغییر کرده است.تصویر ۲- ارتباط میان جنبه‌ها در روش AOPدر تصویر ۳ کد یک ویژگی نمایش داده شده است. در این ویژگی یک کاربر در هر لحظه یک سفارش را بررسی می‌کند، تاریخچه‌ی تراکنش نیز در قسمت تاریخچه نیز وارد خواهد شد. برای پیاده‌سازی این ویژگی، مفهومی به نام نقطه‌ی پیوست (Join Point) و نقطه‌ی برش (Pointcut) تعریف می‌شود. نقطه‌ی پیوست جایی است که کد جنبه اجرا خواهد شد. نقطه‌ی برش نیز کد برنامه است که نقطه‌ی پیوست را انتخاب می‌کند جایی است که کد جنبه اجرا می‌شود. در تصویر ۳ قسمت مربوط به نقطه‌ی برش نشان می‌دهد که کد مربوط به افزودن تاریخچه‌ی تراکنش پس از اجرای متد Checkout در جنبه‌ی AspectCart اجرا خواهد شد. بدین ترتیب این AspectCart عملکرد برنامه‌ی خود را بدون نیاز به کنترل هویت کاربر اجرا می‌کند.تصویر ۳- کد مربوط به Pointcut   پس از طراحی و پیاده‌سازی جنبه‌ها به منظور اجرای آن‌ها نیاز به فرایندی به نام دوختن (Weaving) می باشد. دوختن مکانیزم پایه‌ای استفاده شده برای پیاده‌سازی AOP است که برای سازمان دادن به کلاس‌ها و جنبه‌ها به یک سیستم قابل اجراست. برای آن که بتوان تمام جنبه‌های پیاده‌سازی شده را اجرا نمود، لازم است تا به صورت ضمنی در یک فایل پیکربندی مانند Spring Bean XML که در تصویر ۴ آمده است تعریف شوند. تمام کلاس‌ها و جنبه‌ها با مکانیزم دوختن جهت شکل دادن و اجرای یک برنامه‌ پردازش خواهند شد.تصویر ۴- فایلی که جهت عملیات دوختن باید ساخته شودبدین ترتیب پس از فرایند دوختن محصول نهایی از خط تولید خارج و آماده‌ی بهره‌برداری و استفاده می‌شود.برنامه‌ نویسی مبتنی بر شکست (FragOP)برنامه نویسی مبتنی بر شکست یک روش طراحی و پیاده‌سازی اجزای دامنه‌ی خط تولید نرم‌افزار است و براساس تعریف سه مفهوم زیر بنا شده است:دامنه‌ی اجزانقاط شکست: حاشیه نویسی‌هایی برروی کد اجزای دامنه استشکست‌ها: یک نوع جدیدی از فایل که کد اجزای دامنه را تغییر می‌دهداین سه مفهوم بر پایه‌ی ۶ فعالیت محقق می‌شوند که در ادامه به توضیح هر کدام از شش فعالیت ارائه شده در این روش پراخته می‌شود.طراحی نیازمندی‌های خط تولید: اولین فعالیت فرایند FragOp می‌باشد که در آن باید طرح نیازمند‌ی‌های خط تولید از طریق طراحی ویژگی‌ها ساخته شود. به عنوان مثال در تصویر ۵ ویژگی‌های یک فروشگاه لباس نشان داده شده است که در آن ویژگی‌هایی مانند لیست محصولات، محصول، احراز هویت، مدیر محصول و نمایش کلی محصولات به عنوان ویژگی تعیین شده‌اند. نکته‌ی دیگر در این شکل آن است که برای هر ویژگی تعیین شده که کدام یک اجباری و کدام یک اختیاری می باشد.تصویر ۵- ویژگی‌های یک فروشگاه لباسطراحی اجزای دامنه: در این فعالیت مدل اجزای دامنه ساخته می‌شود و این مدل یک دید انتزاعی نسبت به اینکه اجزا و عناصر دامنه چگونه سازماندهی می‌شوند ارائه می‌دهد. درواقع به کمک این دید انتزاعی می‌توان اجزای دامنه، فایل‌های عملیاتی و اطلاعات در مورد فایل را بدست آورد. در تصویر ۶ به عنوان مثال نشان داده شده است که یک عنصر از اجزا و فایل‌هایی با چه زبانی ساخته شده است.تصویر ۶- اجزای تشکیل دهنده‌ی هر عنصرپیاده‌سازی اجزای دامنه: در این فرایند ساختار خط تولید نرم‌افزار مشخص می‌شود و پوشه‌های اجزای شناسایی شده در فعالیت اول و فایل‌های مربوط به هر عنصر که در فعالیت دوم شناخته شدند ساخته می‌شوند. در این قسمت درواقع یک استخری از اجزا به همراه پیاده‌سازی آن‌ها ایجاد می‌شود. در تصویر ۷ نمونه‌ای از فعالیت نشان داده شده است که در آن در پوشه‌ی ComponentPool یک پوشه‌ی دیگر به نام BasicViewsHtml ایجاد شده است که در آن نیز فایل‌های سازنده‌ی آن قرار دارند. در این مرحله کارهایی مانند پیاده‌سازی فایل‌ها، پیاده‌سازی نقاط شکست و پیاده‌سازی شکست‌ها نیز انجام می‌شود.تصویر ۷- ساختار پوشه‌ها و فایل‌هاپیاده‌سازی فایل‌ها: پیاده‌سازی هر کدام از اجزا و عناصر تعیین شده در این مرحله شروع می‌شود. به عنوان مثال عنصر BasicViewsHtml شامل یک فایل header.php است که در آن کد‌های HTML و PHP نوشته شده است و سرتیتر برنامه را نشان می‌دهد.  کد مربوط به این فایل در تصویر ۸ نشان داده شده است.تصویر ۸- کد عنصر header.phpتصویر ۹- کد عنصر header.php که در آن نقطه‌ی شکست مشخص شده استپیاده‌سازی نقاط شکست: در این مرحله منظور از نقاط شکست، نقاط قابل تغییری است که درون یک فایل مشخص می‌شوند. به عنوان مثال عنصر Login به سرتیتر ساخته شده در BasicViewsHtml نیاز دارد ولی باید تغییراتی در آن صورت گیرد. بنابراین در عنصر header.php یک حاشیه نویسی باید انجام شود تا مشخص گردد که می‌تواند قسمتی از کد توسط یک عنصر دیگه مانند Login تغییر کند. بنابراین کد تصویر ۸ به کد تصویر ۹ تغییر می‌کند. برای نوشتن حاشیه نویسی یک الگویی ارائه شده است که به صورت مقابل می‌باشد: LanguageCommentBlock&lt;B|E&gt;-&lt;PointID&gt;LanguageCommentBlock.  به کمک این الگو محدوده‌ی تغییر الگو را می‌توان تعیین کرد. به عنوان مثال در تصویر ۹ که مربوط به کد header.php می‌باشد، محدوده‌ای که قرار است قابل تغییر باشد به صورت &lt;--B-menu-modificator--!&gt; نشان داده شده است. در این مورد علامت (( --!&gt; )) همان بخش LanguageCommentBlock می‌باشد و B یا E نیز به معنای شروع و پایان محدوده‌ی تغییر است. menu-modificator نیزهمان PointID است که متنی دلخواه است که برای شناسایی نقطه‌ی شکست استفاده می‌شود.پیاده‌سازی شکست: شکست درواقع یک فایل است که در آن توسعه‌دهنده تغییرات کدی که باید در فایل اجزای تعیین شده ایجاد شود را می‌نویسد. ساختار این نوع فایل در تصویر ۱۰ آمده است. در این فایل &lt;Fragment&lt;ID حکم شناسه را برای شکست دارد و برای پیگیری و پیمایش کد مفید می‌باشد. Action نیز نوع تغییر را مشخص می‌کند که می‌توانند اضافه، جایگزین یا پنهان کردن یک بخش از کد باشد. Priority درواقع اولویت شکست را مشخص می‌کند و بدین صورت شکست‌ها با اولویت بالاتر قبل از شکست‌هایی با الویت پایین‌تر یکپارچه می‌شوند. PointBracketsLan نوع نمایش کامنت را نشان می‌دهد که به چه صورت نقطه‌ی شکست تعریف شده است. &lt;...,FragmentationPoints: &lt;PontID 1, PointID 2 نیز نقاط شکست را مشخص می‌کنند و درواقع جاهایی که کد تعریف شده در این فایل باید جایگزین کد اصلی شوند را مشخص می‌کند. &lt;...,Destinations: &lt;fileID1 نشان می‌دهد که کدام فایل‌ها باید تغییر کند. SourceFile: &lt;filename نیز فایلی را مشخص می‌کند که باید جایگزین شود. همچنین در صورتی که قرار باشد یک کد جایگزین شود از SourceCode استفاده می‌گردد و کد مورد نظر در آن نوشته می‌شود. به عنوان مثال در تصویر ۱۱ فایل شکست مربوط به لیست محصولات نوشته شده است که در آن فایل header.php منجر به تغییر خواهد شد.تصویر ۱۰- ساختار فایل شکستتصویر ۱۱- فایل شکاتصال اجزای دامنه به نیازمندی‌های دامنه: در مرحله‌ی آخر از این فعالیت نوبت به توسعه‌ی یک مدل میان مدل‌های نیازمندی‌ها ومدل پیاده‌سازی می‌رسد. درواقع در این مرحله کافی است مدل ویژگی طراحی شده در فعالیت یک و اجزای دامنه در فعالیت دو را به یکدیگر، به تناظر متصل کرد.پیکربندی محصولات: این مرحله شامل انتخاب ویژگی‌های مشخصی است که یک محصول مشخص براساس نیازمند‌ی‌های ذینفعان شامل می‌شوداستخراج محصولات: این فعالیت شامل سه گام می‌شود:تعیین پارامترهای استخراج: در این بخش مسیر پوشه، دارایی‌های اصلی و اجزایی مورد نیاز تعیین می‌شونداجرای استخراج: براساس مسیر‌ها، پوشه‌ها و فایل‌های تعیین شده توسط یک الگوریتم خودکار فایل‌ها با یکدیگر ادغام و یکپارچه می‌شوند تا برنامه‌ی مورد نظر حاصل شود. در تصویر ۱۲ نمونه‌ای از خروجی این مرحله نشان داده شده است که مربوط به header.php در قسمت ListProduct می‌باشدبررسی استخراج: در این مرحله به نوعی فرایند تست و خطایابی انجام می‌شود و خطاهای گرامری برروی فایل‌های استخراج شده پیدا می‌شودتصویر ۱۲- خروجی حاصل از خط تولید که مربوط به فایل header.php می‌باشدابزار ایجاد خط تولید نرم‌افزاربرای ساخت یک خط تولید نرم‌افزار می‌توان از ابزارهای متفاوتی استفاده کرد که فرایند ایجاد این سیستم را راحت و سریع می‌کنند. در ادامه به معرفی سه مورد از این گونه‌ ابزارها پرداخته می‌شود و با برخی ویژگی‌های توضیح داده می‌شود. ابزار Gears  یک ابزار خط تولید نرم‌افزار است که توسط شرکت نرم‌افزاری BigLever توسعه داده شده است. درواقع Gears یک چارچوب چرخه‌ی حیات خط تولید نرم‌افزار است که تمام قابلیت‌های ابزار خط تولید نرم‌افزار را به وسیله‌ی چرخه‌ی حیات توسعه‌ی نرم‌افزار ارائه می‌دهد. . اساس این سیستم FOP است و با استفاده از این روش باید مهندسی خط تولید را انجام داد و آن را ساخت. در جهان نیز سازمان‌ها و شرکت‌ها بزرگی از این محصول برای ایجاد خط تولید خود استفاده نموده‌اند که از جمله‌ی آن‌ها می‌توان به Engenio که یکی از بزرگ‌ترین ارائه دهندگان حافظه‌ی داده است و ارتش ایالت متحده‌ی آمریکا نام بردابزار VariaMos    یک چارچوب و ابزار طراحی است که به راحتی قابل گسترش است و اجازه می‌دهد که بتوانید مدل‌های خود را تعریف کنید. به عنوان ویژگی اصلی آن، از مدل‌سازی‌های ویژگی، اجزا و چسباندن (binding) پشتیبانی می‌کند. همچنین این ابزار یک ابزار متن باز بوده و می‌توان از مخزن گیت هاب آن را دانلود کرد، توسعه و گسترش داد. بنابراین به کمک این ابزار می‌توان مدل‌هایی را توسعه داد تا بتوان یک تولید خط نرم‌افزار را مناسب با روش مورد نظر ایجاد کرد.ابزار Pure::Variant   این ابزار توسط شرکت Pure Systems GmbH توسعه داده شده است و از تمام فازهای توسعه‌ی نرم‌افزار از تشخیص نیازمند‌ی‌ها تا تست و نگهداری پشتیبانی می‌کند. در این ابزار نیازمند‌ی‌ها به صورت مدل‌های ویژگی بیان می‌شود که یک محصول به تنهایی را در خط تولید نرم‌افزار نشان می‌دهد. برای استفاده از این محصول ابتدا باید در سایت شرکت سازنده ثبت نام کنید و لایسنس مربوط به نرم‌افزار را دریافت نمایید. سپس یک پیام به ایمیلی که با آن ثبت نام کردید ارسال می‌شود که در آن پیام نحوه‌ی نصب و استفاده از آن توضیح داده شده است. به گفته‌ی شرکت سازنده‌ی این محصول، نزدیک به ۱۰۰ مشتری و شریک در بخش‌های محتلف شرکت‌ها هستند که در حال استفاده از راه‌حل‌ها و سرویس‌های این شرکت بهره می‌برند و ده‌ها هزار مهندس هستند که فعالیت‌های مهندسی روزانه‌ی خود را به کمک این محصول انجام می‌دهد. اما در سایت این شرکت هیچ اسمی از شرکت‌های استفاده کننده‌ از این محصول دیده نشد.    نکته‌ای که در انتخاب ابزار مهم است شیوه‌ی مدل‌سازی و روشی است که برای ایجاد خط تولید نرم‌افزار قرار است مورد استفاده قرار گیرد. در همان ابتدا روشی که قرار استفاده شود باید مشخص گردد. به عنوان مثال اگر قرار است که یک خط تولید نرم‌افزار مبتنی بر ویژگی ایجاد شود می‌توان از ابزار Gears استفاده نمود اما اگر قرار باشد که از FragOP استفاده شود دیگر نمی‌توان از این ابزار استفاده کرد و می‌توان به سراغ ابزار VariaMos رفت و به کمک آن خط تولید خود را ایجاد کرد.موارد استفاده از خط تولید نرم‌افزاردر این بخش به توضیح دو مورد از خطوط تولید نرم‌افزار پرداخته می‌شود که در محیط صنعتی و آموزشی راه‌اندازی و استفاده شدند. شرکت HomeAway   این شرکت رهبر جهانی اجاره‌ اقامتگاه برای تعطیلات به صورت آنلاین است. این شرکت صاحبان خانه و مدیران املاک را به مسافرانی که به دنبال فضایی جهت اقامت می‌گردند، متصل می‌کند. از نظر گستره‌ی جغرافیایی نیز این شرکت در نزدیک به ۱۰۰ کشور فعالیت دارد و بیش از ۵۰ میلیون کاربر جهت انتخاب و اجاره خانه به این شرکت مراجعه می‌کنند. این شرکت برای ارتباط مشتریان خود در جاهای مختلف جهان محصولات نرم‌افزاری دارد که از جمله‌ی آن‌ها می‌توان به HomeAway.com، Verbo.com، CeyberRentals.com، Holiday-Rentals.co.uk و FeWo-direkt.de اشاره کرد. تمام این محصولات از یک خانواده می‌باشند. شرکت BigLevers روش خط تولید نرم‌افزار را برای این شرکت پیاده‌سازی نمود. مجموعه‌ای از دارایی‌ها با قابلیت استفاده‌ی مجدد برای محصولات ذکر شده که می‌توانند درگاه‌های وب، سیستم‌های مدیریت محتوا (CMS)، عملکرد واسط کاربری گرافیکی، اضافه و حذف ویژگی‌ها، منو و صفحات وب و غیره. به ویژگی‌های متغیری که در این سیستم‌ها وجود دارد می‌توان به زبان، مکان جغرافیایی و برند و غیره اشاره نمود. بنابراین شرکت HomeAway از روش خط تولید نرم‌افزار و چارچوب Gears برای انتقال از توسعه‌ی رسمی و سنتی نرم‌افزار به توسعه‌ی خط تولید استفاده کرد. Gears شرکت HomeAway را قادر به تولید جداگانه و خودکار، ساخت، آزمون و استقرار سایت‌ها نمود.فروشگاه لباس   در یکی از کارهای آموزشی برای ارزیابی روش FragOP پنج محصول نر‌م‌افزاری در نظر گرفته شده بود که تمام این محصولات از یک خانواده بودند و در زمینه‌ی فروش لباس فعالیت می‌کردند. برای تولید این پنج محصول از روش خط تولید نر‌م‌افزار استفاده شد. از ویژگی‌های این فروشگاه‌ها می‌توان به خرید، سبد خرید، مدیریت سایت، سیستم اشتراک‌گذاری، احراز هویت، مدیریت پایگاه داده اشاره کرد. در این پیاده‌سازی از ابزار VariaMos استفاده شد و آن را متناسب با مدل‌ و روش FragOP که در بخش سوم توضیح داده شد تغییر دادند. در مجموع ۲۵ ویژگی و ارتباط میان آن‌ها طراحی شد، ۲۰ عنصر ساخته شد که در مجموع منجر به تولید ۸۰ فایل شد که از این ۸۰ فایل، ۴۶ مورد فایل‌های اجزای دامنه بودند و ۳۶تای دیگر شکست‌ها. در انتهای این پیاده‌سازی، نتایج حاصل از استخراج پنج محصول به کمک روش FragOP در تصویر ۱۳ آمده است. در این تصویر ستون اول نام محصول، ستون دوم تعداد ویژگی‌های انتخابی برای هر محصول، ستون سوم فایل‌های پیوند شده میان ویژگی‌های انتخاب شده و فایل‌های عنصر متناظر، ستون چهارم تعداد خط کدی که برای استخراج محصول نهایی به صورت دستی تغییر کردند و ستون پنجم نیز زمان مورد نیاز برای استخراج محصول را نشان می‌دهد. نکته‌ای که در این روش وجود داشت تغییر تنها ۳ خط کد به صورت دستی جهت تولید محصول مورد نظر بود. تصویر ۱۳- نتیجه‌ی تولید ۵ محصول مشابه فروشگاه لباس به کمک خط تولید به روش FragOPدر هر دو مورد بررسی شده محصولاتی مورد نظر با کمترین میزان تغییرات کد و در زمانی بسیار کمتر نسبت با زمانی که هر کدام به صورت جداگانه پیاده‌سازی می‌شدند، تولید شدند. نتیجه‌گیریبرای تولید نر‌م‌افزارهای مشابه که از یک خانواده هستند و عملکردی یکسان دارند، مانند CMSها و e-commerceها، به جای آن که هر محصول را به صورت جداگانه توسعه داد می‌توان از خط تولید نرم‌افزار استفاده کرد. خط تولید نرم‌افزار کمک می‌کند تا اجزا و دارایی‌هایی که ثابت هستند را دیگر مجدد پیاده‌سازی نکنیم و امکان استفاده‌ی مجدد آن‌ها را در محصولات مشابه فراهم می‌کند. خط تولید نرم‌افزار مزایای زیادی مانند عرضه‌ی سریع‌تر محصول به بازار، هزینه‌ی مالی و زمانی کمتر، کاهش ریسک و خطاها و در نهایت رضایت مشتری را به همراه خواهد داشت. البته ایجاد و نگهداری خط تولید چالش‌هایی دارد. به عنوان مثال مدت زمانی که برای ایجاد اولین محصول صرف می‌شود زیادتر از زمانی است که برای تولید یک محصول به تنهایی صرف می‌گردد و نگهداری از آن با توجه به تغییراتی که در نیازمندی مشتریان و کسب و کار رخ می‌دهد دشوار است و برخی تغییرات بنیادین هزینه‌ی زیادی خواهد داشت. در خط تولید نرم‌افزار مهندسی این خط تولید بسیار اهمیت دارد و باید به خوبی دامنه و محدود‌ه‌ی فعالیت‌های نرم‌افزار و نیازهای آن را شناسایی کرد که به این کار مهندسی دامنه می‌گویند. پس از شناسایی دامنه و اجزای آن و پیاده‌سازی اجزا نوبت به مهندسی برنامه می‌رسد که مربوط به بخش توسعه‌ی نرم‌افزار و ترکیب اجزای ساخته شده در مهندسی دامنه می‌باشد. نکته‌ای که در خط تولید نرم‌افزار مهم است مدیریت دارایی‌ها متغیر یا همان ویژگی‌های متغیر است. برای پیاده‌سازی خط تولید نرم‌افزار به همراه مدیریت این ویژگی‌ها روش‌هایی ارائه شده است که از الگوهای برنامه نویسی بهره برده‌اند مانند FOP، AOP و FragOP.  نکته‌ای که برای ایجاد خط تولید اهمیت دارد همین انتخاب روش توسعه است که با کدام یک از روش‌ها می‌توان نیاز ذینفعان را بهتر برطرف نماید. همچنین انتخاب روش در انتخاب ابزار ایجاد خط تولید نرم‌افزار نیز موثر است و متناسب با روش تعیین شده باید ابزار مناسب را انتخاب کرد. اما در کل روش FragOP را می‌توان ترکیبی از دو روش AOP و FOP دانست که بنظر می‌آید که از انعطاف بیشتری نسبت به دو روش دیگر برخوردار باشد و در صورت وجود آمدن نیاز جدید نیاز به انجام تمام مراحل ایجاد خط تولید از ابتدا دیگر نباشد. همچنین این روش از این نظر شبیه AOP می‌باشد که مرحله‌ای مانند دوختن در انتها دارد و از این نظر مشابه FOP می‌باشد که تمام مراحل مربوط به مهندسی دامنه در آن نیز باید با دقت انجام شود. هر چند که در فعالیت پیاده‌سازی اجزای دامنه بنظر می‌رسد که گام مربوط به اتصال اجزای دامنه به نیازمندی‌های دامنه اضافه باشد و می‌توان از آن به عنوان یک مرحله‌ی اختیاری یاد کرد. البته در راستای مستندسازی می‌تواند کمک کننده باشد. مراجعApel, Sven, Don Batory, Christian Kästner, and Gunter Saake. Feature-oriented software product lines. Springer-Verlag Berlin An, 2016Munir, Qaiser, and Muhammad Shahid. &quot;Software product line: Survey of tools.&quot; (2010)Marques, Maíra, Jocelyn Simmonds, Pedro O. Rossel, and María Cecilia Bastarrica &quot;Software product line evolution: A systematic literature review.&quot; Information and Software Technology 105 (2019): 190-208Iswari, Ni Made Satvika, Eko K. Budiardjo, and Zainal A. Hasibuan. &quot;Aspect Oriented Programming Approach for Variability Feature Implementation in Software Product Line Engineering.&quot; In 2020 Fifth International Conference on Informatics and Computing (ICIC), pp. 1-5. IEEE, 2020Correa, Daniel, Raúl Mazo, and Gloria Lucia Giraldo-Goméz. &quot;Fragment-oriented programming: a framework to design and implement software product line domain components.&quot; Dyna 85, no. 207 (2018): 74-83https://biglever.com/company/customers (last_updated: 2/12/2022)https://variamos.com/home/variamos-web/https://insights.sei.cmu.edu/blog/decisions-for-sustaining-a-software-product-line/این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>محمد ربانی بیدگلی</category>
                <author>محمد ربانی بیدگلی</author>
                <pubDate>Sat, 12 Feb 2022 20:44:26 +0330</pubDate>
            </item>
                    <item>
                <title>API Gateway</title>
                <link>https://virgool.io/@rabbani_mohammad/api-gateway-n5ltxaqub4ka</link>
                <description>مقدمهامروزه در تولید نرم‌افزار کلمه‌ی API بسیار شنیده می‌شود. API درواقع یک واسط نرم‌افزاری است که اجازه می‌دهد دو برنامه بدون دخالت کاربر با یکدیگر ارتباط داشته باشند و مجموعه‌ای از عملکردها و رویه‌ها است. در تصویر ۱ نشان داده شده است که چندین برنامه به یک API متصل شده‌اند و به وسیله‌ی آن اطلاعات را از یک پایگاه داده دریافت می‌کنند. تصویر ۱ - api چیستحال فرض کنید که یک برنامه قرار است که با چندین API به طورهمزمان در ارتباط باشد. یک راه ساده که به ذهن می‌رسد آن است که به طور مستقیم برنامه‌ی مورد نظر را به APIها متصل کنیم. این کار معایبی دارد مانند ارسال تعداد زیاد درخواست به هرکدام از APIها که باعث کاهش سرعت برنامه و همچنین پیچیدگی برنامه می‌شود و مورد بعدی آن است که هر کدام از APIها ممکن است پروتکل مخصوص به خود را داشته باشند که هماهنگ کردن آن پروتکل‌ها نیز دردسرهای خود را دارد. برای حل این مشکلات ابزاری معرفی شده است به نام API Gateway. API Gateway یک ابزار مدیریت API است که میان یک مشتری و مجموعه‌ای از سرویس‌های back قرار می‌گیرد. یک API Gateway مانند یک پروکسی برعکس برای پذیرش تمام فراخوانی‌های API عمل می‌کند. درواقع سرویس‌های گوناگون مورد نیاز را برای تحقق آن‌ها تجمیع می‌کند و نتیجه‌ی مناسب را برمی‌گرداند. به گونه‌ای می‌توان گفت که یک واسط است که این امکان را برای مشتری فراهم می‌کند تا همزمان با چند API در تماس باشند.اکثر API‌های سازمانی برروی API Gateway مستقر شده‌اند. برای Gateway API کنترل وظایف مشترکی که حول یک سیستم از سرویس‌های API مانند احرازی هویت کاربر، rate limit، امارها استفاده می‌شود، رایج است. در پایه‌ای ترین حالت، یک سرویس API یک درخواست را می‌پذیرد و یک پاسخ برمی‌گرداند. اما در زندگی واقعی به این سادگی نیست. هنگام بررسی درخواست و ارسال پاسخ از سمت API، نگرانی هایی وجود دارد مانند:جلوگیری از استفاده نامناسب یا بیش از اندازه که در این حالت می‌توان از rate-limit و احراز هویت استفاده کردبرای آنکه بفهمیم چگونه از APIاستفاده می‌شود از ابزارهای نظارتی استفاده می‌کنیم اگر APIهای پولی داشته باشیم، به یک سیستم پرداخت متصل می‌خواهیم بکنیماگر از معماری میکروسرویس استفاده کرده باشیم برای یک درخواست ممکن است که چندین برنامه‌ی مجزا را صدا بزنیمدر طول توسعه چندین سرویس APIجدید اضافه می‌کنیم و برخی را هم باز نشسته ولی مشتری هنوز می‌خواهد تمام سرویس‌ها را در یک جا پیدا کنداین چالش‌ها و حل آن‌ها سبب می‌شود که یک تجربه‌ی ساده و قابل اعتماد در مواجه با تمام پیچیدگی پیشنهاد شود. یک API Gateway درخواست را به چند درخواست تقسیم می‌کند، به جای درست هدایت می‌کند  و یک پاسخ می‌سازد و تمام عملیات را پیگیری می‌کند.یک Gateway API قسمتی از سیستم مدیریت APIاست. درواقع  API Gateway تمام درخواست‌های ورودی را قطع می‌کند و آن‌ها را به سیستم‌ مدیریت API می‌فرستد که انواع گوناگونی از عملکردهای ضروری را کنترل می‌کند. کاری که  API Gateway دقیقا انجام می‌دهد با توجه به پیاده سازی فرق خواهد کرد. برخی از عملکردهای مشترک شامل احراز هویت، rate limit، مسیریابی، پرداخت، نظارت، تحلیل، سیاست‌ها و امنیت است.در سازمان‌هایی که از شیوه DevOps استفاده می‌کنند، توسعه دهندگان از میکروسرویس‌ها برای ساخت و استقرار برنامه‌ها در یک راه سریع و تکرار شونده استفاده می‌کنند. APIها یکی از بهترین و رایج‌ترین راه‌های ارتباطی میکروسرویس‌ها هستند. علاوه‌ بر این، توسعه مدرن ابری، شامل مدل بدون سرور، برای تامین زیرساخت به APIها نیاز بستگی دارد. شما می‌توانید عملکردهای بدون سرور خود را مستقر کنید و با استفاده از یک Gateway API آن‌ها را کنترل نمایید. در این‌جا بدون سرور(Serverless) منظور حذف سرور از روند تولید نرم‌افزار و قرار داد برنامه‌ برروی آن نیست بلکه بدون سرور یک مدل توسعه‌ی ابری است که به توسعه دهندگان این اجازه را می‌دهد تا بدون آنکه نیاز باشد که سرور را مدیریت کنند، برنامه‌ی خود را بسازند و اجرا کنند. بنابراین کماکان در بدون سرور ما سرور داریم ولی تبدیل به یک انتزاع می‌شود و دیگر توسعه دهندگان درگیر تنظیم آن نمی‌شوند. به طور کلی، چون یکپارچگی و اتصال به یکدیگر مهم‌تر می‌شود، بنابراین APIها نیز به همان اندازه اهمیت پیدا می‌کنند. و چون پیچیدگی API بیشتر می‌شود و استفاده از آن‌ها رشد می‌کند پس ارزش یک  API Gateway نیز مشخص می‌شود. در ادامه به توضیح دو سیستم API Gateway  خواهیم پرداخت که متن باز بوده و توسعه‌ دهندگان می‌توانند رایگان از آن استفاده کنند و آن‌ها را تغییر دهندنرم‌افزارهای متن بازیکی از این برنامه‌های متن باز که سرویس  API Gateway را ارائه می‌دهد Kong Gateway نام دارد که معروف و ابری است و از تمام پلتفرم‌ها نیز پشتیبانی می‌کند. به زبان برنامه‌نویسی Lua نوشته شده است و زیرساخت‌های چند-ابری و ترکیبی را پشتیبانی می‌کند و برای معماری توزیع‌ شده و میکروسرویس‌ها بهینه شده است. هدف از ایجاد Kong کارکرد، قابل گسترش و قابل حمل بالا است و سبک وزن، سریع و مقیاس‌پذیر نیز هست. از ویژگی‌های این نرم‌افزار می‌توان به load balancing، گزارش لاگ، احراز هویت، rate-limit، تبدیلات، نظارت در لحظه، تشخیص سرویس، کش کردن، تشخیص و بازیابی خطا و خوشه‌بندی گره‌ها و عملکردهای بدون سرور اشاره کرد. این نرم‌افزار از تنظیمات پروکسی‌ها برای سرویس‌ها پشتیبانی می‌کند و برروی SSL آن‌ها را اجرا می‌کند، یا از WebSocketها استفاده می‌کند. او می‌تواند تعادل بار ترافیک را از طریق جایگزینی سرویس‌های upstream، نظارت بر دسترس‌پذیری سرویس‌ها، تنظیم کند. علاوه ‌براین، Kong با یک واسط خط دستور منتقل می‌شود که اجازه می‌دهد تا یک خوشه Kong را از طریق خط دستور کنترل کرد. همچنین، این نرم‌افزار را با استفاده از افزونه‌ها، قابل گسترش است و می‌تواند با RESTful API آن برای حداکثر انعطاف‌پذیری مدیریت شود.نرم‌افزار متن باز دوم Tyk نام دارد که نرم‌افزاری قدرتمند، سبک و کامل برای  API Gateway است که با زبان Go توسعه داده شده است. این نرم‌افزار نیز یک نرم‌افزار ابری است و با کارایی بالا با یک توسعه‌پذیری آسان و معماری قابل اتصال براساس استانداردهای متن باز است. برای اجرا تنها به Reddis برای ذخیره داده نیاز دارد و به صورت مستقل قابل اجراست. به کاربران اجازه می‌دهد تا به صورت امن انواع گوناگونی از سرویس‌ها را منتشر و مدیریت کنند که شامل legacy, REST, و GraphQL می‌شود. از سرویس‌هایی که Tykدارد می‌توان به روش‌های احراز هویت، quatas, rate-limit, version control، اعلانات و رویدادها، نظارت، و تحلیل‌ها اشاره کرد. همچنین از تشخیص سرویس، تبدیلات و پایانه‌های مجازی پشتیبانی می‌کند و ساخت APIهای ساختگی قبل از انتشار را اجازه می‌دهد. همچنین از مستندسازی APAI نیز پشتیبانی می‌کندو  یک درگاه توسعه‌ دهنده API نیز پیشنهاد می‌دهد که مانند یک CMS است که در آن می‌توان APIهای مدیریت شده را منتشر کرد و سایر توسعه ‌دهندگان ثبت‌نام کنند و در APIها  وارد شوند و کلیدهای خودشان را مدیریت کنند. نکته‌ی مهم آنکه تنها یک ورژن از Tyk Api Gateway موجود می‌باشد و کاملا هم متن باز است که همین سبب می‌شود تا از تمام امکانات آن به طور کامل بتوان استفاده کرد و دارای دو نسخه community or enterprise نیست.البته برای برخی از سازمان‌ها که تیم توسعه‌ی تیم‌ نرم‌افزار ندارند می‌توانند از شرکت‌هایی که این سرویس را ارائه می‌دهند استفاده کنند و محصول آن‌ها را خریداری کنند. در ایران نیز شرکت‌هایی هستند که این خدمت را ارائه می‌دهند که در بخش بعدی به معرفی دو شرکت ایرانی خواهیم پرداخت.ارائه دهندگان سرویس API Gatewayشرکت‌هایی در ایران هستند که این سرویس را ارائه می‌دهند مانند شرکت وصل و درسا کلود. شرکت وصل نام سرویس مدیریت API که ارائه می‌دهد را سورنا گذاشته است. امکاناتی که توسط این سرویس به کاربر ارائه می‌شود می‌توان به موارد زیر اشاره کرد:فراهم کردن امنیت سرویس با سیاست‌های امنیتی و همچنین نظارت و تحلیل داده‌ها، کنترل دسترسیامکان اضافه کردن مجموعه‌ای از سرویس‌های خود با قیمت و زمان مشخص به فروشگاه سورنا. این ویژگی سبب می‌شود تا سایر کاربران نیز از APIهای شما استفاده کند وشما نیز در‌امد کسب کنیدامکان اضافه کردن تمام خدمات در حوزه‌ی IOT به پنل مدیریت. این امکان برای آن است که API Gateway را با اینترنت اشیا یکپارچه نماییددارای ویژگی تحلیل دقیق و کاربردی. این ویژگی به کاربران کمک می‌کند تا عملکرد سیستم خود را افزایش دهند و از وضعیت پاسخگویی آن‌ها آمار و گزارشات دقیق در اختیار داشته باشنددرسا کلود نیز یک سرویس API Gateway ابری ارائه می‌دهد که قادر است APIهای سیستم‌های تجاری را مدیریت کند بدون در نظر گرفتن مکان سیستم‌های تجاری چه در ابر درسا باشد، مراکز داده محلی یا ابرهای شخص ثالث. این سرویس به عنوان یک سرویس ابری بالع عمل می‌کند که اجازه دسترسی به خوشه‌های برنامه‌ Kubernetes را می‌دهد. Kubernetes یک سیستم هماهنگ‌ کنند کانتینر متن باز است برای خودکارسازی استقرار و مدیریت برنامه‌های کامپیوتری. این سرویس به طور قابل توجهی قابلیت‌های سرویس خوشه‌های برنامه Kubernetes را بهبود می‌بخشد و این معماری به عنوان معماری استاندارد برای برنامه‌های کاربردی اینترنت در مقیاس بزرگ عمل می‌کند.جمع بندیبرای مدیریت APIها از ابزاری به نام API Gatewayاستفاده می‌کنیم. این سرویس کمک می‌کند تا برروی چگونگی استفاده از APIها نظارت داشته باشیم، برای استفاده از آن‌ها محدودیت اعمال کنیم و با یک درخواست از سمت کاربر چندین api را صدا کرد. بنابراین استفاده از چنین سرویسی زمانی که قرار است یک برنامه از چند API استفاده کند ضروری است. نرم‌افزارهایی هستند که این سرویس را به صورت رایگان و متن باز در اختیار سازمان‌ها و توسعه دهندگان قرار می‌دهد و می‌توانند از آن استفاده کنند مانند Kong Gateway و Tyk. همچنین برای برخی از سازمان‌ها که کوچک هستند و تیم توسعه‌ی نرم‌افزار ندارند می‌توانند از شرکت‌هایی که این خدمت را به صورت آماده ارائه می‌دهند استفاده کنند مانند شرکت‌های درسا کلود و وصل که این سرویس را در ایران ارائه می دهندمراجعhttps://www.redhat.com/en/topics/api/what-does-an-api-gateway-dohttps://aws.amazon.com/api-gateway/https://www.tecmint.com/open-source-api-gateways-and-management-tools/https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3%D9%87%D8%A7-%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-api-gateway-qaaprddghopfhttps://dorsacloud.com/service-post/api-gateway-service/https://en.wikipedia.org/wiki/Kuberneteshttp://vasl.ir/این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>محمد ربانی بیدگلی</category>
                <author>محمد ربانی بیدگلی</author>
                <pubDate>Fri, 24 Dec 2021 06:50:31 +0330</pubDate>
            </item>
                    <item>
                <title>سیستم مدیریت لاگ</title>
                <link>https://virgool.io/@rabbani_mohammad/%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%84%D8%A7%DA%AF-agrlazwhorrv</link>
                <description>sumologicمقدمهشاید برای شما پیش آمده باشد که با سیستمی بزرگ تحت وب یک کاری را انجام داده باشید و آن کار برای شما مشکلاتی را بوجود آورد مانند پاک کردن یک اطلاعات مهم. سپس شما به تیم پشتیبانی زنگ زده و درخواست می‌کنید که آن مشکل را در صورت امکان برطرف نمایند و آن‌ها نیز می‌گویند بررسی می‌کنند. هنگامی که با شما تماس می‌گیرند تا صحت عمل انجام شده و زمان انجام آن را بررسی کنند، زمان دقیق، نوع عمل و اینکه برروی کدام داده این کار را انجام داده‌اید را به شما خواهند گفت. تمام این اطلاعات دقیقی که به شما می‌گویند حاصل ذخیره‌ی اطلاعات کارهایی است که به صورت لحظه‌ای توسط سرور و سایر سیستم‌ها به صورت خودکار در یک فایل به نام فایل لاگ انجام می‌شود. یک لاگ درواقع فایلی است که توسط سسیتم تولید می‌شود که فعالیت‌هایی که در سیستم‌عامل یا برنامه‌های نرم‌افزاری رخ می‌دهد را ثبت می‌کند. فایل لاگ به صورت خودکار هر اطلاعات طراحی شده توسط مدیران سیستم مستند می‌شود مانند: پیام‌ها، گزارشان خطا، درخواست‌های فایل و انتقال فایل‌ها. این رکوردهای ثبت شده حاوی زمان نیز هستند که کمک می‌کنند تا زمان وقوع کارها را فهمید.لاگ‌های ثبت شده حجم بسیار بالایی دارند و بررسی آن‌ها کار ساده‌ای نیست زیرا در هر ثانیه چندین عمل را دارند ثبت می‌کنند با فرمت‌های مخاتلف. بنابراین به سیستمی نیاز داریم که به کمک آن بتوان لاگ‌ها را مدیریت کرد. ابتدا باید به این نکته اشاره کرد که مدیریت لاگ یک کاربرد جمع آوری، مرتب کردن، پردازش، سنتز و تحلیل داده به صورت مدام است از برنامه‌های مجزا به منظور بهینه کردن عملکرد سیستم، شناسایی مسائل فنی، مدیریت بهتر منابع، تقویت امنیت و بهبود انطباق. مدیریت لاگ شامل دسته‌های محتلفی می‌شوند.· مجموعه: یک ابزار مدیریت لاگ که داده را از سیستم عامل، برنامه‌ها، سرورها، کاربران، پایانه‌ها یا هر منبع مرتبط با سازمان جمع ‌آوری می‌کند· نظارت: ابزار نظارت لاگ فعالیت‌ها و کارها هنگامی که رخ می‌دهند را به خوبی دنبال می‌کند· تحلیل: این ابزار مجموعه لاگ را بازنگری می‌کند. از سرور لاگ برای شناسایی لاگ‌ها، تهدیدهای امنیتی و سایر مسائل· شاخص بندی یا جستجو: ابزاری که کمک می‌کند به واحد IT سازمان تا داده را خول تمام لاگ‌ها فیلتر، مرتب و جستجو کند· گزارش: یک ابزار پیشرفته که گزارش‌دهی از لاگ‌ها به گونه‌ای که مرتبط به عملکرد عملیاتی، اختصاص منابع، امنیت یا انطباق نظارتی انجام می‌دهدسیستم مدیریت لاگ یک سیستم نرم‌افزاری است که داده و لاگ‌های فعالیت را از منابع مختلف در یک مکان مرکزی جمع‌آوری، ذخیره و مرتب می‌کند. سیستم مدیریت لاگ به تیم DevOps،‌ SecOps و ITاین امکان را می‌ٔهد تا به اطلاعات لاگ‌های فعالیت شبکه و برنامه‌های مختلف دسترسی داشته باشند و از طرف دیگر این لاگ‌های ذخیره شده قابل جستجو و فیلتر هستند و شاخص بندی شده‌اند. بنابریان تیم ‌ITمی‌تواند به راحتی به داده‌‌ای که نیاز دارد تا در مورد سلامت شبکه، تخصیص منابع یا امنیت تصمیم بگیرد. ابزار مدیریت لاگ برای کمک به سازمان جهت مدیریت حجم بالای داده لاگ تولید شده حول سازمان استفاده می‌شود که این ابزار کمک به تشخیص موارد زیر می‌کند:- چه داده و اطلاعاتی باید لاگ شود- رکوردهای لاگ به چه صورت باید باشد- در چه بازهایی داده‌ها باید ثبت شوند- چگونه داده‌ها زمانی که دیگر مورد نیاز نیستند دور از بین بروندبنابراین سیستم مدیریت لاگ برای سازمان مهم می‌تواند با اهمیت باشد زیرا نقش موثری در بسیاری از مسائل امنیت و اشکالات داشته‌اند. یک راه حل مدیریت لاگ موثر به سازمان‌ها موارد زیر را ارائه می‌دهد:· ذخیره داده واحد به وسیله‌ی لاگ متمرکز· بهبود امنیت با کاهش سطح حمله، نظارت  در لحظه و بهبود زمان تشخیص و پاسخ· بهبود شفافیت حول سازمان از طریق لاگ کارهای عادی· بهبود تجربه کاربر با بررسی و تحلیل داده لاگ· قابلیت سریع‌تر و دقیق عیب‌یابی با تحلیل شبکه پیشرفتهکمی پیشتر در مورد مدیریت لاگ متمرکز گفته شد. درواقع مدیریت لاگ متمرکز ‌عمل تجمیع تمام داده لاگ در یک مکان واحد و فرمت مشترک است. چون داده از منابع مختلف می‌آیند باید تلفیق و استاندارد شوند قبل از آنکه سازمان بینش معناداری را بتواند تولید کند. مرکز گرایی، فرایند تحلیل را ساده می‌کند و سرعت ‌انکه بکاربردن کدام داده بدرد کسب‌و‌کار می‌خورد را افزایش ‌می‌دهد.در میریت لاگ چالش‌های وجود دارد:· استانداردسازی: همانگونه که قبلا گفته شد برای آنکه لاگ‌ها در یک جا تحمیع شوند لازم است تا فرمت آن‌ها یکسان باشد و با یک استاندارد مشخصی ذخیره شوند.· حجم: سیستم مدیریت لاگ‌ها باید به گونه‌های طراحی شوند که بتوانند حجم بالای داده‌ای که از سمت شبکه و برنامه‌های موجود ایجاد می‌شود را استاندارد، ذخیره و تحلیل کنند.· تاخیر: افزایش تاخیر مربوط به چگونه شاخص‌بندی داده توسط سیستم‌های مدیریت لاگ است. شاخص‌بندی عمل بسیار محساباتی و هزینه‌بری می تواند باشد. تاخیر میان ورود داده یک سیستم و سپس در نتایج جستجو و تجسم گنجانده می‌شوند.· بار مسئولیتی بالای IT: هنگامی که به صورت دستی انجام شود، مدیریت لاگ به طور شگفت‌انگیزی زمان‌بر و هزینه‌بر است. ابزار مدیریت لاگ دیجیتال کمک به خودکار سازی برخی از این کارها می‌کنند و فشار را به متخصصان ITکاهش می‌دهد.نرم‌افزارهایی هستند که سرویس مدیریت لاگ را در اختیار کاربران قرار می‌دهند اما برای استفاده از آن‌ها نیاز به پرداخت هزینه و خرید اشتراک است. اما برخی دیگر هم هستند که به صورت متن باز وجود دارند و سازمان‌هایی که تیم ‌توسعه‌ی نرم‌افزار دارند می‌توانند از آن استفاده کنند و آن را توسعه دهند. در بخش بعدی به معرفی دو سیستم مدیریت لاگ متن باز می‌پردازیمنرم‌افزارهای متن بازFluent یکی از این نرم‌افزارهای متن باز و رایگان است که کمک می‌کند تا لاگ‌ها را در یک بافر ذخیره کنیم. سرویس‌هایی که پیشنهاد می‌دهد شامل تعادل بار، تلاش مجدد برای حفظ استحکام است. این برنامه بیش از ۵۰۰ پلاگین برای منابع و خروجی ارائه می‌دهد. از ویژگی‌های این نرم‌افزار می‌توان به موارد زیر اشاره کرد:· داده‌ها را چندین منبع می‌تواند جدا کند· یک ساختار برای فهم لاگ‌ها ارائه می‌دهد· تنظیم کردن آن ساده است· به صورت بی‌درنگ از ماشین‌ها داده جمع ‌آوری می‌کند· کمک می‌‌کند تا لاگ‌ها را تحلیل کنیم به راحتی· مدیریت و نظارت بر فایل‌های موجود را فراهم می‌کندنرم‌افزار دیگر نیز که رایگان و متن باز است Graylog نام دارد. این نرم‌افزار یک سیستم براساس لاگ است که یک واسط کاربری گرافیکی نیز دارد. این سیستم شامل توابع پرسش و جستجو است که اجازه می‌دهد تا رکوردها را با توجه به راحتی کاربر فیلتر شوند. این برنامه شمال یک داشبورد برای دیدن جزئيات رکوردها است. از جمله ویژگی‌های این نرم‌افزار عبارت‌اند از:· هشدار سریع‌تری در مورد خطرات سایبری می‌دهد· داده‌ را تحلیل می‌کند و یک پاسخ موثر را ارائه می‌کند· برروی داده‌ها هشدارها و گزارشات شهودی می‌دهد· داده‌ها را جمع آوری، سازماندهی و تحلیل می‌کند· ویژگی‌هایی برای کنترل دسترسی براسا نقش، لاگ‌های حسابرسی و تحمل خطا داردبرای سازمان‌هایی نیز که تیم توسعه‌ی نرم‌افزار ندارند پیشنهاد می‌شود که از سرویس‌ آماده‌ی مدیریت لاگ که توسط برخی از شرکت‌های نرم‌افزار ارائه می‌شود استفاده کنند. در بخش بعد دو شرکتی که این سرویس را در ایران ارائه می‌دهند معرفی می شوند.ارائه دهندگان سرویس مدیریت لاگشرکت کوالاتک، یکی از شرکت‌هایی است که سرویس مدیریت لاگ را در ایران ارائه می دهد. این ابزار کمک می‌کند تا لاگ‌ها به صورت خودکار جمع‌اوری شوند و طبق نیاز سازمان، دسته بندی‌های لازم برای هر لاگ صورت می‌گیرد. جمع آوری لاگ از چندین منبع صورت می‌گیرد که این کار توسط مجموع ابزار Beatانجام می‌شود. همچنین لاگ‌های جمع‌آوری شده را متناسب با نیازهای عام و خاص هر سازمان به داده تبدیل می‌کند تا مواجه، مطالعه و تجزیه و تحلیل داده برای سازمان آسان باشد. مدیر سیستم با این ابزار بجای اطلاعات فنی با داده‌های ساده در ارتباط است. امکان جستجوی لاگ را هم دارد و کمک به دسترسی سریع به لاگ را فراهم می‌کند. مدیر سیستم نیز می‌توان به راحتی متوجه شود که لاگ‌های موجود در سیستم مربوط به چه بخش‌هایی می‌باشد یا در قسمت هشدار، لاگ‌هایی که مربوط به بخش‌های حساس هستند به محض ایجاد، برای مدیر، آلارم ارسال می‌شود. همچنین امکان گزارش گیری را نیز فراهم می‌کند که در این قسمت مدیر سیستم می‌تواند نمای کلی از اتفاقات و آمار‌های مربوط به لاگ‌ها را در یک نمای کلی ببیند. این اطلاعات و آمارها از طریق نمودارها والمان‌های تصویری در بخش داشبورد به مدیر سیستم ارائه می‌شود.سامانه‌ی دیگر مدیریت لاگ آتین است. این سیستم نیز امکان ثبت خودکار رفتارهای کاربران و رخدادهای مرتبط، ثبت وقایع امنيتي تعریف شده در برنامه های کاربردی، امکان پیگیری وقایع و گزارش گیری، امکان نظارت بر عملکرد کلیه کاربران، محفوظ ماندن فعاليت كاربران از سايرين به جز مدیران سامانه و ثبت وقایع در سطوح مختلف به منظور کاهش ریسک های دسترسی به اطلاعات و خدمات را فراهم می‌کند و از مزایای این سیستم به افزایش امنیت، افزایش آگاهی از مشکلات زیرساخت شبکه، کنترل دسترسی به سرور، خدمات و برنامه‌های کاربردی،‌ تشخیص سریع قطع شدن شبکه و ایراد در پروتکل، تشخیص سریع فرایندها، سرویس‌ها، کارهای دوره‌ای و کارهای دسته‌ای شکست خورده، انطباق ممیزی و انطباق با مقررات اشاره شده است.جمع بندیعملیات و رویدادهایی که در هر سیستم سازمانی اتفاق می‌افتد لازم است که ثبت شوند تا مدیران سیستم و به طور کلی واحد ITاز آن‌ها با خبر باشند تا زمانی که اتفاقی افتاد و مشکلی پیش آمد دلیل آن مشکل را بفهمند و بتوانند بررسی کنند. از این رو می‌توان از فایل‌هایی به نام لاگ استفاده کرد. لاگ‌ها فایل‌هایی است که کارکردها سیستم را به طور خودکار ثبت و ذخیره می‌کنند. در یک فایل لاگ رکوردهای زیاد ثبت می‌شود که مدیریت این اطلاعات و جستجو در آن‌ها کار ساده‌ای نیست. بنابراین نیاز به ابزار مدیریت لاگ می‌باشد تا لاگ‌ها را دسته‌ بندی کند، شاخص بندی نماید برای جستجوی بهتر، تحلیل برروی داده‌ها انجام دهد، فرمت ذخیره‌ی آن‌ها را استاندارد و یکسان کند و همچنین امکان آماده سازی گزارش را نیز داشته باشد. سیستم‌های مدیریت لاگ از اهمیت بالایی برخوردارند زیرا در یافتن داده‌های خاص و شناسایی مشکلات به تیم IT بسیار کمک می‌کنند و در نتیجه در وقت و هزینه صرفه جویی می‌شود. برای استفاده از این سرویس می‌توان از نرم‌افزارهای متن باز مانند Fluent و Graylogاستفاده کرد که این امکان را به توسعه دهندگان یک سازمان می‌دهند تا سیستم را برروی سرور خود قرار دهند و آن را متناسب با نیازهای‌ خود تغییر و پیاده سازی کنند. همچنین شرکت‌هایی که کوچک هستند یا تیم توسعه‌ی نرم‌افزار ندارند می‌توانند از شرکت‌‌هایی که این سرویس را ارائه می‌دهند محصول را خریداری کنند. در ایران شرکت‌هایی مانند آتین و کوالاتک هستند که این سرویس را ارائه می‌دهند.مراجعhttps://www.humio.com/glossary/log-management/https://www.guru99.com/log-management-software.htmlhttps://authin.ir/log-management-and-auditing/https://qualatech.ir/log-management/این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>محمد ربانی بیدگلی</category>
                <author>محمد ربانی بیدگلی</author>
                <pubDate>Fri, 24 Dec 2021 01:46:48 +0330</pubDate>
            </item>
                    <item>
                <title>سیستم مدیریت فرایندهای کسب و کار</title>
                <link>https://virgool.io/@rabbani_mohammad/%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%81%D8%B1%D8%A7%DB%8C%D9%86%D8%AF%D9%87%D8%A7%DB%8C-%DA%A9%D8%B3%D8%A8-%D9%88-%DA%A9%D8%A7%D8%B1-ncoz5jerzz02</link>
                <description>planetcrustمقدمههر شرکت یا سازمانی که ایجاد می‌شود با هدف تولید یک محصول یا ارائه‌ی یک خدمت ایجاد می‌شود و برای رسیدن به این هدف مجموعه‌ای از کارها و نقش‌ها تعریف می‌گردد. به هر کدام از این کارها یک فرایند گفته می‌شود. هر فرایند متشکل از چند مرحله است که هر مرحله یک خروجی دارد و این خروجی به مرحله‌ی بعدی منتقل می‌شود تا اینکه به مرحله‌ی آخر برسد و خروجی مرحله‌ی آخر می‌شود محصولی که از آن فرایند انتظار داریم دریافت کنیم. گاهی ممکن است که خروجی یک فرایند آغاز کننده‌ی یک فرایند دیگر باشد و خروجی به فرایند قبلی به عنوان ورودی به فرایند بعدی داده شود و فرایند آغاز گردد. بنابراین فرایند را می‌توان مانند یک خط تولید در نظر گرفت که یک ماده خام وارد خط تولید می‌شود و در هر مرحله کارهایی برروی آن انجام می‌شود در نهایت، پس از اتمام مرحله‌ی آخر آن ماده‌ی خام تبدیل به یک محصول قابل استفاده شده است. در اینجا داده‌ها می‌توانند همان ماده‌ی خام ما باشند که با انجام پردازش‌هایی برروی آن‌ها در هر مرحله تبدیل به داده‌هایی بدرد بخورد و قابل استفاده می‌شوند. نکته‌ای که در مورد فرایند‌ها می‌توان به آن اشاره کرد تغییرپذیر بودن ‌‌آن‌ها است. برای طراحی یک فرایند فاکتور‌های زیادی ممکن است در نظر گرفته شود مانند قوانین کسب و کار، نیروی انسانی موجود، تکنولوژی‌های در دسترس، بودجه‌ی مالی و غیره. بنابراین هر کدام از عوامل موثر در طراحی فرایند که تغییر کنند می‌توانند در تغییر فرایند نیز تاثیر گذار باشند. بنابراین فرایندها یک روند کاری ثابتی ممکن است نباشد و می‌توان برروی آن‌ها بهینه سازی انجام داد و با بررسی هر کدام از آن‌ها مراحلی که اضافه هستند را حذف کرد و زمان و هزینه را بدین ترتیب کاهش داد. بنابراین هر شرکت‌ و سازمانی فرایندها و راهبردهای کسب و کار خود را دارند که نیاز است تا شناسایی و بررسی شوند و در صورت امکان بهبود آن‌ها، راه‌های پیشنهادی برای بهبود و بهینه کردن آن‌ها ارائه شوند. به روش‌ها و متدهایی که برای شناسایی، مدل، تحلیل، اندازه‌گیری، بهبود و بهینه کردن فرایندها و راهبرد کسب و کار بکار گرفته می‌شوند، مدیریت فرایندکسب و کار(Business Process Management یا به اختصار BPM) گفته ‌می‌شود. تعداد فرایندهای موجود در یک سازمان ممکن است بسیار زیاد باشد، مثلا بیشتر از ۱۰۰ تا، و حتی هر فرایند ممکن است که شامل چند زیر فرایند دیگر باشد. همچنین افرادی که در یک فرایند ممکن است دخیل باشند تعدادشان زیاد باشد. به طور کلی مدیریت و مستند کردن این فرایندها کار پیچیده و زمان‌بری است و نیاز به دقت زیادی دارد. برای آسان کردن کار مدیریت فرایند، از سیستم‌ها و نرم‌افزارهای مدیریت فرایند کسب‌ و کار (Business Process Management System یا به اختصار BPMS) استفاده می‌شود. BPMS درواقع ابزاری است برای اجرای متدولوژی‌های مدیریت جهت بهبود فرایند‌های کسب و کار یک سازمان به کمک شناسایی، طراحی، خودکارسازی، تحلیل و اندازه‌گیری عملکرد. این نرم‌افزار برای دراز مدت طراحی شده است، یعنی آنکه شما فرایندهای مدل شده در سیستم را تغییر می‌دهید آن را از حالت خام خارج می‌کنید تا به یک مدل بهینه تبدیل شود و در صورت لزوم در آینده آن را باز هم می‌توانید تعییر دهید و به عنوان یک راه حل یکبار مصرف ارائه نشده است. استفاده از این نرم‌افزار مزیت‌هایی دارد که از جمله‌ی آن‌ها می‌توان به موارد زیر اشاره کرد:نگهداری تمام فرایندها در یک مخزن امکان ویژوال(تصویر) کردن فرایندمشاهده‌ی تمام نقش‌ها و افراد مرتبط به یک فرایندامکان خودکار سازی فرایند و اجرا و مشاهده خروجی آنامکان تغییر و اجرای مجدد فرایند در هر زمان ایجاد یک مستند خوب از فرایندهای موجود در سازمانبنابراین با توجه به مزیت‌های گفته شده وجود یک BPMS متناسب با یک سازمان را می‌توان ضروری دانست. از این رو نرم‌افزارهایی وجود دارند که سازمان‌ها می‌توانند از آن‌ها استفاده کنند و برخی از آن‌ها حتی متن باز و رایگان هستند و هر سازمانی متناسب با نیاز خود می‌تواند آن را تغییر دهد. در بخش بعد به معرفی دو نرم‌افزار متن باز خواهیم پرداختنرم‌افزارهای متن بازنرم‌افزارهایی که این سرویس‌ را ارائه می‌دهند و مشهور هستند می‌توان به Bizagi، Monday و Kissflow اشاره کرد. اما برای استفاده از این نرم‌افزارها لازم است تا سازمان‌ها هزینه کنند و نرم‌افزاری را اتنخاب کنند که سازگاری بیشتری با سازمان آن‌ها دارد. ولی نرم‌افزارهای متن بازی در این حوزه وجود دارند که سازمان‌ها می‌توانند از آن‌ها استفاده کنند و متناسب با نیازهای خود آن را تغییر دهند و جدا از بحث هزینه که آن را کاهش می‌دهد از نظر کارایی نیز توسعه دهندگان نرم‌افزار آن سازمان می‌توانند BPMS متناسب با آن سازمان را طراحی کنند. از جمله نرم‌افزارهای متن باز معروف می‌توان به Bonita و Alfresco اشاره کرد.نرم‌افزار Bonita یک پلتفرم قابل گسترش برای بهینه و خودکارسازی فرایند کسب‌وکار است و این قابلیت را دارد تا با سیستم‌های اطلاعاتی موجود در یک سازمان یکپارچه می‌شود و سیستم‌های ناهمگن را هماهنگ می‌کند و در نتیجه شفافیت عمیقی به فرایندها‌ی سازمان می‌دهد. این نرم‌افزار از سه جزء اصلی تشکیل شده است: محیط توسعه (Bonita Studio): این بخش شامل سه ابزار برای طراحی می‌باشد. اولین جز Whiteboard نام دارد که برای کشیدن نمودار جریان فرایند و توضیح جزئیات گام‌ها، انتقالات، نقاط تصمیم و سایر اجزای یک فرایند است. بخش بعدی ابزار توسعه با کد کم است که برای طراحی مدل‌های داده، برنامه‌های فرایند محور می‌باشد. بخش سوم نیز طراح UI است که برای ایجاد فرم‌های فرایند، لایه‌ها و صفحات برنامه استفاده می‌شود. Bonita Studio درواقع یک ابزار توسعه برای توسعه‌دهندگان حرفه‌ای و معمولی است.محیط اجرا (Bonita Runtime): ترکیب یک یا چند گره سرور خود Bonita است که برروی برخی میزبان‌ها نصب شده است. Bonita برنامه‌هایی را ارائه می‌دهد که در محیط اجرا تعبیه شده‌اند. مانند Bonita Administrator که توسط مدیر سیستم برای نصب، استقرار و مدیریت فرایندها، نظارت بر اجرای فرایند، انجام برخی ارزیابی در سازمان و بازیابی از خطا استفاده می‌شود. نرم‌افزار دیگری که تعبیه شده است Bonita Super Administrator نام دارد که توسط کاربران فنی برای راه اندازی محیط اجرای Bonita با سازمان، مدل داده حرفه و برنامه استفاده می‌شود. برنامه مهم دیگر نیز Application Diracotry نام دارد که یک URL است برای بخاطر سپردن تمام کاربران Bonita و نمایش تمام برنامه‌هایی که در دسترس کاربران وارد شده است.ابزاری برای انتقال پروژه‌های Bonita به صورت مداوم (Bonita Continues Delivery): این جز برخلاف دو جز قبلی رایگان نیست و سازمان برای آنکه بتواند از آن استفاده کند لازم است هزینه اشتراک بپردازد و پس از پرداخت اشتراک توضیحات و مستندات مربوط به این قسمت نیز برای سازمان نمایش داده می‌شود. اما همانگونه که از اسم آن مشخص است وظیفه این برنامه تحویل مدام و خودکار تغییراتی است که انجام گرفته است.یکی دیگر از ابزارهای ذکر شده Alfresco است. سرویس‌های فرایند این نرم‌افزار یک راه حل BPM است که توسعه دهندگان و افراد تجاری را هدف قرار داده. این نرم‌افزار براساس زبان جاوا توسعه داده شده است و در مرکز خود از یک موتور فرایند کسب و کار متن باز با کارایی بالا به نام Acitiviti با قابلیت انعطاف‌پذیری و مقیاس‌پذیری بالا برای کنترل یک محدوده‌ی بزرگی از فرایندهای حیاتی طراحی شده است. این نرم‌افزار امکاناتی را ارائه می‌دهد که از نظر واسط کاربری برای کاربران مناسب است و اصطلاحا User-Friendly است و همچنین با برخی سیستم‌های سازمانی مانند Box، Google Drive و Alfresco Content Services یکپارچه می‌شود. البته شرکت‌هایی نیز هستند که این سرویس را در خدمت سازمان‌های قرار می‌دهند و سازمان نیاز به یک تیم توسعه‌ی مجزا با توسعه‌ی آن ندارد و می‌توان از محصول آماده‌ی شرکت‌های ارائه دهنده استفاده کنند و در صورتی که نیاز به تغییراتی هم داشته باشند می‌توانند مستقیم به تیم پشتیبانی تیم ارائه دهنده بگویند و در صورتی که ممکن باشد آن‌ها نیز تغییرات را اعمال کنند. در ادامه به معرفی دو شرکت ارائه دهنده‌ی این سرویس در ایران خواهیم پرداخت.ارائه دهندگان BPMSاز جمله شرکت‌هایی که در ایران سرویس‌های مربوط به BPMS را ارائه می‌دهند می‌توان شرکت فراگستر و ICAN را نام برد. شرکت فراگستر به طور کلی خدماتی در حوزه‌ی اتوماسیون، نظارت، مدیریت مستندات، امنیت و مدیریت فرایندها ارائه می‌دهد. این شرکت یک اتوماسیون اداری تحت وب را ارائه می‌دهد که به کمک آن می‌توانید فرایندها و مراحل مربوط به آن را در سیستم تعریف کنید. نرم‌افزاری که این شرکت توسعه داده است درواقع یک بومی سازی شده‌ی نرم‌افزار Process maker است که یک نرم‌افزار متن باز برای BPMS است. ICAN نیز شرکتی که اولین ارائه دهنده سرویس BPMS است و این سرویس را در دو سطح سازمانی و استاندارد ارائه می‌دهد. خدماتی که در سطح استاندارد ارائه می‌دهد محدود است و تنها شامل ایجاد فرم، ایجاد گردش کار و سرویس‌ها است اما در سطح سازمانی امکانات دیگری مانند توسعه سریع برنامه، نظارت برای فعالیت‌های کسب و کار و پورتال طراحی شده نیز ارائه می‌شود.جمع بندیهر سازمان شامل مجموعه‌ای از فرایند‌ها است که هرکدام از این فرایندها شامل مراحلی هستند و هر فرایند مسئولین مربوط به خود را دارد. هنگامی که تعداد فرایندها و نقش‌ها در آن‌ها زیاد شود مدیریت آن‌ها نیز مشکل می‌شود و نظارت بر آن‌ها دشوار. بنابراین نیاز به یک سیستمی است که بتوان از آن برای طراحی، مدیریت و نظارت بر فرایندها از آن استفاده کرد. این سیستم، سیستم مدیریت فرایند کسب و کار یا BPMS نام دارد. مزایایی که یک BPMS دارد می‌توان طراحی یک فرایند و مشاهده‌ی خروجی و ارزیابی آن باشد بدون آنکه به صورت عملی در سازمان پیاده سازی شده باشد، امکان مشاهد‌ه‌ی نقش‌ها و افراد مربوط به هر فرایند، امکان تغییر و اجرای مجدد آن و همچنین مستند سازی فرایند‌ها. نرم‌افزارهای چندین نرم‌افزار متن باز هم وجود دارد که این سرویس را ارئه می‌دهند و سازمان‌ها ‌می‌توانند از آن‌ها برای خود استفاده کنند مانند Bonita و Alfresco. اما برخی از سازمان‌های کوچک که تیم توسعه‌ی نرم‌افزار ندارند می‌توانند به سراغ شرکت‌های ارائه دهنده‌ی این سرویس بروند. در ایران شرکت‌هایی مانند فراگستر و ICAN این سرویس را ارائه می‌دهندمراجعhttps://www.alfresco.com/https://documentation.bonitasoft.com/bonita/2021.2/bonita-overview/bonita-bpm-overviewhttps://www.planetcrust.com/what-is-bpms/https://thedigitalprojectmanager.com/bpms-bpm-software/#:~:text=BPMS%20stands%20for%20Business%20Process,interaction%20and%20software%20or%20applications.https://www.faragostar.net/automation/bpms/https://ican.ir/products/%d9%86%d8%b1%d9%85-%d8%a7%d9%81%d8%b2%d8%a7%d8%b1-bpms/این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>محمد ربانی بیدگلی</category>
                <author>محمد ربانی بیدگلی</author>
                <pubDate>Fri, 24 Dec 2021 01:33:13 +0330</pubDate>
            </item>
                    <item>
                <title>احراز هویت متمرکز</title>
                <link>https://virgool.io/@rabbani_mohammad/%D8%A7%D8%AD%D8%B1%D8%A7%D8%B2-%D9%87%D9%88%DB%8C%D8%AA-%D9%85%D8%AA%D9%85%D8%B1%DA%A9%D8%B2-setmbscrdwtm</link>
                <description>مقدمهاحتمالا تاکنون برای شما پیش آمده است که وارد یک برنامه‌ای شوید و برای استفاده از امکانات آن نیاز به ورود به حساب کاربری داشته باشد. شرکتی که این برنامه را توسعه داده است ممکن است که برنامه‌های دیگری نیز توسعه داده باشد که برای استفاده از آن‌ها نیاز است تا شما وارد حساب خود شوید. برای آنکه منظور خود را بهتر بیان کنم سایت Firebaseکه توسط شرکت گوگل توسعه داده شده است را مثال می‌زنم. برای آنکه از امکانات Firebase استفاده کنید لازم است تا ابتدا وارد حساب کاربری خود شوید. همچنین ممکن است همزمان بخواهید از امکانات موجود در Google Cloud نیز استفاده کنید و در آن‌جا نیز برای استفاده از امکانات آن باید وارد حساب خود شده باشید. نکته در این جا است، هنگامی که شما در یکی از این دو برنامه، (Google Could یا Firebase) وارد حساب خود شوید، دیگر نیاز نیست که اطلاعات ورود یعنی نام کاربری و رمز عبور خود را در دیگری وارد کنید و به طور خودکار شما با وارد کردن تنها یک بار نام کاربری و رمز عبور در یکی از برنامه‌ها در برنامه‌ی دیگر نیز وارد حساب کاربری خود شده‌اید. به این ویژگی، احراز هویت متمرکز (Single Sign Onیا به اختصار SSO) می‌گویند. SSOدرواقع یک تکنولوژی است که صفحات ورود برنامه‌های مختلف را به یک صفحه تبدیل می‌کند. SSO این امکان را فراهم می‌کند تا کاربر تنها یک بار نام‌ کاربری و رمز عبور خود را در یک صفحه وارد کند تا به تمام برنامه‌هایی که به گونه‌ای با هم یکپارچه هستند دسترسی داشته باشد. SSOیکی از جنبه‌های مهم در کنترل، شناسایی و مدیریت دسترسی دانست. از جمله مزیت‌هایی که SSOدارد می‌توان به موارد زیر اشاره کرد:رمزهای عبور قوی: برای وارد شدن به حساب کاربری خود دیگری نیازی نیست چندین رمز عبور برای هر حساب خود ایجاد کنید و تنها با تعیین یک رمز عبور قوی برای یک حساب خود می‌توانید وارد شود. همین امر نیز سبب به یاد ماندن بهتر رمز می‌شودعدم رمز عبور تکراری: وقتی که کابران رمزهای عبوری برای سرویس‌ها و برنامه‌های مختلف باید تعیین کنند وضعیتی به نام فرسودگی رمزعبور (password fatigue) رخ می‌دهد. یعنی کاربر رمز‌ها را در سرویس‌های مختلف استفاده‌ی مجدد می‌کند. که این امر خطر بزرگی به حساب می‌آید زیرا تمام سرویس‌ها با ضعیف‌ترین رمزعبور ایمن هستند. اگر پایگاه داده‌ی رمز‌های عبور هک شود آنگاه حمله کننده می‌تواند وارد تمام برنامه‌ها و سرویس‌ها شود. SSO با کاهش تمام صفحات ورود به یک صفحه‌ی ورود این داستان را حذف کرده است. البته این ویژگی تا حدی به ویژگی قبلی نیز برمی‌گردد که شما یک رمز قوی برای یک حساب کاربری خود انتخاب نموده‌ایداعمال بهتر سیاست‌های رمزگذاری: در SSOتنها یک جا برای وارد کردن رمزعبور است و همین امر اعمال سیاست‌ها و قوانین رمزگذاری برای تیم‌های ITرا راحت‌تر کرده است. به عنوان مثال اگر سیاست‌های یک تیم ITتغییر رمز‌های کاربران به صورت دور‌ه‌ای باشد دیگر نیازی نیست که این کار را برای هر سرویس و برنامه به صورت جداگانه انجام دهنداحراز هویت چند فاکتوره: وارد شدن به کمک یه کد یا یک USB علاوه بر گرفتن نام کاربری و رمزعبور می‌توانند روش‌های دیگر احراز هویت باشند که احراز هویت چند فاکتوره نام دارد. در صورتی که به ازای هر حساب کاربری بخواهیم از این روش استفاده کنیم وقت زیادی گرفته می‌شود و خسته کننده نیز می‌باشد. نکته‌ی دیگر در مورد فعال کردن آن است که اگر بخواهید از این گونه احراز هویت استفاده کنید باید به ازای هر حساب کاربری خود این ویژگی را فعال نمایید. اما به کمک سیستم SSOتنها کافی است که در یک برنامه این امکان را فعال سازید و هنگام وارد شدن در حساب کاربری خود در سایر برنامه‌ها این امکان فعال است. همچنین دیگر نیازی نیست که برای وارد شدن به حساب خود در سرویس‌های مختلف هر بار مراحل مربوط به احراز هویت چندگانه را طی نماییداجبار ورود مجدد رمز عبور در یک نقطه: مدیران سیستم می‌توانند بعد از گذشت مدت زمان معینی از وارد شدن کاربر به حساب کاربر خود کاربر را مجبور به وارد کردن مجدد رمز عبور نمایند تا مطمئن شوند که کاربری که با سیستم کار می‌کند، همان کاربری است که مجوز استفاده از سیستم را دارد یا خیر. با SSOهم کار مدیر سیستم راحت می‌شود زیرا دیگر نیازی نیست که اجبار ورود رمز عبور را برای هرکدام از برنامه‌ها به صورت جداگانه فعال کند و هم کاربر دیگر نیازی نیست که رمز عبور خود را به ازای هر برنامه مجدد وارد نمایدمدیریت اعتبار داخلی بجای ذخیره سازی جانبی: سیستم‌هایی که از SSO استفاده نمی‌کنند رمزهای کاربران را در برنامه‌ها و سرویس‌هایی ذخیره می‌کنند که ممکن است از روش‌های امنیتی مناسبی استفاده نکنند. اما به کمک SSOتمام رمزها دریک فضای امن ذخیره می‌شود که تیم IT کنترل بیشتر و بهتری روی آن دارند و می‌توانند پروتکل‌های امنیتی را بجای آنکه روی هر سرویس به صورت جداگانه اعمال کنند روی تنها یک فضای ذخیره سازی اعمال کنندکاهش زمان بازیابی رمز عبور: سرویس SSO مدت زمان بازیابی رمز عبور را نیز کاهش می‌دهد و برای بازیابی یا فعال سازی مجدد نیازی نیست که برای تمام برنامه رمز عبور خود را بازیابی نمایید و با یک بار انجام داد این کار، رمز عبور شما بازیابی شده و در سایر برنامه‌ها کاربرد داردبرای آنکه بیشتر با سرویس SSOآشنا شویم در ادامه به توضیح عملکرد آن می‌پردازیم.عملکرد SSOهنگامی که یک کاربر در سرویس SSO نام کاربری و رمز عبور خود را وارد می‌کند سرویس یک توکن احراز هویت می‌سازد تا بیاد آورد که کاربرد احراز هویت شده و مورد تایید است. یک توکن احراز هویت درواقع حاوی اطلاعات دیجیتال است که در مرورگر کاربر یا سرورهای سرویس SSOذخیره شده‌اند. هر برنامه که کاربر به آن دسترسی دارد با سرویس SSO چک خواهد شد. این سرویس توکن احراز هویت کاربر را به برنامه ارسال می‌کند و سپس اجازه‌ی ورود کاربر به برنامه داده می‌شود. نکته‌ای که وجود دارد آن است که سرویس SSOخود به تنهایی نمی‌داند که چه کسی وارد سیستم شده است یا به عبارت دیگر کاربری که وارد شده، چه کسی است زیرا مشخصات و هویت کاربر را ذخیره نمی‌کند. درواقع اکثر سرویس‌های SSOبه وسیله‌ی چک کردن اعتبارهای کاربر در مقابل یک سرویس مدیریت هویت کار می‌کنند. توکن‌های احراز هویت SSOیک رشته‌ای از حروف و اعداد هستند که یک ساختار و استاندارد مشخصی دارند و سرویس SSO چک می‌کند که آیا این توکن صحیح و قاتونی است یا خیر. معیار قانونی بودن یک توکن نیز میزان تطابق توکن دریافتی با ساختار و استاندارد تعریف شده است.در حال حاضر شرکت‌های بزرگی در حال ارائه‌ی این سرویس هستند مانند Cloud Flare اما پروژه‌هایی هم هستند که به صورت متن باز این سرویس را در اختیار کاربران قرار می‌دهند و سازمان‌هایی که تیم توسعه‌ی نرم‌افزار دارند می‌توانند از این نرم‌افزارها استفاده کنند. در بخش بعد دو نرم‌افزار متن باز که این سرویس را ارائه می‌دهند توضیح خواهیم داد.نرم‌افزارهای متن باز یکی از نرم‌افزارهای معروف ارائه‌ی سرویس SSO، برنامه‌ی Identity Server است. این برنامه یک چارچوب cross-platform براساس OpenID Connect و OAuth2 است و یک احراز هویت مرکزی و قابلیت شناسایی برای برنامه چندتایی می‌دهد. OAuth2 یک پروتکل استاندارد صنعتی برای احراز هویت است و OpenID Connectنیز یک لایه‌ی ساده برروی این پروتکل می‌باشد که به مشتریان اجازه می‌دهد تا هویت کاربرنهایی را براساس احرازهویت انجام شده توسط یک سرور احراز هویت رسیدگی کند. این نرم‌افزار به زبان C# نوشته شده و کد منبع آن در github به همراه مستندات مربوط به استقرار و توسعه قابل مشاهده است.نرم‌افزار KeyCloakنیز یک نرم‌افزار متن باز است که این نرم‌افزار نیز براساس OpenID Connect، Auth2.0و SAML2.0 است. SAML2.0 مخفف Security Assertion Markup Language است و یک پروتکل براساس XML است که از توکن‌های امنیتی شامل اعلان‌هایی برای ارسال اطلاعات درمورد یک کاربر نهایی بین یک ارائه دهنده‌ی هویت و یک ارائه‌ دهنده‌ی سرویس است. این برنامه قابلیت‌های سرویس SSO را برای برنامه و سرویس‌های تحت وب ارائه می‌دهد و قابلیت یکپارچه سازی LDAPو active directory را می‌دهد. درواقع یک واسط کاربری دارد که کاربران می‌توانند جلسه‌ها، اجازه‌ها و نقش‌ها را مدیریت کنند. همچنین کتابخانه‌های مشتری برای زبان‌های رایج مانند Java، JavaScript و C# ارائه می‌هد. این برنامه به زبان Javaنوشته شده است و کد منبع آن نیز در github قرار دارد.البته شرکت‌های نرم‌افزاری هم هستند که این سرویس را ارائه می‌دهند و سازمان‌های کوچک و متوسط امکان استفاده از سرویسی که ارائه می ٔهند را دارند که در ادامه به معرفی دو مورد از این ارائه دهندگان در داخل کشور می‌پردازیمارائه دهندگان سرویس SSOدر ایران یکی از شرکت‌هایی که سرویس SSO را ارائه می‌دهد، می‌توان از شرکت فناوران هویت الکترونیکی امن(هویتا) را نام برد. این شرکت یک سامانه به نام ParsSSOایجاد کرده است که یک سرویس احراز هویت و امضای دیجیتال مبتنی بر PKI است. PKIمخفف Public Key Infrastructure است و یک سیستم از فرایندها، سیاست‌ها، احراز هویت و تکنولوژی‌هایی که رمزگذاری را کنترل می‌کنند و درواقع چیزی است که از پیام‌ها متنی، ایمیل، رمزهای عبور و غیره حفاظت می‌کند. این سامانه از دو زیر سیستم به نام ارائه‌ دهنده‌ی هویت و دروازه‌ی امضای دیجیتال استفاده می‌کند. سیستم ارائه دهنده‌ی هویت برای ارائه خدمات AAAشامل احراز هویت(Authentication)، کنترل دسترسی(Authorization) و حسابرسی(Accounting) است. سیستم دروازه‌ی امضای دیجیتال نیز برای ارائه‌ی خدمات درگاه دیجیتال است. از ویژگی‌های این سیستم می‌توان به موارد زیر اشاره کرد:پشتیبانی از الگوریتم ‌های نامتقارن امضای دیجیتال متعارفپشتیبانی از فرمت ‌های امضای دیجیتال متعارف شامل RAW, PKCS#1, PKCS#7, PAdeS, XAdeS, CAdeSپشتیبانی از الگوریتم های HASH شامل MD5, SHA-1, SHA-2احراز هویت بر اساس چارچوب OAuth2.0 و به صورت Single Sign-Onمدیریت یکپارچه کاربران، نقش ‌ها، سازمان ‌ها، فراهم کنندگان خدمت و نشست‌ هاپشتیبانی از انواع احراز هویت شامل نام کاربری و رمز عبور، توکن امضای دیجیتال سخت افزاری پارس کی، سرویس امضای همراه و OTPشرکت دیگری که در ایران این سرویس را ارائه می‌دهد شرکت متن باز سامانه است که نام این سیستم را متین گذاشته‌اند. سرویسی که توسط این شرکت پیاده سازی شده است امکاناتی مانند پیاده‌سازی به صورت توزیع شده، احراز هویت دو عاملی، ایجاد یکپارچگی در مراکز داده مختلف، اتصال به پایگاه داده کاربران و اتصال به سایر ارائه دهندگان سرویس SSo را فراهم می‌کند. با مراجعه به سایت این شرکت مستنداتی قرار داده شده است که ویژگی‌های و پروتکل‌های استفاده شده در این سرویس را به صورت کامل توضیح داده‌اندجمع بندیبا سامانه‌ی احراز هویت متمرکز دیگر نیازی به وارد شدن به حساب کاربری برای چند برنامه‌ی یکپارچه نیست. مانند برنامه‌هایی که توسط شرکت گوگل ارائه می‌شوند. شما با ورود به حساب کاربری خود در یکی از برنامه‌ها مانند آن است که در سایر برنامه‌ها نیز وارد حساب کاربری خود شده‌اید. این سیستم مزیت‌هایی مانند صرفه جویی در وقت برای بازیابی رمز عبور، تعیین تنها یک رمز قوی برای حساب خود و عدم فراموشی آن، امکان مدیریت بهتر و امن‌تر رمز‌های عبور و امکان اجرای بهتری سیاست‌گذاری‌های رمزعبور. این سرویس به صورت متن باز نیز ارائه می‌شود و نرم‌افزارهایی مانند Identity Serverو KeyCloak وجود دارند که کدهای آن‌ها حتی در گیت‌هاب موجود است و توسعه‌ دهندگان نرم‌افزار سازمان‌ها ‌می‌توانند از آن‌ها استفاده کنند. همچنین در ایران نیز شرکت‌هایی مانند متن باز سامانه و هویتا هستند که این سرویس را در اختیار سازمان‌ها قرار می‌دهندمراجعhttps://www.cloudflare.com/learning/access-management/what-is-sso/https://www.techtarget.com/searchsecurity/definition/single-sign-onhttps://blog.containerize.com/2021/01/29/top-5-open-source-single-sign-on-software-in-the-year-2021/https://mbs.co.ir/fa/content/Single-Sign-Onhttps://www.hovita.ir/portal/viewpage/2/%D8%B3%D8%A7%D9%85%D8%A7%D9%86%D9%87-%D8%A7%D8%AD%D8%B1%D8%A7%D8%B2-%D9%87%D9%88%DB%8C%D8%AA-%D9%85%D8%AA%D9%85%D8%B1%DA%A9%D8%B2-sso-%D8%AA%D8%AC%D9%87%DB%8C%D8%B2-%D8%B4%D8%AF%D9%87-%D8%A8%D9%87-%D8%AF%D8%B1%DA%AF%D8%A7%D9%87-%D8%A7%D9%85%D8%B6%D8%A7%DB%8C-%D8%AF%DB%8C%D8%AC%DB%8C%D8%AA%D8%A7%D9%84-pars-sso/این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>محمد ربانی بیدگلی</category>
                <author>محمد ربانی بیدگلی</author>
                <pubDate>Fri, 24 Dec 2021 01:21:18 +0330</pubDate>
            </item>
                    <item>
                <title>تحویل مدام</title>
                <link>https://virgool.io/@rabbani_mohammad/%D8%AA%D8%AD%D9%88%DB%8C%D9%84-%D9%85%D8%AF%D8%A7%D9%85-jy4q7smlpj7y</link>
                <description>مقدمهاگر تجربه‌ی تولید نرم‌افزار و همکاری با یک تیم کوچک و تازه کار را داشته باشید احتمالا به این مسئله برخورده کرده‌اید که برای هر تغییری که در کد نرم‌افزار می‌دهید، کوچک یا بزرگ، برای آنکه آن تغییر برروی سرور قرار بگیرید و وارد محیط محصول شود و در اختیار کاربر قرار گیرد مدتی صبر کنید. این مدت زمان صبر ممکن است از چند ساعت باشد تا چند روز. حتی ممکن است که برای شما یک روز مشخصی را تعیین کنند و بگوید برای آنکه تغییرات در اختیار کاربر قرار گیرد باید تا آن روز تغییرات را انجام داده باشید و کدهای نرم‌افزار آماده‌ی استقرار برروی سرور باشند. دلیل این تاخیر برای قرار دادن تغییرات در محیط محصول می‌توان عدم خودکارسازی فرایندهای تست و استقرار سیستم باشد. به ازای هر تغییری که انجام می‌شود سیستم باید به صورت دستی تست گردد و همین تست دستی توسط توسعه دهندگان یا تسترها زمان‌بر است. همچنین برای مستقر کردن نرم‌افزار برروی سرور نیاز است تا تیم استقرار حضور داشته باشند و خودشان به صورت دستی تنظیمات را انجام دهند و سیستم را آماده‌ی استقرار نمایند. حال کافی است که در روز استقرار محصول یکی از افراد تیم تست یا استقرار نباشند آنگاه فرایند تحویل نرم‌افزار به تعویق خواهد افتاد. در دنیای امروز هر ثانیه‌ای که از دست برود و محصول دیر به دست مشتری برسد می‌تواند ضررهای سنگینی به سیستم وارد کند. بنابراین لازم است که به دنبال یک روشی باشیم که بتواند این فرایند تولید نرم‌افزار را خودکار کند و تغییرات بدون آنکه وابسته به افراد محدود و خاصی باشد برروی محیط محصول قرار گیرد. از این رو یک مفهوم به نام تحویل مدام بوجود آمد.تحویل مدام یا Continues Delivery (CD) روش توسعه‌ی نرم‌افزار است به گونه‌ای که تغییرات مربوط به کد به طور خودکار برای یک انتشار به عنوان محصول نهایی آماده هستند. یک رکن توسعه‌ی برنامه‌ی مدرن است، همچنین CD با یکپارچه سازی مدام (Continues Intgeration یا به اختصار CI) گسترش می‌یابد و معمولا این دو مفهوم به دنبال یکدیگر در قالب CI/CD می‌آیند. این گسترش به وسیله‌ی استقرار تمام تغییرات کد برروی یک محیط تست و محیط محصول پس از مرحله‌ی ساخت است. هنگامی که تحویل مدام به خوبی پیاده‌سازی شده باشد، توسعه‌ دهندگان همواره یک محصول آماده‌ی استقرار دارند که تمام فرایند تست استاندارد را گذرانده است. تحویل مدام این امکان را می‌دهد تا توسعه دهندگان تست‌ها را خودکار کنند. این تست‌ها تنها شامل unit testing نمی‌شود بلکه شامل تست واسط کاربری، تحمل بار سرور، یکپارچه سازی و اطمینان‌پذیری APIنیز می‌شود. همچنین سبب می‌شود تا قبل از استقرار برنامه و استفاده توسط مشتری بروزرسانی‌های جدید از جنبه‌های مختلف را شناخته و تست شوند.در توسعه‌ی نرم‌افزار یک مفهوم دیگری نیز وجود دارد به نام استقرار مدام یا Continues Deployment که معمولا با تحویل مدام اشتباه گرفته می‌شود. در تحویل مدام تمام تغییراتی که در کد برنامه ایجاد می‌شود ساخت، تست و سپس در یک محیط غیر محصول تست می‌شود. یعنی پیش آن که استقرار برنامه در محیط محصول انجام گیرد تست‌های چندگانه که پیشتر ذکر شدند انجام می‌شود. تفاوت تحویل مدام با استقرار مدام را می‌توان در حضور یک مرحله تست که یک حکم تایید دارد مبنی بر آن که تغییرات به درستی انجام شده و اشکالی در برنامه ایجاد نکرده است، دانست. این مرحله در تحویل مدام وجود دارد اما در استقرار مدام چنین نیست و تغییرات کد مستقیم برروی سرور می‌روند. بنابراین تحویل مدام با استقرار مدام یکسان نیستند و دو مفهوم مستقل هستند. درواقع استقرار مدام یک چرخه‌ی کوچک برای استقرار نرم‌افزار است و ربطی به تست نرم‌افزار ندارد.استفاده از سرویس تحویل مدام مزایایی دارد که موارد زیر را می‌توان از جمله مزایای آن دانست:خودکار سازی فرایند انتشار نرم‌افزار: به تیم توسعه این امکان را می‌دهد تا تغییرات کد را به طور خودکار بسازند، تست و آماده‌ی انتشار کنند. بنابراین انتقال سریع‌تر و موثرتر استبهبود بهره‌وری توسعه دهنده: این کار بهره‌وری تیم توسعه را بالا‌تر می‌برد زیرا توسعه دهندگان از انجام برخی کارها مانند تست به صورت دستی آزاد می‌شوند. همین امر سبب می‌شود که تعداد باگ‌ها و خطاهای برنامه هنگام انتشار و استقرار بسیار کاهش پیدا کندیافتن سریع‌تر باگ‌ها و مکان دقیق آن‌ها: تیم توسعه‌دهنده می‌تواند باگ‌ها را تشخیص دهد و مکان‌ رخداد آن‌ها را نیز شناسایی کند، پیش از آنکه به مشکل بزرگ‌تری تبدیل شوند و برروی سایر بخش‌های نرم‌‌افزار را تحت تاثیر قرار دهد. تحویل مدام این اجازه را می‌دهد که تیم توسعه بتواند برروی انواع تست‌های مختلفی وقت بگذارد زیرا انجام تست‌ها به صورت خودکار انجام می‌شود و بعنی ایجاد وقت کافی برای انجام تست سایر بخش‌های کد برنامهتحویل سریع‌تر در بروزرسانی: همان‌گونه که پیشتر اشاره شد، بروزرسانی که قرار است بالا برود بو به مشتری برسد چون فرایند تست‌های استاندارد را گذرانده است با اطمینان بیشتر و خطای کمتری بالا می‌رود و نیاز به تست کاربری را کاهش می‌دهددرواقع تحویل مدام یک روش مهندسی نرم‌افزار است که در آن تیم‌ها در یک چرخه‌ی کوتاه، نرم‌افزار را تولید می‌کنند. این چرخه‌ی خودکار تضمین می‌کند که نرم‌افزار با اطمینان در هر زمانی منتشر می‌شود. این روش هزینه، مدت زمان و خطر تحویل تغییرات را کاهش می‌دهد و با کاهش بروزرسانی در تولید.سازمان‌هایی که یک تیم DevOps دارند می‌توانند این خط تولید را پیاده سازی کنند و به کمک نرم‌افزارهای متن‌باز که وجود دارد از این سرویس استفاده کنند. در ادامه به بررسی دو نرم‌افزار متن باز که امکان ایجاد تحویل مدام را فراهم می‌کنند می‌پردازیم.نرم‌افزارهای متن بازبرای پیاده سازی تحویل مدام نرم‌افزار و سرویس‌هایی وجود دارند که این خدمت را فراهم می‌کنند. که برخی از آن‌ها اشتراکی هستند و برای استفاده از آن باید هزینه‌ای پرداخت شود مانند سرویس AWS. همچنین برخی هم به صورت رایگان و متن باز در اختیار کاربران قرار می‌گیرد مانند: Buddy و JBossنرم‌افزار Buddyیک ابزار هوشمند CI/CDاست که برای توسعه دهندگان وب طراحی شده است. این ابزار از خطوط تحویل برای ساخت، تست و استقرار نرم‌افزار استفاده می‌کند. این خطوط با بیش‌ از ۱۰۰ عمل آماده‌ انجام ساخته شده‌اند که قابلیت تغییر و جابجایی دارند و به طریق‌های مختلفی می‌توان آن‌ها را مرتب کرد. از مزایای استفاده از آن:استفاده‌ی راحت و انجام config در زمان اندکاستقرار سریع و آسان براساس مجموعه‌ی تغییرات ساخت‌ها در کانتینرهای جداگانه با وابستگی‌های کش شده اجرا می‌شوندتمام زبان‌ها، فریم‌ورک‌ها و مدیریت‌های وظیفه را پشتیبانی می‌کند با AWS و گوگل یکپارچه می‌شودنرم‌افزار متن باز دیگری گه گفته شده JBoss است. این نرم‌افزار توسط تیم REDHat ایجاد شده است. یک برنامه‌ی وب سروری است که به صورت کامل برای میزبانی برنامه‌ی تحت جاوا یکپارجه شده است. این برنامه از سرور Apache Http، Servelet Engines، load balancers و کتابخانه‌های native توسط Apache Tomcatتشکیل شده است. JBossاین توانایی را دارد که برروی پلتفرم‌های چندگانه اجرا شود.اما سازمان‌هایی که افرادی ندارند که نقش DevOps را انجام دهند می‌توانند از سرویس‌هایی استفاده کنند که توسط شرکت‌ها به صورت آماده ارائه می‌شود. در ادامه به معرفی دو شرکت داخلی می‌پردازیم که این سرویس را ارائه می‌دهند.ارائه دهندگان سرویس تحویل مدامشرکت‌ها و سایت‌هایی هستند که این خدمت را ارائه می‌دهند و تیم‌های نرم‌افزاری می‌توانند از آن‌ها استفاده کنند مانند CI/CD شرکت‌های Gitlabو Github اما استفاده ازسرویس‌های این شرکت‌ها ممکن است که هزینه‌ای داشته باشد و به دلیل مسائل سیاسی و تحریم مشکلاتی ایجاد شود. اما در ایران شرکت‌هایی هستند که این سرویس را ارائه می‌دهند مانند لاراهاست که سرویس خود را با github یکپارچه کرده است. پس از هر بار push کردن تغییرات کد، به صورت خودکار کدهای تغییر داده شده برروی سرور مستقر می‌شوند. فرایند فعال سازی آن نیز در githubبسیار ساده است که با مراجعه به آدرس سایت لاراهاست می‌توان مراحل فعال سازی این سرویس را مشاهده کرد.شرکت ایرانی دیگری که این سرویس را ارائه می‌دهد لیارا نام دارد. این شرکت در حوزه‌ی ارائه سرویس‌های ابری فعالیت می‌کند و یک سرویس CI/CD نیز ارائه می‌دهد که امکان راه‌اندازی آن به وسیله‌ی هم gitlab و هم github را دارد. برای فعال کردن این سرویس برروی gitlab یا github کافی است که تنظیمات گفته شده در مستندات خود لیارا در پروژه خود انجام دهید و فایل‌های مربوط به تنظیمات تحویل مدام و استقرار مدام را با مشخصات گفته شده ایجاد نمایید.جمع بندیبرای آنکه یک نرم‌افزار در دسترس کاربران و مشتریان قرار گیرد لازم است که برروی سرور مستقر شود. اما مهم‌تر از استقرار نرم‌افزار تغییرات انجام شده در کد، تست آن تغییرات و مدت زمان تحویل برنامه به مشتری است. امروزه با توجه به سرعت پیشرفت تکنولوژی وافزایش نیاز مشتریان به سرویس‌های نرم‌افزاری لازم است تا مراحل تولید نرم‌افزار از انجام تغییرات برروی کد تا استقرار برروی سرور سریع و به صورت خودکار انجام شود. از این رو مفهومی به نام تحویل مدام معرفی شد که در آن پس از هر بار تغییر کد و بروزرسانی به صورت خودکار پروژه ساخته، تست و مستقر برروی محیط محصول می‌شود تا دردسترس کاربر قرار گیرد. این کار ضمن کاهش زمان بروزرسانی و تولید محصول سبب می‌شود تا نرم‌افزار با خطا و باگ کمتر و درنتیجه با اطمینان بیشتری در اختیار کاربر قرار بگیرد. همچنین توسعه دهندگان این فرصت را دارد که برروی انواع تست‌های نرم‌افزاری وقت بگذارند و بخش‌های مختلف کد را بررسی کنند و تست برای آن‌ها بنویسند زیرا تست‌ها دیگر به صورت خودکار در حال اجرا هستند. همچنین در هر مرحله از تست اگر باگی ایجاد شود، توسعه دهندگان سریع متوجه آن خواهند شد و از طرفی می‌دانند که آن باگ در کجا اتفاق افتاده و می‌توانند بروند به همان قسمتی آن باگ رخ داده است. نرم‌افزارهایی هستند که این سرویس را به صورت رایگان و متن باز در اختیار توسعه دهندگان قرار می‌دهند و تیم‌های DevOpsیک سازمان می‌توانند با استفاده از این نرم‌افزارهای CI/CD خود را راه‌اندازی کنند. از جمله‌ی این سیستم‌های متن باز معروف می‌توان به JBossو Buddy است. اما شرکت‌هایی که تیم DevOps ندارد یا افرادی که بتوانند این نقش را بپذیرند می‌توانند از سرویس‌هایی که توسط شرکت‌های دیگر ارائه می‌شود استفاده کنند مانند شرکت‌های ایرانی لیارا و لاراهاست که با فعال کردن سرویس‌ این دو برروی github امکان ایجاد CI/CD فراهم می‌شودمراجعhttps://aws.amazon.com/devops/continuous-delivery/http://lara-host.ir/continuous-delivery/https://www.redhat.com/en/topics/api/what-does-an-api-gateway-dohttps://docs.liara.ir/cicd/gitlabhttps://www.tecmint.com/open-source-api-gateways-and-management-tools/https://virgool.io/@ar.oroumand/%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3%D9%87%D8%A7-%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-api-gateway-qaaprddghopfاین مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>محمد ربانی بیدگلی</category>
                <author>محمد ربانی بیدگلی</author>
                <pubDate>Fri, 24 Dec 2021 00:54:55 +0330</pubDate>
            </item>
                    <item>
                <title>مستند سازی معماری نرم افزار به کمک مدل C4</title>
                <link>https://virgool.io/@rabbani_mohammad/%D9%85%D8%B3%D8%AA%D9%86%D8%AF-%D8%B3%D8%A7%D8%B2%DB%8C-%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-%D8%A8%D9%87-%DA%A9%D9%85%DA%A9-%D9%85%D8%AF%D9%84-c4-ttbxvkxecmf9</link>
                <description>مقدمههر سیستمی که در این جهان ایجاد می‌شود دارای معماری است، هر چند کسی معماری آن را ننوشته باشد. معماری درواقع یک دید کلی نسبت به یک سیستم است تا به کمک آن بتوان اجزای سازنده‌، ارتباط میان اجزا، تکنولوژی‌های مورد استفاده و هدف از ایجاد آن سیستم را فهمید. از آنجایی که نرم‌افزار هم یک سیستم است بنابراین برای آن نیز می‌توان معماری تعریف کرد و مستند نمود. معماری سیستم‌های نرم‌افزاری در مقایسه با معماری سایر محصولات و سیستم‌ها کمی متفاوت و سخت‌تر است. زیرا نرم‌افزار یک موجود بسیار پیچیده و توسعه‌پذیر است و هر لحظه، با توجه به شرایط و قوانین محیطی، دستخوش تغییراتی شود. بنابراین یک ویژگی اساسی در معماری نرم‌افزار علاوه‌بر ساده و قابل فهم بودن، قابلیت توسعه‌پذیری آن است. . نکته‌ی دیگری که اهمیت دارد آن است که بتوان یک معماری را به خوبی مستند کرد و در اختیار ذینفعان آن سیستم نرم‌افزاری قرار داد. هدف از مستند کردن معماری آن است تا افراد تازه وارد مانند توسعه دهندگان یا مدیران جدید بتوانند در یک نگاه سیستم را بفهمند و به هدف آن پی ببرند.برای مستند کردن معماری روش و مدل مشخصی ارائه داده نشده است و برخی تیم‌ها از نمودارهایی استفاده می‌کنند که فقط توسط خودشان قابل فهم است یا برخی دیگر از استانداردهای UML استفاده می‌کنند. روشی که قرار است برای مستند سازی انتخاب شود باید قابل فهم باشد، سیستم را از جنبه‌های مختلف توصیف کند و در عین حال سریع بتوان آن را توسعه داد. به عنوان مثال استفاده از نمودارهای UML ممکن است که ایده‌ی خوبی بنظر برسد و یک سیستم را به خوبی از جنبه‌های مختلف و به طور دقیق توصیف کند اما دارای پیچیدگی و جزئیات زیادی است و برای رسم و گسترش آن وقت بسیاری باید گذاشت که با توجه به سرعت پیشرفت و گسترش سیستم‌های نرم‌افزاری انتخاب مناسبی نیست. بین سال‌های ۲۰۰۶ تا ۲۰۱۱ روش و مدلی توسط آقای Simon Brown برای مستند سازی معماری نرم‌افزار به نام C4 مطرح شد. این مدل یک سیستم نرم‌افزاری را در ۴ سطح مورد بررسی قرار می‌دهد و روی جزئیات خیلی تمرکز نمی‌کند و سعی دارد تا به صورت مختصر و مفید اطلاعات آن سیستم را در اختیار ذینفعان قرار دهد. در بخش بعدی به توضیح بیشتر این مدل خواهیم پرداختمدل C4کلمه C4 مخفف ۴ کلمه‌ی Component، Container، Context و Code است. هر کدام از این کلمات بیانگر یک سطح از معماری هستند و در هر سطح میزان بیان جزئیات متفاوت است و هر چه از Context به Code حرکت می‌کنیم به جزئيات معماری افزوده می‌شود.در سطح Context تنها خود سیستم نرم‌افزاری که قصد توسعه آن را داریم یا در حال توسعه آن هستیم، نشان داده می‌شود. در این نمودار ارتباط میان سیستم‌ با سایر سیستم‌ها و کاربران را به خوبی می‌توان نشان داد. به طور کلی می‌توان گفت محیطی را که سیستم قرار است با آن تعامل داشته باشد را به خوبی بیان می‌کند و درواقع به صورت کلی به سیستم نگاه می‌‌کند. به عنوان مثال تصویر ۱،یک نمونه از نمودار Context است. در این تصویر یک سیستم بانکداری اینترنت قرار دارد که همان سیستم نرم‌افزاری ما می‌باشد. کاربران این سیستم مشتریان بانک هستند که می‌توانند موجودی خود را مشاهده کنند و پرداخت‌های خود را انجام دهند. همچنین اطلاعات حساب‌ها را از سیستم بانکداری مرکزی می‌گیرد و با یک سرویس ایمیل نیز، برای ارسال پیام به کاربران، در ارتباط است. همانگونه که مشاهده می‌کنید این نمودار اطلاعات محیطی سیستم را به خوبی نمایش می‌دهد و کاربران این نمودار برای فهم آن نیاز به دانش خاصی ندارند و تنها مختص توسعه دهنده و معمار نرم‌افزار نمی‌باشد.تصویر ۱ - نمودار Contextیک سیستم نرم‌افزاری از مجموعه‌ای از اجزا تشکیل شده است که به آن‌ها Container می‌گویند. Containerها همان برنامه‌ها و پایگاه‌های ذخیره اطلاعات هستند مانند: برنامه‌های موبایل، برنامه‌های تحت وب و APIها. در این نمودار نوع، تعداد و ارتباط میان Containerها نمایش داده می‌شود و تکنولوژی‌های استفاده شده نیز قابل نمایش است. به عنوان مثال می‌توان نشان داد که در یک برنامه‌ی تحت وب از چه فریم‌ورکی(Framework) استفاده شده است. از ویژگی‌های Containerها این است که هر کدام به صورت جداگانه قابلیت دیپلوی شدن دارند و وابسته به Container دیگری نیستند. مخاطبان این نمودار افراد فنی هستند چه آن‌هایی که در داخل تیم حضور دارند و چه بیرون تیم. تصویر ۲، درون سیستم بانکداری اینترنتی را نشان می‌دهد که از چه Containerهایی تشکیل شده است و چه ارتباط‌هایی میان آن‌ها برقرار است.تصویر ۲ - نمودار Containerسومین سطح از مدل Component ،C4ها هستند که اجزای سازنده‌ی یک Container نیز می‌باشند. هر Component از مجموعه‌ای از کلاس‌ها تشکیل شده است مانند Controllerهایی که برای یک Container پیاده‌سازی می‌شوند. در نمودار Component مسئولیت‌ها و جزئیات پیاده‌سازی هر کدام نشان داده شده هست. در تصویر ۳، Componentهای API برنامه نشان داده شده است که در این نمودار وظیفه‌ی هر Component و ارتباط میان‌ آن‌ها به خوبی نشان داده شده.تصویر ۳ - نمودار Componentسطح چهارم و آخر که جزئی‌ترین سطح نیز می‌باشد، سطح Code است که کدهای سازنده‌ی یک Component را نشان می‌دهد. البته این سطح اختیاری است و آقای Brown در کنفرانس Agile on the beach در سال ۲۰۱۹ توصیه کردند که از این نمودار استفاده نشود، به دلیل جزئیات زیادی که دارد و از طرفی نمودارهای مربوط به Code را می‌توان از خود IDE استخراج کرد و نیازی به رسم نمودار دیگری نیست. در تصویر ۴ نمونه‌ای از این نمودار را مشاهده می‌کنید.تصویر ۴ - نمودار Codeهمچنین مخاطبان و استفاده کنندگان در دو سطح آخر، Component و Code، توسعه‌دهندگان و معماران نرم‌افزار هستند.علائم در مدل C4در مدل C4 علائم خاصی برای رسم نمودارها به صورت یک قرار داد و قانون گفته نشده ولی پیشنهاداتی داده شده است. اما تاکید شده است که استفاده‌ی درست از علائم و نوشتن توضیحات بسیار مهم است و در فهم نمودار بسیار کمک می‌کند. از مواردی که در رسم نمودار مهم است خط‌هایی است که برای نمایش ارتباط میان جعبه‌های(Box) نمودار کشیده می‌شود. خطوط باید به صورت یک طرفه باشند نه دو طرفه. در برخی مواقع که بین دو جعبه مجبور به رسم دو یا بیشتر خط هستیم می‌توان یک خط میان آن دو بکشیم و یک توضیح مناسب نیز روی خط اتصال کننده بنویسیم. این کار سبب کاهش شلوغی و پیچیدگی نمودار می‌شود. به عنوان مثال در تصویر ۱، ارتباط میان سیستم بانکداری اینترنت با بانکدار مرکزی را با دو خط می‌توان بیان کرد، یک خط برای درخواست اطلاعات از سمت سیستم بانکداری اینترنتی و یک خط دیگر برای پاسخ بانکداری مرکزی به بانکداری اینترنتی. اما همانگونه که مشاهده می‌کنید با یک خط و توضیح مناسب برروی آن ارتباط میان دو سیستم بیان شده است. بنابراین باید به توضیحاتی که درون جعبه‌ها و بین خطوط ارتباطی می‌نویسیم توجه کنیم. نکته‌ی دیگر در مورد لیستی از علائم مانند رنگ‌ها، شکل‌ها، خط‌ها و غیره است. علائم استفاده شده در نمودار باید معلوم باشند که هر کدام نشان دهنده‌ی چه چیزی هستند تا در فهم بهتر و سریع‌تر نمودار کمک کند و مخاطب گیج نشود. همچنین از آیکون‌ها نیز می‌توان به عنوان تکمیل کننده‌ی یک جزء از نمودار استفاده شود به عنوان مثال در تصویر ۲ می‌شد از آیکون‌های Angular و JS ،که در تصویر ۵ نشان داده شده‌اند، به عنوان تکنولوژی‌های استفاده شده در برنامه‌ی Single-Page استفاده کرد و دیگر نیازی به نوشتن توضیح نبود. در استفاده از آیکون‌ها نباید زیاده‌روی کرد و به جای جعبه‌ها یا توضیح در برخی مواقع از آیکون استفاده کرد زیرا این کار ممکن است برای تیم توسعه یا معماری سیستم قابل فهم باشد اما برای یک فرد فنی خارج از سازمان غیرقابل فهم باشد.تصویر ۵ - آیکون‌های جاوا اسکریپت و انگولارابزار رسم نمودارهابرای رسم نمودارهای C4 ابزارهایی هم معرفی شده‌اند مانند C4-PlantUML و Structurizr که مختص رسم نمودارهای معماری نرم‌افزار هستند. اما نکته‌ای که در انتخاب ابزار رسم این نمودارها مهم است آن است که نباید ابزارهایی را انتخاب کرد که با هدف‌های عمومی برای رسم نمودارها ایجاد شده‌اند مانند Visio. زیرا طبق گفته‌ی آقای Brown این گونه ابزارها به صورت تخصصی برای معماری نرم‌افزار طراحی نشده‌اند و فهمی هم از سیستم‌های نرم‌افزاری ندارند، بنابراین برای مستند کردن معماری ابزارهای خوبی نمی‌توانند باشند.نتیجه گیریهر سیستم نر‌م‌افزاری که ساخته می‌شود یک معماری دارد بنابراین بهتر است که معماری آن را مستند کرد زیرا، نرم‌افزار یک محصولی است که مرتب در حال تغییر و گسترش است و افرادی که توسعه می‌دهند ممکن است تغییر کنند و افراد جدید به تیم توسعه اضافه شوند و با وجود مستند معماری به خوبی می‌توانند سیستم را بفهمند. برای مستند کردن آن مدلی به نام C4 معرفی شده است. این مدل معماری یک سیستم نرم‌افزاری را در چهار سطح Component، Container، Context و Code بررسی می‌کند. ابتدا در سطح Context با محیطی که نرم‌افزار درگیر آن است آشنا می‌شوید و با وارد شدن به درون سیستم با Containerهای سازنده‌ی آن مانند APIها و برنامه‌های تحت وب. برای دیدن محتویات درون هر Container نیز می‌توانید به نمودار Component مربوط به آن Container مراجعه کنید و در صورت لزوم، کدهای هر Component نیز به کمک نمودار Code قابل مشاهده است. بنابراین به کمک این مدل به خوبی می‌توان معماری یک سیستم را با جزئیات مختلف بیان کرد.مراجعhttps://www.youtube.com/watch?v=x2-rSnhpw0ghttps://c4model.comhttps://en.wikipedia.org/wiki/C4_modelاین مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است</description>
                <category>محمد ربانی بیدگلی</category>
                <author>محمد ربانی بیدگلی</author>
                <pubDate>Wed, 17 Nov 2021 21:30:32 +0330</pubDate>
            </item>
            </channel>
</rss>