https://virgool.io/feed/@shimaseyfollahi fa 2026-06-16 22:14:46 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@shimaseyfollahi https://virgool.io/@shimaseyfollahi/%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%AF%D8%B1-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%A7%D8%B2%DB%8C-osqogjvsv9yd چکیدهتوسعه دهندگان بازی هر سال با تقاضای فزاینده برای بازی‌های جدید مواجه هستند. فرایند توسعه بازی به دلیل پیچیدگی پلتفرم بازی و عدم وجود متدلوژی‌های توسعه بازی برای فرایندهای یکپارچه‌سازی دشوار است. امروزه برخی از پروژه‌های بازی بسیار پیچیده هستند و پلتفرم‌ها و برنامه‌های نرم‌افزاری که آن‌ها را هدایت می‌کنند به نسبت پیچیده‌تر می‌شوند.که به سبب آن نرم‌افزار بازی دارای معماری نرم‌افزار پیچیده با ماژول‌های فراوان متصل به هم است. در نتیجه تیم‌های توسعه‌دهنده بازی بزرگتر می‌شوند و نقش افراد در این تیم‌ها تخصصی‌تر می‌شود. برای ایجاد یک بازی و مکانیک‌های موجود در آن با کیفیت بالا و هزینه و زمان کمتر باید اصول مهندسی و معماری نرم‌افزار رعایت شود. معماری نرم‌افزار می‌تواند به عنوان نقطه شروعی برای توسعه یکپارچه بازی باشد و به عنوان بخش مهمی از فرایند طراحی و توسعه بازی است که سبب دستیابی به نرم‌افزاری با عملکرد خوب و قابلیت تغییرپذیری و انعطاف بالا می‌گردد. امروزه توسعه‌دهندگان نرم‌افزار به دنبال یافتن معماری نرم‌افزاری هستند که امکان استفاده مجدد، انتقال و توسعه را فراهم کند. بنابراین این مقاله مروری به مرور، بررسی و مقایسه رویکردهای موجود در معماری نرم‌افزار برای طراحی و توسعه انواع بازی‌ها به منظور دستیابی به ویژگی‌های کیفی و یکپارچه‌سازی برنامه‌های بازی و کاهش هزینه، زمان و پیچیدگی می‌پردازد و سپس پیشنهاداتی به منظور بهبود طراحی و توسعه نرم‌افزارهای بازی در حوزه معماری نرم‌افزار ارائه می‌گردد.۱. مقدمهتوصیف مؤلفه‌های اصلی و ساختارهای مهم یک سیستم نرم‌افزاری به همراه توصیف ارتباطات و تعاملاتی که بخش‌های مختلف با یکدیگر دارند را معماری نرم‌افزار می‌گویند که توصیفی سطح بالا از نرم‌افزار است. معماری نرم‌افزار درک مشترک افراد از سیستم و تصمیم‌های طراحی زودهنگام در نرم‌افزار است. هدف معماری نرم‌افزار کمینه کردن منابع انسانی مورد نیاز برای ساخت و نگهداری سیستم مورد نظر است. بازی نیز یک برنامه نرم‌افزاری است و توسعه آن دارای چالش‌ها و مشکلاتی است و با افزایش زمان، هزینه و ویچیدگی همراه است. بنابراین برای طراحی، توسعه و یکپارچه‌سازی آن به منظور دستیابی که ویژگی‌های کیفی از جمله قابلیت استفاده مجدد، قابلیت همکاری، انعطاف‌پذیری، توسعه‌پذیری، قابلیت نگهداری، استحکام، مقیاس‌پذیری، قابلیت اعتماد، قابلیت حمل و ... از رویکردهای موجود در معماری نرم‌افزار استفاده می‌شود.از جمله روش‌های موجود استفاده از رویکرد مدل محور است. سبب افزایش سطح انتزاع در توسعه بازی می‌شود. ترکیبی از زبان‌های خاص دامنه (DLS) تولید‌کننده کد است. از مدل‌هایی برای تعریف مشخصات دامنه‌های مختلف استفاده می‌کند که به عنوان ورودی برای مجموعه‌ای از تبدیل‌ها که به طور خودکار کد را تولید می‌کنند می‌باشد. همچنین سبب می‌شود تا توسعه‌دهندگان کم‌تجربه‌تر با شرکت در فرایند ایجاد بازی برخی از مسائل موجود در صنعت را حل کنند [2]. این رویکرد دارای چسبندگی ضعیف هست که امکان تعویض فناوری‌های اصلی را فراهم می‌کند و به توسعه‌دهندگان این امکان را می‌دهد تا مؤلفه‌های اولویت‌دار را به صورت منعطف برای پشتیبانی از سبک خاصی از بازی جدی انتخاب کنند و بهره‌وری و قابلیت استفاده مجدد از مصنوعات نرم‌افزاری افزایش می‌یابد در نتیجه زمان توسعه کاهش می‌یابد و قابلیت همکاری و قابلیت حل بین پلتفرم‌های بازی افزایش می‌یابد [3][4].روش دیگر استفاده از الگوهای طراحی و معماری است. الگوهای طراحی یک راه‌حل کلی قابل استفاده مجدد در مسائل تکرارشونده و زمینه قابل استفاده مجدد است که مستقیما به کد قابل تبدیل نیستند و در داخل هر پروژه، الگوها به کد تبدیل می‌شوند. الگوهای طراحی راه‌حل‌های ثابت شده‌ای برای مشکلات مهندسی نرم‌افزار هستند و در برنامه‌نویسی بازی سبب اطمینان یافتن از صحت برنامه توسط ارزیابی رفتار کاراکتر ، مقیاس‌پذیری، نگهداری، انعطاف‌پذیری، توسعه‌پذیری، کاهش هزینه نگهداری و استحکام در برابر تغییرات می‌گردد [11]. الگوهای معماری همانند الگوهای نرم‌افزاری هستند ولی در سطح معماری نرم‌افزار قرار دارند و روش‌های طراحی برای معماری نرم‌افزار در ابعاد گسترده‌تری هستند. خط تولید نرم‌افزار مجموعه‌ای از سیستم‌های نرم‌افزاری است که دارای مجموعه‌ای از ویژگی‌های عمومی و مدیریت شده مشترک هستند، نیازهای مشخصی از بازار یا ماموریت خاصی را برآورده می‌نمایند و براساس مجموعة مشترکی از دارایی‌های اصلی توسعه داده می‌شوند. از بین دارایی‌های اصلی یک خط تولید نرم‌افزار، معماری مهم‌ترین دارایی است که محصولات متعلق به خط تولید نرم‌افزار را تعریف می‌کند و به تشخیص صحیح عناصر ثابت و نقاط تغییر برای همه اعضای خط تولید نرم‌افزار می‌پردازد.در این مقاله ابتدا به مرور و بررسی کارهای پیشین در حوزه استفاده از معماری نرم‌افزار در توسعه نرم‌افزار بازی با استفاده از رویکردهای مدل محور، الگوهای طراحی و معماری، سایر رویکردهای موجود در حوزه معماری نرم‌افزار و خط تولید نرم‌افزار به منظور بهبود توسعه، طراحی و یکپارچه‌سازی انواع بازی‌ها، دستیابی به ویژگی‌های کیفی، کاهش زمان، هزینه و پیچیدگی و ... در برنامه‌های بازی پرداخته می‌شود. سپس تحلیل و ارزیابی رویکردهای پیشین و مقایسه و بررسی آن‌ها براساس ویژگی‌هایی بیان می‌گردد. در پایان نیز پیشنهاداتی برای بهبود طراحی و توسعه نرم‌افزار بازی در حوزه معماری نرم‌افزار ارائه می‌گردد.۲. کارهای پیشیندر این بخش به مرور و بررسی کارهای پیشین با استفاده از حوزه مدل‌محور، الگوهای طراحی و معماری، سایر رویکردهای حوزه معماری نرم‌افزار و خط تولید نرم‌افزار در توسعه نرم‌افزار بازی پرداخته می‌شود.حوزه مدل‌محوردر این بخش به مرور و بررسی کارهای پیشین در حوزه مدل‌محور در توسعه نرم‌افزار بازی پرداخته می‌شود.۲.۱. توسعه مدل محور رابط کاربری برای بازی‌های آموزشی [1]هدف این معماری مدلسازی و توسعه رابط کاربری بازی‌های آموزشی و طراحی رابط کاربری برای دادن انگیزه به کاربران با توانایی یادگیری و اولویت‌های متنوع در فرایند یادگیری است است که براساس مدل و چارچوبی شامل فرا مدل‌ها، مدل‌ها،‌ تبدیل‌ها و ابزارهای نرم‌افزاری است و با شناسایی پروفایل‌های بازیکن براساس توانایی‌ها و اولویت‌های بازیکن و اتخاذ تعامل بازی با پروفایل بازیکن به دست می‌آید. این معماری شامل اصول تئوری انگیزشی و همچنین تعامل انسان و کامپیوتر چند وجهی است. مدلسازی این رویکرد با استفاده از UML و XML و ادغام مکانیزم‌ها صورت می‌گیرد و مؤلفه‌ها براساس زبان استاندارد و رایج تعریف شده در متامدل بازی آموزشی است. مزیت آن قابلیت استفاده مجدد از دانش و همچنین محتوای بازی است یعنی توانایی نگهداری تعامل بازی، در حالی که فقط محتوای آموزشی تغییر می‌کند.در شکل 1 مفهوم ارتباط بین بازیکن و بازی نمایش داده شده است. مفهوم اصلی در این فرامدل، GameModality است که به عنوان نوعی تعامل بین بازیکن و بازی تعریف شده است و از فرامدل چندمدلی تعامل انسان – کامپیوتر ایجاد می‌شود. تعامل چندمدلی را می‌توان بین چند بازیکن و (GamePlayer) و چندین پلتفرم بازی (GamePlatform) برقرار کرد. GameContext مجموعه‌ای از شرایط و حقایق مربوط به وضعیتی خاص را تعریف می‌کند و می‌تواند بر تعامل بین انسان و بازی تاثیر بگذارد. طبقه‌بندی GameContext شامل زمینه فیزیکی برای بین شرایط محیطی، زمینه موقعیتی برای بیان وضعیت فعلی در محیط از نقطه نظر وظیفه کاربر، دانش مشترک یعنی مجموعه‌ای از حقایق درک شده توسط انسان و کامپیوتر و زمینه اجتماعی برای بیان محیط اجتماعی تعامل است.شکل 1: مفهوم ارتباط بین بازیکن و بازی [1]در شکل 2 جزئیات ارتباط بین بازیکن و بازی نمایش داده شده است. مؤلفه Input Output EduGameInteraction مربوط به ورودی کاربر و Output EduGameInteraction مربوط به خروجی بازی است. EduGameEngine تمام عناصر یک صحنه را در بازی ایجاد می‌کند. PlayerProfile در ابتدای بازی تشخیص داده می‌شود و می‌تواند به صورت پویا در طول بازی تنظیم شود و به اقدامات بازیکن وابسته است. مؤلفه UserInterfaceAction اقدامات سطح پایین انجام شده توسط بازیکن مانند حرکت ماوس یا فشردن کلید صفحه کلید را نمایش می‌دهد. EduGameInteraction اقدامات را مدیریت می‌کند و تغییراتی که بر EduGame اثر می‌گذارد را تشخیص می‌دهد. زمانی که یک اقدام مهم شناسایی می‌شود، EduGameEvent افزایش می‌یابد مثل پاسخ به یک سوال یا حل یک پازل و سپس به EduGameEngine برای پردازش‌های بیشتر ارسال می‌شود. EduGameEngine یک EduGameScen جدید تولید می‌کند و Output EduGameInteraction را راه‌اندازی می‌کند. هدف اصلی جداسازی EduGameEngine و EduGameInteraction است. EduGameEngine منطق بازی را نمایش می‌دهد و EduGameInteraction نمایانگر تعامل با بازیکن است.شکل 2: جزئیات مفهوم ارتباط بین بازیکن و بازی [1]۲.۲ یک رویکرد توسعه بازی مدل محور منعطف [2]از یک رویکرد توسعه بازی مدل‌محور (MDGD) که ترکیبی از چندین زبان خاص دامنه (DSL) با الگوهایی برای ایجاد انعطاف‌پذیری، بهره‌وری، تسهیل و توسعه استفاده شده است و یک موتور بازی، چند DSL، تولید کد و الگوهای طراحی سبب ادغام کد تولید شده با کد دستی ادغام می‌شود که نتیجه آن یک موتور بازی با مزایای MDGD بدون از دست دادن انعطاف‌پذیری است. توسعه‌دهندگان با تجربه کمتر نیز می‌توانند بازی‌ها را سریع‌تر و آسان‌تر با موتور بازی ایجاد کنند و انعطاف‌پذیری را برای توسعه‌دهندگان فراهم می‌کند. با استفاده از MDGD توسعه‌دهندگان با کد نهایی کمتر آشنا می‌شود و کدنویسی دستی را سخت‌تر می‌کند.شکل 3 نمای کلی رویکرد را نمایش می‌دهد که در آن سه ویرایشگر دوربین، کاراکتر و سناریو توسعه داده شده است. توسعه‌دهنده ممکن است مدل‌هایی برای این ویژگی‌ها ایجاد کند که این مدل‌ها در فایل‌های XML ذخیره می‌شوند. یک پردازنده الگو مدل‌ها را می‌خواند و براساس برخی از قالب‌های توسعه‌یافته کدی تولید می‌شود که جنبه‌های مدلسازی شده را پیاده‌سازی می‌کند. کد تولید شده با معماری بازی مرجع از طریق برخی از الگوهای طراحی ادغام می‌شود. این الگوها امکان ادغام کدهای تولید شده و تولید نشده را فراهم می‌کنند. در نتیجه بازی روی یک موتور بازی اجرا می‌شود و حداکثر انعطاف‌پذیری و پتانسیل را برای بازی ارائه می‌دهد.شکل 3: مؤلفه‌های رویکرد MDGD در بازی [2]برای نمایش معماری، از یک نمودار UML برای نمایش اشیای بازی و ساختار ایستا استفاده می‌شود. این معماری برای تولیدکنندگان کد مختلف امکان همکاری و پشتیبانی از ادغام با کد دستی را فراهم می‌کند که در شکل 4 نمایش داده شده است. در آن یک کلاس اصلی وجود دارد که نمایانگر نقطه ورود به توسعه بازی‌ها در موتور بازی است، این کلاس دارای متدهایی برای مقداردهی اولیه است و تعدادی ویژگی و متد برای تغییرات حالت داخلی دارد. کلاس اصلی همچنین با سایر کلاس‌ها برای نمایش عناصر اصلی یک بازی ارتباط دارد. برای هر زیردامنه یک بسته وجود دارد. بسته دوربین شامل یک interface و یک کلاس پیاده‌سازی است که مسئول پیکربندی دوربین است. بسته کاراکتر شامل یک interface و یک کلاس پیاده‌سازی است که مسئول تغییرات و پیکربندی کاراکتر است. بسته سناریو شامل یک interface و 4 کلاس شامل کلاس سناریو بازی به عنوان ظرفی برای عناصر سناریو، کلاس کف و بستر سناریو، کلاسی برای تشخیص موقعیت اولیه کاراکترها و کلاسی برای تشخیص موقعیت اولیه بازیکن است. سناریو همچنین شامل مجموعه‌ای از بخش‌ها برای نمایش برخی از عناصر هست. برخی از بخش‌های معماری به صورت دستی و برخی دیگر به صورت خودکار انجام می‌شود.شکل 4: معماری رویکرد پیشنهادی [2]این رویکرد برای ادغام کد دستی و کد تولید شده از الگوهای طراحی را با توجه به موقعیت استفاده می‌کند. در موقعیتی که کد تولید شده به کد تولید نشده بستگی داشته باشد، از الگوی Facade استفاده می‌شود که برای سهولت تعامل بین کد تولیدشده و کد تولید نشده استفاده می‌شود. در موقعیتی که کد تولید نشده وابسته به کد تولید شده است، می‌توان از الگوی Factory استفاده کرد. در موقعیتی که کد تولید شده به کد تولید شده وابستگی دارد، دو تا زیردامنه باید به هم ارجاع دهند که یک راه استفاده از نام عناصر به عنوان ارجاعات است که باید با نام عناصر ارجاع شده در مدل دیگر تطبیق داده شود. راه دیگر، پل‌های مدل است که ایجاد تکراری عناصر از فرامدل ارجاع شده به متامدل مرجع است. این معماری ادغام بین چند DSL را سبب می‌شود. همچنین امکان درج کد سفارشی را فراهم می‌کند. با استفاده از رویکرد MDGD وظایف با نرخ بیشتری به درستی انجام می‌شود.۲.۳ یک مدل فناوری بازی مستقل از پلتفرم برای توسعه بازی‌های جدی مدل محور [3]مدل فناوری بازی (GTM) یک نمایش محاسباتی نرم‌افزار بازی و مستقل از پلتفرم پیاده‌سازی و سخت‌افزار مبتنی بر مدل محتوای بازی و معماری داده‌محور برای رفع ضعف ابزارهای نویسندگی سطح بالا برای بازی‌های جدی برای متخصصان غیردامنه ارائه شده است که مدل‌های نرم‌افزاری بازی جدی را مستقل از هر سخت‌افزار یا مشخصات پلتفرم برای استفاده در توسعه بازی جدی مدل محور ایجاد می‌کند. با استفاده از ابزار مهندسی مدل‌محور (MDE) مدل محتوای بازی به مدل فناوری بازی ترجمه می‌شود. در این معماری از مدل‌ها و ابزار MDE برای نمایش محتوا و منطق در تولید مصنوعات نرم‌افزاری استفاده می‌شوند. دسترس‌پذیری GTM و ابزارهای نویسندگی سطح بالا امکان تست و ارزیابی را برای نمونه اولیه فراهم می‌کند و بهبود بیشتری در طراحی بازی‌ بدون داشتن موانع فنی موجود در توسعه بازی‌های جدی آموزشی ایجاد می‌کند.براساس شکل 5 فناوری بازی در این رویکرد دارای دو لایه اصلی یعنی لایه سیستم‌های خاص بازی لایه مؤلفه‌های اصلی است. لایه سیستم‌های خاص بازی از سیستم زمینه بازی تشکیل شده است که بازی را تنظیم می‌کند و تعویض پویا بین presentation و شبیه‌سازی را مدیریت می‌کند. سیستم شبیه‌سازی بازی شامل اشیا بازی ایستا و پویا است و ‌رویدادهای بازی را تشکیل می‌دهد. لایه مؤلفه‌های اصلی انعطاف‌پذیری را برای تعیین مؤلفه‌های ارجح‌تر و افزایش استقلال روی انتخاب فناوری‌های بازی را فراهم می‌کند. از امکانات لایه اصلی برای فعال‌سازی اجرای سیستم محتوای بازی و سیستم شبیه‌سازی بازی استفاده می‌کند. رابط کاربری، پخش‌کننده ویدیو، فیزیک‌های بازی، انیمیشن، گرافیک، صدا، هوش مصنوعی، ورودی، شبکه و مدیریت منابع بازی به عنوان فناوری‌های اصلی در لایه مؤلفه اصلی مدل فناوری بازی هستند. شبکه به عنوان یک مؤلفه سرویس در نظر گرفته می‌شود که توسعه‌دهندگان در هنگام توسعه بازی‌های چند نفره از آن استفاده کنند. در GTM همه داده‌های شبکه به عنوان جریان‌های ورودی توسط کنترل‌کننده پیام مدیریت می‌شوند.شکل 5: نمایی از مدل فنلوری بازی [3]وظیفه سیستم محتوای بازی راه‌اندازی برنامه با راه‌اندازی اولیه سخت‌افزار، صدا، گرافیک و ... است. در GTM یک بازی به بخش‌هایی به عنوان محتوای بازی تقسیم می‌شود. یک زمینه بازی نوع محتوای بازی را به صورت نمایش یا شبیه‌سازی بازی برای بازیکنان توصیف می‌کند. سناریو بازی به عنوان یک محتوا برای شبیه‌سازی بازی در نظر گرفته می‌شوند. جداسازی سناریو از شبیه‌سازی سبب می‌شود تا از سناریو یکسانی در شبیه‌سازی سازگار انواع بازی‌ها بتوان استفاده کرد. زمینه‌ها با استفاده از پشته و به ترتیب و به صورت صحیح اجرا می‌شوند و هر زمینه روش مخصوص به خود را دارد. در بالاترین سطح نرم‌افزار بازی، برنامه بازی جدی قرار دارد که از سیستم محتوای بازی استفاده می‌کند و رابط لازم را برای بازیکن برای تعامل با بازی فراهم می‌کند. این مدل عملکرد بازی‌های جدی تعریف شده توسط مدل محتوای بازی را تسهیل می‌کند و مدل فناوری شبیه‌ساز فقط سبک‌های شبیه‌سازی و نقش‌آفرینی بازی‌های جدی را شامل می‌شود.۲.۴ خودکارسازی prototype در توسعه بازی مدل محور [4]رویکردی برای خودکارسازی نمونه اولیه بازی دو بعدی از طریق استفاده از مهندسی مدل محور (MDE) ارائه شده است که نتایج رضایت‌بخشی را برای تولید کد نشان می‌دهد، سبب افزایش سطح انتزاع توسعه بازی نسبت به مدلسازی مفهومی، افزایش معنادار بهره‌وری و کاهش زمان و هزینه توسعه، امکان استفاده مجدد برای تکامل نهایی می‌گردد. مدل‌های مستقل از پلتفرم (PIM) ساختار و رفتار بازی و یک مدل پلتفرم خاص (PSM) نگاشت کنترل بازی را فراهم می‌کند. نمونه اولیه حاصل می‌تواند برای تکامل بازی نهایی دوباره مورد استفاده قرار گیرد. برنامه‌نویس باید فقط جنبه‌های تعریف نشده در مدل مانند هوش مصنوعی دشمنان را کدنویسی کند. همچنین برای تسهیل ایجاد موجودیت‌های بازی یک ویرایشگر سطح گرافیکی توسعه داده شده است. در شکل 6 نمایی از این رویکرد نمایش داده شده است.شکل 6: نمایی از رویکرد پیشنهادی برای یک بازی [4]ویرایشگرها سبب تسهیل مدلسازی با استفاده از یک رابط کاربری مناسب می‌شود. براساس شکل 7 یک یا چند مدل پلتفرم خاص (PSM) نحوه پیاده‌سازی (PIM) در هر پلتفرم میان‌افزار را توصیف می‌کند. تبدیل مدل PIM به مدل‌های PSM قبل از تولید کد سبب جداسازی سطوح عملکرد و فناوری می‌شود که تطبیق مداوم با پلتفرم‌های فناوری جدید را تسهیل می‌کند. در این رویکرد از زبان خاص دامنه گرافیکی (DSL) برای نمایش جنبه‌های مختلف بازی استفاده می‌شود. با نگاشت کنترلی می‌توان رفتار بازی را از کنترل‌کننده با استفاده از تعامل با بازی جدا کرد که بازیکنان می‌توانند با بازی از طریق کنترل‌کننده‌ها یا نگاشت‌های مختلف تعامل کنند و پاسخ‌دهی به صورت یکپارچه صورت می‌گیرد. به دلیل آن که نمودار نگاشت کنترلی یک عمل بازی را به یک سیگنال کنترلی ارسال شده از یک کنترلر مرتبط می‌کند، نگاشت کنترلی می‌تواند سیگنال‌های کنترلی را به اقدامات بازی ترجمه کند.شکل 7: نمایی از طرح توسعه [7]۲.۵ طراحی بازی MDA برای توسعه بازی ویدیویی توسط سبک [5]روشی نیمه خودکار برای توسعه انواع مختلف بازی‌های arcade با استفاده از معماری مدل محور برای توسعه‌دهندگان مبتدی است و هدف این رویکرد تست فوری برنامه‌ها پس از نوشتن آن‌ها است. همچنین یک فرامدل را برای طراحی بازی فراهم می‌کند که مشخصاتی را برای یک انتزاع سطح بالا و مستقل از پلتفرم ایجاد می‌کند. امکان تولید یک بازی دو بعدی را از ویژگی‌های اساسی تولیدکننده این نوع بازی ویدیویی فراهم می‌کند. همچنین مجموعه‌ای از قوانین تبدیل مدل برای تولید کد جاوا قابل اجرا از یک مدل خاص و روشی استاندارد برای طراحان مبتدی بازی را فراهم می‌کند و کارایی و اثربخشی توسعه‌دهندگان را به حداکثر می‌رساند. در شکل 8 نمایی از این رویکرد نمایش داده شده است.شکل 8: نمایی از رویکرد پیشنهادی [5]پلتفرم مورد استفاده در این بازی به توسعه‌دهندگان اجازه می‌دهد که کد خود را یکبار بنویسند اما آن را روی منابع مختلف و برای هر سبکی اجرا کنند. MDA فرایند مبتنی بر مجموعه‌ای از مدل‌ها را برای ساختار نرم‌افزار ارائه می‌دهد و راهی جدید برای توسعه نرم‌افزار با تبدیل یک مدل ورودی به یک مدل خروجی است. این مدل‌ها در سه راستا شامل مدل مستقل محاسباتی (CIM) برای توصیف سیستم بدون نمایش جزئیات ساخت آن، مدل مستقل از پلتفرم (PIM) برای انعکاس عملکردها، ساختار و رفتار یک سیستم بدون اطلاعاتی از پلتفرم یا فناوری مورد استفاده و مدل پیاده‌سازی گرا و خاص پلتفرم (PSM) مطابق با اولین مرحله اتصال یک PIM مشخص به یک پلتفرم اجرایی مشخص سازماندهی می‌شود. با استفاده از برخی قوانین تبدیلات مدل، سیستم نرم‌افزاری از یک PIM به کد منبع توسعه می‌یابد. در توسعه این رویکرد در مرحله اول، PIM برای انواع بازی‌های arcade تعریف می‌شود. در مرحله دوم یک نمونه از PIM ایجاد می‌شود. در مرحله سوم مجموعه‌ای از قوانین تبدیل مدل به متن، کد منبع را از مدل arcade تولید می‌کند.۲.۶ رویکرد MDA برای قابلیت استفاده مجدد در بازی جدی و طراحی آموزش الکترونیکی [6]هدف این رویکرد کاهش زمان و هزینه توسعه سناریوهای بازی‌های جدی با ارائه فرایندی برای ساخت سناریوهای عمومی با قابلیت استفاده مجدد و قابلیت همکاری مبتنی بر معماری مدل محور است برای این منظور یک متامدل که قابلیت توصیف و شاخص‌گذاری سناریوهای بازی را دارد استفاده می‌شود. سپس از رویکرد MDA برای تولید، ترجمه، تعویض و بروزرسانی این سناریوها و ادغام آن‌ها در پلتفرم‌های مختلف استفاده می‌شود. سناریوهای پیچیده‌تر نیاز به قوانین پیچیده‌تری برای انطباق مدل‌های تولید شده با فرامدل پایه دارند. از ویرایشگر گرافیکی برای طراحی سناریوهای ساده استفاده می‌شود. سپس غنی‌سازی مرحله به مرحله سناریو با طراحی و گنجاندن سایر مؤلفه‌های بازی صورت می‌گیرد. پیاده‌سازی سناریوهای بازی آموزشی و ادغام آن‌ها در دو زمینه ارائه می‌شود. اولین زمینه بر جنبه‌های بازی تمرکز می‌کند و دومین زمینه بر جنبه‌های آموزشی تمرکز می‌کند. در شکل 9 نمایی از این رویکرد نمایش داده شده است.شکل 9: فرامدل رویکرد پیشنهادی [6] در این رویکرد گام اول شامل تعریف یک مدل محاسباتی مستقل (CIM) است. مرحله دوم تبدیل مدل CIM به یک مدل مستقل پلتفرم (PIM) است. در نهایت MDA، مدل PIM را به مدل دیگری (PSM) طراحی شده برای نمایش یک پلتفرم خاص تبدیل می‌کند. بنابراین طراح بازی می‌تواند مدل‌های آموزشی و لذت‌بخش را در سطح PIM مطابق با مفهوم متامدل در مرحله CIM‌ طراحی کند. مدل PSM قابلیت توصیف مشخصات پلتفرم را دارد، به محتوای عملیاتی بستگی دارد، یک پلتفرم هدف را نمایش می‌دهد و جزئیات سناریو و ویژگی‌های گرافیکی در سطح PSM ارائه می‌شوند که این جزئیات می‌تواند مشخصات شی بازی را نمایش دهد. گام بعدی ادغام مؤثر عناصر PSM در پلتفرم هدف است. MDA به مدل‌های انتزاعی متکی است که استقلال آن را از هر سیستم سخت‌افزاری یا نرم‌افزاری ارتقا می‌دهد. در این رویکرد فرامدل باید شامل محتوای بازی باشد. به منظور حفظ انعطاف‌پذیری باید جنبه آموزشی و بازی جداگانه و هم‌زمان تعریف شوند.حوزه الگوهای طراحی و معماریدر این بخش به مرور و بررسی کارهای پیشین با استفاده از حوزه الگوهای طراحی و معماری در توسعه نرم‌افزار بازی پرداخته می‌شود.۲.۷. یک معماری نرم‌افزار مشترک برای بازی‌های آموزشی (EGA) [7]یک معماری نرم‌افزار مشترک برای همه بازی‌های آموزشی (EGA) ارائه شده است که دستورات معماری را به صورت یکپارچه و رسمی تحقق می‌بخشد و می‌تواند به عنوان طرحی برای بهبود بهره‌وری و کیفیت بازی‌های آموزشی مورد استفاده قرار گیرد. EGA می‌تواند به عنوان یک الگوی طراحی، مجددا استفاده قرار گیرد و دارای دو مزیت اصلی است. اول این که طراحان بازی‌ نیازی به کشف و اختراع مجدد ساختار، ارتباطات و مؤلفه‌های مشترک بازی آموزشی ندارد که سبب افزایش بهره‌وری می‌گردد. دوم این که EGA همه ویژگی‌های عملکردی لازم برای اثربخشی بازی‌های آموزشی موفق با احتمال بالا را فراهم می‌کند. EGA یک انتزاع سطح بالا از بازی‌های آموزشی ارائه می‌دهد و در مورد جزئیات پیاده‌سازی نیست و مستقل از پلتفرم و موتور بازی است.معماری EGA شامل 4 زیرسیستم است. اول موضوع است که بازنمایی موضوعات یادگیری توسط عناصر بازی مناسب است. کل موضوعات یادگیری باید ابتدا به گروهی از واحد‌های دانش شکسته شوند و توسط عناصر بازی نمایش داده شوند. شی بازی یک واحد دانش را نمایش می‌دهد که Metaphor نامیده می‌شود. بنابراین زیرسیستم شی گروهی از Metaphorها است. یک بازی می‌تواند ترکیبی از چند سبک باشد. هر سبک به معنای گروهی از عناصر بازی است که برای رسیدن به یک هدف با یکدیگر همکاری می‌کنند. بنابراین زیرسیستم موضوع شامل چندین سبک است که هر سبک گروهی از Metaphorها است. دوم، وظایف یعنی اختصاص دادن وظایف مناسب، خاص، روشن و مرتبط برای بازیکنان براساس عملکرد آن‌ها است. سوم، فعالیت‌ها یعنی ارائه ابزار تعاملی برای بازیکنان به منظور تعامل آن‌ها با آن چه یاد می‌گیرند، است و این مؤلفه شامل گروهی از زیرسیستم‌های ورودی به نام فعالیت است. چهارم، بازخوردها یعنی دادن بازخورد به بازیکنان در مورد عملکردشان است. براساس شکل 10 قهرمان بازی از فعالیت برای تعامل با موضوع استفاده می‌کند که انجام برخی کارها بر موضوع تاثیر می‌گذارد. در نتیجه موضوع از مؤلفه بازخورد برای دادن تعدادی بازخورد استفاده می‌کند که بر قهرمان تاثیر می‌گذارد.شکل 10: نمودار فعالیت برای نمایش جریان کاری در معماری پیشنهادی [7]معماری EGA می‌تواند دوباره برای ایجاد معماری بازی Sim-Eduventure استفاده شود اما باید ابتدا تطبیق یا گسترش یابد. تطبیق EGA برای یک مورد خاص بسیار آسان است. در این معماری حداقل دو زیر سیستم موضوع و وظایف باید گسترش داده شوند و دو زیرسیستم دیگر یعنی بازخوردها و فعالیت‌ها ثابت می‌مانند. هر Metaphor در Sim-Eduventure مسئولیت وظیفه شبیه‌سازی مشابهی را در سیستم هدف به عهده دارد. به دلیل داشتن ماهیت تودرتو ممکن است یک Metaphor جزئی از Metaphor دیگر باشد. همه Metaphorها با یکدیگر کل سیستم هدف را شبیه‌سازی می‌کنند.۲.۸. معماری RAGE برای استفاده مجدد مؤلفه‌های فناوری بازی جدی [8]یک معماری کلی برای تسهیل ادغام و قابلیت استفاده مجدد دارایی‌های نرم‌افزار برای پلتفرم بازی است و از قابلیت استفاده مجدد مؤلفه‌های بازی جدی در زبان‌های برنامه‌نویسی، موتورهای بازی و پلتفرم‌های مختلف بازی پشتیبانی می‌کند. این معماری برای قابلیت حمل دارایی‌ها در سیستم‌ها، زبان‌های برنامه‌نویسی و موتورهای بازی مختلف مورد استفاده قرار می‌گیرد و سبب توسعه در مقیاس بزرگ و برنامه‌های چند موتوره می‌شود.از وابستگی به چارچوب‌های نرم‌افزاری خارجی جلوگیری می‌کند. کدهایی که با کد موتور بازی ادغام نمی‌شوند را به حداقل می‌رساند. به مجموعه محدودی از الگوهای استاندارد نرم‌افزاری متکی است. هدف این معماری تقویت انسجام داخلی و پتانسیل بازی‌های جدی برای آموزش، یادگیری و سایر حوزه‌ها است. در این معماری ساختار و عملکرد دارایی‌های سمت کلاینت مورد توجه قرار می‌گیرد.یک دارایی یک رابط کاربری استاندارد ارائه می‌دهد که می‌تواند مستقیما توسط یک موتور بازی یا الگوی پل پیاده‌سازی شود. دارایی‌ها باید شامل یک سیستم منسجم و مبتنی بر مؤلفه باشند که از قابلیت همکاری داده بین عناصر پشتیبانی می‌کند. دارایی حاوی یک فایل کد منبع یا یک فایل برنامه کامپایل شده یا ممکن است شامل مصنوعات دیگر باشد. دارایی‌های RAGE به عنوان مؤلفه‌های نرم‌افزاری با استفاده مجدد هستند و از یک رویکرد توسعه مبتنی بر مؤلفه استفاده می‌شود. در شکل 11 نمایی از دارایی‌های RAGE نمایش داده شده است.شکل 11: نمایی از دارایی‌های RAGE [8]در این معماری دارایی‌ها می‌توانند در سمت کلاینت و سرور قرار گیرند. در سمت کلاینت بازیکن به زمان اجرای بازی دسترسی دارد. در سمت سرور دارایی‌های سمت سرور پشتیبانی می‌شوند. دارایی‌های سمت سرور ممکن است با سرور بازی ادغام شوند یا در سرورهای راه دور قرار گیرند. دارایی‌های سمت کلاینت زمانی اولویت دارند که تعاملات مستقیم و متعدد با موتور بازی روی کامپیوتر محلی مورد نیاز است یا زمانی که باید نتایج فورا در دسترس قرار گیرد. هر پردازشی می‌تواند در سمت کلاینت انجام شود ولی پردازش گسترده دارایی در سمت سرور به منظور جلوگیری از عملکرد ضعیف بازی صورت می‌گیرد. دارایی‌های که داده‌ها را جمع‌آوری و پردازش می‌کنند و به همگام‌سازی بلادرنگ در بین بازیکنان از راه دور نیاز دارند، باید در سمت سرور قرار گیرند. ارتباط بین موتور بازی و انواع سرورها به براساس پروتکل http مانند REST و SOAP صورت می‌گیرد. در سمت کلاینت همه دارایی‌ها به طور کامل با موتور بازی ادغام شدند. در شکل 12 نمایی از معماری توزیع شده کلاینت – سرور برای دارایی‌ها نمایش داده شده است.شکل 12: نمایی از معماری توزیع شده کلاینت - سرور برای دارایی‌ها [8]۲.۹. قابلیت حمل G-factor در توسعه بازی با استفاده از موتورهای بازی (GSA) [9]این رویکرد توسعه از جنبه‌های مختلف قابلیت حمل پشتیبانی می‌کند، می‌‌توان بازی‌ها را از یک پلتفرم به پلتفرم دیگر منتقل کرد و دارایی‌ها می‌توانند به موتورهای مختلف منتقل شوند. عناصر قابل حمل بازی شامل منطق بازی، مدل شی و وضعیت بازی است که بیانگر مغز و فاکتور بازی (G-Factor) هستند. هدف این رویکرد قابل حمل کردن مغز موتور بازی است. در این معماری از رویکرد GSA استفاد می‌شود که هدف آن کاهش وابستگی است که G-factor را قادر می‌سازد مستقل از موتور بازی باشد. در GSA از نوعی الگوی MVC برای جداسازی G-factor از موتور استفاده می‌شود که از روش داده‌محور برای اصلاح G-factor استفاده می‌کند.مکانیزم جداسازی و ارتباط به G-factor اجازه می‌دهد که مستقل از موتور بازی باشد و سبب می‌شود که هنگام مهاجرت به یک موتور جدید عناصر در فضای بازی یعنی وضعیت بازی، مدل شی و منطق بازی سالم و بدون تغییر باقی بمانند. در مقابل هنگام مهاجرت یک بازی توسعه داده شده با استفاده از یک رویکرد توسعه بازی معمولی، هر سه مورد ذکر شده باید دوباره ایجاد شوند یعنی ایجاد دوباره اشیا بازی، مدل شی و نوشتن مجدد منطق بازی به زبان موتور جدید صورت می‌گیرد. مشکلات این روش شامل وابستگی بازی‌ها به زیرساخت نرم‌افزار و موتورهای بازی، استفاده از زبان‌های برنامه‌نویسی و مدل‌های شی خاص موتورها است. قابل حمل کردن G-factor با الگوی MVC به این صورت هست که اشیای بازی در فضای بازی بدون تغییر باقی می‌مانند اما آن‌هایی که در موتور بازی هستند باید دوباره ایجاد شوند، مدل شی در فضای بازی بدون تغییر باقی می‌ماند اما آن‌هایی که در موتور بازی هستند باید دوباره ایجاد شوند و فضای بازی به موتور جدید متصل می‌شود. در شکل 13 نمایی از رویکردهای معمولی توسعه معمولی و رویکرد GSA برای قابلیت حمل بازی نمایش داده شده است.شکل 13: نمایی از رویکردهای معمولی توسعه بازی و رویکرد GSA برای قابلیت حمل بازی [9]۲.۱۰ کاربرد طراحی داده‌گرا در توسعه بازی [10]این رویکرد به بررسی تجربه یک تیم توسعه بازی کوچک در دو پروژه یکی با استفاده از طراحی شی‌گرا و دیگری با استفاده از طراحی داده‌گرا و بررسی عملکرد و قابلیت نگهداری در هر دو پروژه می‌پردازد که نتایج حاصل از این بررسی به این صورت هست که طراحی شی‌گرا برای افرادی علم کامپیوتر را نمی‌دانند آسان‌تر است در حالی که طراحی داده‌گرا به دانش پایه در حوزه کامپیوتر به ویژه سیستم عامل و نحوه کار با حافظه نیاز دارد. طراحی داده‌گرا دارای عملکرد بهتری است. زمان زیادی برای درک ساختار و جریان کد در طراحی داده‌گرا برای مهندسان تازه‌کاری که در مراحل بعدی وارد پروژه می‌شوند، نیاز است. طراحی داده‌گرا به دلیل تعداد الگوهای کمتر، ساختار کلی و اصول ساده، آسان‌تر از طراحی شی‌گرا است. طراحی داده‌گرا استفاده مجدد از طریق ساختار ساده و خودکار ماژول‌های پروژه را تسهیل می‌کند. ساختار خودکار و سادگی ماژول‌های کد در طراحی داده‌گرا، آن را برای توزیع وظایف بین توسعه‌دهندگان را در زمان نوشتن ماژول‌ها آسان می‌کند. بنابراین پروژه‌های طراحی داده‌گرا آسان‌تر توسعه و نگهداری می‌شوند. پروژه‌های مبتتنی بر طراحی داده‌گرا، سریع‌تر نوشته شده می‌شوند و نسبت به طراحی شی‌گرا بخش قابل توجهی از کد مجددا مورد استفاده قرار می‌گیرد. در شکل 14 مهارت‌های مورد نیاز برای طراحی شی‌گرا و در شکل 15 مهارت‌های مورد نیاز برای طراحی داده‌گرا نمایش داده شده است.شکل 14: مهارت‌های مورد نیاز برای طراحی شی‌گرا [10]شکل 15: مهارت‌های مورد نیاز برای طراحی داده‌گرا [10]۲.۱۱. استفاده از الگوهای طراحی در برنامه‌نویسی بازی [11]یک طراحی شی‌گرا و یک خانواده از الگوهای طراحی برای توسعه بازی عمومی ارائه شده است. کاربردهای الگوهای ساختاری، الگوی تکوینی و الگوی رفتاری برای ایجاد sprite بازی، جداسازی رفتار از sprite توسط الگوهای استراتژی و فرمان، جداسازی sprite و حالت‌‌ها توسط الگوهای حالت، مدیریت وضعیت بازی و sprite بازی با الگوی طراحی حالت، ارتباط میان sprite با الگوی ناظر و واسطه، تشخیص برخورد با الگوی بازدیدکننده، برخورد و پاداش مختلف در میان spriteها یا بین spriteها و نقشه ارائه شده است. همچنین نحوه اعمال الگوهای طراحی برای مدیریت ارتباطات بین spriteها و NPC توسط الگوی ناظر و الگوی واسطه توصیف می‌شود. اگر الگوهای به درستی و در موارد مناسب استفاده شوند قابلیت نگهداری، توسعه‌پذیری، انعطاف‌پذیری و قابلیت درک می‌تواند مفید باشد و بهبود یابد.دو دسته الگوی طراحی در توسعه بازی وجود دارد. یک دسته برای توصیف مکانیک‌های بازی در طول توسعه بازی استفاده می‌شود که روی طرح‌های تعاملی تکراری مرتبط با داستان و مکانیک‌های اصلی بازی تمرکز می‌شود و این الگوها مربوط به مهندسی نرم‌افزار نیستند. مانند الگوی مثلثی که زمانی در بازی مورد استفاده قرار می‌گیرد که سه حالت گسسته در بازی وجود دارد و در شکل 16 نمایش داده شده است. دسته دوم الگوهای طراحی در بازی، الگوهای طراحی شی‌گرا در برنامه‌نویسی بازی است که در ادامه معرفی می‌گردند.شکل 16: الگوی سه‌گانه در توسعه بازی [11]با استفاده از الگوی حالت مانند شکل 17، زمانی که در طول توسعه بازی به حالت‌های بیشتری نیاز باشد، به‌ آسانی‌ می‌توان زیرکلاس‌ها را اضافه کرد. زمانی که حالت نیاز به تغییر داشته باشد، می‌توان فقط کلاس مربوط را تغییر داد. الگوی فرمان رفتار بازیکن را به عنوان یک شی به منظور تسهیل توسعه رفتار بازیکن، کپسوله‌بندی می‌کند. با به‌کارگیری الگوهای Factory و استراتژی کد برنامه به آسانی نگهداری می‌شود و تطبیق و سازگاری با تغییرات در توسعه بازی مانند تغییر رفتار، انعطاف‌پذیرتر است که در شکل 18 الگوی فرمان و Factory در بازی نمایش داده شده است. الگوی بازدیدکننده سبب می‌شود برنامه‌نویس عملیات جدیدی را بدون تغییر در کلاس‌های عناصر تعریف کند و زمانی مناسب است که بتوان کارهای مختلفی را برای اشیایی که ساختار کلاسی پایداری دارند، انجام داد و زمانی مهم است که ساختار کلاس بزرگ است. برای برقراری ارتباط بین الگوهای مورد نظر از الگوی ناظر یا واسط استفاده می‌شود. این الگو زمانی که برنامه دارای دو جنبه مجزا است که می‌توانند مستقل از یکدیگر تغییر کنند یا برنامه شامل اشیایی است که هنگام تغییر نیاز به تغییر اشیای دیگر دارند، مورد استفاده قرار می‌گیرد. اگر الگوی واسطه در میان اشیای بازی استفاده شود، به عنوان واسطه بروزرسانی اشیای بازی است. این الگو ارتباط بین همه اشیا را کنترل می‌کند تا چسبندگی بین اجزای بازی را کاهش دهد. در شکل 19 الگوی ناظر، بازدیدکننده و واسط در بازی نمایش داده شده است.شکل 17: الگوی Stateدر توسعه بازی [11]شکل 18: الگوی Commandو Factory در توسعه بازی [11]شکل 19: الگوی Visitor، Observer و Mediator در توسعه بازی [11]۲.۱۲. قابلیت حمل بازی دیجیتالی STB براساس الگوی MVC [12]یک معماری مبتنی بر الگوی Model-View-Controller ارائه شده است که سبب می‌شود یک بازی به محیط‌های (Set-Top-Box) STB مختلف بدون تغییر یا با تغییر کمی منتقل شود. الگوی MVC قابل حمل است که می‌تواند روی STB از محیط‌های سخت‌افزاری و نرم‌افزاری مختلف عبور کند. اهداف این معماری شامل بهبود قابلیت حمل و تغییر بازی STB، صرفه‌جویی در زمان توسعه بازی STB، ارائه یک مسیر جایگزین برای توسعه بازی STB، کاهش وابستگی بازی STB به محیط STB خاص و تحقق استانداردسازی منطق بازی و استانداردسازی انتقال بین منطق بازی‌های مختلف مبتنی بر محیط STB متفاوت است.الگوی MVC در طراحی معماری بازی STB‌ می‌تواند در پلتفرم‌های STB مختلف حمل شود. زمانی که چندین نما برای مدل یکسانی وجود داشته باشد، معماری MVC پیشنهاد می‌شود. هر تغییری که توسط یکی از نماها حمل می‌شود، برای سایر نماها قابل مشاهده است. براساس الگوی MVC، معماری بازی STB در این رویکرد به سه زیرسیستم یعنی فضای بازی، آداپتورها و محیط STB تقسیم می‌شود. فضای بازی شامل حالت ، مدل و رفتار بازی است. فضای برنامه مؤلفه‌هایی مانند رابط برنامه‌نویسی برنامه (API)، مفسر برنامه‌نویسی، سوکت‌ها و ذخیره‌سازی ماندگار است که برای مدیریت بازی و ارتباط در محیط STB مورد استفاده قرار می‌گیرند. معماری پیشنهادی دقیقا از الگوی MVC پیروی نمی‌کند، زیرا پیوند مستقیم بین نما و مدل را می‌شکند و فقط اجازه ارتباط از طریق کنترل‌کننده را می‌دهد که علت آن، حذف یکی از مسئولیت‌ها با استفاده از MVC است که منجر به اتصال نزدیک بین نما و مدل می‌شود. عناصر مربوط به اشیای حالت بازی باید به محیط اضافه شوند که از طریق ویرایشگر سطح انجام می‌شود. در شکل 20 نمایی از این معماری نمایش داده شده است.شکل 20: معماری الگوی MVC برای پلتفرم بازی STB [12]در این معماری از مکانیزم پیام‌رسانی به عنوان یک مکانیزم ارتباطی بین فضای بازی و محیط STB با آداپتورها استفاده می‌شود. مکانیزم پیام‌رسانی برای همگام‌سازی استفاده می‌شود که هدف آن محدود کردن تاخیری است که توسط مکانیزم همگام‌سازی ایجاد می‌شود. مکانیزم جداسازی و ارتباط به بازی STB اجازه می‌دهد تا مستقل از محیط STB باشد و زمانی که به یک محیط STB جدید مهاجرت می‌کند، عناصر موجود در فضای بازی مانند حالت بازی، مدل شی و منطق بازی می توانند بدون تغییر باقی بمانند.۲.۱۳. معماری Hydra: یک معماری نظیر به نظیر چند نفره بزرگ برای توسعه‌دهندگان بازی [13]سیستم Hydra که یک معماری نظیر به نظیر برای بازی‌های آنلاین بزرگ چند نفره است ارائه شده است. با پشتیبانی از یک مدل برنامه‌نویسی کلاینت - سرور افزوده جدید با پروتکلی، بدون استفاده از قفل یا کننترل همروندی، سازگاری در پیام‌های دریافتی را در زمان خرابی گره‌ها تضمین می‌کند و پیچیدگی‌های مربوط به بازیابی خرابی گره را پوشش می‌دهد. توسعه‌دهندگان بازی می‌‌توانند از مزایای این معماری بدون مدیریت پیچیدگی‌های مربوط به ریزش شبکه، استفاده کنند. ویژگی کلیدی آن توسعه رابط برنامه‌نویسی برای استفاده آسان و بصری است که می‌تواند در لایه شبکه پشتیبانی شود. این معماری سربار پیام کمی را تحمیل می‌کند و باعث کاهش زمان پاسخ و تاخیرها می‌گردد، بنابراین مقیاس‌پذیر است. همچنین مجموعه‌ای از پروتکل‌ها را برای پشتیبانی از روابط کاربری مورد نیاز پشتیبانی می‌کند.در Hydra دنیای بازی به مناطق مجزا تقسیم می‌شود که هر کدام توسط یک سرور مدیریت می‌شوند و هر سرور مسئول یک منطقه است. هر کلاینت، به سرور مربوطه متصل است که آواتار بازیکن در آن ساکن است. کلاینت‌ها فقط می‌توانند با کلاینت‌های دیگری که متصل به همان سرور هستند، تعامل داشته باشند. Hydra پیام‌های دریافتی را برای مشتریان به سرورها تحویل می‌دهد و تمام اتصلات در لایه‌های برنامه توسط سرورهای بازی مدیریت می‌شوند. برای حرکت بازیکن از یک ناحیه مدیریت شده توسط یک سرور به منطقه‌ای که توسط سرور دیگری مدیریت می‌شود، باید کلاینت اتصال را از یک سرور به سرور دیگر منتقل کند یا اتصالات را برای هر دو سرور شبیه‌سازی کند.معماری Hydra یک سیستم توزیع‌شده نظیر به نظیر است و هر گره Hydra شامل یک ماژول کلاینت و یک سرور Hydra است. ماژول کلاینت در این سیستم شامل دو مؤلفه کلاینت بازی و پروکسی کلاینت است. به جای ارسال مستقیم پیام به شبکه، پیام را از طریق پروکسی ارسال می‌کند، به طور مشابه به جای خواندن مستقیم از شبکه، پیام‌های دریافتی برای کلاینت بازی توسط پروکسی کلاینت در صف اولویت قرار می‌گیرند. سرورهای بازی به عنوان مؤلفه‌هایی هستند که برش نام دارند و حالت بازی را برای منطقه خاصی از دنیای مجازی مدیریت می‌کنند و سرور Hydra ممکن است شامل چندین برش باشد. ممکن است زمانی که تعداد کلاینت‌ها کم است، یک host چندین ناحیه از دنیای مجازی را به طور همزمان مدیریت کند. همچنین یک گره ملاقات وجود دارد که هر زمانی که یک گره جدید به سیستم می‌پیوندد، پرس و جو می‌شود و این مؤلفه ردیاب سراسری نامیده می‌شود. علاوه بر این به عنوان یک نفطه تماس برای نودهای جدید عمل می‌کند. همچنین سرورها و برش‌ها را در سیستم ردیابی می‌کند. در شکل 21 نمایی از معماری سیستم Hydra نمایش داده شده است.شکل 21 نمایی از معمای سیستم Hydra [13]۲.۱۴. یک چارچوب معماری سرویس‌گرا برای بازی‌های جدی آموزشی [14]در این مقاله از مدل مبتنی بر نظریه فعالیت برای بازی‌های جدی (ATMSG) برای شناسایی اجزای مرتبط استفاده شده است که می‌تواند برای بازی‌های مختلف دوباره مورد استفاده قرار گیرد. هدف اصلی این رویکرد شناسایی مؤلفه‌های کاندید بازی‌های جدی است که می‌تواند به عنوان سرویسی برای بازی‌ها با سبک‌ها و دامنه‌های مختلف توسعه یابد. در مدل جدید توسعه‌یافته، مؤلفه‌های مختلف را در سطوح مختلف یک بازی به هم متصل می‌شوند. در این مدل از نظریه فعالیت برای ترسیم مدلی که شامل چند مؤلفه سطح پایین مختلف در یک بازی جدی آموزشی است، استفاده می‌شود و نحوه اتصال مؤلفه‌ها، اهداف سطح بالای آموزشی و سرگرمی یک بازی را نمایش می‌دهد. در ATMSG بازی‌های جدی آموزشی در 4 فعالیت مورد استفاده قرار می‌گیرند که شامل بازی، یادگیری، آموزش داخلی که در داخل بازی و آموزش بیرونی توسط مربی در بیرون از بازی است. بر اساس شکل 22 در این مدل فعالیت‌ها به دنباله‌ای از اقدامات با ابزارهایی با اهداف خاص، تجزیه می‌شوند که مجموعه‌ای از دسته‌ها را ارائه می‌دهد که طبقه‌بندی مؤلفه‌های بازی‌های جدی را نشان می‌دهند.شکل 22: نمایی از فعالیت‌ها با ابزارها در مدل نظریه فعالیت [14]برخی عملیات در بازی می‌توانند به عنوان سرویس، پیاده‌سازی شوند که شامل سرویس تعامل بین بازیکنان برای جمع‌آوری، نمایش و مقایسه امتیازها، سرویس تعامل یادگیرنده و مربی برای پرس و جوی بازیکنان یا تعامل در فرایند یادگیری، سرویس ذخیره و بازیابی اطلاعات برای موضوعات مرتبط به دانش داخل بازی، دامنه یادگیری، اتصال به پایگاه‌های دانش و تبدیل اطلاعات به فرمت‌های مورد استفاده در بازی، سرویس بازخورد برای ارسال نتایج ارزیابی درون بازی به بازی، سرویس ارزیابی شامل ماژول‌هایی برای ارزیابی کمی به صورت خودکار، ارزیابی کیفی توسط مربی، ارزیابی مشارکت، تحلیل یادگیری و استفاده از داده‌ها برای شناسایی الگو،‌ سرویس تطبیق‌پذیری برای تجمیع اطلاعات حاصل از چند سرویس ارزیابی مختلف، ارزیابی این اطلاعات، تصمیم‌گیری در مورد نحوه واکنش بازی و ارائه اطلاعات به بازی، سرویس اتصالات بازی برای ایجاد ماژول‌های آداپتور و مدل‌های داده به منظور مرتبط کردن سرویس‌های خارجی را به بازی، سرویس پروفایل کاربری برای فعال کردن تعامل، همگام‌سازی و ویژگی‌های پایدار در بازی‌های مختلف و تنظیمات یادگیری است. در شکل 23 نمایی از سرویس‌ها در چارچوب SOA در بازی‌های جدی نمایش داده شده است.شکل 23: نمایی از سرویس‌ها در چارچوب SOA در بازی‌های جدی [14]سایر حوزه‌های معماری نرم‌افزاردر این بخش به مرور و بررسی کارهای پیشین با استفاده از سایر حوزه‌های معماری نرم‌افزار در توسعه نرم‌افزار بازی پرداخته می‌شود.۲.۱۵. یک معماری نرم‌افزار برای بازی‌ها [15]یک معماری عمومی برای نرم‌افزار بازی بلادرنگ توصیف شده است. از این معماری برای به حداکثر رساندن قابلیت استفاده مجدد از ماژول‌های سیستم در بازی‌های تک نفره و چند نفره استفاده می‌شود. این معماری با قرار دادن سیستم شی برای کمینه کردن چسبندگی، اجزای عمومی بازی مانند موتور را از اجزای خاص بازی مانند شبیه‌سازی به آسانی جدا می‌کند و تاثیر ترکیب حالت‌های بازی چندنفره را کمینه می‌کند. این معماری به راحتی با پیکربندی سرور کلاینت برای بازی‌های چند نفره منطبق می‌شود و این جداسازی منجر به مهاجرت از معماری بازی تک نفره به معماری بازی چند نفره شبکه‌ای می‌شود.شکل 24: نمایی از معماری رویکرد پیشنهادی [15]این معماری دارای ساختاری سطح بالا است و طبق شکل 24 دارای مؤلفه‌های موتور بازی، شبیه‌سازی و مدیر داده با سیستم شی تعامل دارند. موتور بازی مسئول نمایش بازی برای بازیکن و دریافت ورودی‌های بازیکن است و شامل تولید گرافیک، صدا و بازخورد به بازیکن است. سیستم شبیه‌سازی مهم‌ترین بخش بازی و مسئول بروزرسانی حالت دنیای بازی در پاسخ به ورودی‌های بازیکن است و قوانین بازی را حفظ می‌کند. مدیر داده مسئول بازیابی داده بازی از سیستم فایل یا سایر مخازن ماندگار و مدیریت ذخیره‌سازی و بازیابی حالت بازی برای ذخیره و بارگذاری عملکرد بازی است. سیستم شی مسئول نگهداری اطلاعات وضعیتی است که همه اشیا را در دنیای بازی توصیف می‌کند. این سیستم در حافظه برای دسترسی بلادرنگ به تمام اطلاعات وضعیت بازی قرار دارد. مزیت اول این رویکرد کاهش نیاز به تعریف خاص داده‌های در حال جریان بین ماژول‌ها است. یک مسیر داده بین موتور بازی و شبیه‌سازی وجود دارد که از طریق سیستم شی نیست. این مسیر برای انتقال اطلاعات ورودی بازیکن از موتور بازی به شبیه‌سازی است، تعامل بین موتور بازی سیستم شی را برای یک رابط فقط خواندنی محدود می‌کند و موجب تسهیل پردازش می‌شود که توسط لایه شبکه در بازی چندنفره انجام می‌شود.شکل 25: نمایی از سیستم شبیه‌سازی در رویکرد پیشنهادی [15]موتور بازی مسئول تعامل با بازیکن از طریق سخت‌افزار و سیستم عامل است. یکی از ویژگی‌های ماژول‌های موتور بازی چسبندگی کم یا عدم چسبندگی است و جریان داده از طریق آن‌ها یک‌طرفه است. ماژول کنترل شبیه‌سازی مطابق شکل 25، اطلاعات ورودی بازیکن را از موتور بازی دریافت می‌کند و به ماژول هوش مصنوعی بازیکن منتقل می‌کند. ماژول فیزیک، مربوط به تعامل اشیا در دنیای مجازی براساس خواص فیزیکی جهان است. ماژول هوش مصنوعی به داخل و فرایند تصمیم‌گیری در اشیا متحرک می‌پردازد. ماژول منطق بازی به مسائلی که بخشی از دنیای مجازی نیستند و بازی آن‌ها را انجام می‌دهد می‌پردازد و محاسبات و محدودیت‌هایی هستند که از قوانین بازی استنتاج می‌شوند. این ماژول‌ها به طور مستقیم با یکدیگر تعامل ندارند. آن‌ها از طریق اطلاعاتی که حالت را اشیا در بازی توصیف می‌کنند و در سیستم شی ذخیره می‌شوند، با یکدیگر ارتباط دارند. در بازی شبکه‌ای چندنفره مطابق شکل 26، تعدادی از بازیکنان در یک محیط مجازی تعامل دارند که مؤلفه شبیه‌سازی روی سرور پردازش می‌شود و اجرا و رابط موتور بازی روی کامپیوترهای فردی بازیکنان و کلاینت پردازش می‌شود. چون تمام ارتباطات بین شبیه‌سازی و موتور بازی از طریق سیستم شی صورت می‌گیرد، هر کلاینت باید یک کپی از سیستم شی داشته باشد که توسط شبیه‌سازی بروزرسانی می‌شود.شکل 26: نمایی از معماری چندنفره شبکه‌ای در رویکرد پیشنهادی [15]۲.۱۶. استراتژی قابلیت همکاری برای توسعه بازی‌های جدی [16]به محیط تکنولوژی زیرساخت توسعه بازی‌‌های جدی و قابلیت همکاری می‌پردازد. بازی‌های جدی قابلیت همکاری را فراهم می‌سازد و سبب افزایش عمق و توسعه موارد آموزشی در دسترس برای یادگیرندگان می‌شود در حالی که زمان و هزینه کلی توسعه را کاهش می‌دهد. این رویکرد، سه عنصر کلیدی شامل مؤلفه‌های اصلی در بازی جدی (مکانیک بازی، انجام بازی، موتور گرافیکی و اشیا گرافیکی)، اکوسیستمی که بازی جدی در آن پیاده‌سازی می‌شود (توسعه پلتفرم‌ها، زبان‌های برنامه‌نویسی و ارتباطات LMS) و فاکتورهای خارجی فراتر از جنبه‌های تکنیکی اصلی بازی جدی (ارزیابی، کاربرد، طبقه‌بندی و واژه‌ نامه‌های اصطلاحات) را ادغام می‌کند که بر قابلیت همکاری بازی‌های جدی اثر می‌گذارند. هدف قابلیت همکاری، پشتیبانی از تبادل مؤثر اطلاعات براساس داده ثابت و خاص و روش‌های استاندارد است. هدف سناریوهای قابلیت همکاری افزایش تعامل بین توسعه‌دهندگان بازی با استفاده از راه‌حل‌های جایگزین استاندارد است. چارچوب قابلیت همکاری چندبعدی بازی‌های جدی، به منظور تسهیل تحلیل عمیق موضوع و همچنین درنظر گرفتن اکوسیستم توسعه بازی‌های جدی ایجاد شده است که در شکل 27 نمایش داده شده است.شکل 27: چارچوب قابلیت همکاری چندبعدی بازی‌های جدی [16]حوزه خط تولید نرم‌افزاردر این بخش به مرور و بررسی کارهای پیشین در حوزه خط تولید نرم‌افزار در توسعه نرم‌افزار بازی پرداخته می‌شود.بهبود توسعه بازی دیجیتالی با خطوط تولید نرم‌افزار [17]یک فرایند سیستماتیک برای بهره‌برداری از خط تولید نرم‌افزار برای توسعه بازی برای هر دو زبان دامنه خاص و تولیدکنندگان برای زیردامنه‌های بازی است که از تجزیه و تحلیل دامنه بازی برای ایجاد دارایی‌های اصلی و معماری‌های مرجع برای یک خط تولید نرم‌افزار بازی استفاده می‌کند و ویژگی‌های بازی را در نظر می‌گیرد. همچنین سبب کاهش پیچیدگی برای مصرف موتورهای بازی، تقسیم خودکار وظایف توسعه بازی به بخش‌های کوچکتر، تحویل افزایشی مقدار برای اولویت‌بندی زیردامنه‌های بازی، دارایی‌های خاص دامنه متناسب با ویژگی‌های منحصر به فرد بازی و افزایش اعتماد به نتیجه بازی‌ها می‌شود. در رویکرد پیشنهادی ویژگی های بازی در نظر گرفته می‌شودو این رویکرد به صورت خطی انجام می‌شود ولی باید انجام فعالیت‌ها در تکرارها، تحلیل نمونه‌ها، استخراج ویژگی‌ها، بررسی کد، مدلسازی و پیاده‌سازی دارایی‌ها به صورت افزایشی انجام شوند. با استفاده از یک رویکرد توسعه خاص دامنه سیستماتیک که برای بازی‌های دیجیتالی جریان دارد، توسعه‌دهندگان و طراحان می‌توانند دامنه‌های بازی هدف و تجزیه و تحلیل دارایی‌های اصلی در یک SPL بازی را متصل کنند. در شکل 28 خط تولید نرم‌افزار برای بازی‌ها نمایش داده شده است.شکل 28: خط تولید نرم‌افزار برای بازی‌ها [17]۳. ارزیابیدر این بخش ابتدا کارهای پیشین تحلیل و ارزیابی می‌شوند و سپس مقایسه و بررسی آن‌ها براساس ویژگی‌هایی در جدول 1 ارائه می‌گردد.استفاده از رویکردهای مدل محور به منظور توسعه رابط کاربری بازی، افزایش یادگیری، ایجاد انگیزه در کاربران، توسعه منعطف، سریع و آسان بازی، ایجاد انعطاف‌پذیری، افزایش بهره‌وری، دسترس‌پذیری، قابلیت همکاری، افزایش سطح انتزاع، کاهش زمان، توسعه بازی مستقل از پلتفرم، شناسایی مؤلفه‌های اصلی، رفع ضعف ابزارهای سازنده، خودکارسازی نمونه اولیه در توسعه بازی، امکان استفاده مجدد و تسهیل مدلسازی، توسعه نیمه خودکار بازی براساس سبک بازی، مدیریت فرامدل، شاخص‌گذاری سناریوها و انطباق مدل تولید شده با فرامدل اصلی صورت می‌گیرد.استفاده از الگوهای طراحی و معماری به منظور بهبود بهره‌وری و کیفیت بازی، عدم نیاز به تولید مجدد مؤلفه‌ها، ساختارهای مشترک و مستقل از پلتفرم، ادغام و استفاده مجدد مؤلفه‌ها، قابلیت حمل دارایی‌ها در پلتفرم‌های مختلف، تقویت انسجام داخلی و پتانسیل بازی، قابلیت نگهداری، مقیاس‌پذیری، توسعه سریع، آسان و کم هزینه، افزایش عملکرد، جداسازی عناصر اصلی بازی از موتور بازی، حل مشکل چسبندگی بین بازی و محیط بازی، استفاده از طراحی داده‌گرا با ساختار و اصول ساده‌تر و الگوهای کمتر نسبت به طراحی شی‌گرا، قابلیت استفاده مجدد بخش قابل توجهی از کد، مدیریت عناصر بازی و پیچیدگی، تضمین سازگاری در زمان خرابی و رفع پیچیدگی‌های آن، کاهش زمان پاسخ و سربار، افزایش قابلیت همکاری و سازگاری بین مؤلفه‌های بازی، شناسایی مؤلفه‌های مرتبط در بازی و کاهش زمان و هزینه ورود به بازار صورت می‌پذیرد.استفاده از سایر معماری‌ها به منظور کمینه کردن چسبندگی، جداسازی مؤلفه‌های عمومی و خاص بازی، قابلیت استفاده مجدد از ماژول‌ها، ارتباط ماژول‌ها با یکدیگر و تسهیل بررسی و درک آن‌ها، توسعه زیرساخت برای قابلیت همکاری بازی و ادغام عناصر کلیدی در بازی انجام می‌شود. استفاده از خط تولید نرم‌افزار به منظور ساده‌سازی زیردامنه‌های بازی، ایجاد دارایی‌های اصلی و خاص دامنه، افزایش قابلیت اعتماد در نتایج بازی، کاهش پیچیدگی موتور بازی و ریزدانگی وظایف صورت می‌گیرد.جدول 1: مقایسه کارهای انجام شده۴. پیشنهاداتدر این بخش پیشنهادات و کارهایی در حوزه معماری نرم‌افزار که می‌توان در آینده به منظور بهبود طراحی و توسعه نرم‌افزار بازی انجام داد، ارائه می‌گردد.استفاده از رویکرد‌های مدل محور برای توسعه سایر بخش‌های بازی، خودکارسازی سایر لایه‌ها و بخش‌های بازی، استفاده از رویکردهای معماری نرم‌افزار در سایر سبک ها و انواع بازی‌های تک‌نفره و چندنفر، استفاده از رویکردهای معماری نرم‌افزار به منظور دستیابی به سایر ویژگی‌های کیفی، قابل حمل کردن سایر بخش‌های بازی مانند مکانیک‌ها، داینامیک‌ها و مؤلفه‌های بازی، استفاده از سایر الگوهای طراحی برای برنامه‌نویسی بازی، استفاده از الگوهای طراحی برای مدیریت و ایجاد سایر عناصر بازی، استفاده از سایر الگوهای معماری در توسعه بازی، به کاربردن ترکیبی از چند الگوی طراحی در برنامه‌نویسی بازی، به کار بردن ترکیبی از چند الگوی معماری در توسعه بازی، در نظر گرفتن مؤلفه‌های دیگر بازی به عنوان سرویس در معماری سرویس‌گرا، استفاده از معماری میکروسرویس در توسعه بازی، قابل حمل کردن سایر عناصر و مؤلفه‌های بازی، استفاده از سایر رویکردهای موجود در خط تولید نرم‌افزار در فرایند طراحی و توسعه بازی و استفاده از رویکردهای معماری نرم‌افزار بازیگونه‌سازی برای دستیابی به ویژگی‌های کیفی و افزایش آن‌ها و بهبود طراحی، توسعه و یکپارچه‌سازی آن و کاهش زمان، هزینه و پیچیدگی از جمله کارهایی است که می‌توان در آینده به منظور بهبود طراحی، توسعه و کیفیت انواع بازی‌ها انجام داد.۵. جمع‌بندیبا افزایش روزافزون بازی‌ها، گسترش و پیچیدگی نرم‌افزار بازی، پلتفرم‌ها و برنامه‌هایی که آن را هدایت می‌کنند و محدودیت تکنولوژی‌های موجود طراحی، توسعه و یکپارچه‌سازی نرم‌افزار بازی دشوار می‌گردد و ماژول‌های موجود در آن پیچیدگی و چسبندگی بیشتری دارند که افزایش زمان و هزینه تولید و کاهش کیفیت و عملکرد بازی را به همراه دارد. در نتیجه تیم‌های توسعه‌دهنده بازی بزرگتر می‌شوند و وظایف تخصصی‌تری را انجام می‌دهند. بنابراین نرم‌افزار بازی هم مشابه سایر نرم‌افزارها برای بهبود عملکرد، کیفیت، دستیابی به ویژگی‌های کیفی مؤثر و یکپارچه‌سازی نیاز به روش‌های موجود در معماری نرم‌افزار دارد تا زمان و هزینه تولید بازی و ورود به بازار کاهش یابد و سبب رضایت بازیکنان از بازی گردد.در این مقاله در ابتدا تعدادی از کارهای انجام شده در حوزه استفاده از معماری نرم‌افزار در توسعه نرم‌افزار بازی با استفاده از رویکردهای مدل محور، الگوهای طراحی و معماری، سایر رویکردهای موجود در حوزه معماری نرم‌افزار و خط تولید نرم‌افزار به منظور بهبود توسعه، طراحی و یکپارچه‌سازی انواع بازی‌ها، دستیابی به ویژگی‌های کیفی، کاهش زمان، هزینه و پیچیدگی و ... در برنامه‌های بازی پرداخته شد. سپس تحلیل و ارزیابی رویکردهای پیشین و مقایسه و بررسی آن‌ها براساس ویژگی‌های مورد نظر بیان گردید. در پایان نیز پیشنهاداتی برای بهبود عملکرد، کیفیت، طراحی و توسعه نرم‌افزار بازی در حوزه معماری نرم‌افزار به منظور تحقیق و توسعه در آینده ارائه گردید.۶. منابع و مراجع[1] Minovic, Miroslav, et al. "Model driven development of user interfaces for educational games." 2009 2nd Conference on Human System Interactions. IEEE, 2009.[2] do Prado, Ely Fernando, and Daniel Lucrédio. "A flexible model-driven game development approach." 2015 IX Brazilian Symposium on Components, Architectures and Reuse Software. IEEE, 2015.[3] Tang, Stephen, Martin Hanneghan, and Christopher Carter. "A platform independent game technology model for model driven serious games development." Electronic Journal of e-Learning 11.1 (2013): pp61-79.[4] Reyno, Emanuel Montero, and José Á. Carsí Cubel. "Automatic prototyping in model-driven game development." Computers in Entertainment (CIE) 7.2 (2009): 1-9.[5] Vargas, Rosa, et al. "MDA Game Design for Video Game Development by Genre." Demos/Posters/StudentResearch@ MoDELS. 2013.[6] Aouadi, Nada, et al. "MDA approach for reusability in serious game and e-learning design." International Conference on Web-Based Learning. Springer, Cham, 2016.[7] Hu, Wenfeng. "A common software architecture for educational games." International Conference on Technologies for E-Learning and Digital Entertainment. Springer, Berlin, Heidelberg, 2010.[8] Van der Vegt, Wim, et al. "RAGE architecture for reusable serious gaming technology components." International Journal of Computer Games Technology 2016 (2016).[9] BinSubaih, Ahmed, and Steve Maddock. "G-factor portability in game development using game engines." Proceedings of the 3rd International Conference on Games Research and Development. 2007.[10] Fedoseev, K., et al. "Application of Data-Oriented Design in Game Development." Journal of Physics: Conference Series. Vol. 1694. No. 1. IOP Publishing, 2020.[11] Qu, Junfeng, Yinglei Song, and Yong Wei. "Applying design patterns in game programming." Proceedings of the International Conference on Software Engineering Research and Practice (SERP). The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing (WorldComp), 2013.[12] Huang, Jun, and Guangping Chen. "Digtal stb game portability based on mvc pattern." 2010 Second World Congress on Software Engineering. Vol. 2. IEEE, 2010.[13] Chan, Luther, et al. "Hydra: a massively-multiplayer peer-to-peer architecture for the game developer." Proceedings of the 6th ACM SIGCOMM workshop on Network and system support for games. 2007.[14] Carvalho, Maira B., et al. "Towards a service-oriented architecture framework for educational serious games." 2015 IEEE 15th International Conference on Advanced Learning Technologies. IEEE, 2015.[15] Doherty, Michael. "A software architecture for games." University of the Pacific Department of Computer Science Research and Project Journal (RAPJ) 1.1 (2003).[16] Stãnescu, Ioana Andreea, et al. "Interoperability strategies for serious games development." Internet Learning 2.1 (2013): 6.[17] Furtado, Andre WB, et al. "Improving digital game development with software product lines." IEEE software 28.5 (2011): 30-37.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» شیما سیف الهی شیما سیف الهی Sat, 12 Feb 2022 13:07:36 +0330 https://virgool.io/@shimaseyfollahi/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DA%A9%D8%AA%D8%A7%D8%A8-%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%AA%D9%85%DB%8C%D8%B2-fotsyfpeewol مقدمهمهم‌ترین دارایی شرکت‌های نرم‌افزاری انسان‌ها هستند. روابط و احساسات بین افراد در مهندسی نرم‌افزار مهم است. در معماری باید نتایج بر اساس حساب و کتاب و اندازه‌گیری باشد و بتوان آن‌ها را توضیح داد و مستند کرد. همچنین باید نرم‌افزار دارای عملکرد و انعطاف‌پذیری خوبی باشد و به اشکال‌زدایی، ردیابی، انرژی و زمان زیاد برای رفع خطاها و مشکلات و سندهای زیادی نیاز نداشته باشد. در نتیجه باید دارای برنامه‌نویسی تمیز با سربار کمتر باشد.کتاب معماری نرم‌افزار تمیزفصل اول: طراحی و معماری چیست؟معماری طراحی سطح بالا است و معماری و طراحی یعنی جزئیات و مؤلفه‌های سطح بالا دو عنصر جدایی ناپذیر هستند. باید کدنویسی به گونه‌ای باشد که سبب هرج و مرج نشود زیرا هزینه دارد و نباید فقط روی ددلاین پروژه تمرکز کرد بلکه باید کد و معماری درست و تمیز باشند در غیر این صورت مشکلی زیادی را ایجاد می‌کند.آنکل باب فرقی بین معماری و طراحی قائل نیست و معتقد است که برخی از جزئیات طراحی خیلی مهم هستند، مورد نظر معماری هستند و با هم ارتباط دارند. جزئیات می‌توانند روی معماری کلان تاثیر بگذارند، بنابراین در معماری مواردی مربوط به سطح بالا و سطح پایین وجود دارند.هدف معماری نرم‌افزار: هدف معماری نرم‌افزار کمینه کردن نیاز به زحمت افراد در توسعه و نگهداری نرم‌افزار و کمینه کردن زمان و منابع مصرف شده است.همان طور که در نمودار شکل 1 مشاهده می‌شود، پروژه به مرور زمان بزرگتر می‌شود ولی از یک جایی به بعد بهره‌وری افزایش نمی‌یابد و بهره‌وری ثابت می‌ماند. بر اساس نمودار شکل 2 مشاهده می‌شود که به مرور زمان هزینه مربوط به تولید نرم‌افزار و حقوق افراد با افزایش افراد تیم افزایش می‌یابد ولی کد جدیدی تولید نمی‌شود و همچنین ممکن است سرعت کاهش یابد زیرا آموزش به افراد جدید زمانبر است. شکل ۱: نمودار بهره‌وری در طول بازه زمانی یکسانشکل 2: نمودار هزینه در هر خط کد در طول زمانهمان طور که در نمودار شکل 3 مشاهده می‌شود نسخه‌های بعدی نرم‌افزار بهره‌وری را کاهش می‌دهد که نشان‌دهنده تمیز نبودن معماری و ساختار پروژه است. بنابراین هزینه تولید یک نرم‌افزار تمیز کمتر از هزینه تولید یک نرم‌افزار کثیف است و تمیز بودن نرم‌افزار سرعت را افزایش می‌دهد. معمار نرم‌افزار باید کارفرما را راضی نگه دارد و گاهی اوقات باید trade off کند تا ساختار منظم شود.شکل 3: بهره‌وری در طول نسخه‌های بعدی نرم‌افزارروش test develop development (TDD): در این روش برای توابع و مؤلفه‌ها هم‌زمان تست نوشته می‌شود تا عملکرد آن تابع یا مؤلفه به طور هم‌زمان بررسی شود. تست مؤلفه یا تست واحد قبل از شروع به پیاده‌سازی رابط کاربری ابتدا تست مربوط به آن را تولید می‌کنند یعنی ابتدا تست نوشته می‌شود و سپس کد نوشته می‌شود و برنامه‌نویس مجاز به نوشتن به کد جدید نیست مگر آن که مورد آزمون مربوط به آن fail شود و برای ایجاد ویژگی جدید ابتدا تست مربوط به آن برای نمایش رفتار آن ویژگی نوشته می‌شود و اگر fail شد، کد مربوط به آن نوشته می‌شود. اگر خطایی به وجود آمد ابتدا مورد آزمون آن نوشته می‌شود تا نشان داده شود تست با وجود آن خطا fail می‌شود و شرایط خطا در مورد آزمون باز تولید می‌شود و باید کد به گونه‌ای تغییر داده می‌شود که همه موارد آزمون پاس شوند. با استفاده از این روش استفاده از تست در تولید نرم‌افزار ترویج می‌شود و کد تمیزتر می‌شود و زمان تولید آن کاهش می‌یابد.روش Test double: در این روش ممکن است واحدهای اطراف واحد مورد تست، برای تست آماده نشده باشند در این صورت واحدهای اطراف بدل و شبیه‌سازی می‌شوند.روش Real Test: در این روش نیازی نیست که واحدهای مورد تست، یکی یکی تست شوند و می‌توان بعد از آماده شدن چند واحد مرتبط به هم، واحدهای مورد نظر را به هم متصل کرد و با هم تست کرد زیرا بدل کردن واحدها عوارضی دارند و به جای تست واحد مورد نظر، طراحی انجام شده برای آن واحد تست می‌شود.بنابراین گاهی اوقات روش بدل کردن و شبیه‌سازی مفید است و گاهی اوقات این روش مفید نیست بنابراین می‌توان از روش ترکیبی که ترکیبی از روش‌های Test double و Real Test هست، استفاده کرد.نتیجه‌گیری: تنها راه تمیز پیش رفتن است نه سریع پیش رفتن.فصل دوم: یک داستان با دو مقداردو مقدار عملکرد و ساختاری وجود دارد که هر دو ارزشمند هستند و باید بررسی شود که کدام یک مهم‌تر است و معمار باید به معیار مهم‌تر، اهمیت بیشتری دهد. بنابراین باید برای این دو مقدار اولویت‌بندی صورت گیرد. رفتار چیزی هست که ذی‌نفعان انتظار دارند و به معماری توجه نمی‌کند و نرم‌افزار باید بتواند با تغییر نیازمندی‌ها ساختار و معماری خود را تغییر دهد تا با تغییر ایجاد شده منطبق باشد و بتواند ویژگی جدید را اضافه کند. همچنین باید انعطاف‌ داشته باشد. ارزش معماری بیشتر از نرم‌افزار است و باید بتواند رفتارهای مورد نظر ذی‌نفعان را برآورده کند.بنابراین می‌توان از ماتریسی برای این منظور استفاده کرد و به وسیله آن می‌توان معماری و رفتار را اولویت‌بندی کرد. درایه اول ماتریس مربوط به کارهای مهم و ضروری۷ درایه دوم مربوط به کارهای مهم و غیر ضروری، درایه سوم مربوط به کارهای غیر مهم و ضروری و درایه چهارم مربوط به کارهای غیر مهم و غیر ضروری است. در ماتریس نشان داده می‌شود که کارها چقدر مهم و چقدر فوری هستند بنابراین کارها دارای دو بعد هستند. در نتیجه با استفاده از این ماتریس دریافت می‌شود که معماری اولویت بالاتری دارد و باید بیشتر روی آن کار شود.معماری باید نرم و انعطاف‌پذیر باشد در غیر این صورت سخت افزار می‌شود. بنابراین معماری باید تغییر را بپذیرد و مقاومت نکند و باید روی معماری و تمیز بودن تمرکز کرد و رفتار در اولویت دوم قرار می‌گیرد در حالی که معماری و ساختار منسجم در دراز مدت مهم است.نتیجه‌گیری: معمار و توسعه دهنده هم به نوعی در پروژه نرم‌افزاری به عنوان ذی‌نفع هستند و تنها راه برای سریع پیش رفتن کارها تمیز بودن معماری است.فصل سوم: شروع با اجرها (برنامه‌نویسی با الگوها)پارادایم‌های برنامه‌نویسی مانند برنامه‌نویسی ساختاریافته (Structed programming)، برنامه‌نویسی شی‌گرا (Object Oriented Programming) و برنامه‌نویسی تابعی (Functional Programming) مهم و رایج هستند و هر کدام یک سری محدودیت ایجاد می‌کنند.پارادایم ساختار یافته: در برنامه‌نویسی می‌توان به راحتی با استفاده از go to از تابع به تابع دیگری رفت در حالی که این گونه نیست و برنامه‌نویسی سخت‌تر می‌شود در برنامه‌نویسی ساختاریافته go to به صورت محدود استفاده می‌شود یا به طور کلی مورد استفاده قرار نمی‌گیرد و دیسیپلین‌ فراخوانی‌ها و کنترل نوع برنامه را محدود می‌کند و به جای go to می‌توان از if و else استفاده کرد.پارادایم شی‌گرا: این پارادایم اجازه استفاده از pointer برای اشاره به تابع یا شی را نمی‌دهد و جلوی استفاده از این قابلیت را می‌گیرد، دیسیپلین تبدیل و کنترل نوع برنامه را محدود می‌کند، متغیر نباید تغییر کند و باید در ابتدا مقدار شود. این پارادایم قابلیتی برای پلی‌مورفیسم ارائه می‌دهد و خودش آن را مدیریت می‌کند.پارادایم تابعی: اجازه تغییر متغیرها را توسط برنامه و از داخل برنامه در هنگام اجرای همروند نمی‌دهد و از این قابلیت جلوگیری می‌کند.ارتباط سه پارادایم با معماری: از پلی‌مورفیسم برای عبور از مرزهای معماری استفاده می‌شود و از functional‌ برای اعمال نظم و انضباط و مکان و دسترسی به داده‌ها استفاده می‌شود. از این پارادایم به عنوان پایه الگوریتمی برای ماژول‌ها استفاده می‌شود. این سه پارادایم با سه دغدغه معماران شامل تابع، تفکیک مؤلفه و مدیریت داده هم‌راستا هستند. هم چنین این پارادایم‌ها در تناقض با یکدیگر نیستند و می‌توانند با هم مورد استفاده قرار گیرند.نتیجه‌گیری: پارادایم‌های ذکر شده در این فصل سبب ایجاد برنامه‌ای می‌شوند که توسعه آن در آینده بهتر و آسان‌تر است. توجه آنکل باب به معماری کد و اصول کار با کد است در حالی که در منابع دیگر طراحی کلان و سطح بالاتر از کد مهم‌تر هستند.فصل چهارم: برنامه‌نویسی ساخت‌یافته (Functional Programming)برای درستی برنامه باید برنامه‌نویسی را کوچکتر کرد و به ساختارهای کوچک تبدیل و اثبات کرد. عبارت go to برنامه‌نویسی را خراب می‌کند، زیان‌آور است و باید حذف شود. بنابراین می‌توان تمام برنامه‌ها را با توابع گزینش و تکرار یعنی if و else و دستورات شرطی انجام داد، درستی را بررسی کرد و در حلقه‌ها مسیرها را بررسی و اثبات کرد. نادرستی برنامه را می‌توان با تست آن فهمید ولی درستی برنامه را نمی‌توان با تست به دست آورد و اثبات کرد و تست می‌تواند ثابت کند که در برنامه خطایی هست. ولی مکانیزم‌هایی برای اثبات بدون خطا بودن برنامه مانند روش‌های فرمال و رسمی، تبدیل نرم‌افزار به مدل انتزاعی و اثبات درستی از طریق روش‌های ریاضی وجود دارد.برنامه‌نویسی ساخت‌یافته برنامه‌ها را به مجموعه‌ای از توابع قابل اثبات تبدیل می‌کند که قابل تست هستند (به منظور بررسی نادرستی برنامه‌ها) و با حذف go to دیگر کنترل برنامه به صورت نامنظم نیست. زمانی که go to در برنامه زیاد باشد، شکستن و تقسیم برنامه سخت‌تر می‌شود که از نظر معماری مهم است.فصل پنجم: برنامه‌نویسی شی‌گرا (Object Oriented Programming)برنامه‌نویسی شی‌گرا به دلیل وجود قابلیت‌هایی مانند کپسوله‌بندی، وراثت و پلی‌مورفیسم خوب است که این سه ویژگی در یک زبان شی‌گرا مانند جاوا با زبان برنامه‌نویسی دیگری از نوع متفاوت مانند C مقایسه می‌شود.مقایسه کپسوله‌بندی در زبان جاوا و C: برای کپسوله‌بندی در زبان C از کتابخانه‌هایی با دستور include در کد استفاده می‌شود، بدون آن که نیاز به پیاده‌سازی داشته باشند. در جاوا می‌توان متدها را به صورت خصوصی تعریف کرد تا دسترسی از جایی دیگر به آن‌ها وجود نداشته باشد. در زبان C متدهای عمومی و خصوصی را می‌توان بدون پیاده‌سازی آن‌ها در فایل header قرار داد در حالی که در زبان‌های جاوا و C++ باید پیاده‌سازی آن‌ها در فایل header قرار داده شوند. بنابراین زبان C نسبت به زبان جاوا از نظر کپسوله‌بندی قوی‌تر است و کپسوله‌بندی در زبان‌های قدیمی‌تر نیز وجود داشته‌اند.مقایسه وراثت در زبان جاوا و C: د زبان C می توان کلاس بالایی را به پایینی cast کرد و ترتیب پارامترها یکسان است و باید cast را بیان کرد در حالی که در زبان جاوا و شی‌گرا cast بیان نمی‌شود و کلاس پایینی به کلاس بالایی پاس داده می‌شود. همچنین در زبان C باید ترتیب فیلدها در کلاس فرزند و پدر یکی باشد در حالی که در زبان جاوا و شی‌گرا این محدودیت وجود ندارد، بنابراین در این بخش زبان شی‌گرا نیم‌ امتیاز دریافت می‌کند.مقایسه پلی‌مورفیسم در زبان جاوا و C: در زبان‌های قدیمی هم می توان با استفاده از getch می‌توان قابلیت پلی‌مورفیسم را داشت و می‌توان آن را تغییر داد ولی دارای اشاره‌گرهای زیادی هستند که پیچیده است و ممکن است در آن خطا صورت گیرد. در زبان جاوا و شی‌گرا قابلیت پلی‌مورفیسم به راحتی انجام می‌شود، این عملیات را به صورت مخفی انجام می‌دهد، خطاهای کامپایل را نمایش می‌دهد که سبب تسهیل پیاده‌سازی می‌گردد. بنابراین پلی‌مورفیسم در زبان‌های شی‌گرا قوی‌تر و راحت‌تر است و در وارونگی وابستگی مورد استفاده قرار می‌گیرد.وارونگی وابستگی (Dependency Inversion): زمانی که تعدادی کلاس سطح بالا می‌خواهند از کلاس‌های سطح پایین و پایگاه‌های داده استفاده کنند و به آن‌ها وابسته شوند، در این صورت تغییر در کلاس‌های سطح پایین و جزئیات روی کلاس‌های سطح بالا اثر می‌گذارد و آن‌ها را تغییر می‌دهد و جریان اجرا از بالا به پایین است. بنابراین باید جهت وابستگی‌ها بر عکس شود و باید جریان اجرای برنامه از پایین به بالا باشد و باید جزئیات به کلیات وابسته شوند نه برعکس. برای این منظور وارونگی وابستگی مورد استفاده قرار می‌گیرد که می‌توان از یک interface که در شکل 4 نمایش داده شده است و بدون پیاده‌سازی است استفاده کرد و به آن می‌توان وابسته شد و کلاس‌های سطح بالا و سطح پایین به interface وابسته می‌شوند که در این صورت به صورت یک درگاه مشترک است که در این صورت هر کلاسی می‌تواند پیاده‌سازی متفاوتی را بدون وابستگی ارائه دهد، پیاده‌سازی متد در سطح پایین مهم نیست و متدها از طریق interface فراخوانی می‌شوند. بنابراین با شی‌گرایی می‌توان در هر جایی وابستگی را به هر سمتی که مورد نظر است قرار دارد، جریان اجرای برنامه را حفظ کرد، سبب افزایش نگهداری و تغییرپذیری می‌شود و به صورت مجزا توسعه، نگهداری و مستقر می‌شود. injection با وارونگی متفاوت است و با استفاده از وارونگی آسان می‌شود. injection فرایندی است که تولید بخش‌های سطح پایین و وابستگی به آن‌ها را تسهیل می‌کند. برای مدیریت وابستگی‌ها می‌توان از الگویی به نام mediator استفاده کرد که به جای فراخوانی وابستگی‌ها این الگو صدا زده می‌شود و همه وابستگی‌ها را inject می‌کند.شکل 4: وارونگی وابستگی فصل ششم: برنامه‌نویسی تابعی (Functional Programming)در زبان‌های تابعی مانند Clojure به جای حلقه تعدادی توابع به عنوان واحدهای محاسباتی وجود دارند ولی در زبان جاوا و شی‌گرا عملیات در حلقه و توسط متغیر انجام می‌شوند. در زبان Clojure مانند جاوا متغیری که داخل حلقه تغییر کند، وجود ندارد و متغیر دارای مقدار ثابت است. در این فصل مدل برنامه‌نویسی تابعی و غیر تابعی با هم مقایسه می‌شوند و کارهایی که در برنامه‌نویسی تابعی انجام می‌شوند و نحوه انجام آن‌ها مهم نیست.در معماری نیز ثبات در متغیرها وجود دارد که جلوی بن بست را می‌گیرد، مسئله همروندی را حل می‌کند و مشکل رقابت برای گرفتن منابع را کاهش می‌دهد. بنابراین برنامه چند نخی با استفاده از برنامه‌نویسی تابعی راحت‌تر است و تغییر ناپذیری باعث کاهش مشکل چند نخی می‌گردد. بنابراین باید بخش‌هایی که شامل متغیر تغییر پذیر هستند را تفکیک کرد که به بخش‌های تغییر ناپذیر کمک می‌کند که در شکل 5 نمایش داده شده است. متغیرهای تغییر ناپذیر بدون نیاز به همگام‌سازی کمتر دچار خطا می‌شوند و نخ ایمن هستند.شکل 5: تفکیک بخش‌هایی با متغیر تغییر پذیرمنبع رویداد (Event Sourcing): ثبت تمام تغییرات در برنامه به صورت به هم پیوسته و دنباله‌دار صورت می‌گیرد و به جای نگهداری وضعیت سیستم می‌توان رویدادهای را از ابتدای وضعیت سیستم تا زمان فعلی نگهداری کرد که می‌‌توان وضعیت سیستم را بر اساس رویدادها تشخیص داد. بنابراین متناسب با معماری نرم‌افزار و تکنولوژی‌ها باید نوع پایگاه داده و مدل ثبت تغییرات وضعیت نرم‌افزار تعیین شود. با استفاده از منبع رویداد می‌توان تراکنش‌ها را در داخل یک پایگاه داده در برنامه‌های یکپارچه نوشت ولی در میکروسرویس‌ها که پایگاه‌های داده از هم جدا هستند و هر میکروسرویس پایگاه داده مخصوص به خود دارد که روی آن اجرا می‌شود نمی‌توان ویژگی اتمیک بودن را حفظ کرد و تراکنش‌ها جدا هستند. برای حالت اتمیک باید همه تراکنش‌ها را داخل یک پایگاه داده ذخیره کرد، زمانی که همه تراکنش‌ها ذخیره می‌شوند پیغام موفقیت‌ آمیز نمایش داده می‌شود و اگر یکی از آن‌ها انجام نشوند عقبگرد می‌کند. یکی از کاربردهای منبع رویداد استفاده از آن در فضای توزیع شده میکروسرویس‌ها هست. در منبع رویداد به جای عملیاتی مانند ایجاد، حذف، خواندن، بروزرسانی فقط از عملیات ایجاد و خواندن استفاده می‌شود یعنی فقط log اتفاقات ثبت می‌شوند و حالت و متغیری که قرار است بروزرسانی شود، بر اساس اتفاقاتی که افتاده است به دست می‌آید که در این صورت حافظه بیشتر می‌شود و قفل کردن کمتر می‌شود که در مقیاس‌های بالا سبب افزایش سرعت می‌گردد ولی در مقیاس‌های پایین سرعت کاهش می‌یابد. هر چند وقت یکبار در هر بار اجرای سیستم رویدادها از آخرین حالت پایدار خوانده می‌شوند تا از سربار جلوگیری شود.فصل هفتم: اصل مسئولیت واحدهر تابع و واحد باید یک کار را درست و خوب انجام دهد، باید انسجام بالایی داشته باشد و باید بتوان با مستند کمتری آن را فهمید. اگر یک تابع چند کار را انجام دهد، در صورتی خرابی یک کارکرد اشکال‌زدایی و پیگیری روند برنامه سخت می‌شود و سبب کاهش خوانایی و قابلیت استفاده مجدد می‌شود. به همین صورت هم یک ماژول باید فقط در مقابل یک actor مسئول باشد و به آن جواب دهد.اصل مسئولیت واحد: یک ماژول باید یک و فقط یک دلیل برای تغییر داشته باشد و باید فقط در مقابل یک و فقط یک actor مسئول باشد. در هنگام پیاده‌سازی ممکن است ماژول‌ها به دلایل مختلف مانند تغییر در نیازمندی‌ها و سایر بخش‌هایی که از آن‌ها استفاده می‌کنند.اگر هر متد مسئول بخشی از سازمان باشد و هر actor به بخش‌هایی از یک متد مرتبط باشد که هر بخش آن مسئول یک actor است در این صورت تغییر در هر مورد کاربرد سبب تغییر در یک متد می‌شود و هر actor روی کلاس تاثیر می‌گذارد که در شکل 6 نمایش داده شده است.شکل 6: عدم رعایت اصل مسئولیت واحدبنابراین بر اساس اصل مسئولیت واحد این کار نباید انجام شود. برای حل این مشکل دو مکانیزم وجود دارد:1) شکستن طراحی به بخش‌های مختلف و مجزا مانند کلاس‌ها، رابط‌ها و ... که در شکل 7 نمایش داده شده است.شکل 7: شکستن طراحی به بخش‌های مجزا2) استفاده از الگوی Facade که در این الگو از واسطی استفاده می‌شود که امکانات مختلف را با یکدیگر ترکیب می‌کند، دارای متدهای مختلف است که از کلاس‌های مختلف جمع‌آوری شده است و هر کدام از کلاس‌ها مسئولیت مجزایی دارند و جداگانه توسعه و تغییر می‌یابند که در شکل 8 نمایش داده شده است.شکل 8: الگوی Facadeهمچنین می توان به جای شکستن و تقسیم تمام امکانات، برخی از آن‌ها حفظ شوند و برخی دیگر شکسته شوند که در شکل 9 نمایش داده شده است.شکل 9: حفظ برخی از امکانات و شکستن امکانات دیگرفصل هشتم: اصل باز و بسته (Open Close Principle)ماژول‌ها و پیاده‌سازی باید خیلی راحت و باز باشند تا بتوان به راحتی و بدون هیچ تغییری آن‌ها را در سیستم گسترش داد. برای اضافه کردن امکان جدید به پروژه و قرار دادن آن در کنار ساید امکانات موجود در پروژه با استفاده از این اصل می‌توان برای گسترش دادن برنامه هیچ چیز را تغییر نداد، امکان جدید را اضافه کرد و از امکانات موجود استفاده کرد. به این صورت که اگر مؤلفه A باید از تغییر در مؤلفه B محافظت شود، مولفه B باید به مولفه A وابسته باشد و باید مؤلفه‌های سطح بالاتر در آن سلسله مراتب از تغییرات ایجاد شده در مؤلفه‌های سطح پایین محافظت می‌شوند و نهادهای نرم‌افزاری نباید به مواردی که مستقیماً استفاده نمی‌کنند، وابسته نباشند که در شکل 10 نمایش داده شده است.شکل 10: ارتبط مؤلفه‌ها با یکدیگر بر اساس اصل باز و بستهفصل نهم: اصل تعویض لیسکوف (Liskov Substitution Principle)این اصل در مورد یک موضوع بدیهی در وراثت است یعنی هر جایی که از وراثت استفاده می‌شود، باید وراثت به گونه‌ای معنا داشته باشد که در هر زبانی بتوان x را با هر چیزی مانند z که y را به ارث می‌برد، جایگزین کرد. یعنی منطق سیستم در قسمت‌های بالاتر خراب و نقض نشود، یعنی اگر به جای مؤلفه x مؤلفه z که از y ارث‌بری می‌کند قرار داده شود، مشکلی پیش نیاید. یک راه برای بررسی این موضوع استفاده از instance of برای x است که اگر نتیجه شود که شی از نوع دیگری است در این صورت ارث‌بری درست نبوده است.همیشه وراثت درست نیست و باید LSP روی آن عمل کند. اگر وراثت برقرار باشد، با استفاده از LSP می‌توان آن را بررسی کرد که اگر بعدا مؤلفه دیگری جایگزین آن شود درست کار می‌کند یا نه. اگر کنترل برنامه به if یا switchای برسد که نوعی را چک می‌کند و بر اساس هر نوعی کاری را انجام می‌دهد یا به ifای برسد که یک instance of را دریافت می‌کند در این صورت ممکن است رابطه وراثت برقرار نباشد که با اصلاح رابطه وراثت و پلی‌مورفیسم این مشکل حل می‌شود.بنابراین اگر همه مؤلفه‌ها زیر مجموعه یک interface واحد باشند و همه از یک قالب استفاده کنند و برای استثناها if قرار داده شود، راه درستی نیست و ممکن است مؤلفه‌‌های دیگری باشند که کلاس abstract را نقض کنند. در این صورت هر مؤلفه قالب خاص خود را دارد که این قالب در پایگاه داده یا فایل پیکربندی (config file) ذخیره می‌شود تا در کد مورد بررسی و استفاده قرار گیرد. در این صورت اگر مؤلفه جدیدی به پروژه اضافه شود، یک سطر به پایگاه داده یا config file اضافه می‌شود و سایر مکان‌ها تغییری نمی‌کنند.فصل دهم: اصل تفکیک رابط (Interface Segregation Principle)در این فصل به اصل جداسازی رابط‌ها (ISP) پرداخته می‌شود. برای انجام یک عملیات که شامل چند عملیات است و کاربران مختلفی از آن استفاده می‌کنند، در این صورت اگر در جایی تغییری ایجاد شود ممکن است بخش‌های دیگر دوباره کامپایل و مستقر شوند. بنابراین استقرار برنامه سخت می‌شود و زمان‌های زیادی صرف استقرارهای غیر ضروری می‌شود. همچنین ممکن است خطاهایی ایجاد شوند و وابستگی‌هایی ایجاد شوند که با بقیه تداخل دارند و کار سایر اجزا را مختل کنند که در شکل 11 این موضوع نمایش داده شده است.شکل 11: عدم رعایت اصل ISPهمان طور که در شکل 12 مشاهده می‌شود هر تغییری در F که مربوط به S نباشد (S به یک تابع از F وابسته است) و به D مربوط باشد سبب می‌شود تا S دوباره مستقر شود که ممکن است تاثیرات منفی در کد بگذارد.شکل 12: معماری مشکل‌سازراه‌حل: به جای وابستگی به صورت مستقیم، تعدادی interface تعریف می‌شوند یعنی برای هر کاربر یک interface تعریف می‌شود و کلاس اصلی عملیات هم به Interfaceها وابسته می‌شود. تغییر در هر interface سبب تغییر در سایر interfaceها و کلاس عملیات نمی‌شود و فقط کاربر مربوط به آن interface می‌تواند تغییرات را ببیند که این موضوع در شکل 13 نمایش داده شده است. این تغییرات دارای اثرات مخرب نیستند و این اصل در زبان‌هایی مانند جاوا و پایتون مورد استفاده قرار می‌گیرد. بنابراین اگر مؤلفه‌های مختلف از امکانات مختلف استفاده کنند و امکانات در کنار هم جمع شوند، بهتر است هر مؤلفه پنجره‌ای که لازم دارد را ببیند و همه امکانات موجود را نبیند و تغییر در سایر امکانات در آن مؤلفه تاثیر نمی‌گذارد.شکل 13: عملیات تفکیک شدهنتیجه‌گیری: این اصول از یکدیگر مجزا نیستند و یک راه تسهیل ISP داشتن وارونگی وابستگی است و مکمل و هم‌پوشان یکدیگر هستند. در این جا از یک کلاس چند تا رابط تفکیک شد و کدها به رابط‌ها وابسته شدند و کلاسی که رابط‌ها را پیاده‌سازی می‌کند می‌تواند از دید آن‌ها پنهان باشد.فصل یازدهم: اصل وارونگی وابستگیبر اساس این اصل باید بلاک‌های سیستم به کلاس‌های abstraction و interfaceها وابسته باشند و نباید به پیاده‌سازی interfaceهایی که extend شدند وابسته باشند. وارونگی یعنی ماژول‌های سطح بالا و سطح پایین به رابط‌ها و انتزاع‌ها وابسته هستند. همچنین پیاده‌سازی‌ها و کدهای سطح بالا و سطح پایین هم به انتزاع‌ها و رابط‌ها وابسته هستند. در این جا جهت وابستگی‌ها بر عکس شدند که نمایانگر وارونگی است و جریان فراخوانی‌ها و اجراها نسبت به جریان وابستگی‌ها برعکس می‌شوند که می‌توان برای این منظور از الگوی Factory استفاده کرد که در شکل 14 نمایش داده شده است. در زبان جاوا این کار آسان‌تر است.شکل 14: استفاده از الگوی Factory برای مدیریت وارونگیراه حل‌ها برای رعایت این اصل عبارتند از:1) نباید به کلاس‌های پیاده‌سازی اشاره کرد و باید از رابط و انتزاع استفاده کرد، چون ممکن است در آینده به پیاده‌سازی‌های دیگری نیاز باشد.2) نباید از کلاس‌های پیاده‌سازی drive کرد چون ممکن است ارث‌بری از یک کلاس پیاده‌سازی سبب شود پیاده‌سازی‌های دیگری که از آن کلاس هست توجه نشود و مشکل if به وجود بیاید.3) نباید توابع کلاس‌های پیاده‌سازی را override کرد چون override یک پیاده‌سازی خاص ممکن است برای سایر پیاده‌سازی‌ها مشکل ایجاد کند چون از اصول انتزاع استفاده نشده است، همه در یک سطح نیستند، کلاسی که در آن override اتفاق افتاده است در یک سطح پایین‌تر قرار می‌گیرد، سبب ایجاد مشکل می‌شود و ممکن است گاهی اوقات رفتار خاصی را تغییر دهد.مؤلفه concrete: اگر برخی از مؤلفه‌ها مشکلات و وابستگی‌هایی ایجاد کنند، باید تعداد آن‌ها کم باشد و از بقیه سیستم جدا باشند. کدهایی که به مؤلفه‌ concrete وابسته هستند، مستقیما به مؤلفه‌ concrete متصل نیستند و به یک interface وابسته هستند. ایجاد شی‌ از نوع مؤلفه‌ concrete از طریق یک الگوی Factory انجام می‌شود که یک شی از نوع interface را تولید می‌کند که می‌تواند یک concrete تولید کند. مؤلفه concrete‌ ممکن است تغییر کند بنابراین سایر مؤلفه‌ها و اجزا بهتر است که موارد پایدار مثل interface متصل باشند. Interface مانند یک پروتکل است که تغییرات در آن شدید نیست. با تغییر interface موارد زیادی تغییر می‌کنند.فصل دوازدهم: مؤلفه‌هامؤلفه: موجودیت‌هایی هستند که می‌توان به صورت مستقل به عنوان بخشی از یک سیستم توسعه داد. اگر مؤلفه‌ها به خوبی طراحی شوند می‌توانند به صورت مستقل توسعه داده شوند. فایل‌های به هم پیوسته و پویا که می‌توانند در زمان پویا به هم پیوند بخورند، مؤلفه‌های نرم‌افزاری و معماری برنامه هستند و می‌توان به صورت مختلف بخش‌های مختلف را بدون تغییر در اصل برنامه توسعه داد.برنامه‌ها به حجم و حافظه زیادی نیاز دارند و برای کاهش حجم کتاب‌خانه‌ها را کامپایل می‌شوند و به فایل‌های اجرایی تبدیل می‌شوند. همچنین آدرس‌ها پویا نبودند که این مشکل با استفاده از loader حل می‌شود.بار کننده‌ (Loader): برنامه را آدرس‌دهی می‌کند و به صورت پویا و یکی یکی در حافظه بارگذاری می‌کند که به صورت دستی انجام نمی‌شود و سریع انجام می‌شود.پیوند دهنده (Linker): بخش‌های مختلف اجرای برنامه را به هم متصل می‌کند و به فایل‌های یکپارچه تبدیل می‌کند تا به صورت یکپارچه اجرا شوند که سرعت آن پایین بود و با سریع شدن حافظه و دیسک‌ها این مشکل بر طرف شد.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است» شیما سیف الهی شیما سیف الهی Mon, 27 Dec 2021 23:38:38 +0330 https://virgool.io/@shimaseyfollahi/%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D8%A7%DB%8C%D8%B3%D8%AA%D8%A7%DB%8C-%DA%A9%D8%AF-static-code-analysis-f0hiqpa5sgrj تجزیه و تحلیل ایستای کد چیست؟تجزیه و تحلیل ایستای کد یا تجزیه و تحلیل کد منبع به عنوان بخشی از بازنگری کد که به عنوان تست جعبه سفید شناخته می‌شود انجام می‌شود و در مرحله پیاده‌سازی یک چرخه حیات توسعه امنیت (SDL) مورد استفاده قرار می‌گیرد. یک روش اشکال‌زدایی برنامه است که با بررسی کد بدون اجرای برنامه انجام می‌شود. این فرایند درک ساختار کد را فراهم می‌کند. تحلیل ایستای کد به اجرای ابزار تحلیل ایستای کد مربوط است و برای برجسته کردن امکان آسیب‌پذیری در کد منبع ایستا که در حال اجرا نیست با استفاده از روش‌هایی مانند تحلیل Taint و تحلیل جریان داده تلاش می‌کند. چنین ابزارهایی به طور خودکار نقص‌های امنیتی را با درجه بالایی از اطمینان و نقص واقعی را پیدا می‌کنند. چنین ابزارهایی به تحلیلگران کمک می‌کند تا بخش‌های مربوط به امنیت کد به صفر برسند و آن‌ها می‌توانند نقص‌ها را به صورت مؤثرتری پیدا کنند نسبت به ابزاری که به سادگی و به طور خودکار می‌توانند نقص‌ها را پیدا کنند.برخی از ابزارها به سمت یکپارچه‌سازی محیط توسعه حرکت می‌کنند. در انواع مشکلاتی که در طول فاز توسعه نرم‌افزار شناسایی می‌شوند، یک مرحله مهم و قدرتمندی در چرخه حیات توسعه برای استفاده از چنین ابزارهایی است که بازخوردهایی را برای توسعه‌ دهنده در مورد مسائلی که ممکن است در طول توسعه کد با آن‌ها مواجه شود را ارائه می‌دهد. این بازخوردها در مقایسه با آسیب‌پذیری‌ها که بسیار دیرتر در چرخه توسعه یافت می‌شوند، مفید هستند. تحلیل ایستای کد در مهندسی نرم‌افزار توسط تیم توسعه و تضمین کیفیت نرم‌افزار انجام می‌شود. تحلیل ایستای کد در یافتن مسائل کدگذاری مانند خطاهای برنامه‌نویسی، نقض‌های استاندارد کدنویسی، مقادیر تعریف نشده، نقض‌های نحوی، آسیب‌پذیری‌های امنیتی مورد استفاده قرار می‌گیرد.Static Cod Analysisتحلیل ایستای کد چگونه انجام می‌شود؟فرایند تحلیل ایستای کد تا زمانی که خودکار باشد، نسبتا ساده است. این فرایند قبل از تست نرم‌افزار و در مراحل اولیه توسعه اتفاق می‌افتد. در فعالیت‌های DevOps این فرایند در فاز ایجاد رخ می‌دهد. بعد از نوشتن کد، تحلیلگر کد را برای بررسی آن اجرا می‌کند و قوانین کدنویسی استاندارد تعریف شده یا قوانین از پیش تعریف شده سفارشی را بررسی می‌کند و تحلیلگر تطابق کد با قوانین تنظیم شده را بررسی می‌کند و موارد مثبت کاذب و منفی کاذب را شناسایی می‌کند. هنگامی که مشکلات کد حل شود، کد می تواند تست و اجرا شود. بدون داشتن ابزارهای تست کد، تحلیل ایستا سخت و زیاد است. زیرا انسان‌ها باید کد را بررسی کند و بفهمند که کد چگونه در محیط‌های زمان اجرا رفتار می‌کند. بنابراین استفاده از ابزارهایی که این فرایند را خودکار می‌سازند، سبب خلاص شدن از کاری طولانی و طاقت‌فرسا می‌شود و محیط کار کارآمدتری را ایجاد می‌کند.تکنیک‌های تحلیل ایستای کدتکنیک‌های مختلفی برای تحلیل ایستای کد منبع برای آسیب‌پذیری‌‌های احتمالی وجود دارد که ممکن است در یک راه‌ حل با هم ترکیب شوند. این تکنیک‌ها اغلب از تکنولوژی‌های موجود در کامپایلر تشکیل شدند. در ادامه تعدادی از این تکنیک‌ها معرفی می‌شوند.تحلیل جریان داده: تحلیل جریان داده برای جمع‌آوری اطلاعات زمان اجرا (پویا) در مورد داده در نرم‌افزار زمانی که در حالت ایستا هستند مورد استفاده قرار می‌گیرد. اطمینان حاصل می‌کند که داده‌های تعریف شده به درستی استفاده می‌شوند. همچنین از داده‌هایی که به درستی عمل می‌کنند، اطمینان حاصل می‌کند. در تحلیل جریان داده سه اصطلاح مورد استفاده قرار می‌گیرند که شامل بلاک اصلی (کد)، تحلیل جریان کنترل (جریان داده) و مسیر جریان کنترل (مسیری که داده‌ها طی می‌کنند) هست. بلاک اصلی یک دنباله از دستورات متوالی است که کنترل در شروع یک بلاک وارد می‌شود و از انتهای آن خارج می‌شود و بلاک فقط در انتهای آن می‌تواند متوقف یا منشعب شود.تحلیل کنترل: روی جریان کنترل در یک ساختار فراخوانی تمرکز می‌کند. یک جریان کنترل می‌تواند یک پردازش، تابع، متد یا یک زیر برنامه باشد.گراف جریان کنترلی: در یک نمایش گراف انتزاعی نرم‌افزار، نودهای موجود در گراف بلاک‌های اصلی را نشان می‌دهند. یال‌های جهتدار برای نمایش پرش‌ها (مسیرها) از یک بلاک به بلاک دیگر را نشان می‌دهد. اگر نود فقط یک یال خروجی داشته باشد، نشان‌دهنده بلاک ورودی است. اگر یک نود فقط یک یال ورودی داشته باشد، نشان‌دهنده بلاک خروجی است. در شکل زیر یک گراف جریان کنترلی نمایش داده شده است که node 1 یک بلاک ورودی و node 6 یک بلاک خروجی را نمایش می‌دهد.Control Flow Graph (CFG)تحلیل Taint: تجزیه و تحلیل Taint، متغیرهایی که با ورودی قابل کنترل کاربر آلوده می شوند را شناسایی می‌کند و آن‌ها را برای توابع آسیب‌پذیر احتمالی که به عنوان سینک شناخته می‌شود، ردیابی می‌کند. اگر یک متغیر آلوده قبل از این که اصلاح شود به تابع سینک منتقل و ارسال شود،‌به عنوان یک آسیب‌پذیری علامت گذاری می‌شود. برخی از زبان‌های برنامه‌نویسی مانند Perl و Ruby از بررسی Taint استفاده می‌کنند و در شرایط خاصی مانند پذیرش داده‌ها از طریق CGI فعال می‌شوند.تحلیل لغوی: تحلیل لغوی، نحو کد منبع را به توکن‌های اطلاعات برای انتزاع کد منبع تبدیل می‌کند و دستکاری و تغییر آن را آسان‌تر می‌سازد.تحلیل رابط: شبیه‌سازی‌ها را برای بررسی کد تایید می‌کند و اطمینان حاصل می‌کند که رابط با مدل شبیه‌سازی مطابقت دارد.تحلیل خطا و خرابی: خطا و خرابی را در مدل مؤلفه‌ها تجزیه و تحلیل می‌کند.همچنین می‌توان تحلیل ایستای کد دارای دسته‌بندی‌های دیگری مانند رسمی، زیبایی، ویژگی‌های طراحی، بررسی خطا و پیش‌بینی هست. اگر کد صحیح باشد در دسته رسمی قرار می‌گیرند. اگر کد با روش‌های استاندارد همگام شود در دسته زیبایی قرار می‌گیرد. دسته ویژگی‌های طراحی مربوط به سطح پیچیدگی‌ها است. دسته بررسی خطا به دنبال نقض‌های کد است. دسته پیش‌بینی می‌پرسد که کد در هنگام اجرا چگونه رفتار می‌کند.Static Code Analysis Technicsنقاط قوت تحلیل ایستای کددارای مقیاس‌بندی خوب است که می‌تواند روی نرم‌افزارهای زیادی بارها اجرا شود.می‌تواند موارد مورد نیاز را با استفاده از ابزار به صورت خودکار و با قابلیت اطمینان بالا پیدا کرد. که برای مواردی مانند سرریز بافر، نقص‌های SQL Injection و ... ابزارها و روش‌های تحلیل ایستای کد عالی هستند.می‌تواند همه کد را در برنامه ارزیابی کند و کیفیت کد را افزایش می‌دهد.در هنگام استفاده از ابزار خودکار در مقایسه با بررسی دستی کد، سرعت افزایش می‌یابد.همراه با روش تست معمولی، تست ایستا عمق بیشتری در اشکال‌زدایی کد فراهم می‌کند.ابزارهای خودکار کمتر در معرض خطای انسانی هستند.احتمال یافتن آسیب‌پذیری در کد را افزایش می‌دهد و امنیت وب یا برنامه را افزایش می‌دهد.می‌توان تحلیل ایستا را در یک محیط توسعه آفلاین انجام داد.نقاط ضعف تحلیل ایستای کدبسیاری از انواع آسیب‌پذیری‌های امنیتی به صورت خودکار به سختی یافت می‌شوند. مانند مشکلات احراز هویت، مسئله کنترل دسترسی، استفاده ناامن از رمزنگاری و .... ابزارها و حالت‌های فعلی تنها درصد نسبتا کمی از نقص‌های امنیتی برنامه را پیدا می‌کنند.دارای تعداد زیادی مثبت کاذب است.نمی‌توان مشکلات امنیتی را پیدا کرد. زیرا آن‌ها در کد نمایش داده نمی‌شوند.اثبات این که یک مسئله امنیتی شناسایی شده یک آسیب‌پذیری واقعی است، کاری دشوار است.برای بسیاری از ابزارها، تجزیه و تحلیل کدی که کامپایل نشده است، دشوار است. تحلیلگران اغلب نمی‌توانند کد را کامپایل کنند زیرا آن‌ها کتابخانه درست و مناسبی که دارای همه دستورات کامپایل و همه کدها باشد را ندارند.یک ابزار ممکن است در صورت وجود خطا و نقص در کد برنامه، نتواند نشان دهد که نقص و خطا چیست.نمی‌توان همیشه از همه قوانین کدگذاری پیروی کرد. مانند قوانینی که به اسناد خارجی نیاز دارند.تحلیل ایستا ممکن است زمان بیشتری را نسبت به روش‌های قابل مقایسه داشته باشد.تحلیل ایستا نمی‌تواند نحوه اجرای یک تابع را تشخیص دهد.کتابخانه‌های سیستمی و سوم شخص ممکن است قادر به تجزیه و تحلیل نباشند. زیرا در برنامه‌هایی که به صورت پویا کتابخانه‌های سوم شخص را از کد ایستا بارگیری می‌کنند، تحلیل پویا رویکرد عملی‌تری برای تضمین امنیت است.ابزارهای تحلیل ایستا به سختی می‌توانند یک مشکل غیرقابل انتظار را که ممکن است در طول زمان اجرا رخ دهد را تشخیص دهند.پیکربندی‌های نادرست منبع آسیب‌پذیری‌ها هستند و تحلیل ایستا به تنهایی برای تضمین امنیت برنامه کافی نیست.محدودیت‌های تحلیل ایستای کدابزارهای تحلیل ایستا ممکن است به دلیل اتکا به مدل‌های انتزاعی و نمایش جریان‌های داده و منطق برنامه همراه با ناتوانی در درک هدف توسعه دهنده در زمینه‌های کدنویسی معین نتایج مثبت کاذب و منفی کاذب تولید کند.مثبت کاذب: یک ابزار تحلیل ایستای کد اغلب نتایج مثبت کاذب را تولید می‌کند. جایی که ابزار آسیب‌پذیری احتمالی را گزارش می‌کند که در واقع درست و واقعی نیست که به این دلیل است که ابزار نمی‌تواند از یکپارچگی و امنیت داده که در برنامه از ورودی به خروجی جریان می‌یابد، مطمئن باشد. نتایج مثبت کاذب ممکن است هنگام تحلیل یک برنامه که با مؤلفه‌های کد بسته یا سیستم‌های خارجی تعامل دارد، گزارش شوند. زیرا بدون کد منبع، ردیابی جریان داده در سیستم خارجی و اطمینان از یکپارچگی و امنیت داده امکان‌پذیر نیست.منفی کاذب: استفاده از ابزارهای تحلیل ایستای کد می‌تواند نتایج منفی کاذب را ارائه دهد یعنی جایی که آسیب‌پذیری‌ها ایجاد می‌شوند ولی ابزار نمی‌توانند آن‌ها را گزارش دهند. ممکن است این اتفاق زمانی رخ دهد که یک آسیب‌پذیری جدید در یک مؤلفه خارجی کشف شود یا زمانی که ابزارهای تحلیل دانشی در مورد محیط زمان اجرا و پیکربندی ایمن و نحوه آن نداشته باشند.مقایسه تحلیل ایستا و تحلیل پویامزیت اصلی تحلیل ایستا این هست که می‌تواند خطاهایی را آشکار کند که تا زمانی که فاجعه‌ای رخ ندهد نمی‌توانند خود را نشان دهند. تحلیل ایستا اولین گام در کنترل کیفیت یک نرم‌افزار جامع است. بعد از انجام تحلیل ایستا، تحلیل پویا برای کشف خطاهای پنهان و نامحسوس یا آسیب‌پذیری‌ها است. در حوزه کامپیوتر استاتیک (ایستا) به معنای ثابت است در حالی که داینامیک (پویا ) به معنای قابلیت عمل یا تغییر است. تحلیل پویا شامل تست و ارزیابی یک برنامه بر اساس زمان اجرا است. تحلیل ایستا و پویا با هم در نظر گرفته می‌شوند و به عنوان تست جعبه سفید شناخته می‌شوند.تفاوت اصلی بین تحلیل ایستا و تحلیل پویا زمانی است که خطا در چرخه عمر توسعه نرم‌افزار پیدا می‌شود. تحلیل ایستا خطا را بین فاز کدنویسی و تست واحد بدون آن که هیچ کدی اجرا شود، تشخیص می‌دهد. تحلیل پویا خطا را در طول فاز تست واحد شناسایی می‌کند و نحوه رفتار کد در طول زمان اجرا را بررسی می‌کند. بنابراین بهترین راه برای تضمین امنیت برنامه، ترکیب هر دو تحلیل ایستا و پویا است. تحلیل ایستا می‌تواند با حذف بسیاری از مسائل قبل از اجرا ، کیفیت کلی کد و نرم‌افزار را بهبود بخشد،‌ در حالی که تحلیل پویا خطاها را در زمان اجرا و آسیب‌پذیر‌هایی که با استفاده از روش‌های ایستا قابل شناسایی نیستند را پیدا می‌کند.Static Code Analysis VS Dynamic Code Analysisابزارهای تحلیل ایستای کددر این بخش دو مورد ابزارهای منبع باز مهم و کاربردی مورد استفاده برای تجزیه و تحلیل ایستای کد به منظور افزایش کیفیت و بررسی کد معرفی و بررسی می‌گردند.ابزار SonarQubeاین ابزار در بررسی کیفیت و امنیت کد مورد استفاده قرار می‌گیرد و ابزارهایی برای مدیریت کیفیت مانند IDE یکپارچه، سرور یکپارچه ماندگار محبوب و ابزارهای بررسی کد را فراهم می‌کند. با استفاده از آن توسعه‌دهندگان می‌توانند کدهای تمیزتر ایمن‌تری بنویسند و توسعه‌دهندگان را در طول بررسی کد هدایت می‌کند. با هزاران قانون خودکار تحلیل ایستای کد در بیش از 25 زبان برنامه‌نویسی مانند Java، C#، JavaScript، TypeScript، C/C++، COBOL و .. مورد استفاده قرار می‌گیرد و مستقیما با پلتفرم DevOps ادغام می‌شود. این ابزار برای خودکارسازی بررسی کد مورد استفاده قرار می‌گیرد. از جمله معایب این ابزار، عدم پشتیبانی از هر IDE است. ویژگی‌های مهم ابزار SonarQube عبارتند از:چند زبان بودنتحلیل امنیتانتشار کد با کیفیتقابلیت نگهداریتشخیص مسائل پیچیدهSonarQubeابزار DeepSourceیک ابزار خوب برای تحلیل ایستای کد است که برای تشخیص کیفیت کد و مسائل امنیتی در چرخه عمر توسعه نرم‌افزاز استفاده می‌شود. یکی از سریع‌ترین و کم نویزترین ابزارهای تحلیل ایستا است و ریسک‌های خطا، ضد الگوها، عملکرد و مسائل امنیتی را قبل از این که در محصول نهایی مداخله کنند، تشخیص می‌دهد. توسعه‌دهندگان در راه‌اندازی و توسعه این ابزار مشکلی ندارند. این ابزار می‌تواند خطاها و برخی از مشکلات رایج را در کد به صورت خودکار در طول بررسی کد پیدا کند و ترمیم هایی را برای آن‌ها تولید کند و به صورت خودکار کد را قالب‌بندی می‌کند. این ابزار برای پروژه‌های منبع باز و تیم‌های کوچک رایگان است و برای شرکت‌ها یک گزینه استقرار self hosted را پیشنهاد می‌دهد. این ابزار می تواند با Bitbucket، GitHub یا GitLab ادغام شود. DeepSource معیارهایی مانند تعداد وابستگی، پوشش اسناد و ... را به صورت خودکار تولید و ردیابی می‌کند. ازجمله معایب این ابزار در دسترس نبودن پشتیبانی از زبان PHP است. ویژگی‌های مهم ابزار DeepSource عبارتند از:پیکربندی تک‌فایلبررسی کیفیت برای درخواست Pullطیف گسترده‌ای از پوشش مشکلات را دارد.تحلیل‌گران را به طور فعال نگه‌ می‌دارد.شناسایی و تفسیر مسائل با جزئیاتردیابی معیارهای کدتحلیلگران می‌توانند ترمیم‌هایی را برای مشکلاتی که رخ می‌دهند را پیشنهاد دهند و در صورتی که به آ‌ن‌ها اجازه داده شود، می‌توانند درخواست‌های Pull را با ترمیم آن‌ها ایجاد کنند.پشتیبانی از زبان‌های python، JavaScript، go، ruby، java و ...DeepSourceشرکت‌های فعال در زمینه آزمون و کیفیت نرم‌افزار و تحلیل ایستای برنامهدر این بخش دو مورد از شرکت‌های ایرانی فعال در حوزه آزمون و کیفیت نرم‌افزار و تحلیل ایستای کد برنامه و محصولات آن‌ها معرفی می‌شوند.آزمایشگاه آزمون و تایید نرم‌افزار دانشگاه شهید بهشتیاین آزمایشگاه در طراحی و اجرای انواع آزمون‌‏ها بر روی سامانه‏‌های نرم‏‌افزاری و ارزیابی کیفیت نرم‌‏افزارها فعالیت می‌کند. با هدف رشد صنعت آزمون نرم‏افزار و سایر حوزه‏های مرتبط با کیفیت نرم‏افزار ایجاد شده است. خدمات این آزمایشگاه عبارتند از:طراحی و اجرای آزمونهای عملکردی (Functional): در انجام آزمونهای عملکردی، آزمایشگاه ابتدا به تحلیل آزمون می پردازد، سپس طراحی آزمون انجام می‌شود. در ادامه، فعالیت پیاده سازی آزمون انجام خواهد شد و در نهایت، اجرای آزمون صورت می پذیرد. در این مرحله، محیط آزمون راه اندازی شده، اسکریپتهای آزمون اجرا شده و نتایج آزمون در قالب گزارشهای آزمون ثبت و تحلیل می شوند.آزمون کارایی: آزمایشگاه، خدمات آزمون در موضوع کارایی نرم‌افزار را در انواع مختلف آزمون بار، آزمون فشار، آزمون استقامت، آزمون مقیاس پذیری، آزمون حجم و پروفایلینگ و همچنین مشاوره در اجرای فرآیند توسعه مبتنی بر کارایی ارائه می‌کند.آزمون امنیت: آزمایشگاه رخدمات مشاوره و آزمون در موضوع امنیت نرم‌افزار را در سطوح مختلف قبل از توسعه نرم‌افزار، در فاز تحلیل و طراحی، در فاز کدنویسی و بعد از تولید و استقرار محصول نرم‌افزاری ارائه می‌کند. در ارتباط با این آزمون، حوزه های محرمانگی، جامعیت محتوا، قابلیت دسترس‌پذیری، احراز هویت و صلاحیت کاربران، انکارناپذیری عملکرد نرم‌افزار و کاربران و ... درنظر گرفته می شوند.مشاوره و نظارت بر فرایند آزمون: علاوه بر خدمات آزمایشگاه در حوزه های مختلف تحلیل، طراحی، پیاده‌سازی و اجرای انواع آزمون‌ها، خدمات آزمایشگاه به صنعت در قالب مشاوره و نظارت بر فرآیند آزمون، تاسیس دپارتمان آزمون در شرکت‌ها، موسسات و سازمان‌ها، افزایش قابلیت آزمون پذیری نرم‌افزارها، آموزش زمینه‌های مختلف مرتبط با آزمون، توسعه، سفارشی‌سازی و ارائه ابزارهای مختلف آزمون می‌باشد.ارتقاء میزان آزمون‌پذیری نرم‌افزار: آزمایشگاه با هدف ارتقاء میزان آزمون‌پذیری نرم‌افزارها، مواردی از جمله بررسی راه‌های کاهش پیچیدگی نرم‌افزار، کاهش عدم قطعیت در رفتار نرم‌افزار و کاهش وابستگی‌ها را پوشش می‌دهد و افزایش ساختار مناسب برنامه‌ها از طریق حذف وابستگی‌های چرخشی و افراز کلاس‌ها و بسته‌ها با هدف کاهش پیچیدگی واسط‌های نرم‌افزاری از طریق آزمون‌های تعبیه شده صورت می‌گیرد.شرکت مهندس پیشگان آزمون افزار یاسهدف این شرکت ارتقا تعالی سازمانی از طریق تضمین کیفیت خدمات و محصولات نرم‌افزاری است و استراتژی کاری آن طبق استاندارد و متدلوژی و به کارگیری ابزارهای مدرن است. این شرکت به منظور آزمون و کیفیت نرم‌افزار از ابزارهایی در زمینه مدیریت کیفیت، تست کارکردی، تست کارایی، تست امنیت، تست برنامه‌نویسی، تحلیل ایستا، تحلیل پویا و مانیتورینگ استفاده می‌کند. چشم‌انداز این شرکت عبارتند از:ارائه راهکارهای ارزیابی، تست و تضمین کیفیت نرم‌افزاررفع مشکلات کندی، قطعی و امنیت سیستم‌های نرم‌افزاریکاهش هزینه‌های تست و تضمین کیفیت با ابزارهای خودکارمشاوره و نظارت بر کیفیت فرایند تولید سیستم‌های نرم‌افزاریخدمات این شرکت به منظور آزمون و تضمین کیفیت نرم‌افزار عبارتند از:انجام پروژه های برون سپاری در زمینه تست و تضمین کیفیتارائه مشاوره در زمینه تست و تضمین کیفیت نرم افزارآموزش راهکارهای تست و تضمین کیفیت نرم افزارکمک به تهیه RFP جهت تدوین شرایط پذیرش یک سیستمراه اندازی تیم تست و تضمین کیفیت نرم افزارارائه ابزارهای پیشرفته‌ تست و تضمین کیفیتتست نفوذ و امنیت نرم افزار، شبکه و زیرساختنظارت بر تحویل یک سیستم و انجام تست های پذیرشممیزی کیفیت فرایند تولید نرم افزارجمع‌بندیدر این مقاله ابتدا در بخش اول به معرفی و بررسی تحلیل کد ایستا در حوزه معماری نرم‌افزار و توسعه نرم‌افزار پرداخته شد و سپس در بخش دوم دو مورد از ابزارهای مورد نیاز به منظور تحلیل کد ایستا و تضمین کیفیت و آزمون نرم‌افزار معرفی شدند و در پایان نیز دو مورد از شرکت‌های ایرانی فعال در حوزه ارائه خدمات مربوط به کیفیت و تضمین نرم‌افزار به همراه محصولاتی که ارائه می‌دهند معرفی و بیان گردید.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابع و مراجع: https://owasp.org/www-community/controls/Static_Code_Analysis https://whatis.techtarget.com/definition/static-analysis-static-code-analysis https://www.whitehatsec.com/glossary/content/static-analysis https://dzone.com/articles/top-7-static-code-analysis-tools https://www.softwaretestinghelp.com/tools/top-40-static-code-analysis-tools/ http://ticksoft.sbu.ac.ir/ http://mohandespishegan.com/ شیما سیف الهی شیما سیف الهی Fri, 24 Dec 2021 22:18:38 +0330 https://virgool.io/@shimaseyfollahi/%DA%AF%D8%B0%D8%B1%DA%AF%D8%A7%D9%87-%D8%B3%D8%B1%D9%88%D9%8A%D8%B3-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86%D9%8A-esb-zek8njf3xtb6 گذرگاه سرويس سازماني چيست؟يک گذرگاه سرويس سازماني (enterprise service bus) يک الگوی معماری و پلتفرم نرم‌افزاری است که برای توزیع کار بین مؤلفه‌های متصل برنامه مورد استفاده قرار می‌گیرد و از طریق آن یک مؤلفه نرم‌افزاری مرکزی، ادغام بین برنامه‌ها را انجام می‌دهد. انتقال مدل داده را انجام می‌دهد و اتصال را مدیریت می‌کند و به صورت بالقوه ترکیب چندین درخواست را مدیریت می‌کند. یک سیستم ارتباطی بین برنامه‌های نرم‌افزاری در حال تعامل در یک معماری سرویس‌گرا و الگویی برای معماری سرویس‌گرا پیاده‌سازی می‌کند و برای طراحی شبکه مورد قبول در شبکه جهانی وب نیز مورد استفاده قرار می‌گیرد. برای ایجاد یکنواختی در جابه‌جایی کار طراحی شده است. برنامه‌هایی با قابلیت اتصال به ESB و تصدیق پیام‌ها براساس ساختار ساده و قوانین و سیاست‌های کسب و کار را ارائه می‌دهد. EBS در نرم‌افزاری که بین برنامه‌های تجاری کار می‌کند و ارتباط بین آن‌ها را فعال می‌کند، پیاده‌سازی می‌شود. باید بتواند تمام تماس‌های مستقیم با برنامه‌ها را روی گذرگاه جایگذاری کند، به طوری که تمام ارتباطات از طریق ESB انجام شود. برای رسیدن به این هدف ESB باید عملکرد ارائه شده توسط برنامه‌های بخش خودش را به صورت معنادار کپسوله کند. مدل پیام مجموعه‌ای استاندارد از پیام‌ها را تعریف می‌کند که ESB ارسال و دریافت می‌کند.عملکرد اصلی آن این هست که به عنوان گذرگاه پیام عمل می‌کند که بعد از دریافت پیام‌ها، آن‌ها را بین مؤلفه‌ها یا برنامه‌های مناسب بر اساس یک سیاست هدایت می‌کند. اغلب چون برنامه بدون مدل پیام یکسان تکامل یافته است، ESB پیام را به قالبی تبدیل می‌کند که برنامه بتواند آن را تفسیر کند. یک آداپتور نرم‌افزاری مانند یک آداپتور فیزیکی وظیفه انجام این تغییرات را دارد. کاربرد اصلی آن یکپارچه‌سازی برنامه‌های سازمانی ناهمگن و چشم‌انداز سرویس پیچیده است. یک معماری نرم‌افزاری و ابزاری است که در محاسبات توزیع شده و یکپارچه سازی مؤلفه‌ها مورد استفاده قرار می‌گیرد و نوع خاصی از مدل کلی‌تر client-server است. می‌توان آن را به عنوان مجموعه‌ای از سوئیچ‌ها در نظر گرفت که می‌تواند به صورت مستقیم یک پیام را در امتداد یک مسیر خاص بین مؤلفه‌های برنامه بر اساس محتوای پیام و پیاده‌سازی سیاست‌های کسب و کار هدایت کند. ESB قابلیت agile و انعطاف‌پذیری را با توجه به ارتباطات پروتکل سطح بالا بین برنامه‌ها ارتقا می‌دهد.مفهوم گذرگاه سرویس سازمانی مشابه مفهوم گذرگاه موجود در معماری سخت‌افزار کامپیوتر است که با طراحی ماژولار و همروند سیستم عامل کامپیوتر با کارایی بالا ترکیب شده است. ESB مفاهیم جدید سیستم عامل‌ها برای سرویس‌های مستقل که روی شبکه‌هایی از کامپیوترهای مختلف و مستقل اجرا می‌شوند را اعمال می‌کند. یک ESB مانند سیستم عامل‌های همروند،‌علاوه بر پذیرش، تفسیر و مسیریابی درخواست‌های مشتری برای سرویس‌های پاسخگویی مناسب یک سرویس مربوط به کالا را نیز ارائه می‌دهد. پیاده‌سازی‌های ESB از میان‌افزار پیام‌گرا مبتنی بر رویداد محور و استاندارد در ترکیب با صف‌های پیام به عنوان چارچوب‌های تکنولوژی استفاده می‌کند. ESB بر ساخت دقیق مدل پیام سازمانی و طراحی مناسب عملکرد ارائه شده توسط برنامه‌ها متکی است. اگر مدل پیام به طور کامل عملکرد برنامه را کپسوله نکند، برنامه‌های دیگری که مایل به آن عملکرد هستند، ممکن است مجبور شوند گذرگاه را دور بزنند و برنامه‌های ناهماهنگ را به طور مستقیم فراخوانی کنند. با انجام این کار اصول مدل ESB نقض می‌شود و بسیاری از مزایای استفاده از این معماری را نقض می‌کند.گذرگاه سرويس سازماني (ESB)موضوع و راه حلدر چند دهه اخیر چندین الگوی معماری برای کاهش زحمات ناشی از ادغام سیستم‌های متفاوت در یک سازمان به وجود آمدند. معماری Client-Server (CSA) اولین رویکرد در این زمینه بود که ساده بود ولی فاقد مقیاس‌پذیری بود. پس از آن معماری سرویس‌گرا (SOA) به وجود آمد که منطق کسب و کار را به خوبی و به سرویس‌هایی که با هم همکاری می کنند، تقسیم می‌کند. ESB به عنوان یک لایه میان‌افزار در SOA برای تسهیل این همکاری و به عنوان یک جز داخلی SOA در نظر گرفته می‌شود.معماري SOA به همراه ESB به عنوان جز داخلي آنوظایف اصلی ESBتبدیل پروتکل‌ها و مسیریابی پیام‌ها بین سرویس‌ها به آسانیتغییر قالب داده را به منظور ایجاد قابلیت همکاری برای تراکنش‌های اجرا شده در صورت نیازنظارت و کنترل مسیریابی تبادل پیام بین سرویس‌هارفع اختلاف بین مؤلفه‌های سرویس ارتباطیکنترل استقرار و نسخه‌سازی سرویس‌هامرتب کردن استفاده از خدمات اضافیارائه سرویس‌های کالا مانند مدیریت رویداد، تبدیل و نگاشت داده، صف‌بندی و مرتب‌سازی پیام و رویداد، امنیت یا مدیریت استثنا، تبدیل پروتکل و اجرای کیفیت مناسب سرویس ارتباطیویژگی‌های ESBفراگیر بودن: می‌توان یک ESB را برای نیازهای پروژه‌های یکپارچه‌سازی همه منظوره در موقعیت‌های مختلف یکپارچه‌سازی تطبیق داد که می‌تواند پروژه‌های یکپارچه‌ای را ایجاد کند که کل سازمان و شرکای کسب و کار را دربرگیرد.معماری SOA بسیار توزیع شده و رویداد محور: مؤلفه‌های یکپارچه با اتصال سست می‌توانند روی گذرگاه در کل توپولوژی‌های استقرار جغرافیایی توزیع شده مستقر شوند. اما به عنوان سرویس‌های اشتراکی از هر جایی در گذرگاه قابل دسترس هستند.انتخاب استقرار مؤلفه‌های ادغام شده: آداپتورها، سرویس‌های تبدیل داده‌های توزیع شده و سرویس‌های مسیریابی مبتنی بر محتوا می‌توانند به طور انتخابی در زمان و مکان مورد نیاز مستقر شوند و به طور مستقل مقیاس‌بندی می‌شوند.امنیت و قابلیت اطمینان: همه مؤلفه‌هایی که از طریق گذرگاه با یکدیگر ارتباط دارند می‌توانند دارای مزایایی مانند پیام‌رسانی قابل اعتماد، یکپارچگی تراکنشی و ارتباطات احراز هویت ایمن باشد.جریان پردازش و تنظیم: یک ESB سبب می‌شود تا داده در میان هر برنامه و سرویس که به گذرگاه وصل شده است، به صورت محلی یا از راه دور جریان یابد.محیط مدیریت شده خودمختار در عین حال وابسته: یک ESB از خودمختاری محلی در سطح واحد دپارتمان و تجاری پشتیبانی می‌کند و همچنان می‌تواند در یک محیط یکپارچه مدیریت شده بزرگتر ادغام شود.پذیرش افزایشی: یک ESB می‌تواند برای پروژه‌های کوچک استفاده شود. هر پروژه منحصر به فرد می‌تواند در یک شبکه یکپارچه بسیار بزرگتر ایجاد شود که می‌تواند از هر جایی روی گذرگاه از راه دور مدیریت شود.پشتیبانی از XML: یک ESB می‌تواند از XML به عنوان نوع داده محلی استفاده شود.بینش در زمان واقعی: یک ESB زیرساخت‌هایی را برای فعال کردن بینش بلادرنگ در مورد داده‌های کسب و کار زنده فراهم می‌کند.چالش‌های گذرگاه سرویس سازمانیعدم استاندارد پذیرفته شده واحد برای ویژگی‌ها، رفتار، مفاهیم و پیاده‌سازی‌های ESBممکن است برای توصیف هر چیزی که از گردش کار پشتیبانی می‌کند مورد استفاده قرار گیرد. مثلا ارائه دهنده اوراکل می‌تواند چند نوع ابزار میان‌افزار در دسته‌بندی ESB قرار دهد که ممکن است این ابزارها تعدادی تابع مدیریت برنامه داشته باشند.هدایت پیام‌ها بر اساس سیاست عملکردی است که ESBها را از سایر ابزارهای میان‌افزار جدا می‌کند. برای کاربران مهم است که نیازهای کسب و کار خود را به وضوح تعریف کنند و سپس ویژگی‌های ESBهای کاندید خود را در برابر این نیازها ارزیابی می‌کنند.مزایای گذرگاه سرویس سازمانیبه دلیل آن که ESB نحوه حرکت کار را کنترل می‌کند، تغییر مؤلفه‌ها یا افزودن مؤلفه‌های اضافی را برای برنامه آسان می‌سازد.مکانی مناسب برای اجرای امنیت و انطباق نیازمندی‌ها، شرایط استثنا یا ثبت log عادی و مدیریت و نظارت بر عملکرد تراکنش ایجاد می‌کند.تعادل بار را فراهم می‌کند، که می‌توان در آن چندین کپی از مؤلفه‌ها را برای بهبود عملکرد ایجاد کرد. همچنین از یک مؤلفه یا منبع خراب در صورت شکست و خرابی پشتیبانی می‌کند.مقیاس‌‌بندی از راه‌ حل‌های نقطه‌ای تا استقرار در سطح سازمانی (گذرگاه توزیع شده)پیکربندی بیشتر نسبت به یکپارچه‌سازی کدموتور قواعد مرکزی و واسطه و کارگزار مرکزی ندارد.متصل کردن و قطع کردن آن آسان است و سیستم دارای چسبندگی و اتصال سست است.یک ESB متمرکز می‌تواند ارتباط، پیام‌رسانی و ادغام آسان و استانداردی را در میان سرویس‌های سازمان ارائه دهد. که می‌توان هزینه‌های سخت‌افزاری و نرم‌افزاری را به اشتراک گذاشت و سرورها را در صورت نیاز برای استفاده ترکیبی فراهم کرد و یک راه‌حل متمرکز و مقیاس‌پذیر را ارائه کرد.از یکپارچه‌سازی برنامه‌، یکپارچه‌سازی داده و تنظیم خودکار سرویس در فرایند تجاری پشتیبانی می‌کند. سبب می‌شود تا توسعه‌دهندگان زمان کمتری را برای یکپارچه‌سازی و زمان بیشتری را برای ارائه و بهبود برنامه‌های خود صرف کنند. همچنین توانایی استفاده مجدد از این ادغام‌ها را از یک پروژه به پروژه دیگر سبب افزایش بهره‌وری و صرفه‌جویی می‌گردد.معایب گذرگاه سرویسسرعت ارتباط به ویژه برای سرویس‌هایی که از قبل سازگار هستند پایین است.یک نقطه شکست و خرابی می‌تواند ارتباطات را در کل سازمان پایین بیاورد.دارای پیکربندی و پیچیدگی نگهداری بالا است.در بسیاری از سازمان‌های دیگر ESB به عنوان گلوگاه در نظر گرفته می‌شود. ایجاد تغییرات یا پیشرفت‌ها در یک ادغام سبب بی‌ثباتی سایر استفاده‌کنندگان از آن ادغام می‌گردد. بروزرسانی‌ها برای میان‌افزار ESB بر ادغام موجود تاثیر می‌گذارد. بنابراین تست‌های قابل توجهی برای هر بروزرسانی مورد نیاز است. به دلیل مدیریت مرکزی ESB تیم‌های برنامه خیلی زود در صف انتظار ادغام قرار می‌گیرند. بنابراین افزایش حجم ادغام‌ها، اجرا با قابلیت دسترسی بالا و بازیابی سخت سرورهای ESB سبب افزایش هزینه و دشواری چالش‌های فنی می‌گردد.چالش‌های بروزرسانی، نگهداری و مقیاس‌بندی یک ESB متمرکز طاقت‌فرسا و پرهزینه است که افزایش بهره‌وری را به تاخیر می‌اندازد.الگوی ESB با استفاده از طراحی ویژه ادغام شده در زمان اجرا و مجموعه‌ای از ابزارها پیاده‌سازی می‌شود که بهترین بهره‌وری ممکن را تضمین می‌کند.ابزارهای گذرگاه سرویس سازمانی (ESB)ابزارهای ESB مناسب می‌توانند به سازمان‌ها کمک کنند تا سرعت یکپارچه‌سازی برنامه را افزایش دهند و سریع‌تر وارد بازار شوند. در ادامه دو نمونه از ابزارهای ESB معرفی می‌شوند و بر اساس ویژگی‌ها و مزایای فنی بررسی می‌‌شوند.ESB Toolsابزار Mule ESBیک گذرگاه سرویس سازمانی مبتنی بر جاوا است و منبع باز است که توسط MuleSoft ارائه شده است و تعاملات داده و برنامه را انجام می‌دهد. توسعه‌ دهندگان ادغام‌های چند پروتکلی را بین سیستم و سرویس‌ها را روی ابر و در محل ایجاد می‌کنند. این معماری بسیار سبک و مقیاس‌پذیر است و می‌تواند تعاملات بین سیستم‌های قدیمی، برنامه‌های داخلی و تمام انتقال‌ها و پروتکل‌های مهم را مدیریت می‌کند. می‌توان در ابتدا برنامه کوچک را شروع کرد و در طول زمان برنامه‌های بیشتری را متصل کرد. ویژگی‌ها و مزایای آن عبارتند از:پروتکل صف‌بندی پیام پیشرفته: پشتیبانی بر اساس RabbitMQ که کلاینت جاوا هست، انجام می‌شود.مسیریاب‌ها: از مسیریاب‌ها برای تقسیم، ترکیب، مرتب‌سازی مجدد، ارزیابی و رساندن پیام‌ها استفاده می‌کند.اتصال‌دهنده Anypoint: پروتکل، پایگاه داده، انتقال و رابط‌های پایگاه داده از قبل ساخته شدند که در صورت نیاز می‌توان آن‌ها را ساخت.موتور زمان اجرای Mule: روی ابر یا در محل مستقر می‌شود.مدیر زمان اجرای Mule: امکان استقرار، نظارت و اشکال‌زدایی نمونه‌های Mule را فراهم می‌کند.Mule ESBابزار Red Hat JBoss Fuseچیزی بیش از درگاه سرویس سازمانی است و بخشی از یک راه حل یکپارچه‌سازی چابک است. یک پلتفرم یکپارچه منبع باز سبک است که در ابر یا در محل در دسترس است. بر اساس استانداردهای باز ساخته شده است و می ‌توان سرویس‌های یکپارچه را در صورت نیاز مستقر کرد. توسط جامعه بزرگی از توسعه‌دهندگان نسبت به تیم‌های کوچکی که کد منبع اختصاصی را نگهداری می‌کنند، تقویت شده است. این ابزار دارای ویژگی‌هایی است که عبارتند از:دارای یک واسط پیام منبع باز و سریع است که از JMS و کلاینت‌هایی با زبان‌های C و پایتون پشتیبانی می‌کند.دارای یک چارچوب منبع باز است که پیاده‌سازی‌های آزمایش شده و درست الگوهای یکپارچه سازمانی را فراهم می‌کند. همچنین سبب می‌شود تا از راه حل‌های از پیش موجود برای چالش‌های کد‌نویسی مرتبط با یکپارچه‌سازی سازمانی استفاده کنند.دارای یک چارچوب سرویس وب منبع باز است که برای ارتباط با استفاده از استانداردها و فرمت‌های مختلف استفاده می‌شود.دارای یک کانتینر زمان اجرا برای استقرار برنامه‌ها است و API محور است. خدمات را از هم جدا می‌کند تا بتوان به صورت مستقل ایجاد و مستقر کرد و گسترش داد.دارای یک ابزار ارکستراسیون برای استقرار میان‌افزارهای بزرگ است.RedHat Fuseشرکت‌های ایرانی فعال در حوزه ESBدر این بخش دو مورد از شرکت‌های ایرانی فعال در حوزه ESB و محصولات آن‌ها در زمینه ESB معرفی می‌گردند.شرکت داده پردازشرکت داده پرداز یک پلتفرم ESB به منظور یکپارچه‌سازی انواع سرویس‌ها در سازمان‌های بزرگ، مدیریت جریان اطلاعات در آن‌ها و مدیریت و تجمیع اطلاعات سرویس‌های یک سازمان را ارائه می‌دهد. ویژگی‌های اصلی این پلتفرم توانایی برقراری ارتباط با ماکروسرویس‌های بزرگ و برقراری جریان اطلاعات بین برنامه‌های کاربردی سازمانی و مدیریت آن‌ها است و مهم‌ترین ویژگی‌های آن توسعه‌پذیری و چابکی است. این پلتفرم به عنوان نرم‌افزاری مرکزی برای پردازش و ارائه اطلاعات در مجموعه‌های بزرگ می‌باشد. کاهش هزینه‌های توسعه و پشتیبانی از نرم‌افزار،‌ایجاد ارتباط و بهینه‌سازی سیستم‌ها، افزایش بهره‌وری سازمان‌ها، امکان اتصال به انواع وب سرویس‌ها و پایگاه‌های داده و پشتیبانی ازتعداد زیادی کاربر به طور هم‌زمان از دیگر ویژگی‌های پلتفرم ESB شرکت داده پرداز است.شرکت فناوری اطلاعات ایرانیانشرکت فناوری اطلاعات ایرانیان محصولی به نام گذر به عنوان بستر تبادل سرویس سازمانی برای یکپارچه‌سازی و مدیریت ارتباطات بین سازمانی و درون سازمانی را ارائه می‌دهد. از جمله امکانات سامانه ESB گذر عبارتند از:ایجاد API روی سامانه‌های قدیمی یا غیرقابل تغییر و یا اصلاح ساختاری یا تبدیل فنی بر روی APIهای موجود این سامانه‌هاترکیب میکروسرویس‌های مختلف و ایجاد یک وب ‌سرویس جدیدبرقراری و مدیریت ارتباط با سازمان‌های بالادستی و یا همکارامکان انطباق‌پذیریمدیریت ارتباطات آسنکرونکنترل دسترسی در سطح ارتباطات سیستمیحسابرسی دسترسی‌های انجام شده در سطح ارتباطات سیستمی ( بر اساس SLA تعریف ‌شده با بهره‌بردار)پایش صحت عملکرد واسط‌های سامانه‌های اطلاعاتیشمای کلی سامانه گذرجمع‌بندیدر این مقاله ابتدا در بخش اول به معرفی و بررسی گذرگاه سرویس سازمانی (ESB) در حوزه معماری نرم‌افزار و توسعه زیرساخت نرم‌افزار پرداخته شد و سپس در بخش دوم دو مورد از ابزارهای مورد نیاز برای ایجاد گذرگاه سرویس سازمانی (ESB) و زیرساخت مناسب معرفی شدند و در پایان نیز دو مورد از شرکت‌های ایرانی فعال در حوزه ارائه خدمات مربوط به گذرگاه سرویس سازمانی (ESB) به همراه محصولاتی که ارائه می‌دهند معرفی و بیان گردید.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابع و مراجع: https://searchapparchitecture.techtarget.com/definition/Enterprise-Service-Bus-ESB https://en.wikipedia.org/wiki/Enterprise_service_bus https://rapidapi.com/blog/enterprise-service-bus/?utm_source=google&utm_medium=cpc&utm_campaign=DSA&gclid=Cj0KCQiA2NaNBhDvARIsAEw55hikDVsC9JxqC4Dhh7IUy5etNSIzAfMNFYkGDkAYaI6wtvLTI0av1dAaAvSxEALw_wcB https://www.oreilly.com/library/view/enterprise-service-bus/0596006756/ch01.html https://www.ibm.com/cloud/learn/esb https://www.mulesoft.com/resources/esb/what-mule-esb https://en.wikipedia.org/wiki/Mule_(software) https://shadow-soft.com/enterprise-service-bus-esb-tools/ https://dadehpardaz.com/esb https://www.iritco.ir/gozar-esb/ شیما سیف الهی شیما سیف الهی Fri, 24 Dec 2021 22:16:52 +0330 https://virgool.io/@shimaseyfollahi/%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-%DA%A9%D8%B3%D8%A8-%D9%88-%DA%A9%D8%A7%D8%B1-bpms-gn4sahjliqeh سیستم مدیریت فرایند کسب و کار (BPMS) چیست؟سیستم مدیریت فرایند کسب و کار در واقع Business Process Management System یاBusiness Process Management Software است. BPMS یا iBPMS که BPMS هوشمند است، ابزاری برای اجرای متدلوژی مدیریت برای بهبود فرایندهای کسب و کار یک سازمان از طریق شناسایی، مدل‌سازی، خودکارسازی، تحلیل و اندازه‌گیری مدیریت است و بخشی از مدیریت فرایند کسب و کار (BPM) است که امکان برنامه‌ریزی مؤثر و نظارت بر عملکرد فعالیت‌های مختلف در محیط‌های تجاری را فراهم می‌کند. کسب و کارها برای همگام شدن با خواسته‌های مدرن و محیط‌های تجاری در حال تغییر به خودکارسازی فرایندها نیاز دارند. این عملیات درباره مدیریت فرایندهای مختلف هستند و پایه‌های تضمین گردش کار ساده و کارآمد است به رشد هر سازمانی کمک می‌کند. BPMS سبب افزایش بهره‌وری سازمان می‌گردد.سیستم مدیریت فرایند کسب و کار به تعریف گردش کار و ایجاد فرایندها برای وظایف با هر پیچیدگی برای خودکارسازی عملیات در چندین بخش کمک می‌کند. پلتفرم‌های BPM فناوری اصلی برای سازمان‌هایی که در حال تغییر دیجیتال هستند فراهم می‌کند و چرخه تحول، نوآوری و انطباق را تسریع می‌کند. قبل از خودکارسازی جریان کار فرایندها باید مستند شوند و نیاز به برنامه‌ریزی و همکاری و همچنین ابزاری برای نمایش نحوه ظهور فرایندها دارد. مدل‌های فرایند کسب و کار می‌توانند در BPMS با روش‌های مختلف ایجاد شوند. تغییرات مکرر در فرایندهای کسب و کار برای بازارهایی با محیط رقابتی بالا رایج هستند. انواع مختلف روش‌ها و راه حل‌های نرم‌افزاری وجود دارند که سبب تنظیم فرایندها برای مطابقت با شرایط تجاری در حال تغییر پویا می‌گردد. امروزه فرایندها اغلب از کلاس جدیدی از سیستم‌ها و راه حل BPMS استفاده می‌کنند. BPMSها یک رویکرد فرایند محور برای مدیریت شرکت اعمال می‌کنند و سبب خودکارسازی فرایند کسب و کار end-to-end و تغییر سریع در صورت نیاز می‌شوند. مدل‌های فرایند را می‌توان با روش‌های مختلف یا به فرمت‌های مختلف منتشر کرد.Business Process Management Systemمتدلوژی BPMنرم‌افزار BPM ابزاری برای اجرای یک متدلوژی مدیریتی جدید به نام BPM (Business Process Management) است که بخش تکنولوژی آن است. BPM ترکیبی از ایدئولوژی و نرم‌افزار برای مدیریت فرایند کسب و کار است و در سازمان‌ها برای تشخیص، مستندسازی و بهبود سایر فرایندهای کسب و کار استفاده می‌شود که نرم‌افزار برای فعال‌سازی سایر جنبه‌های BPM مورد استفاده قرار می‌گیرد. با تفکیک BPM به ماژول‌های مختلف، مدیریت منابع موجود آسان‌تر است. این رویکرد برای اولین بار در سال 2000 ارائه شد و جایگزین مهندسی مجدد فرایند کسب و کار شد که بسیار پیچیده بود و شامل فرایندهای بازاندیشی اساسی و بازسازی بنیادی بود. BPM تشویق می‌کند تا افراد از یک رویکرد عملکردی در مدیریت شرکت دور شوند و به سمت تفسیری به عنوان مجموعه‌ای از فرایندهای کسب و کار بیایند. برخلاف مهندسی مجدد BPM به معنای بهبود مستمر فرایندهای کسب و کار است و مفهوم آن مبتنی بر اصل تعامل نزدیک در تیم با سخت‌افزار و سایر سیستم‌ها هست.ویژگی‌های BPMSابزار بصری رسم نمودار فرایند: مهم‌ترین ویژگی در ‌BPMS است. چهار دسته ابزار برای مدل‌سازی BPMS وجود دارد:بدون ابزار مدل‌سازی: برای پیاده‌سازی فرایند از کدگذاری استفاده می‌کنند.داده‌های جمع‌آوری شده از طریق فرم‌های رابط کاربری: اطلاعات مربوط به فرایند کسب و کار از طریق فرم‌ها ثبت و جمع‌آوری می‌شوند.رابط بصری مبتنی بر فعالیت: کل فرایند شامل مدیریت طرد و استثنا را در هر مرحله ترسیم می‌کند.رابط بصری مبتنی بر مراحل کسب و کار: امکان تمرکز بر روی مسیر اصلی فرایند کسب و کار را برای کاربر فراهم می‌کند و نرم‌افزار مسیرهای استثنا را به صورت خودکار مدیریت می‌کند.کنترل دستی بر اساس نقش: دسترسی ممکن است شامل ایجاد یک فیلد قابل ویرایش، خواندنی یا کاملا پنهان باشد. برای کنترل دستی باید شرایطی برقرار باشند که عبارتند از:محدود کردن دسترسی به بخش خاصی از فرم برای افرادی خاصدادن دسترسی یک بخش خاص به کل یک گروه بدون وارد کردن نام آن‌هانمایش فیلدهای خاصی بر اساس داده‌های نشان داده شده در فیلدهای دیگردسترسی به موارد فوق در همه مراحل فرایندهای کسب و کارپشتیبانی از موبایل: یک BPMS ابری عملکردهای کاملی را برای کاربران موبایل ارائه می‌دهد.ویژگی‌های قدرتمند مدیر: امکان مدیریت و ویرایش فرایند و فرم‌ها، تخصیص مجدد وظایف فردی، تخصیص انبوه، حذف موارد و انتقال موارد به حالت کامل را ایجاد می‌کند.ورود واحد (Single Sign-On): SSO سبب می‌شود تا کاربر بتواند با یک مجموعه از گواهی‌نامه‌ها به چندین پلتفرم نرم‌افزار مستقل وارد شود و سبب دسترسی و ردیابی فعالیت‌ها می‌گردد.یکپارچه‌سازی با سیستم‌های نرم‌افزاری موجود: بدون قابلیت ادغام انتقال داده‌ها به صورت دستی فواید خودکارسازی را از بین می‌برد.گزارش‌ها و تحلیل‌ها: گزارشات باید شامل اطلاعاتی باشند:میانگین زمان برای تکمیل مراحل جداگانه و کل مواردتصویر لحظه‌ای از موارد باززمان‌هایی که موارد رد می‌شوند یا تغییر مسیر داده می‌شوند.عملکرد برای پایگاه‌های کاربر بزرگ: عملکرد نرم‌افزار در زمانی که تعداد مشتریان کم هستند با زمانی که تعداد مشتریان زیاد هستند، متفاوت است و باید نرم‌افزار پتانسیل تعداد مشتریان موجود در سیستم را داشته باشد.معیارهای عملکرد فرایند: به شرکت‌ها کمک می‌کنند تا مسائل مربوط به یک فرایند را شناسایی کنند و تصمیمات معناداری را برای بهبود فرایند ناکارآمد بگیرد. این معیارها به صورت خودکار داده‌های سیستم را ثبت و جمع‌آوری می‌کنند و توسط مدیر فرایند ارزیابی می‌شود تا علت مشکل که مدل‌سازی یا اجرای فرایند ضعیف هست، مشخص شود.همکاری: فرایندها به بحث‌های متنی، اشتراک‌گذاری یادداشت‌های جلسه و سایر ارتباطات در محل کار نیاز دارند. همکاری مکالمات را فشرده و متمرکز می‌کند و سبب بهبود فرایند و بهینه‌سازی اطلاعات در کل تیم می‌گردد.ویژگی‌های BPMSنحوه کار BPMSتعریف فرایند و تحلیل‌ها: یک فرایند دنباله‌ای از فعالیت‌هایی است که برای رسیدن به یک نتیجه خاص اجرا می‌شوند. قبل از خودکارسازی جریان کار، فرایند به مستندسازی نیاز دارد. فرایند مستندسازی مستلزم همکاری و برنامه‌ریزی بین ذی‌نفعان برای تعیین کارآمدترین و مناسب‌ترین عملیات برای انجام یک وظیفه است. جریان فرایند کسب و کار را می‌توان در یک سیستم مدیریت فرایند کسب و کار باز‌آفرینی و توسط کارکنان مربوطه و ذی‌نفعان بازبینی کرد تا اطمینان حاصل شود که تصویر مؤثری از فرایند به دست می‌آید.طراحی فرایند: سیستم Creatio از قابلیت‌های اولیه BPMS استفاده می‌کند و امکان همگام‌سازی مدیریت وارد کم مصرف و پویا را فراهم می‌سازد. برای ساخت فرایند در یک سیستم Creatio، کاربر نیاز به یک ابزار طراحی فرایند دارد. ابزارهای که توسط طراحان برای مدل‌سازی فرایند کسب و کار استفاده می‌شوند، به صورت فلوچارت‌ها و دیاگرام‌هایی نمایش داده می‌شوند. یک مجموعه از قوانین و عناصر که برای مدل‌سازی فرایند استفاده می‌شود، آن را انعطاف‌پذیر می‌کند. مزیت مدل‌سازی فرایندهای کسب و کار شرکت در BPMS این هست که این فرایندها به سادگی مستند نشدند ولی تست شدند و سبب می‌شود تا قبل از اجرای زنده، نقاط ضعف را ترمیم کنند.خودکارسازی: خودکارسازی سب می‌شود تا فرایند با کمترین مداخله انجام شود. خودکارسازی جریان کار به کسب و کار کمک می‌کند تا فرایندها بهتر مدیریت و بهینه شوند. ایجاد خودکارسازی شامل مونتاژ اقدامات و وظایف و وارد کردن مکانیزم‌های ورودی مورد نیاز برای شبیه‌سازی رفتار و نتیجه یک فرایند تجاری است. کارهایی احتمالا خودکارسازی می‌شوند که به طور مکرر تکرار می‌شوند، کارهای تکراری معمولی در عملکرد روزانه کارکنان که از طریق یک فرایند خودکار سریع‌تر تکمیل می‌شوند. جنبه اصلی فرایند خودکارسازی تخلیه کردن تعداد زیادی از کارهای معمولی و تکراری مربوط به عملکردهای روزانه کارکنان سیستمی هست که با قوانین تجاری و محرک‌های خودکار با تعامل انسانی خودکار با کمک یک موتور جریان کار برنامه‌ریزی شده است.تحلیل‌ها: ابزارهای BPMS سطوح متعدد گزارش یا قابلیت یکپارچه‌سازی با ابزارهای گزارش‌گیری برای ارائه تحلیل‌ها در مورد عملکرد فرایند را ایجاد می‌دهد. گزارش‌ها به شاخص‌های کلیدی عملکرد (KPI) متصل هستند و داده را برای اثربخشی فرایندها، عملکرد اقدامات فردی، فرایندها، اعضای تیم، تیم‌ها و ... را فراهم می‌کند. تحلیل‌های داده می‌توانند گلوگاه فرایند را شناسایی کنند و به تعیین ناکارآمدی‌های عملیاتی برای بهبود فرایندها و عملیات در حال پیشرفت، کمک کنند.مزایای BPMSمزیت مهم و کلیدی BPMS این هست که کاربران می‌توانند در بهبود فرایندهای کسب و کار از طریق ابزار ساده و مشهود، مشارکت کنند. این مزایا به دلیل سه مؤلفه امکان‌پذیر است که عبارتند از: ابزار ساخت فرایند، اجرای آن‌ها (پلتفرم) و نظارت (کتابخانه فرایند)با استفاده از BPMS می‌توان مراحل فرایند دستی را برای کاهش نرخ‌های خطا حذف کرد.با استفاده از BPM می‌توان فرایندها را تسریع کرد و در عین حال هزینه‌ها را کاهش داد و در پول صرفه جویی می‌شود زیرا استفاده از ابزار به صورت بهینه است.با ارائه بینش بیشتر از طریق تجزیه و تحلیل‌ها و داشبوردهای بلادرنگ، یک BPMS عالی می‌تواند سبب شناسایی گلوگاه‌ها شود و از مشکلات در پایین دست جلوگیری می‌کند.زمان ذخیره شده است و به تنظیم سریع فرایندها در تغییرات محیط تجاری کمک می‌کند. کارها سریع‌تر پیش می‌روند، زیرا هر بار نیاز به زمان فکر کمتری برای کار بعدی وجود دارد.تحویل دادن و جایگزینی بی‌کاری به دلیل مستندات کار بهینه آسان است.یک BPMS قوی می‌تواند به تحول سازمان با چابکی بیشتر کمک کند.سبب بهبود کیفیت کار می‌شود زیرا مراحل نادیده گرفته نمی‌شوند و میانبرها برداشته نمی‌شوند.رضایت کارکنان افزایش می‌یابد زیرا همه افراد نقش خود را درک می‌کنند.خلاقیت و بهبود فرایند، رشد می‌کند زیرا افراد از تمرکز بر روی مراحل فرایند کوچک، آزاد هستند. به جای آن می‌توانند بر روی ایده‌های تصویر بزرگ تمرکز کنند.عملکرد بهبود می‌یابد زیرا می‌توان مراحل را به راحتی ردیابی و اندازه‌گیری کرد.کار از نظر دیجیتالی و فیزیکی ایمن‌تر است، زیرا بررسی‌های امنیتی و اعلان‌های نقض را می‌توان مستقیما در فرایندها برنامه‌ریزی کرد.مدیریت تغییر آسان شده است زیرا می‌تواند به وضوح تاثیرات آن را مشاهده کرد و گاهی اوقات در پشت صحنه به وقوع می‌پیوندند.ابزارهای BPMSاز ابزارهای BPMS برای خودکارسازی وظایف در طول یک فرایند کسب و کار استفاده می‌شود. BPM یک فعالیت ثابت است که به فرایندی مداوم نیاز دارد. این ابزارها نظم، ادراک، عملکرد کل گردش کار را که فرایند کسب و کار را تشکیل می‌دهد، بهبود می‌بخشد، آشفتگی را در گردش کار کسب و کار از بین می‌برد، امکان مشاهده کامل فرایند کسب و کار و توجه ویژه به خطاها را فراهم می‌کنند و سبب افزایش کارایی در کار و صرفه‌جویی در منابع می‌شوند. در ادامه دو مورد از ابزارهای مورد استفاده در زمینه BPMS معرفی و بررسی می‌گردند.ابزار BPMSابزار IBMBlueworks Liveبهترین ابزار BPMS برای useability است و یک نرم‌افزار مدیریت گردش کار مبتنی بر ابر است. با استفاده از drag and drop می‌توان نقشه فرایند را به سرعت و به آسانی ایجاد کرد و مرتب‌سازی کرد. یک راه حل نرم‌افزاری برای مستندسازی، ایجاد و بهبود و خودکارسازی گردش کار از طریق رسم فرایند است، می‌توان فرایندهای کسب و کار را به صورت بصری کشید، مالکان را به خطوط و مسیرهای مختلف انتساب داد و جزئیات را در مراحل مختلف فرایند قرار داد. همچنین می‌توان به بیش از 200 پروژه تجاری قالب‌های گردش کار دسترسی داشت که می‌توان آن را به روش مورد نظر سفارشی کرد و تغییر داد. سایر افراد تیم یا افراد خارج از تیم می توان نقشه‌های فرایند را از داشبورد Blueworks ویرایش و بررسی کنند.این ابزار دارای drag and drop برای ایجاد نقشه فرایند، قالب‌های شروع، آموزش‌های تعبیه شده، همکاری بلادرنگ، کار در فضای مشترک و به صورت هم‌زمان، کنترل همه موارد، دسترسی آسان و گسترده به دلیل بستر ابری، یک مخزن فرایند تجاری متمرکز و ... هست. Blueworks معیارهای ارزیابی را برآورده می‌کند زیرا بسیار ساده و مشهود استقرار را انجام می‌دهد. در شروع کار می‌توان از کارهای اساسی مانند ثبت و ساختن فرایند با کشف نقشه ساده استفاده کرد. یکپارچه‌سازی سیستم با مجموعه‌ای گسترده از APIها از طریق Blueworks امکان‌‌پذیر است. از APIهای مختلف REST برای دریافت داده یا انتقال داده به Blueworks Live برای ایجاد یکپارچه‌سازی‌های مختلف استفاده می‌شود. یکی از مزایای این ابزار این هست که دارای قابلیت سفارشی بیشتر برای رنگ خطوط و قرار دادن جعبه‌ها هست. یکی از اشکالات Blueworks این هست که برای جا به جایی خطوط و اتصالات برای تجسم اطراف، به اندازه سایر برنامه‌های مشابه ماهر نیست.IBMBlueworks Liveابزار K2 Platformبهترین پلتفرم برای امنیت، نظارت و مدیریت است. با استفاده از drag-and-drop طراح امکان ترکیب منطق با فرایندهای مختلف مدیریت را برای کاربران فراهم می‌کند. با استفاده از این ابزار می‌توان گردش کار و خودکارسازی فرایند را به صورت پیچیده و در سطح بالا انجام داد. همچنین دارای امکان drag and drop برای ایجاد گردش‌های کار، به دست آوردن بینش بلادرنگ، استفاده و استفاده مجدد از شکل‌هایی با ویژگی غنی، ویژگی‌های مدیریتی، نظارتی و امنیتی جامع و ... است. K2 Platform می‌تواند با پلتفرم‌های مختلف بسیاری قابلیت یکپارچه‌سازی دارد. نصب و استقرار این ابزار دارای تاخیرهایی است. یکی از مشکلات مهم و قابل توجه این ابزار این هست که مقدار زمان مورد نیاز برای راه‌اندازی و اجرای آن، بسیار کمتر از آن هست که افراد در مورد چیزی که یادگیری آن یک منحنی شیب‌دار است، آموزش ببینند.K2 Platformشرکت‌های ایرانی فعال در حوزه BPMSدر این بخش دو مورد از شرکت‌های فعال ایرانی در حوزه‌ BPMS به همراه محصولات آن‌ها در زمینه BPMS معرفی می‌شوند.شرکت آرمان دنیای فناوری اطلاعات تتیسشرکت تتیس با هدف رفع مشکلاتی مانند هزینه‌های سنگین مالی و زمانی، هزینه‌ در جهت تولید، نگهداری و مجتمع‌کردن با دیگر نرم‌افزارهای موجود به سازمان سيستم يكپارچه مديريت فرآيندهاي تتيس را تولید می‌کند. سيستم مديريت فرآيند‌هاي كسب و كار تتيس، خانواده‌اي يكپارچه از محصولات نرم‌افزاري سازماني به هم مرتبط هستند كه سازمان را قادر به تعريف، طراحي، مدل‌سازي، اجرا و مديريت فرآيند‌هاي كسب و كار مي‌نمايند. اين سيستم، ابزارهايی را ارائه مي‌دهد كه با كمك آن مي‌توان فرآيند‌هاي كسب و كار را خودكار کرد و در صورت لزوم و با هزينه اندك زماني و مالی، فرآيندهاي سازماني را با نيازهاي جديد منطبق نمود. از جمله قابلیت‌های سیستم مدیریت فرآیند عبارتند از:امکان تعریف پروژه‌ها و سامانه‌های مختلف در سیستمامکان تعریف و مدیریت جداول و فیلدهاامکان طراحی و مدیریت گردش کارها و فرآیندهاامکان طراحی فرم ها به صورت WYSIWYGامکان طراحی گزارش‌های جدولی و نموداری با استفاده از ابزار گزارش‌سازامکان طراحی انواع قالب‌های گرافیکیامکان تعریف نقش‌های مختلف و کارتابل متناسب با آنشرکت فراگسترنرم‌افزار مدیریت فرایند فراگستر در کنار امکانات اتوماسیون اداری پایه، سبب می‌شود تا سریع و ساده تمامی فرم‌ها و فرآیندهای سازمان که مکررا توسط شخص یا تیم مشخصی اجرا می‌شوند، به صورت الکترونیکی باشند که سبب کاهش خطای انسانی و پاسخ‌دهی سریع به نیازهای مورد تقاضای ذینفعان می‌شود. این محصول امکان تعریف، بهبود، مدلسازی و طراحی فرم‌ها، مدیریت و کنترل جریان گردش فرایندها در سازمان را با حداقل دانش برنامه نویسی در یک محیط بصری گرافیکی و به صورت استاندارد وکاملا تحت وب و بدون نیاز به نصب نرم‌افزار سمت کلاینت به راحتی در اختیار کاربران قرار می‌دهد. قابلیت‌های برتر BPMS فراگستر عبارتند از:یکپارچگی با اتوماسیون اداری فراگستر: این یکپارچگی در چندین نقطه از نرم‌افزار صورت گرفته که از جمله این موارد می‌توان به فراخوانی کاربران و چارت سازمانی، گزارشات یکپارچه، کارتابل تحت وب جریان کار، تعیین جانشین و … اشاره کرد.انعطاف‌پذیری بسیار بالا: به دلیل متن‌باز بودن نرم‌افزار، به راحتی قابلیت توسعه و سفارشی‌سازی دارد و انعطاف بسیار بالایی برای سازمان‌های مختلف ایجاد می‌نماید تا طبق سیاست‌های سازمان خود فرایندها را طراحی و مدیریت نمایند.طراحی فرایند با حداقل دانش برنامه‌نویسی: راهبران مدیریت فرایند سازمان مشتری با استفاده از قابلیت Drag & Drop می‌توانند به راحتی المان‌های مختلف برای رسم مدل فرایند را بر روی صفحه قرار داده و تنها با چند کلیک مدل فرایندی خود را بسازند.تعیین جانشین برای کارتابل جریان کار: کاربران این محصول، می‌توانند در سیستم اتوماسیون اداری برای بخش فرایندهای خود، در تاریخ معینی جانشین تعریف کنند تا در صورت عدم حضور خود در سازمان جانشین آن‌ها جریان‌های کاری را ایجاد و یا پیگیری نماید.جمع‌بندیدر این مقاله ابتدا در بخش اول به معرفی و بررسی سیستم مدیریت فرایند کسب و کار (BPMS) در حوزه معماری نرم‌افزار و بهبود و یکپارچگی فرایندهای توسعه نرم‌افزار در سازمان‌ها پرداخته شد و سپس در بخش دوم دو مورد از ابزارهای مورد نیاز برای ایجاد سیستم مدیریت فرایند کسب و کار (BPMS) و پکپارچگی فرایندهای سازمان و رفع مشکلات موجود معرفی شدند و در پایان نیز دو مورد از شرکت‌های ایرانی فعال در حوزه ارائه خدمات مربوط به سیستم مدیریت فرایند کسب و کار (BPMS) به همراه محصولاتی که ارائه می‌دهند معرفی و بیان گردید.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابع و مراجع: https://www.creatio.com/page/bpms https://www.integrify.com/what-is-bpms/ https://www.cflowapps.com/process-management-system/ https://www.softwareag.com/en_corporate/resources/what-is/bpms.html https://kissflow.com/workflow/bpm/business-process-management-systems-top-features/ https://bpmapp.com/bpm-tools https://www.adamenfroy.com/bpm-software https://thedigitalprojectmanager.com/bpms-bpm-software/ http://www.tetis.ir/bpms.html https://www.faragostar.net/automation/bpms/ شیما سیف الهی شیما سیف الهی Fri, 24 Dec 2021 22:15:04 +0330 https://virgool.io/@shimaseyfollahi/%D8%AF%D8%B1%DA%AF%D8%A7%D9%87-%D8%B1%D8%A7%D8%A8%D8%B7-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-api-gateway-mrzrc3gjfif5 دروازه API چیست؟یک دروازه API یک الگوی نرم‌افزاری و ابزار مدیریت API است که بین یک client و مجموعه‌ای از سرویس‌های back end قرار می‌گیرد. به عنوان یک proxy معکوس عمل می‌کند تا همه فراخوانی‌های رابط‌ برنامه‌نویسی برنامه (API) را بپذیرد، سرویس‌های مورد نیاز برای انجام آن‌ها را جمع‌آوری کند و نتایج مناسب را برگرداند. با افزایش اهمیت یکپارچگی و اتصال به یکدیگر، اهمیت دروازه‌های API‌ هم بیشتر می‌شود. افزایش پیچیدگی APIها و افزایش رشد آن‌ها سبب افزایش اهمیت دروازه‌های API می‌گردد. دروازه API در مقابل رابط برنامه‌نویسی برنامه (API) یا گروهی از میکروسرویس‌ها قرار می‌گیرد تا تسهیل درخواست‌ها و تحلیل داده‌ها در سرویس‌ها را تسهیل کند.یک دروازه API از DevOps و محیط‌های بدون سرور پشتیبانی می‌کند. در سازمان‌هایی که از رویکرد DevOps استفاده می‌کنند، توسعه‌ دهندگان از میکروسرویس‌ها برای ایجاد و استقرار برنامه‌ها به صورت سریع و تکراری استفاده می‌کنند. همچنین توسعه ابر مدرن از جمله مدل‌های بدون سرور به APIها برای تامین زیرساخت بستگی دارد. بنابراین می‌توان توابع بدون سرور را مستقر کرد و با استفاده از یک درگاه API آن را مدیریت کرد.API Gatewayنحوه انجام کار API Gatewayسبب می‌شود تا برنامه‌های مجزا با یکدیگر ارتباط برقرار کنند و داده‌ها را در بیرون و داخل یک کسب و کار منتقل می‌کنند. همچنین یک نقطه کانونی و رابط استاندارد برای انجام این فعالیت‌ها، پیام‌رسانی API، سازماندهی و تسهیل فرایند API فراهم می‌کند. درخواست‌ها را از منابع داخلی و خارجی دریافت می‌کند که فراخوانی‌های API نام دارند و چندین درخواست را بسته‌بندی می‌کند و ‌آن‌ها را به API یا APIهای مناسب هدایت می‌کند و پاسخ‌ها را به کاربر یا دستگاهی که درخواست را ارسال کرده بود، تحویل می‌دهد.دروازه API سایر عملکردهای مرتبط با APIها و میکروسرویس‌ها شامل تفسیر پروتکل، کشف سرویس، منطق پایه کسب و کار، احراز هویت و اجرای سیاست های امنیتی، نرخ محدودیت، مسیریابی، آمارها، تثبیت و تعادل بار، مدیریت cache، صدور صورت حساب، نظارت، تجزیه و تحلیل، هشدارها و ثبت و تحلیل رخدادها برای تجزیه و تحلیل فراخوانی‌ها و پاسخ‌ها برای اطمینان از امنیت و ارزیابی خطاها را مدیریت می‌کند. همچنین API Gateway کلیدی برای معماری مبتنی بر میکروسرویس است که در آن درخواست‌های داده در واقع برنامه و سرویس‌های متعددی را که در چند API مجزا مورد استفاده قرار می‌گیرند، فراخوانی می‌کنند.دلایل استفاده API Gatewayبیشتر APIهای سازمانی از طریق دروازه‌های API مستقر می‌شوند. در ابتدایی‌ترین حالت یک سرویس API یک درخواست از راه دور را می‌پذیرد و پاسخی را برمی‌گرداند. اما در واقعیت به این سادگی نیست و باید نگرانی‌های مختلف در هنگام host کردن APIهای بزرگ مقیاس در نظر گرفت. در ادامه تعدادی از دلایل استفاده از API Gateway معرفی می‌گردند.می‌توان از APIها در برابر استفاده بیش از حد و سوء استفاده محافظت کرد. بنابراین می‌توان از سرویس‌های احراز هویت و محدودیت نرخ استفاده کرد.با استفاده از ابزارهای تجزیه و تحلیل آن می‌توان نحوه استفاده افراد از APIها را دریافت.برای استفاده از APIهای پولی باید به یک سیستم صدور صورت حساب متصل شد.در صورت استفاده از یک معماری میکروسرویس، یک درخواست نیازمند فراخوانی ده‌ها برنامه متمایز است.با گذشت زمان تعدادی از سرویس‌های API جدید را می‌توان اضافه کرد و می‌توان برخی دیگر را کنار گذاشت، ولی مشتریان تمایل دارند که همه سرویس‌ها در همان مکان پیدا کنند.چالش توسعه ‌دهندگان ارائه یک تجربه آسان و قابل اعتماد به مشتریان در برابر پیچیدگی‌ها است. یک API gateway راهی برای جداسازی رابط مشتری از پیاده‌سازی back end است. هنگامی که مشتری درخواستی را می‌دهد، API gateway آن را به چند درخواست تقسیم می‌کند سپس آن‌ها را به مکان‌های درست هدایت می‌کند، پاسخی را تولید می‌کند و همه چیز را پیگیری و ردیابی می‌کند.نقش API Gateway در API Managementیک دروازه API بخشی از سیستم مدیریت API است. یک دروازه API تمام درخواست‌های دریافتی را جدا و رهگیری می‌کند و آن‌ها را از طریق سیستم مدیریت API ارسال می‌کند که انواع توابع ضروری را مدیریت می‌کند. کاری که API gateway انجام می‌دهد، از یک اجرا به اجرای و از یک پیاده‌سازی به پیاده‌سازی دیگر متفاوت است. نقش اصلی آن این هست که به عنوان یک نقطه ورودی و فرایند استاندار شده برای تراکنش‌ها بین برنامه‌های یک سازمان‌، داده‌ها و سرویس‌ها، میکروسرویس‌ها و اعمال سیاست‌ها برای تشخیص دسترس‌پذیری و رفتار آن‌ها و مشتریان داخلی و خارجی عمل می‌کند. API gateway می‌تواند عملکردهای مختلفی را برای پشتیبانی و مدیریت استفاده از APIها انجام دهد.معماری APIشبیه به طراحی API است که روی نحوه ایجاد API، نتیجه و نحوه اجرای آن تمرکز دارد. معماری API کل فرایند و متدلوژی برای اجرا و افشای APIها را تعریف می‌کند. این معماری شامل دروازه API که خود دارای نحوه امنیت API، حافظه نهان و تنظیمات مربوط به کار هست، توسعه یک پورتال API برای تحلیل API، مستند API، APIهای بازاریابی، ایجاد اطمینان از کار با برنامه‌های موبایل و وب و تعریف نحوه قرار گرفتن آن‌ها در معرض توسعه دهندگان داخلی، شریک و سوم شخص است. دروازه API می‌تواند سربار احراز هویت یک فراخوانی API را از خارج مدیریت کند. سپس تمام فراخوانی‌های داخلی سبب حذف چک‌های امنیتی را حذف می‌کنند. اگر درخواست از داخل VPC بیاید، می‌تواند بررسی امنیت را حذف کند، تاخیر شبکه را کمی کاهش می‌دهد و سبب می‌شود که توسعه دهندگان بیشتر روی منطق کسب و کار نسبت به نگرانی‌های امنیتی تمرکز کنند.معماری API Gatewayکاربران API Gatewayمدیریت و نظارت توسط دروازه API‌ سبب می‌شود تا به جای تلاش برای ردیابی و مدیریت APIها به صورت مجزا در واقع کسب و کار بتواند دامنه وسیعی از APIها و ادغام‌ها را به صورت متمرکز ببیند و کنترل کند. کاربران و استفاده‌کنندگان از درگاه API عبارتند از:مدیران خط مشی از عبارات منطقی استفاده می‌کنند که از طریق یک API gateway برای تشخیص در دسترس پذیری و رفتار APIها عمل می‌کند. نحوه کنترل جریان داده و کاهش فراخوانی‌ها و توان عملیاتی فراخوانی APIها از جمله این کارها هستند.سازمان‌هایی که یک معماری مبتنی بر میکروسرویس را می پذیرند، به API gateway برای تسهیل ارتباطات بین این سرویس‌ها نیاز دارند و میکرو سرویس می‌تواند روی منطق کسب و کار تمرکز کند.دروازه API به ساده‌سازی یکپارچه‌سازی B2B به عنوان جایگزینی برای رویکردهای قدیمی مانند سرویس‌های تبادل داده الکترونیکی کمک می‌کند.پلتفرم API Gateway به عنوان زیرساختچالش‌های API Gatewayدروازه API به عنوان درواز‌ه‌بانی بین مشتریان API و ارائه‌ دهندگان API است. این نقش گسترده دارای چالش‌های منحصر به فردی است که در ادامه بررسی می‌گردند.قابلیت اطمینان و انعطاف‌پذیری: هر مانع یا اختلالی در عملکرد درگاه‌های API ممکن است باعث خرابی سرویس‌های مرتبط شود. سازمان‌ها باید در مورد اضافه کردن ویژگی‌هایی که بر روی عملکرد تاثیر می‌گذارند محتاط باشند. همچنین به ویژه API gateway یک مرحله فرایند اضافه بین مشتریان و برنامه‌ها یا داده را نمایش می‌دهند.امنیت: API gateway یک منبع قابل اعتماد است که بسیاری از زوایای کسب و کار یک شرکت را حس در نظر می‌گیرد که اگر در معرض خطر قرار گیرد،‌یک مشکل امنیتی گسترده و جدی است. کسب و کارها باید به دقت رابط‌های خارجی را از APIها و سیستم‌های داخلی جدا کنند و پارامترهای احراز هویت و مجوز را تعریف کنند.پیچیدگی و وابستگی‌ها: هر زمانی که یک API یا میکرو سرویس اضافه یا حذف می‌شود یا تغییر می‌کند،‌ توسعه دهندگان باید درگاه API را بروزرسانی کنند که در مدلی چالش برانگیز هست که تعدادی برنامه به ده‌ها یا صدها میکروسرویس تبدیل می‌شوند. ایجاد و پیروی از قوانین طراحی API و میکروسرویس‌ها به کاهش این مشکلات کمک می‌کنند.مزایای API Gatewayمزیت اصلی API Gateway این هست که سرویس‌ها را از طریق APIها یا میکروسرویس‌ها استاندارد و متمرکز می‌کند. همچنین به امنیت و سازماندهی یکپارچه‌سازی مبتنی بر APIها به روش‌های متعدد کمک می‌کند. در ادامه تعدادی از مزایای دروازه API معرفی می‌گردند.ساده‌سازی ارائه خدمات: درگاه‌‌های API می‌توانند چندین API فراخوانی شده برای درخواست و بازیابی داده‌ها و سرویس‌ها ترکیب کنند که حجم درخواست‌ها و ترافیک را کاهش می‌دهد. فرایند API را ساده می‌کند و رابط کاربری را به ویژه برای موبایل و برنامه‌های کاربردی بهبود می‌دهد. همچنین client می‌تواند همه داده‌ها را یکباره دریافت کند و نتایج مورد نیاز و مناسب مشتری را ارائه می‌دهد.ایجاد انعطاف‌پذیری: درگاه‌های API بسیار قابل پیکربندی و قابل تنظیم هستند. توسعه‌ دهندگان می‌توانند ساختارهای داخلی برنامه را به روش‌های مختلف کپسوله کنند تا چندین سرویس back end را فراخوانی کنند و نتایج را جمع‌آوری کنند. بنابراین برای استفاده از پروتکل‌های کاملا مستقل انعطاف‌پذیری وجود دارد که در آن client و میکروسرویس می‌توانند با یکدیگر ارتباط برقرار کنند.گسترش برنامه‌های قدیمی: سازمان‌هایی که به برنامه‌های قدیمی متکی هستند، می‌توانند از دروازه‌های API برای کار با این برنامه‌ها و گسترش عملکرد آن‌ها به عنوان یک جایگزین برای مهاجرت گسترده‌تر، پیچیده‌تر و گران‌تر استفاده کنند.کمک به نظارت و قابلیت مشاهده: بیشتر سازمان‌ها به ابزارهای خاصی برای فعالیت نظارت از طریق APIها متکی هستند و یک فرایند API به این کارها کمک می‌کنند. API Gateway می‌تواند به مشخص کردن یک مشکل از طریق نظارت یک رویداد خرابی و خرابی‌های جزئی کمک کند.معایب API Gatewayبه دلیل اتفاقات زیادی که در دروازه API می‌افتد می تواند عملکرد را کاهش دهد.باید برای این منظور سرویس اکتشاف پیاده سازی شود.گاهی اوقات تنها نقطه خرابی است.مدیریت مسیریابی یک سربار الگو است.در هنگام فراخوانی hopeهای اضافی را به شبکه می‌افزاید.سبب افزایش پیچیدگی سیستم می‌گردد و اجرای بیش از منطق در دروازه API سبب ایجاد مشکل وابستگی به دیگری می‌گردد.ابزارهای API Gatewayدر این بخش سه مورد ابزارهای منبع باز مهم و کاربردی مورد استفاده برای مدیریت و ایجاد درگاه API معرفی و بررسی می‌گردند.API Gatewayابزار Kong Gatewayمحبوب‌ترین ابزار منبع باز برای درگاه API و مبتنی بر ابر است و می‌توان آن را به عنوان یک راه حل ترکیبی در فضای ابری یا در محل خود مستقر کرد. که بر روی یک proxy سبک ‌وزن ساخته شده است و بارهای کاری بزرگ و متغیر را پشتیبانی می‌کند. این ابزار به زبان Lua نوشته شده است و به کمک Nginx اجرا می‌شود. یک موتور قالب است که سبب تسریع زمان رویداد می‌شود. عملکرد تاخیر غیر موازی مقیاس‌پذیری را برای همه برنامه‌های میکروسرویس را بدون در نظر گرفتن مکان اجرا تضمین می‌کند و ارائه می‌دهد. این ابزار دارای ویژگی‌هایی مانند احراز هویت، کنترل ترافیک، تجزیه و تحلیل، تغییرات و تبدیلات، ورود به سیستم، بدون سرور، قابل توسعه با استفاده از معماری پلاگین، قابلیت اجرا روی پلتفرم دلخواه و مناسب برای مستندسازی و یکپارچه‌سازی است. این ابزار برای برنامه‌های مهم سازمان‌ها راه حل ارائه می‌دهد و به گسترش APIها و میکروسرویس‌ها کمک می‌کند.Kong Gatewayابزار Tykیک درگاه API منبع باز آماده برای سازمان‌ها است و دارای دو گزینه hosted و managed است. این ابزار دارای ویژگی‌هایی مانند احراز هویت، محدودیت سهمیه و نرخ، کنترل نسخه، رویدادها و اعلان‌ها، نظارت و تحلیل جزئیات، commit کردن به منظور سازگاری عقبگرد، GraphQL خارج از جعبه و موجود بودن در بازار AWS است.Tyk Gatewayابزار KrakenDیک درگاه API منبع باز با عملکرد بالا است. عملکرد اصلی آن ایجاد یک API است که بسیاری از میکروسرویس‌ها را در یک نقطه پایانی واحد جمع می‌کند و کارهای سنگین و سخت مانند تجمیع، تبدیل، انتقال، فیلتر، رمزگشایی، جلو بردن، احراز هویت و ... را به صورت خودکار انجام می‌دهد. به خوبی ساختاریافته و لایه‌بندی شده است و برای گسترش عملکرد خود از میان‌افزار plug-and-play استفاده می‌کند. همچنین این ابزار نسبت به Try و Kong سرعت بیشتری دارد. KrakenD Gatewayشرکت‌های ایرانی فعال در حوزه API Gatewayدر این بخش دو مورد از شرکت‌های فعال در حوزه API Gateway و محصولات آن‌ها معرفی می‌گردند.شرکت دانش بنیان پلتکواین شرکت برای حل مشکل متمرکز نبودن وظایفی مانند فعال بودن مداوم، امنیت، سهولت دسترسی ، نرخ دسترسی و اطلاع دائم و آنلاین از مسائل دیگر وب سرویس‌ها در یک سازمان پلتفرمی یکپارچه برای مدیریت زیر ساخت وب سرویس‌ها ارائه داده است تا بتوان کل چرخه زندگی وب سرویس‌های سازمان را از ابتدای بوجود آمدن تا زمان قطع سرویس مدیریت کرد. شرکت پلتکو از طریق API Manager چالش‌های سازمان‌ها حل کرده‌ است. سازمان‌ها از طریق API Manager به راحتی می‌توانند زیر ساخت کل سرویس‌های خود را یکپارچه کنند و با ابزارهای مدیریت بر تمام رخدادهای وب سرویس‌ها نظارت آنلاین داشته باشند این پلتفرم 98 درصد از قطع سیستم، 45 درصد از اتلاف زمان و 50 درصد از اتلاف هزینه جلوگیری می‌کند. ویژگی‌های این محصول و پلتفرم عبارتند از:ایجاد درگاه امن برای وب سرویس‌هاامکان سفارشی‌سازی API Managerپشتیبانی از RAML ، OAS ، SOAPمدیریت دسترسی یکپارچهامکان تعیین خط مشی وب سرویس‌هامدیریت وب سرویس‌ها از طریق فضای ابریمحافظت از منابع خودتسریع در ارائه خروجی وب سرویس‌هابهبود قابلیت معرفی وب‌ سرویس به سرویس‌گیرندگانپلتفرم پلتکوشرکت ابر درسایک سرویس API Gateway ابری ارائه می‌دهد که یک سرویس میزبانی API است. این مجموعه وسیعی از توابع مدیریت چرخه زندگی را برای کمک به ایجاد معماری سیستم API محور ارائه می‌دهد. توابع مدیریت چرخه زندگی شامل طراحی API، توسعه، آزمایش، انتشار، فروش، O&M و نظارت، کنترل امنیت و عدم انتشار است. سرویس API Gateway ابری با استفاده از قابلیت‌های سازگاری و یکپارچگی قدرتمند خود،API های سیستم‌های تجاری مختلف را مدیریت می‌کند و API ها را به صورت متمرکز فراخوانی می کند. از جمله قابلیت‌های این محصول عبارتند از:از محیط های ناهمگن شبکه پشتیبانی می کند: سرویسApi Gateway ابری می‌تواندAPI های سیستم‌های تجاری کاربران را مدیریت کند، صرف نظر از اینکه سیستم های تجاری کاربران در ابر درسا ، مراکز داده محلی یا ابرهای شخص ثالث مستقر شده اند یا خیر.ساخت انواع معماری فنی: معماری بدون سرور ترکیبی از Function Compute و API Gateway است که به توسعه‌دهندگان امکان می دهد تا کد را کشف کرده و به سرعت خدمات کم هزینه، بسیار در دسترس و مقیاس‌پذیر در زمان واقعی را ایجاد کنند. این معماری توسعه مشاغل مرتبط با دستگاه های تلفن همراه، برنامه های وب و اینترنت اشیا (IoT) بازار ابر را تسهیل می کند. این معماری امکانات توسعه تجارت و مرزهای تجاری را گسترش می دهد. انعطاف پذیری ترکیبات محصول بهبود یافته است.معماری میکروسرویس: سرویس Api Gatewayابری به عنوان یک سرویس ابری بالغ عمل می‌کند که اجازه دسترسی به خوشه های برنامه Kubernetesرا می‌دهد. این به طور قابل توجهی قابلیت‌های سرویس خوشه‌های برنامه Kubernetesرا بهبود می‌بخشد. این معماری به عنوان معماری استاندارد برای برنامه های کاربردی اینترنت در مقیاس بزرگ عمل می‌کند.جمع‌بندیدر این مقاله ابتدا در بخش اول به معرفی و بررسی درگاه رابط برنامه‌نویسی (API Gateway) در حوزه معماری نرم‌افزار و بهبود زیرساخت توسعه نرم‌افزار پرداخته شد و سپس در بخش دوم دو مورد از ابزارهای مورد نیاز برای ایجاد درگاه رابط برنامه‌نویسی (API Gateway)، توسعه و بهبود زیرساخت و رفع مشکلات موجود معرفی شدند و در پایان نیز دو مورد از شرکت‌های ایرانی فعال در حوزه ارائه خدمات مربوط به درگاه رابط برنامه‌نویسی (API Gateway) به همراه محصولاتی که ارائه می‌دهند معرفی و بیان گردید.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابع و مراجع: https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do https://www.nginx.com/learn/api-gateway/ https://www.axway.com/en/products/api-management/gateway https://hub.packtpub.com/api-gateway-and-its-need/ https://virgool.io/d/mrzrc3gjfif5/WhatisanAPIgatewayandwhyisitimportant?(techtarget.com) https://www.softwaretestinghelp.com/api-management-tools/ https://geekflare.com/api-gateway/#anchor-tyk https://platco.ir/services/integration-web-services/api-management/ https://dorsacloud.com/ شیما سیف الهی شیما سیف الهی Fri, 24 Dec 2021 22:12:42 +0330 https://virgool.io/@shimaseyfollahi/%DA%A9%D8%A7%D9%86%D8%AA%DB%8C%D9%86%D8%B1%D8%B3%D8%A7%D8%B2%DB%8C-%D9%88-%D8%A7%D8%B1%DA%A9%D8%B3%D8%AA%D8%B1%D8%A7%D8%B3%DB%8C%D9%88%D9%86-%DA%A9%D8%A7%D9%86%D8%AA%DB%8C%D9%86%D8%B1-ntutwjta3jyj کانتينرسازي چيست؟کانتينرسازي نوعی مجازی‌سازی در سطح برنامه است که چندین نوع فضای کاربر ایزوله شده را روی یک هسته واحد ایجاد فراهم می‌کند. به این نمونه‌ها کانتینر می‌گویند. کانتینرها یک روش استاندارد بسته‌بندی کد برنامه، زمان اجرا، ابزارهای سیستم، کتابخانه‌های سیستم و پیکربندی در نمونه را ارئه می‌دهد. کانتینرها یک هسته (سیستم عامل) مشترک دارند که روی یک سخت‌افزار نصب شده است. تفاوت اصلی کانتینرها با ماشین‌های مجازی این هست که از سیستم عامل یا زیرساختی که روی آن اجرا می‌شوند جدا و انتزاع شده هستند. به بیان ساده‌تر یک کانتینر شامل کد برنامه و هر چیزی است که برای اجرای درست به آن نیاز دارد.Containerizationارکستراسیون کانتینری چیست؟استقرار، سازماندهی، مدیریت، مقیاس‌بندی و شبکه‌سازی کانتینرها به صورت خودکار برای پشتیبانی برنامه‌ها ارکستراسیون کانتینر گفته می‌شود که از طریق ابزار ارکستراسیون کانتینر انجام می‌شود و برای اجرای بارهای کاری و سرویس‌های کانتینری است. شرکت‌ها و سازمان‌هایی که نیاز به استقرار و مدیریت صدها یا هزاران کانتینر و host دارند، می‌توانند از ارکستراسیون کانتینر استفاده کنند. ارکستراسیون کانتینر می‌تواند در هر محیط که از کانتینرها استفاده می‌شود، مورد استفاده قرار گیرند که می‌توان برنامه یکسانی را در محیط‌های مختلف بدون نیاز به طراحی مجدد اجرا کرد. مدیریت چرخه عمر کانتینرها با ارکستراسیون همچنین از تیم DevOpsای که کانتینر را در گردش‌های کاری CI/CD ادغام می‌کند، پشتیبانی می‌کند. علاوه بر APIها و تیم DevOps، میکروسرویس‌های کانتینری پایه و اساس برنامه‌های ابری محلی هستند.Container Orchestrationچه زمانی می‌توان از کانتینر استفاده کرد؟تقریبا هر برنامه‌ای که به تغییر و استقرار مجدد سریع و مکرر نیاز داشته باشد و برنامه‌هایی که از معماری میکروسرویس استفاده می‌کنند، برای کانتينرسازي مناسب و خوب است. میکروسرویس‌ها در کانتینرها سبب ساده‌سازی سرویس‌های ارکستراسیون، ذخیره‌سازی، شبکه‌سازی و امنیت می‌شود. کانتینرها در برنامه‌های مبتنی بر میکروسرویس یک واحد استقرار برنامه ایده‌آل و یک محیط استقرار مستقل و جامع می‌دهد. آن‌ها امکان اجرای چندین بخش از یک برنامه را به طور مستقل در میکروسرویس‌ها روی یک سخت‌افزار با کنترل بسیار بیشتر روی تک تک قطعات و چرخه‌های عمر، ممکن می‌سازد.دلیل نیاز به ارکستراسیون کانتینربه دلیل آن که کانتینرها به صورت طبیعی سبک و بی‌دوام هستند و اجرای آن‌ها نیاز در محیط و محصول نهایی به تلاش زیادی نیاز دارد، به ویژه زمانی که با میکروسرویس همراه می‌شود که معمولا هر کدام در کانتینر خودشان اجرا می‌شوند. یک برنامه کانتینرسازی شده ممکن است به صدها یا هزاران کانتینر عملیاتی به ویژه در هنگام ساخت و راه‌اندازی یک سیستم بزرگ مقیاس تبدیل شود. در صورت مدیریت دستی پیچیدگی قابل توجهی را ایجاد می‌شود. ارکستراسیون کانتینر پیچیدگی توسعه و عملیات DevOps را قابل مدیریت می‌کند و راهی را برای خودکارسازی بیشر کارها ارائه می‌دهد که برای تیم‌های DevOps که با سرعت و چابکی بیشتری نسبت به تیم‌های نرم‌افزاری سنتی عمل می‌کنند، مناسب است.مزایای ارکستراسیون کانتینرارکستراسیون کانتینر برای کار با کانتینرهای کلیدی مورد استفاده قرار می‌گیرد و دارای مزایایی برای سازمان‌ها و محیط‌های کانتینری خاص است که عبارتند از:عملیات ساده‌ شده: مهم‌ترین مزیت ارکستراسیون کانتینر است. کانتینرها دارای پیچیدگی زیادی هستند که بدون ارکستراسیون کانتینر برای مدیریت آن، به سرعت از کنترل خارج می‌شوند.تاب‌آوری: ابزار ارکستراسیون کانتینر می‌توانند به صورت خودکار یک کانتینر یا خوشه را راه‌اندازی یا مقیاس‌بندی کنند و تاب‌آوری را افزایش می‌دهد.امنیت افزوده شده: رویکرد خودکار ارکستراسیون کانتینر با کاهش یا حذف احتمال خطای انسانی به امنیت و ایمنی برنامه‌های کانتینری کمک می‌کند.تحویل مداوم و DevOps: زمانی که برنامه از چندین برنامه با رابط مشخصی بین آن‌ها تشکیل شده است، برای بروزرسانی یک کانتینر، ارزیابی تاثیر و بازگشت به نسخه قدیمی یا چرخش بروزرسانی در کانتینرهای مشابه یک موضوع کم خطر و درست است. با داشتن چندین کانتینر که قابلیت یکسانی را ارائه می‌دهند، ارتقا هر کانتینر می‌تواند بدون تاثیر منفی بر سرویس انجام شود.مقیاس‌پذیری: با طراحی یک برنامه ساخته شده از چند نمونه کانتینر، افزودن کانتینرهای بیشتر سبب مقیاس‌بندی ظرفیت و توان عملیاتی می‌شود. همچنین زمانی که تقاضا کاهش می‌یابد، می‌توان کانتینرها را حذف کرد. چارچوب ارکستراسیون مقیاس‌بندی الاستیک را ساده‌تر می‌کند.انزوا: هر کانتینر روی یک host مستقل و ایزوله از دیگر hostها اجرا می‌شود. تجهیزات می‌توانند به صورت هم‌زمان توسعه، پشتیبانی، تست و نسخه‌های برنامه را host کنند. حتی نسخه‌های مختلف ابزارها، زبان‌ها، پایگاه‌های داده و کتابخانه‌ها بدون هیچ خطر و تاثیری روی محیط‌های دیگر اجرا می‌شوند.دسترس پذیری بالا: با اجرای چندین کانتینر، در برنامه افزونگی ایجاد می‌شود. اگر یکی از کانتینرها خراب شوند، کانتینرهای مشابه باقی مانده سرویس را ارائه می‌دهند. با برخی از خودکارسازی‌ها می‌توان کانتینرهای خراب شده را به صورت خودکار بازسازی کرد و ظرفیت کامل و افزونگی را بازیابی کرد.معایب کانتینرکمبود معیارهای امنیتی: کانتینرها، جداسازی سبکی از سیستم عامل host و کانتینرها را در سیستم یکسانی را ایجاد می‌کند که منجر به امنیت کمتر و ضعیف‌تری در مقایسه با ماشین مجازی می‌گردد.اجرا روی یک سیستم عامل: هنگامی که به یک سیستم عامل نیاز هست، استفاده از کانتینر مفید است ولی زمانی که نیاز به استفاده از چندین سیستم عامل است، استفاده از کانتینر یک نکته منفی است. می‌توان نسخه قبلی سیستم عامل یکسانی را با استفاده از ماشین مجازی سبک‌تری اجرا کرد.ذخیره‌سازی داده: ذخیره‌سازی داده برای ماشین‌های مجازی آسان است ولی برای کانتینرها دارای پیچیدگی است. طراحی کانتینر به دلیل از بین رفتن اطلاعات آن‌ها است. زمانی که یک کانتینر خاموش می شود، داده‌های آن برای همیشه ناپدید می‌شوند مگر آن که در جای دیگری ذخیره شده باشند.نظارت: نظارت کانتینرها از نظر عملکرد و امنیت خیلی مهم است. محیط ابری پیچیده است بنابراین به نظارت عمیق امنیتی نیاز هست.موارد استفاده از ارکستراسیون کانتینرارکستراسیون کانتینر برای خودکارسازی و مدیریت وظایفی مورد استفاده قرار می‌گیرند که عبارتند از:تامین و استقرار و می‌توان برنامه‌‌ها را بدون کوچکترین تغییری در کد آن‌ها از یک محیط به محیط دیگر منتقل کرد.پیکربندی و زمان‌بندیتخصیص منابعمقیاس‌بندی یا حذف کانتینرهای مبتنی بر تعادل بار کاری در کل زیرساختتعادل بار و مسیریابی ترافیکنظارت بر سلامتی کانتینرپیکربندی برنامه‌ها بر اساس کانتینری که در آن اجرا می‌شوند.ایمن نگه داشتن تعاملات بین کانتینرهابرنامه‌های مبتنی بر میکروسرویس را برای اجرا در محیط ابری فعال می‌کند.بهینه‌سازی برنامه‌های قدیمی تا بعد از بازسازی آن‌ها، بدون نقص با معماری ابر کار کنند.با استفاده از استراتژی مهاجرت، یک برنامه داخلی یا قدیمی را می‌توان به محیط ابری منتقل کرد که سبب مدرن‌سازی برنامه بدون تغییر در کد برنامه می‌شود.با استفاده از imageهای کانتینر یکسان برای کمک به تیم‌ها برای پیاده‌سازی یکپارچه‌سازی مداوم و توسعه پیوسته در DevOps استفاده می‌شود. توسعه، استقرار و تست وظایف سریع‌تر است زیرا بهبود کد می‌تواند در طول زمان انجام شود.سهولت استقرار وظایف تکراری در پس ‌زمینههزینه رایانش ابری توسط کاهش سخت‌افزار مورد نیاز برای مجازی‌سازی برنامه‌ها کاهش می‌دهد.برخلاف ماشین‌های مجازی، بعد از تکمیل یک کار کانتینرها آسان‌تر ایجاد، مستقر و تخریب می‌شوند که هزینه محاسبات را کاهش می‌دهد.کانتینرها همچنین برای سازمان‌هایی که از یک استراتژی ابری ترکیبی یا ابری چندگانه برای اجرای نیازهای محاسباتی روی همه پلتفرم‌های ابری و مرکز داده ابری خود استفاده می‌کنند، مناسب و عالی است.مزایای کانتینرهاقابل حمل بودن: یکی از بزرگ‌ترین مزایای کانتینرها این هست که برای اجرا در هر محیطی ساخته شده‌اند که سبب می‌شود بارهای کانتینری بین پلتفرم‌های ابری مختلف به آسانی جا به جا شوند. همچنین بهره‌وری توسعه‌دهندگان را افزایش می‌دهد زیرا می‌توان کد را به گونه‌ای نوشت که زمانی که روی محیط‌های مختلف از ماشین محلی تا یک سرور داخلی برای یک ابر عمومی مستقر می‌شود، بدون نگرانی اجرا شود.توسعه برنامه: کانتینرها می‌توانند به سرعت استقرار و توسعه برنامه‌ها شامل تغییرات یا بروزرسانی‌ها در طول زمان است که این موضوع در میکروسرویس‌های کانتینری صادق است و رویکردی برای معماری نرم‌افزار است که مستلزم شکستن راه حل بزرگتر به بخش‌های کوچکتر است. مؤلفه‌های گسسته (میکروسرویس‌ها) می‌توانند به طور مستقل مستقر، بروزرسانی یا منزوی شوند، بدون آن که نیاز به بروزرسانی یا استقرار مجدد کل برنامه باشد.بهره‌وری و بهینه‌سازی منابع: کانتینرها سبک و بی‌دوام هستند، بنابراین منابع کمتری را مصرف می‌کنند. مثلا می‌توانند کانتینرهای زیادی را روی یک ماشین اجرا کنند.سبک بودن: کانتینرها نسبت به ماشین‌های مجازی، فضای کمتری را روی سرور اشغال می‌کنند و معمولا در چند ثانیه راه‌اندازی می‌شوند.قابلیت ارتجاعی: کانتینرها قابلیت ارتجاع زیادی دارند به تخصیص مقدار مشخصی از منابع نیاز ندارند که به این معنی هست که کانتینرها می‌توانند استفاده پویاتر و مؤثرتر از منابع سرور داشته باشند. هنگامی که تقاضا برای کانتینر کاهش می‌یابد، منابع اضافی برای استفاده توسط سایر کانتینرها آزاد می‌شوند.تراکم: تراکم به تعداد اشیایی که یک سرور فیزیکی می‌تواند در یک زمان اجرا کند، اشاره می‌کند. کانتينرسازي امکان ایجاد محیط‌های متراکم را فراهم می‌کند که در آن منابع سرور host به طور کامل استفاده می‌شوند. اما بیش از حد مورد استفاده قرار نمی‌گیرند. در مقایسه با مجازی‌سازی سنتی، کانتينرسازی برای محیط‌های متراکم‌تری را ایجاد می‌کند زیرا کانتینرها نیازی به host بودن سیستم عامل خود ندارند.کارایی: زمانی که فشار منبع بالا هست، عملکرد برنامه‌ها با کانتینرها بهتر از هایپروایزرها هست. زیرا با مجازی‌سازی سنتی، سیستم عامل مهمان باید نیازهای حافظه خود را برطرف کند RAM با ارزش زیاد را از host دور کند.بهره‌وری تعمیر و نگهداری: با فقط یک هسته سیستم عامل، بروزرسانی‌ها یا اتصال در سطح سیستم عامل باید فقط یک بار انجام شود تا تغییرات روی همه کانتینرها اعمال شود و اثر بگذارد که عملیات، تعمیر و نگهداری سرورها را کارآمدتر می‌سازد.ابزارهای کانتینرسازی و ارکستراسیون کانتینردر این بخش دو مورد از ابزارهای پرکاربرد و منبع باز در حوزه ارکستراسیون کانتینر معرفی و بررسی می‌گردند و ویژگی‌های هر کدام بیان می‌شوند.ابزار ارکستراسیون کانتینرابزار Kubernetesیک پلتفرم ارکستراسیون منبع باز و خارج از جعبه است که از اعلان خودکار و پیکربندی پشتیبانی می‌کند و رایج‌ترین ارکستراسیون کانتینری است. دارای زمانبندی و مدیریت منابع عالی برای استقرار کانتینرها با کارآمدی و دسترس‌پذیری بالا است. دارای مقیاس‌بندی و بارگذاری متعادل خودکار است. با بهبود گردش کار و به حداکثر رساندن بهره‌وری سبب انعطاف‌پذیری و سهولت استفاده می‌گردد. این ابزار دارای ویژگی‌هایی مانند کشف سرویس، ارکستراسیون ذخیره‌سازی، عرضه و عقبگرد به صورت خودکار، خود درمانی، اجرای دسته‌ای است. دارای کتابخانه بزرگی از قابلیت‌های توسعه یافته در جوامع سراسر جهان است که سبب ایجاد قابلیت مدیریت میکروسرویس‌ می‌شود. این ابزار شامل 4 مؤلفه اصلی است که عبارتند از:گره: یک نود مسئول اجرای بارهای کاری کانتینر است و می‌تواند به صورت فیزیکی یا مجازی باشد. این به عنوان host برای زمان اجرای کانتینر عمل می‌کند و ارتباط بین کانتینرها و سرویس‌های Kubernetes را برقرار می‌کند.خوشه: یک مجموعه از گره‌هایی است که منابع را به اشتراک می‌گذارند و برنامه‌های کانتینر را اجرا می‌کنند.کنترل‌کننده‌های تکراری: عوامل هوشمندی هستند که مسئول زمانبندی و تخصیص منابع بین کانتینرها هستند.برچسب‌ها: برچسب‌هایی هستند که سرویس Kubernetes با استفاده از آن‌ها کانتینرهایی که عضو یک pod هستند را شناسایی می‌کند.Kubernetesابزار Docker Swarmیک ابزار کاملا یکپارچه، پرکاربرد و منبع باز ارکستراسیون کانتینر برای اجرا و بسته‌بندی برنامه‌ها به عنوان کانتینر، استقرار آن‌ها و مکان‌یابی imageهای کانتینر از hostهای دیگر است. این ابزار به جای ماشین مجازی در سازمان‌ها مورد استفاده قرار می‌گیرد. شامل گروهی از ماشین‌های فیزیکی و مجازی است که برای اجرای برنامه‌های داکر با هم کار می‌کنند. فعالیت‌های شلوغ را مدیریت می‌کند و به مدیریت عملیات کانتینرهای مستقر روی ماشین‌های host کمک می‌کند، تعادل بار مناسب را تضمین می‌کند، به صورت پیش فرض دارای ایمنی است، دارای بروزرسانی چرخشی است و از طریق ایجاد و حذف انجام‌ دهنده وظایف برای کمک به نگهداری یک حالت مطلوب خوشه مقیاس‌بندی مناسب را تضمین می‌کند. دارای دو مؤلفه اصلی است:گره مدیر: گره‌های مدیر وظایف را به گره‌های worker اختصاص می‌دهند. یک رهبر بر اساس الگوریتمی انتخاب می‌شود و تمام تصمیمات هماهنگی وظایف و مدیریت ازدحام را انجام می‌دهد.گره worker: وظایف را از گره مدیر دریافت می‌کند و آن‌ها را اجرا می‌کند.ویژگی‌های داکر عبارتند از:نودهای مدیر با اختصاص دادن وظایف به مناسب‌ترین hostها سبب تعادل بار می‌شوند.با استفاده از افزونگی سبب افزایش دسترس‌پذیری می‌گردد.کانتینرها سبک‌ وزن و قابل حمل هستند.با اکوسیستم داکر ادغام شده است و سبب تسهیل مدیریت کانتینرها شده است.برای راه‌اندازی به پلاگین اضافی نیاز ندارد.محیط توزیع شده این ابزار امکان دسترسی و همکاری غیر متمرکز را فراهم می‌کند.یکی از چالش‌های داکر این هست که روی ماشین‌های مجازی در خارج از پلتفرم لینوکس مانند ویندوز و مک اجرا می‌شود. همچنین در هنگام انتقال کانتینرها به فضای ذخیره‌سازی دارای مشکلاتی است.Docker Swarmشرکت‌های ایرانی فعال در حوزه کانتینرسازی و کوبرنیتزدر این بخش دو مورد از شرکت‌های ایرانی فعال درحوزه کانتینر و محصولات آن‌ها در زمینه کانتینر معرفی می‌گردد.شرکت هم روششرکت هم روش پلتفرم ابری ساخت، استقرار و اجرای برنامه‌های کانتینری به نام دارکوب را ارائه می‌دهد که بستر ابری استقرار نرم‌افزار را برای کسب و کارها فراهم می‌کند. این محصول امکان ارائه خدماتی مانند انواع پایگاه‌ داده‌های مدیریت شده سیستم مانیتورینگ، سیستم لاگ و پشتیبان‌گیری را در این بستر برای مشتریان فراهم می‌کند. با استفاده از این محصول می‌توان سریع و آسان از مزایا و امکانات کوبرنیتز استفاده کرد. در عین سادگی می‌توان از امکانات پیشرفته و قوی کوبرنیتز به صورت گسترده و راحت استفاده کرد. خدمات یکپارچه ابری این شرکت امکانات لازم برای اجرای کامل چرخه DevOps را به سادگی و به صورت خودکار در محیط کوبرنتز ارائه می‌کند.شرکت سبز سیستمشرکت سبز سیستم محصول کوبیت را به منظور ایجاد سرورهای مجازی ابری و تست و استقرار برنامه‌ها ارائه می‌دهد. مجموعه سامانه‌های نرم‌افزاری و زیرساخت‌های ابری کوبیت که شرکت سبز سیستم ارائه می‌دهد عبارتند از:مدیریت شبکه: رصد و گزارش‌گیری از تجهیزات شبکه، به همراه تحلیل کارایی آنمدیریت ذخیره‌سازی: شامل سرویس‌های استقرار، تحکیم، مدیریت، بازیابی و پشتیبان‌گیری. به‌کارگیری بهینه‌ی منابع برای محیط‌های ذخیره‌سازی پیچیده.هشداردهی: هشداردهی خودکار و قابل تنظیم، به موقع و در فرمتی مناسب.گزارش‌گیری: داشبوردهای گزارش‌گیری برای نمایش برخط داده‌ها به منظور بررسی حوادث، کارایی، دسترسی و خطاهای احتمالی.مزایا و ویژگی‌های محصول شرکت سبز سیستم به صورت مقابل هستند:دسترسی بالا: حذف down time‌های از قبل برنامه‌ریزی شده به وسیله‌ی مهاجرت و ارتقای زنده و به حداقل رساندن down time‌های پیش‌بینی نشدهمحافظت از داده‌ها: پشتیبان‌گیری و بازیابی ساده‌ی داده‌ها، سیستم عامل و برنامه‌ها.بازدید بعد از فاجعه: فراهم کردن راه‌حل‌هایی منعطف برای اتفاقات ناگوار پیش‌بینی نشدهتکثیر داده‌ها: ایجاد چندین کپی از داده‌های کاربران و ذخیره‌ی آن‌ها در جایگاه‌های مختلف.جمع‌بندیدر این مقاله ابتدا در بخش اول به معرفی و بررسی کانتینرسازی در حوزه معماری نرم‌افزار و بهبود توسعه نرم‌افزار پرداخته شد و سپس در بخش دوم دو مورد از ابزارهای مورد نیاز برای ایجاد کانتینرسازی، توسعه و بهبود نرم‌افزار و رفع مشکلات موجود معرفی شدند و در پایان نیز دو مورد از شرکت‌های ایرانی فعال در حوزه ارائه خدمات مربوط به کانتینرسازی و کوبرنیتز به همراه محصولاتی که ارائه می‌دهند معرفی و بیان گردید.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابع و مراجع https://www.vmware.com/topics/glossary/content/container-orchestration.html https://virgool.io/p/ntutwjta3jyj/alibabacloud.com/knowledge/what-is-containerization https://www.redhat.com/en/topics/containers/what-is-container-orchestration https://www.cloudzero.com/blog/container-orchestration https://avinetworks.com/glossary/container-orchestration/ https://www.mongodb.com/basics/container-orchestration https://blog.engineyard.com/containers-vs-virtual-machines-differences-pros-cons https://www.veritas.com/information-center/containerization https://www.cloudzero.com/blog/container-orchestration https://appfleet.com/blog/top-10-container-orchestration-tools/ https://devopscube.com/docker-container-clustering-tools/ https://geekflare.com/container-orchestration-software/ https://hamravesh.com/darkube?utm_source=menuLink&utm_medium=darkubeSection&utm_campaign=users https://sabz.co/ شیما سیف الهی شیما سیف الهی Fri, 24 Dec 2021 22:11:16 +0330 https://virgool.io/@shimaseyfollahi/%D8%A7%D9%84%DA%AF%D9%88%DB%8C-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D8%AF%D8%A7%D9%85%D9%86%D9%87-%D9%85%D8%AD%D9%88%D8%B1-ddd-rfppofgvhwx1 الگوی طراحی دامنه محور چیست؟یک رویکرد طراحی نرم‌افزار برای توسعه نرم‌افزار است که بر روی مدلسازی نرم‌افزار برای انطباق با یک دامنه بر اساس ورودی‌ از کارشناسان دامنه و توسعه برنامه‌نویسی یک مدل دامنه تمرکز دارد، از اصول و ایده‌های تحلیل شی‌گرا استفاده می‌کند و درکی غنی از فرایندها و قوانین مربوط به یک دامنه دارد. توسط اریک ایوانز در سال 2003 در کتابش منتشر شد و این رویکرد را توسط فهرستی از الگوها توصیف می‌کند. در آن زمان این ایده بیشتر توسط مجموعه‌ای از پزشکان گسترش یافت که کتاب‌های مختلف دیگر و دوره‌های آموزشی را توسعه دادند.طراحی داده محور سیستمی با انتزاع بالا است که جنبه‌های انتخابی یک دامنه را توصیف می‌کند و برای حل مشکلات مربوط به دامنه مورد استفاده قرار می‌گیرد. ساختار و زبان کد نرم‌افزار مانند نام کلاس‌ها، نام متدها، متغیرهای کلاس و ... باید با دامنه کسب و کار منطبق شوند. DDD پیاده‌سازی را به یک مدل در حل تکامل متصل می‌کند. این رویکرد به ویژه برای دامنه‌های پیچیده مناسب است که دارای منطق بی‌نظم هستند و نیاز به سازماندهی دارند و سیستم‌های نرم‌افزاری باید مبتنی بر مدل دامنه توسعه یافته خوب باشند. DDD تاکید دارد که توسعه این مدل‌ها در نرم‌افزار انجام شوند برخلاف رویکردهای قبلی که روی کاغذ انجام می‌شدند. همچنین تکامل این مدل‌ها در طول عمر محصول نرم‌افزاری انجام شوند برخلاف روش‌های قبلی که از قبل انجام می‌شد.مدل دامنه محور دارای فوایدی مانند قابلیت نگهداری است. مایکروسافت فقط برای دامنه‌های پیچیده آن را توصیه می‌کند که سبب فوایدی در فرمول‌بندی درک روشنی از دامنه می‌گردد. منظور از دامنه در طول توسعه برنامه حوزه دانش و فعالیتی است که منطق برنامه حول آن می‌چرخد. در این مدل معماری، لایه دامنه یا منطق دامنه یکی از لایه‌های مشترک در یک معماری چند لایه شی‌گرا است و به عنوان منطق کسب و کار است. منطق کسب و کار یک برنامه به قوانین سطح بالاتر برای نحوه تعامل اشیا کسب و کار با یکدیگر و اصلاح داده مدلسازی شده اشاره دارد.الگوی طراحی دامنه محورانواع مدل‌هاطراحی دامنه محور چندین نوع مدل را تشخیص می‌دهد. مثلا یک موجودیت با ویژگی‌های آن شناخته نمی‌شود و با هویت آن شناسایی می‌شود. مثلا هر صندلی هواپیما در هر پرواز دارای شماره منحصر به فردی است که با آن شناسایی می‌شود. ولی یک شی دارای ویژگی‌هایی است و تغییر ناپذیر است ولی هویت در آن مفهومی ندارد. مثلا افراد فقط به اطلاعات روی یک کارت ویزیت توجه می‌کنند به جای آن که بین کارت‌های منحصر به فرد تمایز قائل شوند.مدل‌ها می توانند رویدادها چیزی که اتفاق می‌افتد را نیز تعریف کنند. رویداد دامنه، رویدادی است که برای کارشناسان دامنه مهم است. مدل‌ها می‌توانند توسط یک موجودیت ریشه در کنار هم قرار بگیرند و به یکدیگر متصل شوند. اشیای خارج از این جمع، می توانند ارجاعاتی به ریشه داشته باشند ولی به هیچ یک از اشیای داخل این مجموعه نمی‌تواند ارجاع دهد. ریشه این مجموعه سازگاری تغییرات در مجموعه را بررسی می‌کند. مثلا رانندگان به هر کدام از چرخ‌های ماشین را به صورت جداگانه کنترل نمی‌کند و آن‌ها به راحتی رانندگی می‌کنند. در این زمینه ماشین مجموعه از چند شی دیگر مانند موتور، ترمز، چراغ‌های جلو و ... است.اهداف طراحی دامنه محورتمرکز اولیه پروژه روی دامنه اصلی و منطق دامنهاشتراک گذاری یک زبان مشترک توسط کارشناسان دامنه برای توصیف نیازمندی‌های سیستم، کاربران کسب و کار، حامیان مالی و توسعه‌دهندگانپایه‌ گذاری طراحی‌های پیچیده روی یک مدل‌های دامنهتسهیل ایجاد برنامه‌های پیچیده با اتصال قطعات مرتبط نرم‌افزار به یک مدل همیشه در حال تکاملآغاز همکاری بین متخصصان همکاری و دامنه برای بهبود مدل برنامه،‌حل مشکلات مرتبط با دامنه اصلاح مکرر یک مدل مفهومی که به مسائل دامنه خاصی می‌پردازد.انتقادات از طراحی دامنه محور استدلال می‌کند که توسعه دهندگان باید معمولا قدار زیادی انزوا و کپسوله‌سازی برای نگهداری مدل به عنوان ساختاری مفید و خالص را اجرا کنند، هست.کار کردن با مدل‌هادر طراحی دامنه محور یک شی ایجاد شده از یک شی اغلب از خود شی جدا می‌شود. مثلا یک repository یک شی با متدهایی برای بازیابی اشیای دامنه از یک مخزن داده مانند پایگاه داده است. همچنین یک کارخانه نیز یک شی با متدهایی برای ایجاد مستقیم اشیای دامنه است. زمانی که بخشی از عملکرد برنامه از نظر مفهومی به هیچ شی‌ای وابستگی ندارد، معمولا به عنوان یک سرویس در نظر گرفته می‌شود.مثالی از الگوی طراحی مدل محورتعدادی از اصطلاحات رایج در طراحی دامنه محورطراحی دامنه محور دارای تعدادی از مفاهیم سطح بالا است که برای ایجاد و اصلاح مدل‌های دامنه می‌تواند در ارتباط و ترکیب با یکدیگر مورد استفاده قرا گیرند. در ادامه تعدادی از این مفاهیم بررسی می‌گردند.منطق دامنه: منطق دامنه هدف مدلسازی و منطق کسب و کار است. در این جا قوانین کسب و کار مواردی مانند ایجاد، ذخیره‌سازی و اصلاح داده را مشخص می‌کند.مدل دامنه: مدل داده شامل ایده‌ها، دانش‌ها، داده‌ها، معیارها و اهدافی مربوط راه حل مسئله مورد نظر است. شامل همه قوانین و الگوها برای مقابله با منطق کسب و کار پیچیده است و برای برآوردن نیازهای کسب و کار مفید است.زیردامنه: یک دامنه شامل چندین زیردامنه است مه به بخش‌های مختلف منطق تجاری اشاره دارد. مانند یک فروشگاه آنلاین که کاتالوگ، موجودی و تحویل یک محصول به عنوان زیردامنه‌های آن هستند.الگوهای طراحی: الگوهای طراحی در مورد استفاده مجدد از کد هستند. بدون توجه به پیچیدگی مسئله، قبل از برنامه‌نویسی شی‌گرا از الگویی برای حل مسئله استفاده شده است. تقسیم مسئله به چندین بخش سبب حل آن می‌گردد.موجودیت: شی‌ای که توسط یک thread محکم و پیوسته مشخص شناسایی می‌شود، برخلاف اشیای سنتی که توسط ویژگی‌هایشان شناسایی می‌شوند.موجودیتشی ارزش (Value Object): یک شی تغییر ناپذیر و غیر قابل تغییر است که دارای ویژگی‌ها و صفاتی است ولی شناسه و هویت متمایز ندارد. Value Objectرویداد دامنه: شی‌ای که برای ثبت یک رویداد گسسته مربوط به فعالیت مدل در یک سیستم استفاده می‌شود. در حالی که همه رویدادها در سیستم می‌توانند ردیابی شوند. یک رویداد دامنه فقط برای رویدادهایی ایجاد می‌شوند که برای کارشناسان دامنه مهم هستند.کاردینالیتی انجمن‌ها: هر چه کاردینالیتی انجمن‌ها بین کلاس‌ها بیشتر باشد، پیچیدگی ساختار بیشتر می‌شود. با افزودن موارد واجد شرایط می‌توان کاردینالیتی را کاهش داد. همچنین انجمن‌های دو جهته نیز می‌تواند پیچیدگی را افزایش دهد.کاردینالیتی انجمن‌ها تجمیع (Aggregate): خوشه‌ای از موجودیت‌ها و اشیای ارزش با مرزهای مشخص در اطراف گروه است. به جای آن که هر موجودیت یا شی ارزش همه عملیات را خودش انجام دهد، به جمعی از بخش‌ها یک ریشه متراکم واحد اختصاص داده می‌شود. در این صورت اشیای خارجی به هر موجودیت یا شی ارزش در مجموعه دسترسی مستقیم ندارند و فقط می‌توانند به ریشه مجموعه دسترسی داشته باشند که از آن برای ارسال دستورات به گروه استفاده می‌شود. این کار با بسیاری از عملیات کدگذاری واقعی که در الگوهای طراحی پوشش داده می‌شوند، مرتبط است. ریشه به صورت سراسری شناسایی می‌شود در حالی که بقیه به صورت محلی شناسایی می‌شوند. ریشه بررسی می‌کند که همه نامتغیرها ارضا می‌شوند یا خیر. تابع حذف هر موجودیت‌ها را در مجموعه حذف می‌کند. زمانی که یک شی تغییر می‌کند باید همه نامتغیرها ارضا شوند.Aggregateسرویس: یک سرویس یک عمل یا شکلی از منطق کسب و کار است که به طور طبیعی با قلمرو اشیا سازگار نیست. اگر تعدادی از عملکردها وجود داشته باشند اما به یک موجودیت یا شی ارزش مرتبط نباشد، احتمالا یک سرویس است. سرویس دامنه یک لایه اضافی شامل منطق دامنه است که بخشی از مدل دامنه است. در عین حال سرویس برنامه، لایه دیگری است که شامل منطق برنامه نیست که برای هماهنگ کردن فعالیت‌های دامنه در بالای مدل دامنه قرار دارد.مخازن دامنه: با مخازن مربوط به کنترل نسخه متفاوت است. مخزن DDD سرویسی است که از یک رابط سراسری برای دسترسی به همه موجودیت‌ها و اشیای ارزش که در یک مجموعه متراکم خاص هستند، استفاده می‌کند و مجموعه‌ای از موجودیت‌های کسب و کار است. متدهایی برای ایجاد، اصلاح و تشخیص اشیا در مجموعه را فراهم می‌کند و زیرساخت داده را آسان می‌کند و نگرانی های زیرساختی را کاهش می‌دهد. از سرویس مخزن برای ایجاد کوئری‌های داده استفاده می‌شود. هدف مخازن حذف قابلیت‌های کوئری داده داخل منطق کسب و کار مدل‌های شی است.کارخانه‌ها: DDD استفاده از یک کارخانه را پیشنهاد می‌دهد که منطق ایجاد اشیا و aggregateهای پیچیده را کپسوله‌بندی می‌کند و تضمین می‌کند که client اطلاعی از عملکرد درونی دستکاری اشیا ندارد.Factoriesمحتوا: تنظیماتی در یک کلمه یا جمله که معنای آن را تعیین می‌کند. جملات مربوط به یک مدل را می‌توان فقط در یک محتوا (زمینه) درک کرد.زبان فراگیر: بخش اصلی این ایده است. زبانی است که در اطراف مدل دامنه ساختار یافته است، تمام اصطلاحات حول مدل دامنه در سیستم نرم‌افزاری ایجاد و تعبیه می‌شوند و توسط همه اعضای تیم برای اتصال تمام اعضای تیم به نرم‌افزار استفاده می‌شود. یک متدلوژی است که به زبانی اشاره دارد که کارشناسان دامنه و توسعه‌دهندگان از آن استفاده می‌کنندمحتوای محدود: توصیف یک مرز (معمولا یک زیر سیستم یا کار یک تیم خاص) که در یک مدل خاص تعریف شده و قابل اجراست. یک الگوی مرکزی در طراحی دامنه محور است که شامل پیچیدگی برنامه است و مدل‌ها و تیم‌های بزرگ را مدیریت می‌کند. در این قسمت پیاده‌سازی کد بعد از تعریف دامنه و زیردامنه انجام می‌شود. یک موجودیت در محتواهای مختلف می‌تواند نام‌های متفاوتی داشته باشد. زمانی‌ که یک زیر مدل در یک محتوای محدود تغییر می‌کند، کل سیستم نیازی به تغییر ندارد. به همین دلیل توسعه‌دهندگان از وفق‌دهندگان مختلف بین محتواها استفاده می‌کنند.نقشه‌های محتوا: نقشه‌ها (نگاشت‌ها) محتوا یک فرایند طراحی است و جایی است که نقاط برخورد و تغییرات بین زمینه‌های محدود به صراحت ترسیم و نگاشت می‌شوند. روی نقشه‌برداری از چشم‌انداز موجود تمرکز می‌کند و بعدا از تغییرات واقعی جلوگیری می‌کند. از ادغام پیوسته در یک محتوای محدود برای نرم کردن انشعاباتی که از درک‌های متفاوت ناشی می‌شوند، استفاده می‌شود. ادغام مکرر کد، خودکارسازی تست و به کارگیری زبان فراگیر قطعه قطعه شدن در محتوای محدود را به سرعت برجسته می‌کند.Context Mapمزایای طراحی دامنه محورتسهیل ارتباط: با تاکید زودهنگام بر سازماندهی و ایجاد یک زبان مشترک و فراگیر مربوط به مدل دامنه پروژه، ‌تیم‌ها ارتباط در کل چرخه عمر توسعه را آسان‌تر پیدا می کنند. طراحی دامنه محور هنگام بحث در مورد جنبه‌های برنامه به اصطلاحات تخصصی فنی کمتری نیاز دارد، زیرا زبان فراگیر که در ابتدا ایجاد شد، اصطلاحات فنی ساده‌تری را برای جنبه‌های فنی‌تر تعریف می‌کند.بهبود انعطاف‌پذیری: به دلیل آن که طراحی دامنه محور به شدت مبتنی بر مفاهیم تحلیل و طراحی شی‌گرا است. تقریبا همه چیز در مدل دامنه مبتنی بر یک شی است. بنابراین کاملا ماژولار و کپسوله شده است که سبب می‌شود اجزای مختلف یا کل سیستم به صورت منظم و مستمر بهبود یابد و تغییر کند.تاکید روی رابط دامنه: به دلیل آن که طراحی دامنه محور تمرینی از ایجاد مفاهیم دامنه و آن چه را که کارشناسان دامنه در پروژه توصیه می‌کنند هست، برنامه‌هایی را تولید می‌کند که برای نمایش دامنه مورد نظر مناسب است برخلاف برنامه‌هایی که در درجه اول روی UI/UX تاکید دارند. در حالی که یک تعادل روشن مورد نیاز است. تمرکز بر دامنه یعنی روش DDD می‌تواند محصولی را تولید کند که به خوبی مورد توجه مخاطبان مربوط به دامنه قرار گیرد.معایب طراحی دامنه محورنیاز به تخصص دامنه قوی: با وجود افراد متخصص و خلاق در تیم توسعه، اگر حداقل یک متخصص دامنه در تیم وجود نداشته باشد که جزئیات و داخل و بیرون حوزه مورد نظر برای اعمال روی برنامه را بشناسد، در این صورت طراحی دامنه محور ممکن است به ادغام یک یا چند عضو از تیمی دیگر بیرون از تیم مورد نظر نیاز داشته باشد که می‌توانند به عنوان متخصصان دامنه در طول چرخه توسعه عمل کنند.تشویق به تمرین‌های تکراری: تمرین‌های DDD‌ به طور قوی متکی به تمرین‌هایی با تکرار ثابت و ادغام مداوم برای ایجاد پروژه‌ای انعطاف‌پذیر هست که می‌تواند در صورت لزوم خود را تنظیم کند. برخی از سازمان‌ها ممکن است با این روش مشکل داشته باشند. به ویژه اگر تجربه‌های قبلی آن‌ها تا حد زیادی به مدل‌های توسعه با انعطاف‌پذیری کم مانند مدل آبشاری مربوط باشد.نامناسب برای پروژه‌های خیلی فنی: اگر چه DDD برای برنامه‌هایی با پیچیدگی زیاد که منطق کسب و کار نسبتا پیچیده است، مناسب است ولی برای برنامه‌هایی با پیچیدگی دامنه حاشیه‌ای و کم و پیچیدگی فنی زیاد مناسب نیست. اگر چه DDD به شدت بر روی نیاز به کارشناسان دامنه و اهمیت آن‌ها برای تولید زبان فراگیر مناسب و سپس مدل دامنه‌ای که پروژه بر اساس آن ایجاد شده است، تاکید می کند پروژه‌ای که از نظر فنی به شدت پیچیده است، ممکن است برای متخصصان دامنه از نظر درک چالش برانگیز باشد و مشکلاتی را ایجاد کند که ممکن است نیازمندی‌ها یا محدودیت‌های فنی کاملا توسط اعضای تیم درک نشده باشند.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابع و مراجع: https://en.wikipedia.org/wiki/Domain-driven_design https://martinfowler.com/bliki/DomainDrivenDesign.html https://airbrake.io/blog/software-design/domain-driven-design https://medium.com/microtica/the-concept-of-domain-driven-design-explained-3184c0fd7c3f https://dzone.com/refcardz/getting-started-domain-driven شیما سیف الهی شیما سیف الهی Fri, 10 Dec 2021 22:30:46 +0330 https://virgool.io/@shimaseyfollahi/%D8%A7%D9%84%DA%AF%D9%88%DB%8C-model-view-viewmodel-mvvm-zgsmmii8kqzr الگوی MVVM چیست؟یک الگوی طراحی نرم‌افزار است که برای جداسازی منطق برنامه و کنترل‌های رابط کاربری گرافیکی با استفاده از یک زبان نشانه‌گذاری یا کد GUI و حذف همه کدهای GUI از لایه view ساخته شده است و به هیچ پلتفرم خاصی وابسته نیست. MVVM همچنین به عنوان model-view-binder شناخته می‌شود که توسط معماران مایکروسافت به نام‌های کن کوپر و جان گاسمن برای ساده‌سازی برنامه‌نویسی رویداد محور رابط‌های کاربری ساخته شده است. این الگو به سازماندهی کد و تبدیل برنامه به ماژول‌ها برای توسعه، بروزرسانی، استفاده مجدد از کد به صورت ساده‌تر و سریع‌تر کمک می‌کند. جداسازی قوانین سبب می‌شود تا طراحان تعاملی بتوانند بر روی نیازهای UX به جای منطق کسب و کار برنامه‌نویسی تمرکز کنند. لایه‌های برنامه می‌توانند در چندین جریان کاری برای بهره‌وری بالاتر توسعه داد. زمانی که یک توسعه‌دهنده روی کل کد پایه کار می‌کند، جداسازی مناسب view از مدل موثرتر است. زیرا رابط کاربری در اواخر چرخه توسعه براساس بازخورد کاربر نهایی چندین دفعه تغییر می‌کنند.این الگو اغلب در ویندوز و نرم‌افزار نمایش گرفیکی وب مورد استفاده قرار می‌گیرد. این الگو یک تبدیل کننده مقدار است یعنی view model مسئول نمایش یا تبدیل اشیای داده مدل است، به گونه‌ای که اشیا به راحتی مدیریت و ارائه شوند. بنابراین view model نمونه‌تر از view است. در غیر این صورت همه منطق نمایش view را بیشتر کنترل می‌کند. view model ممکن است یک الگوی میانجی را پیاده‌سازی کند و دسترسی به منطق back-end در اطراف مجموعه‌ای از use caseها را توسط view پشتیبانی می‌کند. از توابع اتصال داده در WPF (پایه ارائه ویندوز) برای تسهیل بهتر جداسازی توسعه لایه view از سایر الگوها استفاده می‌کند. توسعه‌دهندگان تجربه کاربری (UX) به جای نوشتن کد GUI می‌توانند از زبان نشانه‌گذاری framework مثل XAML استفاده کنند و پیوندهای داده‌ای را برای view model ایجاد می‌کنند که توسط توسعه‌دهندگان نرم‌افزار نوشته نگهداری می‌شوند. الگوی MVVM تلاش می‌کند تا هر دو مزیت جداسازی توسعه عملکردی را توسط MVC فراهم می‌کند، در حالی که از مزایای پیوندهای داده و چارچوب توسط اتصال داده و تا حد امکان نزدیک به مدل برنامه خالص استفاده می‌کند. این الگو از binder، view model و بررسی ویژگی داده هر لایه کسب و کار برای اعتبارسنجی داده ورودی استفاده می‌کند. در نتیجه مدل و framework تا حد امکان عملیات را هدایت می‌کند و منطق برنامه را که مستقیما view را تغییر می‌دهد، حذف می‌کند یا به حداقل می‌رساند.معماری MVVMهدف الگوی MVVMاین الگوی طراحی دارای اهدافی است که در ادامه این اهداف معرفی می‌گردند.هدف آشکار الگوی MVVM انتزاع View است که مقدار منطق کسب و کار در پشت کد را کاهش می‌دهد.هدف اصلی این الگو ارائه یک جداسازی روشن بین منطق حوزه و لایه presentation است.هدف دیگر این الگو ماژولار کردن کد و ایجاد آن روی یک محیط توسعه تست محور است.مکانیزم‌های اتصال سست برای جداسازی بین همه مؤلفه‌ها در View، کسب و کار و منطق داده را فراهم می‌کند.اجزای الگوی MVVMجداسازی کد و اجزای الگوی MVVM به سه لایه View، ViewModel و Model و بخش binder تقسیم می‌شود که در ادامه معرفی می‌گردند.لایه View یا View Controller: مجموعه‌ای از عناصر قابل مشاهده است که ورودی را از کاربر دریافت می‌کند. شامل رابط کاربری، انیمیشن‌ها و متن است. محتوای View به طور مستقیم با تغییراتی که ارائه می‌شوند در تعامل نیست. تمام مؤلفه‌های UI روی نمایشگر یک برنامه مشاهده می‌شوند. View یک ساختار، طرح‌بندی یا هر چیزی است که کاربر در صفحه نمایش مشاهده می‌کند. نمایش از مدل را نمایش می‌دهد و تعامل کاربر با view مانند کلیک‌های ماوس، ورودی کیبرد، ضربه و حرکت روی صفحه نمایش و ... را دریافت می‌کند و آن‌ها را برای view model را از طریق اتصال داده مانند ویژگی‌ها، تماس‌های رویداد و ... مدیریت می‌کند که سبب پیوند view و view model می‌شود. view شامل فقط منطق UI مانند ارائه داده، راهبری و ... است. view مالک view model است.لایه View Model: بین دو لایه View و Model قرار گرفته است که در آن جا کنترل‌ها برای تعامل با View قرار دارند. از binding برای اتصال عناصر رابط کاربری در View با کنترل‌های در ViewModel استفاده می‌شود. انتزاعی از view است که ویژگی‌های عمومی و دستورات را نمایش می‌دهد. رویدادهای UI را دریافت می‌کند و منطق‌های کسب و کار را انجام می‌دهد و خروجی را برای نمایش در UI ارائه می‌دهد. مسئول مدیریت منطق کسب و کار در view است. به صورت داخلی UI‌را تغییر نمی‌دهد و به view ارجاع ندارد و خودش مدل داده دارد. به جای کنترل‌کننده در الگوی MVC یا ارائه‌دهنده الگوی MVP، در واقع الگوی MVVM یک binder دارد که به صورت خودکار بین view و ویژگی‌های محدود در view model ارتباط برقرار می‌کند. این لایه به عنوان وضعیتی از داده‌ در مدل توصیف شده است. اختلاف بین view model و Presenter در الگوی MVP این هست که Presenter به یک view ارجاع دارد در حالی که در view model این گونه نیست. یک view به طور مستقیم به ویژگی‌های view model متصل می‌شود تا بروزرسانی‌ها را ارسال و دریافت کند.لایه Model: منطق برنامه در این لایه قرار دارد که توسط ViewModel که روی آن قرار دارد بازیابی می‌شود و از طریق لایه View ورودی را از کاربر دریافت می‌کند. . این لایه به یک مدل دامنه‌ای اشاره دارد که محتوای حالت واقعی (رویکرد شی‌گرا) را نمایش می‌دهد یا لایه دسترسی به داده که محتوا (رویکرد داده محور) را نمایش می‌دهد. این لایه مدل داده یا موجودیت‌هایی است که در برنامه قرار دارد. ساختارها یا کلاس‌هایی با ویژگی های مرتبط ساده هستند. به سادگی داده‌هایی را که از ساختار داده خام مانند APIها یا سایر منابع مانند فایل‌های SQLite و ... نگاشت می‌شوند را نگهداری می‌کند.بخش binder: توصیف داده و فرمان اتصال در الگوی MVVM به صورت ضمنی هستند. در پشته راه‌حل مایکروسافت binder یک زبان نشانه‌گذاری به نام XAML است. binder توسعه‌دهنده را موظف به نوشتن منطق boiler-plate برای همگام‌سازی view model و view می‌کند. زمانی که در خارج از پشته مایکروسافت پیاده‌سازی می‌شود، وجود یک فناوری اتصال داده تعریف شده، چیزی است که این الگو را ممکن می‌سازد و در صورت نبودن یک binder، می‌توان به جای آن از MVC یا MVP استفاده کرد که باید boilerplate بیشتری را بنویسد یا آن را با ابزار دیگری تولید کند.اجزای الگوی MVVMویژگی‌های الگوی MVVMبرای برنامه‌های دسکتاپ با قابلیت اتصال داده نوشته می‌شود.برای ایجاد تغییرات در view model، view model از یک الگوی مشاهده‌گر استفاده می‌کند.الگوی MVVM بیشتر توسط WPF، Silverlight، nRoute و ... استفاده می‌شود.دلایل متمایز شدن الگوی MVVMجداسازی کد: کد را جداسازی می‌کند. الگوی MVVM مبتنی بر مؤلفه است و یک مدیریت view خاص توزیع شده در میان View، Model و View Model را تقسیم می‌کند. در نتیجه یک ساختار کد ماژولار شده را فراهم می‌کند.اجتناب از کنترل‌ کننده‌های بزرگ: توسعه‌دهندگانی که از MVC استفاده می‌کنند می دانند که وقتی برنامه مقیاس‌پذیر می‌شود و نیازمندی‌ها با منطق موجود به هم می‌خورند، کنترل‌کننده‌ها گسترش می‌یابند تا زمانی که کد کنترل‌کننده برای فایل‌های مجزا هدایت شود. با استفاده از الگوی MVVM منطق کسب و کار در View Model نوشته می‌شود و خروجی فقط به view یا کنترل‌ کننده منتقل می‌شود.توسعه تست محور: MVVM یک پلتفرم خوب برای انجام TDD فراهم می‌کند. موارد آزمون برای View Modelها نوشته می‌شود و منطق کسب و کار برای هدایت UI تست می‌شود. موارد آزمون در زمان توسعه بسیار مهم هستند زیرا شانس شکستن کد را تا حد زیادی به حداقل می‌رسانند.ویژگی‌های الگوی MVVMتفاوت بین MVC و MVVMدر MVC کنترل‌کننده نقطه ورود به برنامه هست در حالی که در MVVM لایه view نقطه ورودی به برنامه است.در MVC تعداد زیادی ارتباط بین کنترل‌کننده و view وجود دارد در حالی که در MVVM یک یا چند رابطه بین View و View Model وجود دارد.الگوی MVC به کنترل‌کننده ارجاع ندارد در حالی که در MVVM لایه View به View Model ارجاع دارد.الگوی MVC یک مدل قدیمی است در حالی که الگوی MVVM یک الگوی نسبتا جدید است.در MVC خواندن، تغییر، تست واحد و استفاده مجدد از این مدل دشوار است در حالی که در MVVM زمانی پیچیده می‌شود که پیوندهای داده پیچیده باشند.مؤلفه‌های مدل MVC را می‌توان به صورت مجزا از کاربر تست کرد در حالی که در مدل MVVM جداسازی تست واحد از کد رویداد محور آسان است.مزایای الگوی MVVMجداسازی View و Model: مزیت اصلی این هست که امکان جداسازی درست بین View و Model و کارایی حاصل از آن را فراهم می‌کند. وقتی مدل نیاز به تغییر دارد، می‌توان به ‌آسانی بدون نیاز به view آن را تغییر داد و برعکس. view model داده لایه مدل را به چیزی که لایه view می‌تواند استفاده کند، تبدیل می‌کند که کنترل‌کننده دیگر مسئولیت این وظیفه را به عهده ندارد.قابلیت نگهداری: جداسازی کامل انواع مختلف کد و بخش‌های مختلف کد برنامه باید ورود به یک یا چند قسمت ریزتر آن، تمرکز روی بخش‌ها و ایجاد تغییرات بدون نگرانی را آسان‌تر سازد و سطحی از ساختار و یکنواختی کد را به وجود می‌آورد که می‌توان در متدلوژی agile باقی ماند و به سرعت به سمت نسخه‌های جدیدتر حرکت کرد و می‌توان به آسانی فهمید که هر چیزی به کجا می‌رود یا در کجا قرار دارد.قابلیت تست‌پذیری: کنترل‌کننده‌های view برای تست دشوار و طاقت‌فرسا هستند زیرا با لایه view ارتباط دارند. با انتقال تغییرات داده به مدل view تست آسان‌تر می‌گردد. تست مدل‌های view آسان است زیرا مدل view به شی متعلق به آن ارجاع ندارد و نوشتن تست‌های واحد برای مدل view آسان است. با الگوی MVVM هر قطعه از کد دانه‌بندی‌تر می‌شود و اگر به درستی پیاده‌سازی شود، وابستگی‌های داخلی و خارجی در قطعات مجزای کد از قسمت‌هایی با منطق اصلی که مورد تست هستند، قرار می‌گیرند که سبب می‌شود نوشتن تست‌های واحد در مقابل منطق اصلی را آسان‌تر شود. همچنین MVVM اتصال بین منطق برنامه و UI را می‌شکند و در دسترس‌ پذیری تست را آسان می سازد. View Model تست واحد پشت کد یا کد رویداد محور را تسهیل می‌کند. می‌توان بدون نیاز به خودکارسازی و تعامل UI این الگو را تست کرد. همچنین لایه presentation و منطق به سستی به هم متصل شدند.قابلیت توسعه‌پذیری: گاهی اوقات با قابلیت نگهداری همپوشانی دارد، که علت آن مرزهای جداسازی آشکار و قطعات دانه‌بندی‌تر کد است و شانس بیشتری برای استفاده مجدد از هر قطعه کد وجود دارد. همچنین می تواند قطعات جدید کد را جایگزین یا اضافه کند که کارهای مشابهی را در مکان‌های مناسب معماری انجام می‌دهد.کار مشارکتی: با جداسازی بخش بصری برنامه یعنی UI از کد مربوطه امکان کار هم‌زمان در هر ناحیه در موارد مرتبط برای متخصصان را فراهم می‌کند. طراحان می‌توانند روی UI به طور هم‌زمان با توسعه‌دهندگان در حال کار روی کد کار کنند. بدون آن که نیاز باشد که هر دو روی فایل یکسانی به طور هم‌زمان کار کنند.ارتباطات شفاف: مسئولیت‌های کنترل‌کننده view کنترل تعامل بین لایه view و لایه مدل و چسباندن هر دو لایه به هم را کاهش می‌دهد. view model یک رابط شفاف برای کنترل‌کننده view فراهم می‌کند که از آن برای پر کردن لایه view و تعامل با لایه model استفاده می‌کند که منجر به ارتباطی روشن بین چهار لایه از برنامه می‌گردد.اتصال سست معماری: MWM در معماری برنامه، اتصال و چسبندگی کاهش می‌دهد.کاهش حجم کنترل‌کننده‌ها : الگوی طراحی سنتی MVC برای اپل کنترل‌کننده‌ها را بزرگ می‌سازد و الگو MVVM سبب حل این مشکل می‌گردد.معایب الگوی MVVMبرای UIهای ساده الگوی MVVM بیش از حد هست و مناسب نیست.کلاس‌ها را افزایش می‌دهد.در برخی از موارد بزرگتر برای طراحی View Model استفاده از این الگو سخت است.زمانی که پیوندهای داده پیچیده باشند،‌ اشکال‌زدایی کمی دشوار است.لایه View Model به مرور زمان بزرگتر می‌شود و پیچیدگی‌های فراخوانی را افزایش می‌دهد.از تعدادی زیادی کد در کنترل‌کننده نگهداری می‌کند.اتصال و چسبندگی محکمی بین view model و view ارائه نمی‌دهد.اگر برنامه به تعداد زیادی تغییر در view و model نیاز داشته باشد، MVVM به خوبی کار می‌کند. با این حال هر شی به طور منظم در دسته‌های view، view model و model قرار نمی‌گیرد. بنابراین باید از MVVM در ترکیب با سایر الگوهای طراحی استفاده کرد.ممکن است زمانی که برای اولین بار MVVM در برنامه ایجاد می‌شود، چندان مفید نباشد و ممکن است الگوی MVC نقطه شروع بهتری باشد. همان طور که نیازمندی‌های برنامه تغییر می‌کند بنابراین باید از الگوهای طراحی متفاوتی و متناسب با نیازمندی‌های جدید و تغییریافته استفاده کرد.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابع و مراجع: https://whatis.techtarget.com/definition/Model-View-ViewModel https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel https://www.tutorialspoint.com/mvvm/mvvm_advantages.htm https://medium.com/swift-india/mvvm-1-a-general-discussion-764581a2d5d9 https://blogsnook.com/mvvm-pattern-advantages/ https://developpaper.com/ios-advantages-and-disadvantages-of-mvc-and-mvvm/ https://cocoacasts.com/what-are-the-benefits-of-model-view-viewmodel https://www.guru99.com/mvc-vs-mvvm.html https://www.raywenderlich.com/34-design-patterns-by-tutorials-mvvm شیما سیف الهی شیما سیف الهی Fri, 10 Dec 2021 19:59:21 +0330 https://virgool.io/@shimaseyfollahi/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D9%85%D8%AF%D9%84-cqrs-bonx70banae8 الگوی CQRS چیست؟تفکیک مسئولیت فرمان کوئری (Command Query Responsibility Segregation)، الگویی است و وظایف سرویس خواندن و نوشتن را از هم جدا می‌کند که اولین بار توسط گرگ یانگ مطرح شد که می‌توان از مدلی متفاوت برای بروزرسانی اطلاعات نسبت به مدلی که برای خواندن اطلاعات استفاده می‌شود، استفاده کرد و عملکرد، مقیاس‌پذیری و امنیت را به حداکثر می‌رساند. CQRS مدل مفهومی را به مدل جداگانه برای بروزرسانی و نمایش معرفی می‌کند و عملیات خواندن و بروزرسانی برای ذخیره داده‌ها را جداسازی می‌کند. در برخی از حالات جداسازی می‌تواند ارزشمند باشد، اما برای بیشتر سیستم‌های CQRS پیچیدگی خطرناکی را ایجاد می‌کند.این مدل یک رویکرد اصلی است که افراد برای تعامل با یک سیستم اطلاعاتی استفاده می‌کنند که به عنوان یک انبار داده رفتار می‌کند. در واقع یک مدل ذهنی از ساختار رکورد است که می‌توان در آن جا اعمالی مانند ایجاد رکورد جدید، خواندن رکوردها، بروزرسانی رکوردهای موجود حذف رکوردها را انجام داد و همه تعاملات در مورد ذخیره و بازیابی رکوردها هستند. انعطاف‌پذیری حاصل از migrate شدن CQRS سبب می‌شود سیستم در طول زمان بهتر تکامل یابد و از ایجاد تداخل‌های ادغام در سطح دامنه توسط بروزرسانی دستورات جلوگیری می‌کند. معمولا فعالیت خواندن بیشتر از فعالیت نوشتن است و فعالیت خواندن تغییر ناپذیر است. بنابراین نسخه‌های مربوط به خواندن داده را می‌توان در نقاط مختلف منتشر کرد. این رویکرد سبب می‌شود تا کاربران داده‌هایی که به آن‌ها نزدیکتر هست را دریافت کنند و سبب ایجاد یک برنامه سازمانی کاراتر می‌گردد.منظور از مدل‌های جداگانه، مدل‌های شی متفاوت است که احتمالا در فرایندهای منطقی متفاوتی و روی سخت‌افزارهای جداگانه ایجاد می‌شوند. به عنوان مثال می‌توان یک صفحه وب را در نظر گرفت که با استفاده از مدل کوئری ارائه شده است. اگر در ابتدا تغییری ایجاد شود که تغییر به مدل فرمان جداگانه برای پردازش هدایت شود، تغییر حاصل به مدل کوئری داده می‌شود تا حالت بروزرسانی شده را ارائه دهد. مدل‌های درون حافظه ممکن است پایگاه داده یکسانی را به اشتراک بگذارند. در برخی موارد پایگاه داده به عنوان ارتباط بین دو مدل عمل می‌کند. اگر چه ممکن است آن‌ها از پایگاه داده‌های جداگانه استفاده کنند، آن‌ها پایگاه داده سمت کوئری را به صورت بلادرنگ به پایگاه داده گزارشی تبدیل می‌کنند. در این موارد باید مکانیزم‌های ارتباطی بین دو مدل یا پایگاه داده‌های آن‌ها وجود داشته باشد.الگوی معماری CQRSمسئلهدر معماری سنتی از یک مدل داده یکسان برای کوئری و بروزرسانی پایگاه داده استفاده می‌شود که رویکردی آسان است و برای عملیات CRUD به خوبی کار می‌کند. در برنامه‌های پیچیده‌تر این رویکرد دشوار است. مثلا در سمت خواندن برنامه ممکن است کوئری‌های مختلفی را انجام دهد و اشیای انتقال داده را با اشکال مختلف برگرداند و نگاشت اشیا ممکن است پیچیده و دشوار شود. در سمت نوشتن مدل ممکن است اعتبارسنجی و منطق کسب و کار پیچیده را پیاده‌سازی کند. اغلب یک عدم تطابق بین خواندن و نوشتن داده وجود دارد، مانند ستون‌ها یا ویژگی‌های اضافی که باید به درستی بروزرسانی شوند حتی اگر به عنوان بخشی از یک عملیات مورد نیاز نباشند.زمانی که عملیات به صورت موازی روی یک مجموعه داده یکسان انجام می‌شوند، ممکن است اختلاف داده رخ دهد. رویکردهای سنتی به دلیل بارگذاری روی ذخیره داده و لایه دسترسی به داده و کوئری‌های پیچیده مورد نیاز برای بازیابی اطلاعات می‌توانند تاثیر منفی بر عملکرد داشته باشند و مدیریت امنیت و مجوزها می‌تواند پیچیده باشد زیرا هر موجودیتی که تحت هر دو عمل خواندن و نوشتن است، ممکن است داده‌ها را با محتوای نادرستی نمایش دهد.معماری سنتیراه حلمدل CQRS خواندن‌ها و نوشتن‌ها را در مدل‌های مختلف با استفاده از دستورات بروزرسانی داده و کوئری برای خواندن داده جدا می‌کند. دستورات باید مبتنی بر وظیفه باشند و داده محور نباشند. دستورات ممکن است در یک صف برای پردازش ناهمگام قرار گیرند و به صورت همگام پردازش نمی‌شوند. کوئری‌ها هرگز پایگاه داده را تغییر نمی‌دهند. یک کوئری یک شی انتقال داده را برمی‌گرداند که هیچ اطلاعی از دامنه را کپسوله نمی‌کند.الگوی CQRS پایهداشتن کوئری و مدل‌های بروزرسانی جداگانه طراحی و پیاده‌سازی را آسان می‌سازد. برای جداسازی بیشتر می‌توان خواندن داده را از نوشتن داده به صورت فیزیکی جدا کرد. در این صورت پایگاه داده خوانده شده می‌تواند از طرح داده خودش برای بهینه‌سازی کوئری استفاده کند یا ممکن است از نوع متفاوتی از ذخیره داده استفاده کند. مثلا ممکن است پایگاه داده نوشته شده یک پایگاه داده رابطه ای باشد در حالی که پایگاه داده خوانده شده یک سند پایگاه داده باشد.اگر از پایگاه داده‌های خواندن و نوشتن مجزا استفاده شود، باید به صورت هماهنگ نگهداری شوند که معمولا با انتشار مدل نوشتن یک رویداد، هر زمان که پایگاه داده را بروزرسانی می‌کند انجام می‌شود. ذخیره خواندن می‌تواند یک نسخه فقط خواندنی از مخزن نوشتن باشد یا مخزن های خواندن و نوشتن می‌توانند ساختارهای متفاوتی با یکدیگر داشته باشند. با استفاده از چند نسخه فقط خواندنی می‌توان عملکرد کوئری را افزایش داد. به ویژه در نسخه‌های توزیع شده که نسخه‌های فقط خواندنی نزدیک نمونه‌های برنامه قرار دارند. جداسازی مخزن‌های خواندن و نوشتن همچنین سبب مقیاس‌بندی مناسب و متناسب با بار می‌گردد. مثلا معمولا مخازن خواندن بار بیشتری نسبت به مخازن نوشتن دارند.جداسازی مخازن خواندن و نوشتن در الگوی CQRSانواع معماری CQRSمدل CQRS با یک پایگاه داده: در یک پایگاه داده CQRS هر دو سمت کوئری و فرمان به یک پایگاه داده مرتبط هستند. دستورات use-caseها را در دامنه اجرا می‌کنند که وضعیت موجودیت را تغییر می‌دهد. سپس موجودیت در پایگاه داده ذخیره می‌شود. کوئری‌ها به طور مستقیم از طریق دسترسی به لایه داده اجرا می‌شوند.Single Database CQRSمدل CQRS با دو پایگاه داده: دو پایگاه وجود دارد که یکی برای عملیات نوشتن و دیگری برای عملیات خواندن است. سمت فرمان از پایگاه داده نوشتن بهینه‌ شده برای عملیات نوشتن استفاده می‌کند و سمت کوئری از پایگاه داده خواندن بهینه شده برای عملیات خواندن استفاده می‌کند. با تغییر هر حالت توسط فرمان، داده تغییر یافته باید از پایگاه داده نوشتن به پایگاه داده خواندن به عنوان یک تراکنش هماهنگ واحد در میان هر دو پایگاه داده یا با استفاده از الگوی سازگاری احتمالی منتقل می‌شود. این معماری سبب بهبود عملکرد سمت کوئری نرم‌افزار می‌شود زیرا کاربران وقت بیشتری را برای خواندن داده‌ها نسبت به نوشتن داده‌ها صرف می کنند.Two-Database CQRSمدل CQRS برای یافتن منبع رویداد: پیچیده‌ترین معماری CQRS است و وضعیت برنامه به صورت یک توالی از رویدادها ذخیره می‌شود که هر رویداد نمایانگر یک مجموعه تغییر برای داده است. رویداد فعلی با اجرای دوباره رویدادها ایجاد می‌شود. می‌توان از یک رویداد برای اطلاع‌رسانی سایر اجزا به ویژه برای اطلاع رسانی مدل خواندن استفاده کرد. در این رویکرد فقط موجودیت‌های وضعیت فعلی ذخیره نمی‌شوند و هر حالتی که برای موجودیت رخ داده است به عنوان تصاویر لحظه‌ای ذخیره می‌شوند. مدل خواندن از رویدادها برای ایجاد یک تصویر لحظه‌ای وضعیت فعلی استفاده می‌شود که برای کوئری کاراتر است. موجودیت‌ها به عنوان داده‌های نرمال ذخیره نمی‌شوند بلکه به عنوان تغییرات مستقیم با زمان مهر یک رویداد ذخیره می‌شوند. فرمان‌ها می‌توانند موجودیت فعلی را تغییر دهند. تغییرات رویداد جدید را تولید می‌کنند که در منبع رویداد ذخیره می‌شوند. بنابراین وضعیت فعلی موجودیت در یک پایگاه داده خواندن قرار داده می‌شود تا خواندن بسیار سریع صورت گیرد. یافتن منبع رویداد سبب افزایش پیچیدگی‌ می‌گردد.Event-Sourcing CQRSمؤلفه‌های مورد استفاده در مدل CQRSسمت Query: باید مسئول و بهینه‌ شده برای خواندن داده باشد. کوئری‌ها داده را می‌خوانند و سپس آن‌ها را در فرم مورد نیاز به لایه presentation نگاشت می‌کنند. این فرم‌ها به عنوان اشیای انتقال داده شناسایی می‌شوند.سمت Commands: مسئول و بهینه شده برای نوشتن داده است. دستورات موارد مورد استفاده ر اجرا می‌کنند، وضعیت‌های موجودیت‌ها را تغییر می‌دهند و آن‌ها را ذخیره می‌کنند.موارد استفاده از مدل CQRSاین مدل در بخش‌های خاصی از یک سیستم یعنی لایه برنامه استفاده می‌شود و در کل سیستم استفاده نمی‌شود. این مدل لایه برنامه را به دو سمت دستورات و کوئری‌ها تقسیم می‌کند.با استفاده از CQRS می‌توان به آسانی با چند دامنه پیچیده مقابله کرد. معمولا همپوشانی کافی سمت فرمان و کوئری وجود دارد که به اشتراک‌گذاری یک مدل را تسهیل می‌کند.سبب مدیریت برنامه‌هایی با کارایی بالا می‌گردد. می‌توان load را به صورت مجزا از خواندن و نوشتن انجام داد و می‌توان هر یک را به صورت جداگانه مقیاس‌گذاری کرد. اگر برنامه تفاوت زیادی را بین خواندن‌ها و نوشتن‌ها مشاهده کند، سودمند است.دامنه‌های مشارکتی که در آن‌ها بسیاری از کاربران به داده یکسان به طور موازی دسترسی دارند. با استفاده از CQRS می‌توان دستوراتی با دانه‌بندی کافی با کمینه کردن تداخلات ادغام در سطح دامنه تعریف کرد و تداخل‌های حاصل را می‌توان با دستورات ادغام کرد. رابط‌های کاربری مبتنی بر وظیفه که در آن کاربران از طریق یک فرایند پیچیده به عنوان یکی سری از گام‌ها با مدل‌های دامنه پیچیده هدایت می‌شوند. مدل نوشتن یک پشته پردازش دستور کامل با منطق کسب و کار، اعتبارسنجی ورودی و اعتبارسنجی کسب و کار است. مدل نوشتن ممکن است به عنوان مجموعه‌ای از اشیای مرتبط به عنوان یک واحد برای تغییرات داده (یک جمع در اصطلاح طراحی مدل محور) رفتار کند که باید همیشه این اشیا در وضعیتی ثابت باشند. مدل خواندن منطق کسب و کار یا پشته اعتبارسنجی ندارد و فقط یک شی انتقال داده را برای استفاده در مدل view را برمی‌گرداند. مدل خواندن با مدل نوشتن سازگار است.سناریوهایی که یک تیم توسعه‌دهنده می‌تواند روی مدل دامنه پیچیده که بخشی از مدل نوشتن است، تمرکز کند و تیم‌های دیگر می‌توانند روی مدل‌ خواندن و رابط کاربری تمرکز کنند.سناریوهایی که انتظار می‌رود سیستم در طول زمان تکامل یابد و ممکن است شامل چندین نسخه از مدل باشند یا جایی که قوانین کسب و کار به طور منظم تغییر می‌کنند.ادغام با سایر سیستم‌ها به ویژه در ترکیب با منبع رویداد که در آن جا خرابی موقت یک زیر سیستم نباید روی در دسترس پذیری سایر سیستم‌ها تاثیر بگذارد.موارد عدم استفاده از مدل CQRSزمانی که دامنه یا قوانین کسب و کار ساده هستند یا زمانی که رابط کاربری ساده است و عملیات دسترسی به داده کافی هست، این مدل توصیه نمی‌شود.استفاده از CQRS در دامنه‌ای که با آن مطابقت ندارد، پیچیدگی را افزایش می‌دهد، بنابراین سبب کاهش بهره‌وری و افزایش ریسک می‌گردد.اگر دامنه برای CQRS مناسب نباشد و کوئری‌ها پیچیدگی‌ها یا مشکلات عملکردی اضافه کنند، می‌توان از پایگاه داده گزارش استفاده کرد، زیرا CQRS از یک مدل مجزا برای کوئری‌ها استفاده می‌کند. با استفاده از پایگاه داده گزارش می‌توان از سیستم اصلی برای بیشتر کوئری‌ها استفاده کرد.تعدادی از سیستم‌های اطلاعاتی که با مفهوم یک پایگاه اطلاعاتی که با همان روی که خوانده می‌شوند بروزرسانی می‌شوند، به خوبی مطابقت دارند. افزودن CQRS به چنین سیستم‌هایی سبب پیچیدگی معناداری می‌شود.چالش‌های پیاده‌سازی مدل CQRSپیچیدگی: مدل CQRS برای پایه سادگی بنا نهاده شده است ولی ممکن است منجر به طراحی برنامه پیچیده‌تر منجر می‌شود. به خصوص اگر شامل الگوی منبع رویداد باشد.پیام‌رسانی: اگر چه مدل CQRS نیاز به پیام‌رسانی ندارد، استفاده از پیام‌رسان برای پردازش دستورات و انتشار رویدادهای بروزرسانی شده مرسوم است. برنامه باید از پیام‌های خراب و تکراری جلوگیری کند.ثبات احتمالی: اگر پایگاه داده خواندن و نوشتن از یکدیگر جدا شوند، داده خوانده شده ممکن است قدیمی شود. مدل خواندن ذخیره شده باید بروزرسانی شود تا تغییرات در مدل نوشتن ذخیره شده منعکس شود. زمانی که کاربر درخواستی را بر اساس داده خوانده شده قدیمی می‌دهد، تشخیص دشوار می‌باشد.مزایای مدل CQRSجداسازی فعالیت‌های خواندن از فعالیت‌های نوشتن سبب می‌شود تا بتوان از بهترین فناوری پایگاه داده برای وظایف استفاده کرد. مثلا یک پایگاه داده SQL برای نوشتن و یک پایگاه داده non-SQL برای خواندن مورد استفاده قرار می‌گیرد.تعداد فعالیت خواندن بیشتر از تعداد فعالیت نوشتن است، بنابراین می‌توان تاخیر زمان پاسخ را با قرار دادن منابع خواندن داده در موقعیت‌‌های جغرافیایی استراتژیک برای افزایش عملکرد کاهش داد.جداسازی فعالیت خواندن از فعالیت نوشتن منجر به مقیا‌س‌بندی کاراتر ظرفیت ذخیره‌سازی بر اساس استفاده در دنیای واقعی می‌شود.مرزهای بین رفتار سیستم را پاک می‌کند یعنی راهنمایی خاصی روی ساختار برنامه در رابطه با رفتار ارائه می‌دهد.به منطق تجاری نزدیکتر است. کد و معماری توسط عملیات تجاری آن‌ها مجزا شدند و تمرکز بر روی موارد کسب و کار را آسان‌تر می‌سازد.سبب اتصال و چسبندگی ضعیف می‌گردد. منطق به صورت منسجم است و کمتر به هم مرتبط است و ایجاد برنامه‌های ماژولار و قابل نگهداری را آسان‌تر می‌سازد.سبب کاهش بار شناختی می‌گردد. به دلیل جداسازی عمودی، کدهای مرتبط با هم نگه داشته می‌شوند. برای تغییر کد موجود یا ایجاد کد جدید نیاز به درک کل معماری یا منطق کسب و کار نیست و تمرکز روی یک کار خاص آسان‌تر است.سبب مقیاس‌بندی آسان، بهینه‌سازی و تغییرات معماری می‌شود. به دلیل نگهداری کد در منابع ذخیره‌سازی، تنظیم دقیق یک خط لوله آسان‌تر است. تمرکز روی بهینه‌سازی‌های دقیق در مکان‌های بحرانی برای کسب و کار، آسان‌تر است.قابل پیش‌بینی است. به دلیل جداسازی قوانین کلی برای رفتار عملیات وجود دارد. تغییر وضعیت کوئری برنامه تعجب‌آور نیست. حفظ فاصله بین نوشتن و خواندن، احتمال پایان یافتن با کد spaghetti را کاهش می‌دهد.معایب مدل CQRSپشتیبانی از الگوی CQRS نیاز به تخصص در انواع فناوری‌های پایگاه داده دارد.استفاده از الگوی CQRS به معنی نیاز به فناوری پایگاه داده بیشتر است، بنابراین هزینه‌های سخت‌افزاری و هزینه‌های مربوط به ابر در صورت استفاده از یک ارائه‌دهنده ابر وجود دارند.سازگاری داده نیاز به توجه ویژه به قراردادهای سطح سرویس دارد.استفاده از تعداد زیادی پایگاه داده به معنی نقاط خرابی بیشتر است. بنابراین باید مکانیزم‌های ایمنی و نظارتی کاملی برای ارائه عملکرد مناسب داشته باشد.استفاده از CQRS در یک سیستم سبب سربار و پیچیدگی معناداری می‌شود. به جای استفاده از یک مدل و فناوری داده واحد، توسعه‌دهندگان باید حداقل از دو مدل داده و چندین فناوری بالقوه استفاده کنند.مشکل دیگر همگام‌سازی فرمان و مدل‌های داده کوئری است. اگر انتخابی سبب ناهمگامی بروزرسانی‌ها شود، کل سیستم منجر به ناسازگاری احتمالی می شود. حتی یک نیاز واحد برای سازگاری می‌تواند کل طراحی را به خطر بیندازد.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابع و مراجع: https://levelup.gitconnected.com/3-cqrs-architectures-that-every-software-architect-should-know-a7f69aae8b6c https://martinfowler.com/bliki/CQRS.html https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs https://www.redhat.com/architect/pros-and-cons-cqrs https://www.eventstore.com/cqrs-pattern شیما سیف الهی شیما سیف الهی Fri, 10 Dec 2021 02:35:58 +0330 https://virgool.io/@shimaseyfollahi/%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%D8%A7-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-%D9%85%D8%AF%D9%84-c4-uyvxfypkuori مدل C4 (context containers components codes) رویکردی ساده برای یادگیری و ایجاد نمودارهای معماری نرم‌افزار و نقشه‌های کد است. مدل C4 یک رویکردی انتزاعی برای ایجاد نمودار معماری نرم‌افزار بر اساس انتزاع است و نشان می‌دهد که معماران و توسعه‌دهندگان نرم‌افزار چگونه در مورد نرم‌افزار و ساخت آن فکر می‌کنند. برای ایجاد نقشه‌هایی از کد ابتدا به یک مجموعه‌ای از انتزاعات مشترک نیاز است تا زبانی مشترک ایجاد شود و برای توصیف ساختار ایستای سیستم نرم‌افزاری مورد استفاده قرار گیرد. این مدل به تیم‌های توسعه نرم‌افزار برای توصیف و برقراری ارتباط موثر با معماری نرم‌افزار خود در سطوح مختلف جزئیات، بیان سناریوهای مختلف برای مخاطبان در هنگام انجام طراحی یا مستندسازی در یک پایگاه کد موجود کمک می‌کند. یک روش نشانه‌گذاری گرافیکی نادر برای مدل‌سازی معماری سیستم‌های نرم‌افزاری است و مبتنی بر تجزیه ساختاری یک سیستم به containerها و مؤلفه‌ها است. مدل C4 توسط معمار نرم‌افزاری به نام Simon Brown در سال‌های ۲۰۰۶ تا ۲۰۱۱ ایجاد شد. می‌توان از مدل C4 برای میکرو سرویس‌ها به منظور ساخت و توصیف یک سیستم استفاده کرد. نمودار C4 یک چارچوب جایگزین ساده شده برای نمودارهای UML است و می‌تواند چندین سیستم را توصیف کند. مدل C4این مدل دارای 4 سطح نمودار و انتزاع به صورت سلسله مراتبی است که این نمودارها باید به ترتیب رسم شوند. C4 معماری یک سیستم نرم‌افزاری را با نمایش چند دیدگاه مستند می‌کند و تجزیه یک سیستم نرم‌افزاری را به containerها، مؤلفه‌ها، ارتباط بین این عناصر، مکان مناسب و رابطه با کاربران توضیح می‌دهد. مدل C4 ساختار ایستای یک سیستم نرم‌افزاری را از نظر محتوا، containerها، مؤلفه‌ها و کد (UML class) در نظر می‌گیرد و درک خوبی از ساختار ایستا را برای نمایش سایر جنبه‌ها ارائه می‌دهد. یک سیستم نرم‌افزاری از یک یا چند container (برنامه‌های تحت وب، برنامه‌های موبایل، برنامه‌های کامپیوتر، پایگاه داده‌ها، سیستم‌های فایل و …) تشکیل شده است که هر container شامل یک یا چند مؤلفه است و هر مؤلفه توسط یک یا چند عنصر کد (کلاس‌ها،‌ interfaceها، اشیا، توابع و …) پیاده‌سازی شده است. شکل 2 نمایی از سطوح و سلسله مراتب مدل C4 را نمایش می‌دهد.سطوح و سلسله مراتب مدل C4سطح ۱: نمودار محتوا (context) سیستمیک نمودار محتوا یک نقطه شروع خوب برای ترسیم نمودار و مستندسازی یک سیستم نرم‌افزاری است و نشان می‌دهد که چگونه یک سیستم نرم‌افزاری از نظر دامنه با دنیای اطراف خود تناسب دارد. در یک نمودار، سیستم به عنوان جعبه‌ای در مرکز قرار دارد که توسط کاربران و سیستم‌های دیگر که با آن در تعامل هستند، محصور شده است. در این نمودار جزئیات مهم نیست و باید بر روی افراد و سیستم‌های نرم‌افزاری به جای فناوری‌ها، پروتکل‌ها و سایر جزئیات سطح پایین تمرکز شود و می‌توان این نمودار را به افراد غیر فنی نیز نشان داد. دامنه آن یک سیستم نرم‌افزاری واحد است. عنصر اصلی، سیستم نرم‌افزاری در دامنه است. عناصر پشتیبان شامل افراد (کاربران، نقش‌ها،‌کارکنان یا شخصیت‌ها)، سیستم‌های نرم‌افزاری (وابستگی‌های خارجی) است که به طور مستقیم به سیستم نرم‌افزاری در دامنه متصل شده‌اند. معمولا سیستم‌های نرم‌افزاری دیگر در خارج دامنه یا مرز سیستم نرم‌افزاری مورد نظر قرار می‌گیرند. مخاطب آن همه افراد فنی و غیر فنی و افراد داخل و خارج تیم توسعه نرم‌افزار است. سطح محتوا، سیستم را از نظر حوزه و ارتباط با کاربران و سایر سیستم‌ها نمایش می‌دهد و توصیف کلی‌تری از عملیات سیستم، دامنه و کاربران سیستم و سیستم‌هایی که با سیستم مورد نظر در تعامل هستند ارائه می‌دهد.نمودار contextسطح ۲: نمودار Containerبا استفاده از نمودار container می‌توان مرز یک سیستم را بررسی کرد و سیستم نرم‌افزاری را از نظر دامنه بزرگنمایی و بررسی می‌کند که docker نیست. container در واقع برنامه تحت وب سمت سرور، برنامه تک صفحه‌ای،‌ برنامه دسکتاپی، برنامه موبایل، طرح پایگاه‌ داده، پایگاه داده ذخیره شده، سیستم فایل و ... است که برای استقرار و اجرای کد و ذخیره داده‌ها مورد استفاده قرار می‌گیرد و یک برنامه کاربردی یا یک داده ذخیره شده را نمایش می‌دهد که در آن تعدادی کد توسعه یافته است. container باید در حال اجرا باشد تا کل سیستم نرم‌افزاری کار کند. نمودار container معماری نرم‌افزار در سطح بالا و نحوه توزیع مسئولیت‌ها در آن را نمایش می‌دهد. همچنین نحوه ارتباط containerها با یکدیگر را نشان می‌دهد. حوزه و دامنه آن یک سیستم نرم‌افزاری واحد است. عناصر اصلی، containerهای داخل سیستم‌ نرم‌افزاری در دامنه و عناصر پشتیبانی افراد و سیستم‌های نرم‌افزاری هستند که به طور مستقیم به containerها متصل شدند. مخاطبان آن افراد فنی در داخل و خارج تیم توسعه نرم‌افزار، توسعه‌دهندگان و کارکنان عملیاتی و پشتیبانی هستند. container از مؤلفه‌هایی ساخته شده است. این نمودار یک سیستم را به containerهای مرتبط تجزیه می‌کند. container یک ظرف یا محیط زمان اجرای قابل استقرار و قابل اجرای مجزا است که معمولا در فضای فرایندهای خود اجرا می‌شود. به همین دلیل ارتباط بین containerها معمولا به شکل ارتباط بین فرایندی است. نمودار containerسطح ۳: نمودار مؤلفه (Component)در این مرحله هر container برای تشخیص بلاک‌های ساختار اصلی و تعاملات آن‌ها بزرگنمایی و تجزیه می‌شوند. یک container از تعدادی مؤلفه تشکیل شده است که هر مؤلفه مسئولیت‌های آن‌ها و جزئیات فناوری و پیاده‌سازی است و از مجموعه قوانین کمتری برای ایجاد نمودار معماری نرم‌افزار استفاده می‌کند. دامنه و حوزه مؤلفه، یک container و عناصر اصلی آن مؤلفه‌های داخل یک container در دامنه است. عناصر پشتیبانی شامل container (در سیستم نرم‌افزاری در محدوده) به علاوه افراد و سیستم‌های نرم‌افزاری هستند که به طور مستقیم به مؤلفه‌ها متصل شدند. مخاطبان این نمودار معماران و توسعه‌دهندگان سیستم نرم‌افزاری هستند. در صورتی نمودارهای مؤلفه ارزش افزوده داشته باشند و برای مستندسازی طولانی مدت در نظر گرفته شوند، ایجاد می‌شوند. این نمودار یک گروه‌بندی با ماژولاریتی و مرزبندی خوب و رابط کاربری ساده است که داخل container اجرا می‌شود. این نمودار container را به مؤلفه‌های مرتبط تجزیه می‌کند و مؤلفه‌ها را به سایر containerها و سیستم‌ها، مرتبط می‌کند. نمودار component یک مجموعه از عملکردهای مرتبط است که واحدهای قابل استقرار مجزا نیستند که در زبان‌هایی مانند Java و C++ یک مجموعه‌ای از کلاس‌های پیاده‌سازی شده در پشت یک interface است. همه اجزای داخل یک container معمولا در همان فضای فرایند اجرا می‌شوند. هر مؤلفه‌ از عناصر سطح کد ساخته شده‌اند. نمودار componentسطح ۴: نمودار کد (Code)در این مرحله می‌توان هر مؤلفه را بزرگنمایی و بررسی کرد تا نحوه پیاده‌سازی کد آن را با استفاده از نمودارهای UML class، نمودارهای ارتباط موجودیت و … نشان دهد. نمودار کد یک سطح اختیاری از جزئیات است و فقط برای مهم‌ترین و پیچیده‌ترین اجزا به کار می‌رود و برای اسناد طولانی مدت توصیه نمی‌شود. برای این منظور نمودارهای موجود مانند UML (زبان مدل‌سازی یکپارچه)، ERD (نمودارهای رابطه موجودیت) یا IDE (نمودارهای تولید شده توسط محیط توسعه یکپارچه) ایجاد می‌شود.در بهترین حالت این نمودار به صورت خودکار با استفاده از ابزار تولید می‌شود و فقط ویژگی‌ها و متدهایی نمایش داده می‌شوند که امکان ایجاد یک سناریو را فراهم می‌کنند. حوزه این نمودار یک مؤلفه واحد است. عناصر اصلی آن همان عناصر اصلی کد یعنی کلاس‌ها، رابط‌ها، اشیا، توابع، جداول پایگاه داده و ... در مؤلفه در دامنه است و مخاطبان آن معماران و توسعه‌دهندگان نرم‌افزار هستند. بیشتر IDEها می‌توانند این سطح از جزئیات را بر اساس تقاضا تولید کنند. این نمودار جزئیات اضافی درباره طراحی عناصر معماری که می‌توانند روی کد نگاشت شوند را ارائه می‌دهد.نمودار codeمدل C4 برای سطوح ۱ تا ۳ از ۵ عنصر مدل‌سازی اصلی شامل افراد،‌سیستم‌های نرم‌افزاری، containerها، مؤلفه‌ها و روابط استفاده می‌کند. این روش نسخه‌ای برای طرح‌بندی، شکل، رنگ و سبک این عناصر ندارد. C4 به استفاده از نمودارهای آسان بر اساس جعبه‌های تو در تو به منظور تسهیل ترسیم مشارکتی تعاملی توصیه می‌کند. همچنین شیوه‌های مدل‌سازی خوب مانند ارائه عنوان و توضیحات روی هر نمودار و برچسب‌گذاری بدون ابهام به منظور تسهیل درک مخاطبان را ترویج می‌دهد. مدل C4 معماری بصری مشارکتی و معماری تکاملی در زمینه تیم‌های agile که در روش‌های مستندسازی رسمی‌تر و طراحی معماری اولیه مطلوب نیستند را تسهیل می‌کند.نرم‌افزار Gliffy برای ایجاد مدل C4برای ایجاد مدل C4 می‌توان از نرم‌افزار Gliffy استفاده کرد. برای این منظور می‌توان در دیاگرام از لینک‌هایی مستقیم بر روی شکل‌ها استفاده کرد و با دو بار کلیک می‌توان به سطوح عمیق‌تر مدل دسترسی پیدا کرد. رسم نمودار C4 با استفاده از این ابزار دارای چند مرحله است که عبارتند از:‌1) استفاده از Drag & Drop شکل‌ها برای رسم نمودار context با استفاده از اشکال اصلی برای ساخت نمودار مانند کاربر و سیستم‌های متصل به سیستم و اضافه کردن متنی به عنوان برچسب یا توصیف اجزا2) ایجاد کلیدی برای تصریح و وضوح نمودارها و تنظیم قوانینی نمودارها برای ایجاد نمودارهای اضافی یک مدل C4، ایجاد ویژگی‌های بصری مانند رنگ و خواندن و درک آسان هر ۴ نمودار در ارتباط با یکدیگر3) رسم اتصالات بین مؤلفه‌ها در نمودار با استفاده از ابزار اتصال، drag and drop خطوط بین عناصر، تغییر سبک خطوط، استفاده از پیکان‌هایی برای نمایش جریان مستقیم داده در سیستم و ایجاد برچسب برای خطوط4) ایجاد یک لایه جدید در نمودار بعدی در مدل،‌ امکان تغییر نام و کپی لایه، تغییر دید لایه‌ها و قفل کردن لایه‌ها برای جلوگیری از تغییرات تصادفی5) تکرار مراحل ۱ تا ۴ برای رسم نمودار container و استفاده از اشکال و اطلاعات در آن برای رسیدن به سطح عمیق‌تر از جزئیات، استفاده از یک شی یا مستطیل به منظور ایجاد مرزی برای عناصر موجود در container و کپی لایه نمودار container به عنوان پایه یا الگویی برای نمودار مؤلفه6) تکرار مراحل ۱ تا ۴ برای رسم نمودار مؤلفه برای شرح جزئیات کد داخل container در لایه قبلی7) تکرار مراحل ۱ تا ۴ برای رسم نمودار کد یا کلاس برای شرح جزئیات کد در سیستم، ضروری نبودن این نمودار برای توصیف معماری سیستم و امکان رسم نمودار UML class برای توصیف این کد8) اضافه کردن پیوندهای هر لایه برای اضافه کردن هر لایه، استفاده از ویژگی‌های پیوند لایه پویا برای ایجاد لایه‌ جدیدی به نام نمای لایه و سپس ایجاد ۴ دکمه برای انتخاب، جا‌به‌جایی و تغییر وضعیت در لایه‌های مدل C49) ذخیره، جاسازی و اشتراک‌گذاری مدلابزار Gliffyاین مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهید بهشتی است. منابع و مراجع: https://c4model.com/ https://www.youtube.com/watch?v=x2-rSnhpw0g https://en.wikipedia.org/wiki/C4_model https://www.gliffy.com/blog/c4-model شیما سیف الهی شیما سیف الهی Tue, 07 Dec 2021 02:08:12 +0330