نوشته های محمد صادقی

بررسی روند تکامل معماری نرم‌افزار در سازمان‌های بزرگ

محمد صادقی — Thu, 23 Jul 2026 21:58:57 +0330

چکیدهمعماری نرم‌افزار نقش بنیادینی در موفقیت سامانه‌های نرم‌افزاری ایفا می‌کند و تصمیمات معماری اتخاذشده در مراحل مختلف توسعه، تأثیر مستقیمی بر ویژگی‌های کیفی، قابلیت توسعه و نگهداشت سیستم دارند. از آنجا که نیازهای کسب‌وکار، فناوری‌ها و حجم کاربران در طول زمان تغییر می‌کنند، معماری نرم‌افزار نیز ناگزیر از تکامل و انطباق با این تغییرات است. بررسی روند تکامل معماری در سامانه‌های واقعی می‌تواند دید مناسبی نسبت به دلایل تغییرات، تصمیمات اتخاذشده و آثار آن‌ها بر کیفیت سیستم ارائه کند.سازمان های موفق مقیاس وسیعدر این مقاله روند تکامل معماری سه سامانه نرم‌افزاری مورد مطالعه قرار گرفته و تغییرات معماری هر سامانه از منظر ساختار، اجزای اصلی، شیوه تعامل مؤلفه‌ها و تصمیمات کلیدی معماری تحلیل شده است. سپس این سامانه‌ها بر اساس مجموعه‌ای از ویژگی‌های کیفی شامل کارایی، دسترس‌پذیری، نگهداشت‌پذیری و توسعه‌پذیری با یکدیگر مقایسه شده‌اند. همچنین تصمیمات معماری اتخاذشده در هر مرحله و تأثیر آن‌ها بر کیفیت کلی سامانه مورد بررسی قرار گرفته است.نتایج این پژوهش نشان می‌دهد که با رشد سامانه‌ها، معماری آن‌ها به سمت کاهش وابستگی میان اجزا، افزایش استقلال سرویس‌ها، بهره‌گیری از ارتباطات غیرهمزمان و استفاده از زیرساخت‌های مدرن استقرار حرکت کرده است. همچنین مشخص شد که انتخاب آگاهانه تصمیمات معماری در مراحل اولیه توسعه، نقش مهمی در کاهش هزینه‌های توسعه و نگهداشت، افزایش انعطاف‌پذیری و پاسخ‌گویی بهتر به نیازهای جدید کسب‌وکار ایفا می‌کند.کلیدواژه‌ها: معماری نرم‌افزار، تکامل معماری، تصمیمات کلان معماری، ویژگی‌های کیفیروند تکامل معماری نرم‌افزار AirbnbمعرفیAirbnb یکی از بزرگ‌ترین سامانه‌های رزرو اقامتگاه در جهان است که فعالیت خود را از سال ۲۰۰۸ آغاز کرد. رشد سریع تعداد کاربران، میزبانان، اقامتگاه‌ها و تراکنش‌های رزرو موجب شد نیازهای معماری این سامانه در طول زمان به‌طور چشمگیری تغییر کند. معماری اولیه که برای یک استارتاپ کوچک مناسب بود، پس از چند سال دیگر پاسخگوی مقیاس سیستم و سرعت توسعه موردنیاز نبود. ازاین‌رو Airbnb طی چند مرحله معماری خود را بازطراحی کرد تا علاوه بر افزایش مقیاس‌پذیری، استقلال تیم‌های توسعه، قابلیت نگهداری و سرعت ارائه قابلیت‌های جدید نیز بهبود یابد.معماری اولیهنسخه‌های اولیه Airbnb با استفاده از Ruby on Rails و به صورت یک Monolithic Application توسعه یافت. در این معماری تمام بخش‌های سیستم شامل رابط کاربری، منطق کسب‌وکار و دسترسی به داده در یک مخزن کد و یک فرآیند اجرایی قرار داشتند. این رویکرد در سال‌های ابتدایی مزایایی مانند سادگی توسعه، استقرار سریع و مناسب بودن برای تیم کوچک توسعه را فراهم می‌کرد.انتخاب معماری Monolith در ابتدای کار به چند دلیل تصمیمی کاملاً منطقی بود:تیم توسعه بسیار کوچک بود و هماهنگی میان اعضا ساده انجام می‌شد.سرعت توسعه اولیه اهمیت بیشتری نسبت به مقیاس‌پذیری داشت.استقرار سیستم تنها با یک فرآیند انجام می‌شد.چارچوب Ruby on Rails امکانات فراوانی برای توسعه سریع محصولات اولیه (MVP) فراهم می‌کرد.تغییرات در سیستم بدون نیاز به هماهنگی میان چندین سرویس مختلف انجام می‌شد.در این مرحله، معماری یکپارچه موجب شد Airbnb بتواند در مدت کوتاهی محصول اولیه خود را توسعه داده و وارد بازار شود.معماری یکپارچه Airbnbدلایل تغییر معماریبا رشد سریع شرکت، محدودیت‌های معماری Monolith به تدریج آشکار شد. تعداد توسعه‌دهندگان از چند نفر به صدها مهندس افزایش یافت و همه تیم‌ها روی یک مخزن کد مشترک فعالیت می‌کردند. در نتیجه مشکلات زیر ایجاد شد:1.افزایش وابستگی بین بخش‌های مختلف سیستمتمام قابلیت‌ها در یک کدبیس مشترک قرار داشتند؛ بنابراین تغییر در یک قسمت می‌توانست به‌صورت ناخواسته سایر قسمت‌های سیستم را تحت تأثیر قرار دهد. این وابستگی‌ها فرآیند توسعه و آزمون را پیچیده‌تر می‌کرد.2.کاهش سرعت توسعهبا بزرگ شدن کدبیس زمان Build، اجرای تست‌ها و انتشار نسخه‌های جدید افزایش یافت. همچنین توسعه‌دهندگان برای اعمال تغییرات کوچک نیز ناچار بودند کل سامانه را Build و Deploy کنند.3.دشوار شدن استقراردر معماری Monolith امکان استقرار مستقل هر قابلیت وجود نداشت. انتشار هر نسخه جدید مستلزم استقرار کل سامانه بود و در صورت بروز خطا احتمال اختلال در تمامی سرویس‌ها وجود داشت.4.محدودیت در مقیاس‌پذیریتمام اجزای سیستم به‌صورت یکپارچه مقیاس می‌یافتند. درحالی‌که ممکن بود تنها یک بخش مانند سیستم جستجو یا رزرو نیازمند منابع بیشتر باشد، کل برنامه باید روی سرورهای بیشتری اجرا می‌شد که موجب افزایش هزینه زیرساخت می‌شد.5.افزایش پیچیدگی سازمانیرشد تعداد تیم‌های توسعه باعث شد مرز مسئولیت‌ها مشخص نباشد. تیم‌های مختلف ناچار بودند برای ایجاد تغییرات کوچک نیز با یکدیگر هماهنگ شوند که این موضوع سرعت توسعه را کاهش می‌داد.معماری جدیدAirbnb به جای مهاجرت ناگهانی به معماری Microservices، مسیر تدریجی را انتخاب کرد و به سمت معماری سرویس گرا یا SOA حرکت نمود. در این رویکرد قابلیت‌های اصلی سیستم به سرویس‌های مستقل تقسیم شدند.سرویس هایی مثل:مدیریت کاربرانمدیریت اقامتگاه‌هاسیستم رزروپرداختجستجوپیامرسانیدرین معماری، هر سرویس مسئول منطق کسب‌وکار مربوط به خود بود و از طریق API با سایر سرویس‌ها ارتباط برقرار می‌کرد. این معماری باعث شد هر تیم مالک سرویس خود باشد و توسعه قابلیت‌های جدید مستقل‌تر انجام شود. همچنین امکان استقرار سرویس‌ها به‌صورت جداگانه فراهم بود که این قابلیت منجر به از دسترس خارج نشدن کل سامانه در صورت خرابی یک سرویس میشد. بعلاوه فقط سرویس‌هایی که بار بیشتری داشتند مقیاس داده میشدند.تکامل زیرساخت توسعهبا افزایش تعداد سرویس‌ها، مدیریت ارتباط میان آن‌ها نیز به یک چالش جدید تبدیل شد. Airbnb برای کاهش این پیچیدگی مجموعه‌ای از ابزارهای داخلی را توسعه داد که مهم‌ترین آن‌ها Service Platform بود. این بستر امکاناتی مانند کشف سرویس‌ها (Service Discovery)، مدیریت ارتباط میان سرویس‌ها، استانداردسازی APIها، مانیتورینگ و مشاهده‌پذیری، مدیریت خطاها و ابزارهای استقرار را در اختیار تیم‌های توسعه قرار داد.علاوه بر این، Airbnb کتابخانه داخلی Powergrid را نیز معرفی کرد که امکان اجرای هم‌زمان درخواست به چندین سرویس را فراهم می‌کرد. این ابزار باعث کاهش زمان پاسخ‌دهی صفحات و ساده‌تر شدن مدیریت فراخوانی‌های موازی شد.نتایج مهاجرت معماریتغییر معماری Airbnb نتایج قابل توجهی به همراه داشت که مهم‌ترین آن‌ها عبارت بودند از:افزایش سرعت توسعه قابلیت‌های جدیدکاهش وابستگی میان تیم‌های توسعهامکان استقرار مستقل سرویس‌هابهبود مقیاس‌پذیری زیرساختافزایش پایداری سامانه در هنگام بروز خطاکاهش ریسک انتشار نسخه‌های جدیدافزایش قابلیت نگهداری و توسعه بلندمدت سیستمروند تکامل معماری Airbnb نشان می‌دهد که انتخاب معماری Monolith در ابتدای مسیر تصمیمی مناسب و متناسب با شرایط یک استارتاپ بوده است؛ زیرا سرعت توسعه و سادگی پیاده‌سازی را فراهم می‌کرد. با این حال رشد سریع کاربران، افزایش تعداد توسعه‌دهندگان و پیچیده‌تر شدن فرآیندهای کسب‌وکار موجب شد این معماری دیگر پاسخگوی نیازهای سازمان نباشد. به همین دلیل Airbnb به‌صورت تدریجی به معماری سرویس گرا مهاجرت کرد و با ایجاد زیرساخت‌هایی مانند Service Platform و Powergrid توانست ضمن حفظ سرعت توسعه، استقلال تیم‌ها، مقیاس‌پذیری و قابلیت نگهداری سامانه را نیز به میزان قابل توجهی افزایش دهد.تکامل معماری Airbnbروند تکامل معماری نرم‌افزار SpotifyمعرفیSpotify یکی از بزرگ‌ترین سرویس‌های پخش موسیقی آنلاین جهان است که روزانه میلیون‌ها کاربر از آن استفاده می‌کنند. رشد سریع کاربران، افزایش تعداد سرویس‌ها و بزرگ شدن تیم‌های توسعه باعث شد چالش‌های جدیدی در مدیریت معماری سیستم ایجاد شود. برخلاف بسیاری از شرکت‌ها که تمرکز اصلی آن‌ها بر مهاجرت از معماری Monolith به Microservices بود، Spotify پس از استقرار معماری مبتنی بر سرویس‌های مستقل با مسئله مهم‌تری مواجه شد؛ اینکه چگونه می‌توان معماری هزاران سرویس را به‌صورت استاندارد مستندسازی، مشاهده و مدیریت کرد.به همین دلیل روند تکامل معماری Spotify تنها به تغییر ساختار نرم‌افزار محدود نشد، بلکه شامل توسعه ابزارها و استانداردهایی برای مدیریت دانش معماری، مستندسازی و هماهنگی میان صدها تیم توسعه نیز بود.معماری اولیهنسخه‌های اولیه Spotify مشابه بسیاری از استارتاپ‌های فناوری با معماری نسبتا متمرکز و تعداد محدودی سرویس توسعه یافت. در این مرحله تعداد کاربران و قابلیت‌های سیستم محدود بود و تمرکز اصلی تیم توسعه بر عرضه سریع محصول و افزودن قابلیت‌های جدید قرار داشت.با رشد سریع کاربران و گسترش خدمات، سیستم به‌تدریج به مجموعه‌ای از سرویس‌های مستقل تبدیل شد. هر سرویس مسئول بخشی از منطق کسب‌وکار مانند مدیریت کاربران، پخش موسیقی، جستجو، پیشنهاد آهنگ و مدیریت Playlist کاربران بود.انتخاب معماری مبتنی بر Microservices مزایای متعدد مشابهی برای Spotify ایجاد کرد، از جمله:توسعه مستقل هر سرویساستقرار جداگانه سرویس‌هامقیاس‌پذیری مستقل هر بخشافزایش قابلیت اطمینان سیستمامکان فعالیت همزمان تیم‌های متعدد روی بخش‌های مختلف سامانهدر این مرحله معماری مبتنی بر سرویس‌ها پاسخگوی نیازهای عملکردی سیستم بود و رشد سریع سازمان را امکان‌پذیر ساخت.دلایل تغییر معماریاگرچه معماری Microservices بسیاری از مشکلات مقیاس‌پذیری را برطرف کرده بود، اما با افزایش تعداد سرویس‌ها و تیم‌های توسعه، چالش‌های جدیدی ظاهر شدند که بیشتر جنبه مدیریتی و معماری داشتند.1.افزایش تعداد سرویس‌هابا گذشت زمان تعداد سرویس‌های مستقل به صدها و سپس هزاران سرویس رسید. در چنین شرایطی توسعه‌دهندگان دیگر دید کاملی نسبت به ساختار کلی سیستم نداشتند و تشخیص وابستگی میان سرویس‌ها دشوار شده بود.2.مستندسازی غیرهماهنگهر تیم مستندات معماری خود را با قالب و ابزار متفاوتی تهیه می‌کرد. این موضوع موجب می‌شد اطلاعات معماری قدیمی، ناقص یا ناسازگار باشند و اعتماد به مستندات کاهش یابد.3.دشواری تحلیل وابستگی‌هادر زمان توسعه قابلیت‌های جدید یا ایجاد تغییرات، شناسایی اینکه هر سرویس به چه سرویس‌های دیگری وابسته است به فرآیندی زمان‌بر تبدیل شده بود. این موضوع احتمال بروز خطا و ایجاد وابستگی‌های ناخواسته را افزایش می‌داد.4.کاهش دید معماریاگرچه هر تیم معماری سرویس خود را می‌شناخت، اما تصویر کلی از معماری کل سازمان وجود نداشت. این مسئله تصمیم‌گیری‌های معماری را دشوار می‌کرد و هماهنگی میان تیم‌ها را کاهش می‌داد.5.افزایش هزینه نگهداری مستنداتبه‌روزرسانی دستی نمودارهای معماری پس از هر تغییر تقریبا غیرممکن شده بود و بسیاری از نمودارها پس از مدت کوتاهی اعتبار خود را از دست می‌دادند.معماری جدیدبرای رفع این مشکلات، Spotify تمرکز خود را از تغییر ساختار سرویس‌ها به سمت مدیریت معماری در مقیاس بزرگ معطوف کرد.یکی از مهم‌ترین اقدامات این شرکت استفاده از مدل C4 برای استانداردسازی توصیف معماری سیستم بود. مدل C4 امکان نمایش معماری در چهار سطح مختلف (Context، Container، Component و Code) را فراهم می‌کند و موجب می‌شود همه تیم‌ها از زبان مشترکی برای مستندسازی استفاده کنند.علاوه بر این، Spotify پلتفرم Backstage را توسعه داد. بستری متن‌باز که تمامی اطلاعات مربوط به سرویس‌ها، تیم‌ها، وابستگی‌ها، APIها و مستندات را در یک محل متمرکز نگهداری می‌کند. در نسخه‌های جدید این پلتفرم، امکان تولید خودکار نمودارهای معماری نیز فراهم شد. این نمودارها به جای اینکه به‌صورت دستی رسم شوند، مستقیما از اطلاعات واقعی سرویس‌ها تولید شده و همواره با وضعیت فعلی سیستم همگام هستند.نقش پلتفرم backstage در معماری Spotifyاین رویکرد موجب شد مستندسازی معماری از یک فعالیت دستی به بخشی از فرآیند توسعه نرم‌افزار تبدیل شود.نتایج تکامل معماریبه‌کارگیری این رویکرد مزایای متعددی برای Spotify به همراه داشت:استاندارد شدن مستندسازی معماری در کل سازمانافزایش شفافیت وابستگی میان سرویس‌هاکاهش قدیمی شدن مستنداتتسهیل ورود اعضای جدید به تیم‌هابهبود تصمیم‌گیری‌های معماریافزایش هماهنگی میان تیم‌های توسعهمشاهده‌پذیری بهتر ساختار سیستمکاهش هزینه نگهداری مستندات معماریتجربه Spotify نشان می‌دهد که پس از حل مسائل مقیاس‌پذیری با استفاده از معماری مبتنی بر Microservices، چالش اصلی سازمان از ساخت نرم‌افزار به مدیریت معماری نرم‌افزار تغییر می‌کند. در این مرحله مسئله اصلی دیگر توسعه سرویس‌های جدید نیست، بلکه حفظ دید جامع نسبت به هزاران سرویس، مدیریت وابستگی‌ها و هماهنگی میان صدها تیم توسعه است.Spotify برای پاسخ به این نیازها به جای ایجاد معماری جدید، بر استانداردسازی مستندسازی معماری، مصورسازی خودکار ساختار سیستم و توسعه ابزارهایی مانند Backstage و استفاده از مدل C4 تمرکز کرد. این رویکرد موجب شد معماری سیستم همواره قابل مشاهده، به‌روز و قابل فهم باقی بماند و فرآیند توسعه در مقیاس بسیار بزرگ با کارایی بیشتری انجام شود.مسیر تغییرات مدیریت معماری نرم افزار در Spotifyروند تکامل معماری نرم‌افزار UberمعرفیUber یکی از بزرگ‌ترین سامانه‌های حمل‌ونقل هوشمند جهان است که روزانه میلیون‌ها سفر را در کشورهای مختلف مدیریت می‌کند. رشد سریع کاربران، توسعه مداوم قابلیت‌های جدید و افزایش تعداد تیم‌های توسعه باعث شد معماری اولیه نرم‌افزارهای Uber، به‌ویژه برنامه موبایل Rider، به تدریج با محدودیت‌هایی مواجه شود. مهم‌ترین چالش افزایش پیچیدگی کد، دشواری نگهداری و وابستگی زیاد میان بخش‌های مختلف برنامه بود. به همین دلیل Uber معماری جدیدی با نام Riblets را معرفی کرد که با هدف جداسازی مسئولیت‌ها، افزایش توسعه‌پذیری و مدیریت بهتر برنامه‌های بزرگ طراحی شده است.معماری اولیهدر نسخه‌های اولیه، برنامه Rider Uber با استفاده از الگوی متداول MVC توسعه یافته بود. این معماری برای پروژه‌ای با اندازه کوچک و تیم‌های محدود انتخاب مناسبی محسوب می‌شد، زیرا ساختار ساده‌ای داشت و توسعه قابلیت‌های اولیه را با سرعت مناسبی امکان‌پذیر می‌کرد.در این معماری کنترل‌کننده‌ها مسئول مدیریت رابط کاربری، دریافت ورودی کاربران، کنترل جریان اجرای برنامه و ارتباط با منطق کسب‌وکار بودند. این رویکرد در مراحل ابتدایی توسعه مزایایی داشت:سادگی پیاده‌سازیسرعت بالای توسعه اولیهیادگیری آسان برای توسعه‌دهندگانمناسب بودن برای تیم‌های کوچکدر سال‌های نخست، این معماری پاسخگوی نیازهای Uber بود و امکان توسعه سریع نسخه‌های اولیه برنامه را فراهم کرد.دلایل تغییر معماریبا گسترش خدمات Uber و اضافه شدن قابلیت‌هایی مانند درخواست سفر، پرداخت، اشتراک سفر، پیشنهادهای هوشمند، تبلیغات، پشتیبانی و سرویس‌های متنوع دیگر محدودیت‌های معماری MVC به تدریج آشکار شد.1.افزایش حجم Controllerهابخش قابل توجهی از منطق برنامه در Controllerها قرار گرفته بود. با اضافه شدن قابلیت‌های جدید، Controllerها بسیار بزرگ و پیچیده شدند و نگهداری آن‌ها دشوار گردید.2.وابستگی زیاد میان بخش‌های مختلف برنامهاجزای مختلف برنامه به یکدیگر وابستگی زیادی پیدا کرده بودند. تغییر در یک قابلیت می‌توانست بخش‌های دیگر را نیز تحت تأثیر قرار دهد و احتمال بروز خطا را افزایش دهد.3.دشواری توسعه همزمان توسط تیم‌های مختلفبا افزایش تعداد تیم‌های توسعه، هماهنگی میان آن‌ها دشوارتر شد. توسعه‌دهندگان مختلف روی قسمت‌های مشترک برنامه کار می‌کردند و این موضوع باعث ایجاد تداخل در تغییرات و افزایش پیچیدگی فرآیند توسعه می‌شد.4.کاهش قابلیت آزمونترکیب منطق رابط کاربری، منطق کسب‌وکار و مدیریت جریان برنامه در یک بخش، نوشتن آزمون‌های واحد و آزمون‌های یکپارچه را دشوار کرده بود.5.کاهش قابلیت استفاده مجددبخش زیادی از منطق برنامه به ساختار Controllerها وابسته بود و امکان استفاده مجدد از آن در سایر قسمت‌های برنامه به سادگی وجود نداشت.گذار از معماری MVC به معماری ماژولارمعماری جدید(Riblets)برای رفع این مشکلات Uber معماری Riblets را معرفی کرد. این معماری نسخه‌ای متن‌باز و ساده‌شده از معماری داخلی RIBs (Router, Interactor, Builder) است که برای توسعه برنامه‌های بزرگ و ماژولار طراحی شده است.در این معماری هر قابلیت برنامه به یک ماژول مستقل یا Riblet تبدیل می‌شود و هر ماژول از اجزای مشخصی تشکیل شده است:Builder: ایجاد و اتصال اجزای ماژولRouter: مدیریت جریان ناوبری و ارتباط میان ماژول‌هاInteractor: پیاده‌سازی منطق کسب‌وکارView: نمایش رابط کاربریاین تفکیک مسئولیت‌ها موجب شد هر بخش وظیفه مشخصی داشته باشد و وابستگی میان اجزا کاهش یابد. همچنین هر Riblet به صورت مستقل توسعه، آزمایش و نگهداری می‌شود و ارتباط آن با سایر بخش‌ها از طریق رابط‌های مشخص انجام می‌گیرد.نتایج تکامل معماریاستفاده از معماری Riblets مزایای متعددی برای Uber به همراه داشت:کاهش پیچیدگی ساختار برنامهجداسازی مناسب مسئولیت‌هاافزایش قابلیت نگهداری کدتوسعه مستقل قابلیت‌های مختلف توسط تیم‌های گوناگونبهبود قابلیت آزمون واحد و آزمون یکپارچهافزایش قابلیت استفاده مجدد از اجزای نرم‌افزارساده‌تر شدن توسعه قابلیت‌های جدیدکاهش وابستگی میان ماژول‌های برنامهعلاوه بر این، معماری Riblets امکان توسعه برنامه توسط صدها توسعه‌دهنده را به‌صورت همزمان فراهم کرد، بدون آنکه پیچیدگی کد به اندازه معماری MVC افزایش یابد.تجربه Uber نشان می‌دهد که معماری MVC اگرچه برای پروژه‌های کوچک و مراحل ابتدایی توسعه انتخاب مناسبی است اما با افزایش اندازه نرم‌افزار، تعداد قابلیت‌ها و تیم‌های توسعه به تدریج با مشکلاتی مانند پیچیدگی کد، وابستگی زیاد میان اجزا و دشواری نگهداری مواجه می‌شود. Uber برای حل این مشکلات معماری Riblets را معرفی کرد که بر پایه تفکیک مسئولیت‌ها، ماژولار بودن و استقلال اجزای نرم‌افزار طراحی شده است. این معماری موجب شد توسعه و نگهداری برنامه Rider در مقیاس بسیار بزرگ ساده‌تر شود و تیم‌های متعدد بتوانند به صورت همزمان و مستقل روی بخش‌های مختلف سیستم فعالیت کنند.تکامل معماری در Uberنتیجه‌گیری و تحلیلمطالعه روند تکامل معماری سه سازمان Airbnb، Uber و Spotify نشان می‌دهد که اگرچه هر یک در حوزه‌ای متفاوت فعالیت می‌کنند و راهکارهای معماری متفاوتی را برگزیده‌اند، اما محرک‌های اصلی تغییر معماری در همه آن‌ها تا حد زیادی مشترک است. نکته قابل توجه آن است که هیچ‌یک از این شرکت‌ها معماری اولیه خود را اشتباه انتخاب نکرده بودند بلکه معماری اولیه کاملا متناسب با نیازها، اندازه تیم و مقیاس کسب‌وکار در زمان شروع فعالیت انتخاب شده بود. با رشد سازمان، افزایش تعداد کاربران، توسعه قابلیت‌های جدید و گسترش تیم‌های مهندسی نیازهای کیفی سیستم یا همان Quality Attributes تغییر کرد و همین تغییر نیازها عامل اصلی تکامل معماری شد.۱) در Airbnb معماری یکپارچه مبتنی بر Ruby on Rails Monolith در سال‌های ابتدایی امکان توسعه سریع محصول و ورود به بازار را فراهم کرد. اما با افزایش تعداد توسعه‌دهندگان و رشد حجم درخواست‌ها، ویژگی‌های کیفی مانند مقیاس‌پذیری، قابلیت نگهداری و استقرارپذیری اهمیت بیشتری پیدا کردند. به همین دلیل این شرکت به سمت معماری Service-Oriented حرکت کرد تا هر سرویس بتواند به صورت مستقل توسعه، استقرار و مقیاس‌دهی شود.۲) در Uber مسئله اصلی بیشتر در معماری سمت کلاینت و مدیریت پیچیدگی نرم‌افزار نمایان شد. معماری MVC که برای نسخه‌های اولیه برنامه Rider مناسب بود، با افزایش قابلیت‌ها و بزرگ شدن تیم‌های توسعه به ساختار پیچیده‌ای با Controllerهای بسیار بزرگ تبدیل شد. در نتیجه ویژگی‌های کیفی مانند Modularity، Testability و Maintainability بیش از گذشته اهمیت یافتند. معرفی معماری Riblets با تفکیک مسئولیت‌ها میان Builder Router، Interactor و View موجب شد توسعه قابلیت‌های جدید مستقل‌تر انجام شود، آزمون‌پذیری افزایش یابد و وابستگی میان بخش‌های مختلف برنامه نیز کاهش پیدا کند.۳) در Spotify هم مسئله اصلی پس از استقرار معماری مبتنی بر Microservices ظاهر شد. این شرکت برخلاف دو نمونه دیگر، بیشتر با چالش مدیریت پیچیدگی معماری در مقیاس سازمانی روبه‌رو بود. افزایش تعداد سرویس‌ها و تیم‌های توسعه باعث شد مشاهده ساختار سیستم، مستندسازی و مدیریت وابستگی‌ها به مسئله‌ای مهم تبدیل شود. در نتیجه Spotify با توسعه پلتفرم Backstage و استفاده از مدل C4 تلاش کرد ویژگی‌های کیفی مانند Understandability، Observability، Maintainability و Team Coordination را بهبود دهد. در این رویکرد تمرکز از تغییر ساختار نرم‌افزار به سمت مدیریت دانش معماری و استانداردسازی مستندات معطوف شد.روند و دلایل تکامل معماری ۳ سازمانبا مقایسه این سه مطالعه موردی می‌توان مشاهده کرد که اگرچه راهکارهای نهایی متفاوت هستند، اما فلسفه تغییر معماری تقریبا یکسان است. در هر سه سازمان رشد سریع کسب‌وکار باعث افزایش پیچیدگی سیستم شد و این پیچیدگی مستقیما ویژگی‌های کیفی نرم‌افزار را تحت تأثیر قرار داد. به بیان دیگر، معماری زمانی تغییر می‌کند که دیگر نتواند ویژگی‌های کیفی مورد انتظار سازمان را تأمین کند. این نتیجه یکی از مهم‌ترین درس‌های مهندسی معماری نرم‌افزار است. معماری یک تصمیم ثابت و دائمی نیست، بلکه باید همگام با تغییر نیازهای کسب‌وکار و رشد سازمان تکامل یابد.در میان ویژگی‌های کیفی بررسی‌شده، قابلیت نگهداری یا Maintainability مهم‌ترین عامل مشترک در هر سه سازمان بود. پس از آن مقیاس‌پذیری، استقلال تیم‌های توسعه، استقرار مستقل و قابلیت مشاهده و مستندسازی معماری بیشترین تأثیر را در تصمیمات معماری داشتند:معیار‌های کیفی موثر بر معماری نرم افزاربنابراین می‌توان نتیجه گرفت که معماری نرم‌افزار در سازمان‌های بزرگ تنها با هدف افزایش عملکرد تغییر نمی‌کند، بلکه بخش عمده‌ای از این تغییرات برای کاهش پیچیدگی سازمانی، افزایش بهره‌وری تیم‌های توسعه و تسهیل نگهداری بلندمدت سیستم انجام می‌شود.کلام پایانیمطالعه تاریخچه و روند تغییرات در معماری سازمان‌های مقیاس وسیع بالا نشان می‌دهد که هر سه شرکت، با وجود تفاوت در فناوری و راهکارهای معماری در پاسخ به یک مسئله مشترک تکامل یافته‌اند:حفظ کیفیت نرم‌افزار در مواجهه با رشد مداوم سامانه و سازماناين مطلب، بخشی از تمرينهای درس معماری نرم‌افزار در دانشگاه شهيدبهشتی است.مراجع[1] https://blog.bytebytego.com/p/a-brief-history-of-airbnbs-architecture[2] https://www.irjcs.com/volumes/Vol8/iss-03/03.MRCS10082.pdf[3] https://codersguild.github.io/System-Design/Airbnb%20Engineering/[4] https://engineering.atspotify.com/2022/07/software-visualization-challenge-accepted[5] https://medium.com/@mathurvidhi2505/behind-the-music-spotify-architecture-explained-a942878468c7[6] https://www.systemdesignhandbook.com/guides/spotify-design-system/[7] https://www.techaheadcorp.com/blog/decoding-software-architecture-of-spotify-how-microservices-empowers-spotify/[8] https://www.uber.com/us/en/blog/new-rider-app-architecture/[9] https://emizentech.com/blog/uber-tech-stack-software-architecture.html

مرور برخی مفاهیم مهم در نرم افزار

محمد صادقی — Sat, 30 May 2026 18:43:14 +0330

درین پست قصد داریم درباره هریک از موضوعات موجود در لیست زیر توضیحی مختصر، مفید و کم عمق جهت آشنایی اولیه ای با هرکدام از این مفاهیم داشته باشیم. موضوعات مورد بحث:1.Chaos Engineering2.Backend for Frontend3.AI4SE4.SE4AI5.MLOps6.Infrastructure as Code (IaC)7.API Gateway & Service Mesh8.CQRS (Command Query Responsibility Segregation)9.Event-Driven Architecture (EDA)10.Serverless Architecture11.API-first Approach12.Domain Driven Design13.Hexagonal architecture14.Event Sourcing15.Low-code/No-code platforms16.Business Process Management Systems (BPMS)17.Message Queue (such as Kafka and RabbitMQ)18.Containers (eg., Docker) and Container orchestration (e.g., Kubernetes)19.Multi-Tenancy Architecture20.Data Migrationدر ادامه این مقاله به ترتیب به شرح کوتاهی از هر موضوع خواهیم پرداخت.Chaos Engineeringمهندسی آشوب نوعی سازوکار است که بصورت عمدی و کنترل شده، خرابی هایی را در سیستم ایجاد می کنند تا بتوانند در آینده، در صورت وقوع خرابی، مقدار آسیبی که به سیستم می رسد را کمینه کنند. به عبارت دیگر این سازوکار به شناخت و اندازه گیری آسیب ها و خرابی‌های احتمالی سیستم بصورت پیشگیرانه و proactive می پردازد و تیم توسعه قبل از وقوع خرابی آن را پیش بینی و راهکارهایی برای آن در نظر می گیرد. تکنیک های مختلفی برای این کار وجود دارد:۱)تزریق تاخیر: تیم دوآپس سناریوهایی را که ارتباط شبکه ضعیف یا قطع شود را شبیه سازی میکنند.۲)تزریق خطا: ایجاد عمدی باگ و خطا در یک سرویس، برای بررسی اینکه سیستم های وابسته به این سرویس دچار خطا میشوند یا خیر.۳)تولید بار: فرستادن ترافیک با حجم بالا به سمت سیستم برای تشخیص گلوگاه ها، که رفع کردن آنها منجر به افزایش مقیاس پذیری سیستم خواهد شد.۴)تست قناری: یک ویژگی یا کارکرد جدید سیستم را فقط برای درصدی از کاربران در دسترس قرار می دهیم تا در صورت وجود ایراد، باقی کاربران سیستم اثر آن را مشاهده نکنند.جهت مطالعه بیشتر به [1] و [2] در بخش منابع مراجعه کنید.Backend For Frontendاین مفهوم که در صنعت بیشتر با BFF از آن یاد میشود، یک الگوست که به جداسازی سرویس های بکند و پیاده سازی های سمت فرانت اند در سامانه می پردازد. در واقع می گوید نباید در یک سازمان، برای رابط های کاربری مختلف، بکند های سفارشی سازی شده طراحی و ساخته شود. داشتن یک سرویس بکند و چندین نوع رابط کاربری مشکلاتی را از قبیل تزاحم و race condition می تواند بوجود بیاورد. شکل زیر ساختاری را نشان میدهد که هر رابط مستقیما با سرویس بکند ارتباط دارد و چون هر رابط کاربری قابلیت ها و نیازهای متفاوتی را دارد، لذا مشکلاتی که قبل تر ذکر شد ناگزیر اتفاق میافتند:برای حل این مشکل از الگوی BFF استفاده می کنند که ایده اش اضافه کردن یک لایه بین سرویس بکند و لایه ی رابط کاربری است که این لایه تنها نیازمندی های رابط کاربری متناظر خودش را مدیریت میکند. مزیت این کار این است که تیم های توسعه فرانت هر رابط کاربری، بصورت مجزا توسعه میدهند بی آنکه نگران تاثیر کار خود بر روی رابط های دیگر باشند. شکل زیر ساختار جدید سیستم بعد از اعمال این الگو را نمایش می دهد:جهت مطالعه بیشتر به [3] در بخش منابع رجوع شود.AI4SEهوش مصنوعی برای مهندسی نرم افزار کانسپتی نسبتا جدید درین حوزه است که با ظهور مدل های زبانی همه گیر شده است. این حوزه به کاربرد فناوری های موجود در هوش مصنوعی جهت بهبود فرایند طراحی، توسعه و نگهداشت سیستم های نرم افزاری است. این فرایند شامل مراحلی مثل تحلیل نیازمندی های سیستم، مدل های پیش بینی و تصمیم گیری و همچنین شبیه سازی هستند. هدف اصلی این رویکرد استفاده از نتایج بدست آمده از تحلیل های داده محور است تا بتوانند عملکرد سیستم را بهبود داده، زمان توسعه را کم کرده و همچنین کلیت فرایند مهندسی سیستم نرم افزاری را با کارایی بهتری انجام دهند.SE4AIبا افزایش چشمگیر استفاده از هوش مصنوعی، سیستم های پیچیده نیازمند این هستند تا این فناوری در آنها ادغام شود. فریم ورک Software Engineering for AI بوجود آمده تا با استفاده از اصول مهندسی سیستم - که بر روی طراحی، یکپارچه سازی و مدیریت سیستم های پیچیده تمرکز دارد - بتواند فناوری های هوش مصنوعی را با اینگونه سیستم ها ادغام کند. این فریم ورک در واقع از اعمال practice های مهندسی سیستم در فرایندهای طراحی، توسعه و استقرار سیستم های قدرت گرفته با AI استفاده میکند. بعضی مراحلی که ادغام فناوری های هوش مصنوعی در آنها توسط این practice ها انجام میشوند میتوان به تعریف نیازمندی ها، طراحی معماری سیستم، آزمون و اعتبارسنجی سامانه اشاره کرد. این فریم ورک در واقع از ادغام کارای فناوری های هوش مصنوعی در سامانه های پیچیده اطمینان حاصل میکند در حالی که ویژگی های کیفی مانند قابلیت اطمینان و دسترس پذیری را هم تضمین میکنند.جهت مطالعه بیشتر درباره دو موضوع بالا به [4] و [5] در منابع مراجعه کنید.MLOpsترکیبی از یادگیری ماشین (ML) و عملیات (Operations) است که به ساده سازی و بهینه کردن فرایند استقرار، پایش و مدیریت مدل های یادگیری ماشین در محیط تولید خودکار می پردازد. در واقع این روش همکاری بین متخصصین داده و مهندسان دوآپس است تا بتوانند در مقیاس بزرگ و بصورت پیوسته تحویل و نگهداری مدل های یادگیری ماشین را در مقیاس بزرگ انجام دهند. تقریبا شبیه devops است با این فرق که آنجا ما مرحله بین توسعه فنی و استقرار را خودکار میکنیم اما درینجا تغییرات و بروزرسانی ها روی الگوریتم های یادگیری یا هر آپدیتی روی مدل زبانی بصورت خودکار و پیوسته باید روی مدل مستقر شود. کلا تمرکز دوآپس فقط روی چرخه توسعه محصول است اما در MLOps کل چرخه حیات مدل از جمع آوری داده تا توسعه و آزمون و استقرار مد نظر است. این مفهوم در سالهای اخیر بنام MLOps ظهور کرده و ترند شده است.برای مطالعه بیشتر و آشنایی با مراحل این فرایند به [6] در بخش منابع رجوع کنید.Infrastructure As Codeزیرساخت بعنوان کد یا همان IaC همانطور که از نامش پیداست تهیه و آماده سازی شرح و جزییات زیرساخت های سیستم نرم افزار در غالب کد است. زیرساخت های نرم افزاری شامل مولفه هایی مثل سیستم عامل، اتصال پایگاه داده و یا حافظه میباشد. در IaC تمرکز روی این است تا بجای اینکه تیم های توسعه وقت و انرژی زیادی را صرف آماده سازی و تهیه دستی محیط توسعه یا همان زیرساخت های نرم افزاری کنند، فایل های پیکربندی را - که محتوای آنها کدی است که جزییات دقیقی از محیط توسعه و زیرساخت های لازم را شرح میدهد - آماده می کنند که هم راحت تر تغییر را می پذیرند هم به توسعه دهندگان اجازه میدهد وقت خود را روی توسعه فنی صرف کنند. برای تولید فایل های پیکربندی در قالب کد دو رویکرد وجود دارد:1) صریح: بصورت شفاف منابع و زیرساخت های مورد نیاز در کد ذکر میشود.2)ضمنی: کد شامل دستوراتی است که اجرای به ترتیب آنها برای دستیابی به محیط مناسب ضروری است.برای مطالعه عمیق تر درین حوزه به [7] و [8] در منابع مراجعه کنید.API Gateway and Service Meshهردو عبارت ذکر شده در تیتر این بخش ابزار هایی هستند جهت تسهیل و مدیریت هرچه بهتر ارتباطات در معماری های میکروسرویس که درین معماری چندین سیستم و سرویس مختلف با هم تعامل میکنند تا یک سامانه بزرگ اصلی بتواند کار کند. در ادامه مختصرا هریک را توضیح می دهیم:1)api gateway: یک هاب مرکزی است که وظیفه تعامل های خارجی با سیستم میکروسرویس شما را دارد. این هاب درخواست هایی را که از طرف کلاینت ها به سیستم ارسال میشود را بر اساس یک سری ضوابط، به سرور های بکند مناسب ارجاع میدهد و همچنین بحث دسترسی و احراز کاربران را نیز به عهده دارد. یکی از کارهای مهم این هاب جمع آوری پاسخ از سرورهای بکند مختلف و تجمیع آنها در یک فرمت استاندارد مناسب برای کاربر درخواست دهنده است.2)service mesh: این یک معماری است که درون هر سرویس بصورت جداگانه یک پروکسی قرار میگیرد و برعکس رویکرد اول غیر متمرکز است. در واقع شبکه توزیع شده ای از پروکسی ها روی تمام سرویس های سامانه بصورت جداگانه است. هر پروکسی وظیفه رهگیری ارتباطات سرویس به سرویس را دارد که این رویکرد هم بار حجم ارتباطات را می کاهد و هم از نظر امنیتی بهتر است.شکل زیر به تشریح تفاوت بین دو رویکرد را خلاصه سازی کرده است:جهت مطالعه بیشتر به [9] و [10] در بخش منابع رجوع کنید.CQRSجداسازی مسوولیت های کوئری و دستورات یکی از الگوهای معماری معرفی شده توسط Greg Young است. این الگو می گوید برای برزورسانی داده ها و خواندن آنها از دو مدل مجزا استفاده کنید که آقای مارتین فالر معتقد است برای اکثر سیستم ها این الگو پیچیدگی پر ریسکی به همراه دارد. در معماری های سنتی مثل MVC معمولا یک مدل واحد هم برای خواندن و هم برای نوشتن داده ها استفاده میشود که اگر بنابه نیازمندی های سیستم حجم یکی ازین دو نوع عملیات بیش از دیگری باشد، این معماری خیلی منطقی نیست. شکل زیر نمای کلی این معماری را نشان میدهد:اما در جایی که میخواهیم از مدل های خواندن و نوشتن متفاوت استفاده کنیم و یا مستقلا نیاز به مقیاس پذیر بودن این دو نوع عملیات داریم به سراغ الگوی CQRS می رویم. درین الگو از دو مدل مجزا بهره میبریم:1- بخش کامند: مسئولیت ایجاد، به‌روزرسانی یا حذف داده‌ها را بر عهده دارد. این بخش معمولا از مدل‌های تحلیلی یا عملیاتی پیروی می‌کند که پیچیده‌تر بوده و قوانین تجاری زیادی هم دارد.2- بخش کوئری: مسئولیت خواندن و نمایش داده‌ها را بر عهده دارد. این بخش از مدل‌های خوانش مثل Projection استفاده می‌کند که برای پرس‌وجوهای خاص بهینه‌سازی شده‌ و ممکن است ساختار متفاوتی با مدل نوشتن داشته باشد. شکل زیر نمای کلی معماری را نمایش میدهد:برای جزییات بیشتر به [11] در منابع رجوع کنید.Event-Driven Architectureمعماری مبتنی بر رویداد یک نوع معماری برای تعامل سرویس های مختلف در برنامه های مدرن مبتنی بر میکروسرویس است. یک رویداد، تغییر در استیت برنامه یا آپدیتی است که اتفاق می افتد. اضافه یا کم شدن یک محصول از سبد خرید کاربر در سایتی مثل آمازون یا دیجیکالا مثالی از رویداد است. این معماری 3 رکن دارد. تولید کننده رویداد، روتر یا هدایت کننده آن و در نهایت مصرف کننده آن رویداد رکن های این معماری هستند. رویداد می تواند حاوی خود استیت باشد مانند اطلاعات محصول اضافه شده، آدرس و قیمت آن. در عین حال می تواند یک شناسه معمولی باشد مثل اینکه یک سفارش ارسال شد یا تحویل گرفته شد. روتر رویداد وظیفه فیلتر کردن و فرستادن این رویداد به سمت مصرف کننده را دارد. سرویس های مربوط به تولید و مصرف کننده رویداد کاملا مجزا از هم هستند تا قابلیت توسعه و نگهداشت آنها بصورت مستقل امکان پذیر باشد.جهت مطالعه بیشتر به [12] در منابع مراجعه کنید.Serverless Architectureمعماری بدون سرور (Serverless Architecture) یک الگوی توسعه نرم‌افزار است که در آن مدیریت زیرساخت، سرورها و مقیاس‌پذیری به‌عهده ارائه‌دهنده خدمات ابری قرار می‌گیرد و توسعه‌دهندگان تنها روی نوشتن منطق برنامه تمرکز می‌کنند. در این معماری کدها معمولا به‌صورت توابع مستقل اجرا می‌شوند و فقط هنگام دریافت درخواست فعال می‌شوند. بنابراین هزینه‌ها بر اساس میزان استفاده واقعی محاسبه می‌شود. معماری بدون سرور باعث افزایش سرعت توسعه، مقیاس‌پذیری خودکار و کاهش هزینه‌های نگهداری می‌شود. اما در مقابل ممکن است چالش‌هایی مانند تأخیر در شروع اولیه، وابستگی به ارائه‌دهنده سرویس و محدودیت در کنترل زیرساخت را نیز به همراه داشته باشد. تصویر زیر این معماری را نشان میدهد:اجزای داخل این معماری به اختصار در ادامه آمده اند:1) Web App: رابط کاربری که کاربران از طریق آن با سیستم تعامل می‌کنند.2) API Gateway: درگاه مرکزی دریافت و هدایت درخواست‌ها به سرویس‌های مختلف3) Authorizer: مسئول احراز هویت و بررسی مجوز دسترسی کاربران4) Content Service: سرویسی برای مدیریت و پردازش محتوای برنامه5) User Service: سرویس مربوط به اطلاعات، حساب و عملیات کاربران6) External APIs: سرویس‌ها و API های خارجی که سیستم از آن‌ها داده یا امکانات دریافت می‌کند7) External Database: پایگاه‌داده خارجی برای ذخیره و بازیابی اطلاعات سیستمبرای مطالعه بیشتر به [13] و [14] در منابع مراجعه شود.API-first Approachرویکرد API-First یعنی قبل از ساخت برنامه، ابتدا APIها طراحی شوند و بقیه بخش‌های سیستم بر اساس آن توسعه پیدا کنند. در این روش API هسته اصلی ارتباط بین سرویس‌ها، اپلیکیشن‌ها و دستگاه‌های مختلف است. درین رویکرد معمولا ابتدا یک قرارداد برای رفتار API تعریف می‌شود تا همه تیم‌ها بدانند هر سرویس چگونه کار می‌کند. این کار باعث می‌شود توسعه‌دهندگان بتوانند همزمان روی بخش‌های مختلف پروژه کار کنند و منتظر تکمیل سایر قسمت‌ها نمانند. این رویکرد همچنین در معماری میکروسرویس کاربرد زیادی دارد چون سرویس‌ها به شکل مستقل طراحی شده و از طریق API با هم ارتباط دارند.از مهم‌ترین مزایای API-First می‌توان به کاهش هزینه توسعه، استفاده مجدد از کدها و افزایش سرعت تولید محصول اشاره کرد. بسیاری از ابزارها نیز می‌توانند مستندات، نمونه API و فایل‌های موردنیاز را به‌صورت خودکار تولید کنند که زمان توسعه را کمتر می‌کند. این رویکرد تجربه بهتری برای برنامه‌نویسان ایجاد می‌کند چون APIهای استاندارد و مستند یادگیری و استفاده آسان‌تری دارند. علاوه بر این ریسک خطا و شکست پروژه کم می شود زیرا مشکلات طراحی اغلب قبل از پیاده‌سازی اصلی شناسایی می‌شوند.برای مطالعه بیشتر به [15] در منابع مراجعه شود.Domain Driven Designطراحی دامنه‌محور یا DDD یک رویکرد در توسعه نرم‌افزار است که تمرکز اصلی اش روی درک دقیق نیازها، قوانین و فرایندهای کسب‌وکار است. در این روش قبل از پیاده‌سازی فنی تلاش می‌شود مفاهیم واقعی دامنه مسئله به‌درستی شناسایی و مدل‌سازی شوند تا نرم‌افزار بتواند رفتار واقعی سیستم را بازتاب دهد. DDD بیشتر در پروژه‌های پیچیده استفاده می‌شود، جایی که منطق کسب‌وکار گسترده و تغییرپذیر است.در طراحی دامنه‌محور، توسعه‌دهندگان و متخصصان کسب‌وکار از یک زبان مشترک استفاده می‌کنند تا همه اعضای تیم برداشت یکسانی از مفاهیم سیستم داشته باشند. همچنین سیستم به بخش‌های کوچک‌تر و مستقل تقسیم می‌شود تا مدیریت و توسعه آن ساده‌تر باشد. این رویکرد باعث می‌شود نرم‌افزار ساختار منظم‌تر، قابلیت نگهداری بالاتر و انعطاف بیشتری در برابر تغییرات آینده داشته باشد.جهت مطالعه بیشتر به [16] و [17] در منابع مراجعه شود.Hexagonal architectureمعماری شش‌ضلعی یا Ports and Adapters یک الگوی معماری نرم‌افزار است که هدفش جدا کردن منطق اصلی سیستم از بخش‌های خارجی مثل پایگاه‌داده، رابط کاربری و APIها است. در این معماری هسته اصلی برنامه فقط شامل منطق کسب‌وکار است و ارتباط آن با بخش‌های بیرونی از طریق Port و Adapter انجام می‌شود. این ساختار باعث می‌شود وابستگی مستقیم بین منطق سیستم و فناوری‌های خارجی کاهش پیدا کرده و تغییر یا جایگزینی بخش‌های مختلف آسان‌تر شود. شکل زیر نمای کلی این معماری را نمایش می دهد:در معماری شش‌ضلعی Adapterها وظیفه اتصال سیستم به دنیای بیرون را دارند. برای مثال API، دیتابیس یا رابط کاربری می‌توانند به‌عنوان Adapter عمل کنند. در طرف دیگر Portها نیز قراردادهای ارتباطی بین هسته سیستم و این Adapterها هستند. این رویکرد باعث افزایش آزمون پذیری، انعطاف‌پذیری و قابلیت نگهداری نرم‌افزار شده و در پروژه‌هایی که نیاز به توسعه بلندمدت و معماری تمیز دارند کاربرد زیادی دارد.مطالعه بیشتر در [18] و [19] بخش منابع انجام شود.Event Sourcingیک الگوی دیگر معماری نرم‌افزار است که در آن به‌جای ذخیره فقط وضعیت نهایی داده‌ها، تمام تغییرات و رویدادهای سیستم به‌ترتیب ذخیره می‌شوند. یعنی هر عملیاتی که در سیستم انجام می‌شود به‌صورت یک Event ثبت می‌شود. مثل ایجاد کاربر، تغییر رمز یا ثبت سفارش. در این روش وضعیت فعلی سیستم از روی مجموعه رویدادها به‌دست می‌آید. این معماری بیشتر در سیستم‌های بزرگ و حساس استفاده می‌شود چون امکان پیگیری کامل تغییرات، بازیابی اطلاعات و تحلیل رفتار سیستم را فراهم می‌کند. یکی از مزیت‌های اصلی Event Sourcing این است که تاریخچه کامل عملیات حفظ می‌شود و می‌توان وضعیت سیستم را به هر زمان دلخواه بازگرداند. همچنین این معماری برای سیستم‌های توزیع‌شده، پردازش همزمان و تحلیل داده‌ها مناسب است. البته مدیریت تعداد زیاد رویدادها و پیچیدگی پیاده‌سازی از چالش‌های آن محسوب می‌شود. شکل زیر معماری این الگو را نشان می دهد:در تصویر، ابتدا برنامه عملیات مختلف را در Event Store ذخیره می‌کند. Event Store نقش مخزن اصلی رویدادها را دارد و تمام تغییرات سیستم در آن نگهداری می‌شود. سپس بخش Event Store Consumer این رویدادها را مصرف کرده و بر اساس آن‌ها وضعیت فعلی سیستم را در Current State DB ذخیره میکند. همچنین بخشی به نام Replay Processor وجود دارد که می‌تواند رویدادهای قبلی را دوباره اجرا کند تا وضعیت سیستم در یک زمان خاص بازسازی شود. در پایین تصویر نیز Point in Time DB دیده می‌شود که برای نگهداری وضعیت سیستم در زمان‌های مشخص استفاده می‌شود. این معماری باعث می‌شود سیستم همواره قابل بازسازی و ردیابی باشد.جهت بررسی بیشتر این معماری به [20] در منابع رجوع شود.Low-code/No-code platformsپلتفرم‌های Low-code و No-code ابزارهایی هستند که امکان توسعه نرم‌افزار و ساخت برنامه را با کمترین میزان کدنویسی فراهم می‌کنند. در No-code کاربران معمولا بدون نوشتن کد و فقط با رابط‌های گرافیکی، Drag & Drop و تنظیمات آماده برنامه می‌سازند. اما در Low-code امکان افزودن کد سفارشی هم وجود دارد تا توسعه‌دهندگان فنی بتوانند قابلیت‌های پیشرفته‌تری ایجاد کنند. این پلتفرم‌ها باعث می‌شوند توسعه نرم‌افزار سریع‌تر، ارزان‌تر و ساده‌تر انجام شود و افراد غیرمتخصص هم بتوانند اپلیکیشن‌های کاربردی طراحی کنند.این رویکرد بیشتر برای ساخت سیستم‌های سازمانی، فرم‌ها، داشبوردها و اپلیکیشن‌های وب و موبایل استفاده می‌شود. همچنین به شرکت‌ها کمک می‌کند محصولات را سریع‌تر وارد بازار کنند و وابستگی کمتری به تیم‌های بزرگ برنامه‌نویسی داشته باشند. البته در پروژه‌های بسیار پیچیده ممکن است محدودیت‌هایی در شخصی‌سازی، مقیاس‌پذیری و کنترل کامل روی سیستم وجود داشته باشد.نمونه‌هایی از این پلتفرم ها:n8n : پلتفرمی برای اتوماسیون فرایندها و اتصال سرویس‌ها با رابط گرافیکیCursor : محیط توسعه مبتنی بر هوش مصنوعی که تولید و ویرایش کد را ساده‌تر می‌کند.Bubble : ابزار ساخت اپلیکیشن وب بدون نیاز به کدنویسیZapier : سرویس اتصال و خودکارسازی بین برنامه‌های مختلفWebflow : پلتفرم طراحی و توسعه وب‌سایت بدون کدنویسیجهت آشنایی بیشتر با این پلتفرم ها به [21] در منابع رجوع شود.Business Process Management Systemsنرم‌افزار مدیریت فرآیند کسب‌وکار (BPMS) ابزاری است که به شرکت‌ها کمک می‌کند فرآیندهای دستی و زمان‌بر را خودکار کرده و آنها را به جریان‌های کاری سازمان‌یافته تبدیل کنند. با استفاده از BPMS می‌توان وظایف مختلفی مثل بررسی و تأیید مدارک، مدیریت اسناد، فرآیندهای استخدام و پاسخ به درخواست‌های کارکنان را ساده و سریع‌تر انجام داد. نسخه‌های پیشرفته‌تر به نام iBPMS با اضافه کردن هوش مصنوعی و تحلیل داده‌های بزرگ و امکانات ابری، امکان خودکارسازی پیچیده‌تر و سرعت بالاتر در طراحی جریان‌ها و هماهنگی بهتر فرآیندها را فراهم کرده اند. این نرم‌افزار ها باعث افزایش بهره‌وری، کاهش کارهای تکراری و بهبود همکاری بین تیم‌ها می‌شوند. همچنین تجربه مشتری را با پاسخ‌دهی منظم و شخصی‌سازی شده بهبود می‌بخشند. BPMS امروز طوری طراحی شده که نیاز چندانی به پشتیبانی توسعه‌دهندگان و تیم IT ندارد و افراد مختلف در سازمان می‌توانند با استفاده از ابزارهای ساده‌ای مثل کشیدن و رها کردن، فرآیندهای خودکار ایجاد کنند. انتخاب نرم‌افزار مناسب بستگی به نیاز کسب‌وکار، نوع فرآیندها، سطح پشتیبانی و بودجه دارد. در کل BPMS ابزاری مهم برای تسهیل کارها، سرعت بخشیدن به عملیات و بهبود هماهنگی و پاسخ‌دهی در سازمان است.مطالعه بیشتر درباره این ابزار در منابع [22] انجام شود.Message Queueصف پیام یک سازوکار است که امکان تعامل بخش های مختلف سامانه را بصورت آسنکرون و غیر همزمان می دهد. در رویکرد های سنکرون یا همزمان، فرستنده بلاک میشود تا از رسیدن پیامش مطمئن شود اما در معماری آسنکرون مثل صف پیام اینگونه نیست و تولید کننده پیام آن را داخل صف گذاشته و به کار خودش ادامه می دهد. این معماری شامل 3 نقش اصلی است:1-تولید کننده پیام2-مصرف کننده پیام3-صف نگهدارنده پیام هاتصویر زیر معماری این ابزارها را نمایش می دهد:خود ساختار پیام معمولا شامل دو بخش هدر و بادی است. بخش هدر شامل متادیتا هایی مانند نوع پیام، تاریخ پیام و آدرس فرستنده و گیرنده است. محتوای بادی نیز شامل اطلاعات اصلی پیام است که در فرمت های مختلفی مانند متن معمولی یا JSON فرستاده میشود. انواع متنوعی از صف های پیام داریم. نوع اول صف نقطه به نقطه است. یعنی به محض مصرف پیام توسط یک مصرف کننده آن پیام حذف میشود. نوع دوم انتشار - اشتراک است که در آن تولید کنندگان صف مخصوص خود را دارند و هر مصرف کننده می تواند پیام های چند تولیدکننده را با مشترک شدن به صف آنها دریافت کند.جهت مطالعه بیشتر این معماری به [23] در منابع رجوع شود.Containers and Container orchestrationدو مفهوم کانتینر و ارکستریشن با ظهور محاسبات و فضاهای ابری بسیار ترند و حائز اهمیت شده اند. Container ها روشی برای بسته‌بندی و اجرای نرم‌افزار هستند که همه وابستگی‌های لازم برنامه مثل کتابخانه‌ها و تنظیمات را در یک محیط ایزوله قرار می‌دهند. به کمک این روش، برنامه روی هر سیستم یا سروری بدون مشکل اجرا می‌شود و تفاوت محیط‌ها باعث خطا نخواهد شد. ابزارهایی مثل Docker باعث شدند استفاده از Containerها در توسعه نرم‌افزار بسیار رایج شود چون فرآیند توسعه، تست و استقرار را سریع‌تر و ساده‌تر می‌کنند.وقتی تعداد Containerها زیاد می‌شود، مدیریت آن‌ها به‌صورت دستی دشوار میشود. اینجاست که Container Orchestration اهمیت پیدا می‌کند. سیستم‌های ارکستریشن وظیفه مدیریت، مقیاس‌پذیری، توزیع و مانیتورینگ Containerها را بر عهده دارند. برای مثال اگر یکی از سرویس‌ها از کار بیفتد، سیستم به‌صورت خودکار آن را دوباره اجرا می‌کند یا در زمان افزایش کاربران، تعداد نمونه‌های سرویس را بیشتر می‌کند. معروف‌ترین ابزار این حوزه Kubernetes است که در بسیاری از زیرساخت‌های ابری و سامانه‌های بزرگ استفاده می‌شود. این فناوری‌ها باعث شده‌اند توسعه و نگهداری سیستم‌های مدرن مخصوصا معماری‌های مبتنی بر میکروسرویس بسیار انعطاف‌پذیرتر و قابل اطمینان‌تر شوند.برای مطالعه بیشتر به [24] و [25] در منابع رجوع شود.Multi-Tenancy Architectureمعماری Multi-Tenancy روشی در طراحی نرم‌افزار است که در آن یک نسخه از برنامه به‌صورت هم‌زمان به چندین کاربر یا سازمان مختلف سرویس می‌دهد. در این معماری هر سازمان که به آن Tenant گفته می‌شود، داده‌ها و تنظیمات مخصوص به خود را دارد اما همه از یک زیرساخت و برنامه مشترک استفاده می‌کنند. این معماری بیشتر در سرویس‌های ابری و نرم‌افزارهای SaaS کاربرد دارد چون هزینه نگهداری و توسعه را کاهش می‌دهد و مدیریت سیستم را ساده‌تر می‌کند. شکل زیر نمایی از این معماری را نمایش می دهد:در معماری Multi-Tenancy، جداسازی اطلاعات کاربران اهمیت زیادی دارد تا داده‌های هر Tenant امن و مستقل باقی بماند. این جداسازی می‌تواند در سطح پایگاه داده، جداول یا حتی منطق برنامه انجام شود. یکی از مزیت‌های اصلی این معماری مقیاس‌پذیری بالا و امکان به‌روزرسانی سریع سیستم برای همه کاربران است. با این حال طراحی آن نیازمند توجه دقیق به امنیت، مدیریت منابع و عملکرد سیستم است تا استفاده هم‌زمان چندین Tenant باعث کاهش کیفیت سرویس نشود.جهت بررسی بیشتر و آشنایی با انواع مختلف این معماری به [26] در منابع مراجعه کنید.Data Migrationمهاجرت به فرآیند انتقال داده‌ها از یک سیستم، پایگاه داده یا زیرساخت به محیطی جدید گفته می‌شود. این کار معمولا زمانی انجام می‌شود که یک سازمان بخواهد نرم‌افزار قدیمی خود را ارتقا دهد، به فضای ابری مهاجرت کند یا سیستم‌های مختلف را با هم یکپارچه کند. در این فرآیند داده‌ها باید بدون از دست رفتن اطلاعات و با حفظ صحت و ساختار اصلی منتقل شوند.مهاجرت داده فقط کپی کردن اطلاعات نیست. معمولاً شامل پاک‌سازی، تبدیل فرمت‌ها و هماهنگ‌سازی داده‌ها با ساختار سیستم جدید نیز می‌شود. اگر این فرآیند به‌درستی انجام نشود، ممکن است باعث ناسازگاری داده‌ها، اختلال در سرویس یا حتی از دست رفتن اطلاعات مهم شود. به همین دلیل قبل از اجرای Data Migration معمولا نسخه پشتیبان تهیه می‌شود و مراحل انتقال در چند مرحله آزمایشی بررسی می شود. امروزه بسیاری از سازمان‌ها هنگام مهاجرت به سیستم‌های ابری یا معماری‌های مدرن از ابزارهای خودکار Data Migration برای کاهش خطا و افزایش سرعت استفاده می‌کنند.برای مطالعه بیشتر درین مورد به [27] و [28] در منابع رجوع کنید.References[1] https://www.ibm.com/think/topics/chaos-engineering[2] https://principlesofchaos.org/[3] https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends[4] https://www.linkedin.com/pulse/what-se4ai-ai4se-cmde-brijendra-singh-rawat/[5] https://computingintelligenceblog.wordpress.com/2023/08/21/what-is-se4ai-and-ai4se/[6] https://liara.ir/blog/mlops-%DA%86%DB%8C%D8%B3%D8%AA/[7] https://aws.amazon.com/what-is/iac/[8] https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac[9] https://www.geeksforgeeks.org/blogs/api-gateway-vs-service-mesh/[10] https://www.akamai.com/glossary/api-gateway-vs-service-mesh[11] https://martinfowler.com/bliki/CQRS.html[12] https://aws.amazon.com/event-driven-architecture/[13] https://medium.com/@dave-patten/serverless-architecture-pros-cons-and-use-cases-4a0769744ca2[14] https://www.geeksforgeeks.org/system-design/serverless-architectures/[15] https://swagger.io/resources/articles/adopting-an-api-first-approach/[16] https://www.geeksforgeeks.org/system-design/domain-driven-design-ddd/ [17] https://martinfowler.com/bliki/DomainDrivenDesign.html[18] https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/hexagonal-architecture.html[19] https://scalastic.io/en/hexagonal-architecture/[20] https://www.geeksforgeeks.org/system-design/event-sourcing-pattern/[21] https://www.techtarget.com/searchsoftwarequality/definition/low-code-no-code-development-platform[22] https://www.microsoft.com/en-us/power-platform/products/power-automate/topics/business-process/bpms-business-process-management-software[23] https://www.geeksforgeeks.org/system-design/message-queues-system-design/[24] https://dev.to/ezinne_anne/containers-what-is-containerization-and-container-orchestration-38pe[25] https://www.stackscale.com/blog/containerization-containers-orchestration/[26] https://www.geeksforgeeks.org/system-design/multi-tenancy-architecture-system-design/[27] https://www.zuar.com/blog/database-data-migration-considerations/[28] https://www.ibm.com/think/topics/data-migration

تحلیل ساختار شبکه هم‌رخدادی واژگان در غزلیات حافظ

محمد صادقی — Sat, 07 Feb 2026 00:24:25 +0330

نویسنده: محمد صادقیدانشجوی کارشناسی ارشد مهندسی نرم افزاردانشگاه شهید بهشتی1-چکیدهتحلیل متون ادبی با استفاده از روش‌های محاسباتی در سال‌های اخیر به یکی از شاخه‌های جذاب پژوهشی در حوزه پردازش زبان طبیعی و علوم شبکه تبدیل شده است. در این پژوهش تلاش شده تا ساختار معنایی و واژگانی غزلیات حافظ شیرازی با بهره‌گیری از مدل‌های شبکه‌های پیچیده مورد بررسی قرار گیرد. در این چارچوب، واژگان به عنوان گره‌های شبکه و هم‌رخدادی آن‌ها در سطح بیت‌های شعر به عنوان یال‌های ارتباطی مدل‌سازی شده‌اند.برای انجام این پژوهش ابتدا مجموعه‌ای از غزلیات حافظ از پایگاه داده گنجور استخراج گردید. پس از پیش‌پردازش زبانی شامل نرمال‌سازی، توکن‌سازی و حذف واژگان دستوری شبکه هم‌رخدادی واژگان ساخته شد. سپس شاخص‌های مختلف تحلیل شبکه از جمله درجه مرکزیّت، بینابینی یال‌ها، چگالی شبکه، ضریب خوشه‌بندی و توزیع درجه مورد محاسبه قرار گرفتند. بعلاوه با استفاده از الگوریتم تشخیص اجتماع، خوشه‌های معنایی غالب در شعر حافظ استخراج گردید.نتایج نشان می‌دهد شبکه واژگان حافظ دارای ساختاری ناهمگن و نزدیک به شبکه‌های مقیاس‌آزاد است و برخی واژگان نقش هسته‌های معنایی را ایفا می‌کنند. همچنین بررسی همبستگی واژگان پرتکرار نشان داد که مفاهیم کلیدی شعر حافظ الزاما به صورت همزمان در یک بیت ظاهر نمی‌شوند و ساختار معنایی شعر حافظ از نوعی توزیع مفهومی گسترده پیروی می‌کند.2-مقدمهادبیات فارسی یکی از غنی‌ترین منابع فرهنگی و زبانی در جهان به شمار می‌رود و آثار شاعرانی مانند حافظ، سعدی، مولوی و صائب تبریزی بخش مهمی از هویت ادبی و فکری جامعه ایرانی را شکل داده‌اند. در میان این شاعران، حافظ شیرازی جایگاه ویژه‌ای دارد به‌گونه‌ای که شعر او نه تنها از نظر زیبایی‌شناسی بلکه از نظر لایه‌های پیچیده مفهومی و نمادین نیز مورد توجه پژوهشگران قرار گرفته است.در سال‌های گذشته تحلیل آثار ادبی عمدتا بر پایه روش‌های سنتی و تفسیری انجام می‌شد. این روش‌ها گرچه بسیار ارزشمند هستند اما به دلیل ماهیت کیفی خود معمولا امکان تحلیل ساختارهای کلان و الگوهای پنهان در مقیاس بزرگ را فراهم نمی‌کنند. با پیشرفت علوم داده و پردازش زبان طبیعی، امکان بررسی متون ادبی از دیدگاه‌های کمی و ساختاری فراهم شده است.یکی از رویکردهای نوظهور در تحلیل متون، استفاده از نظریه شبکه‌های پیچیده است. در این رویکرد، متن به عنوان مجموعه‌ای از عناصر مرتبط در نظر گرفته می‌شود که می‌توان آن را به صورت یک گراف مدل‌سازی کرد. در چنین مدلی، واژگان به عنوان گره‌ها و ارتباط بین آن‌ها به عنوان یال‌ها تعریف می‌شوند. پژوهش‌های مختلف نشان داده‌اند که شبکه‌های زبانی دارای ویژگی‌هایی مشابه شبکه‌های طبیعی و اجتماعی هستند و معمولا ساختارهایی مانند توزیع درجه نامتوازن و خوشه‌بندی معنایی را نشان می‌دهند [1].در حوزه ادبیات فارسی نیز تلاش‌هایی برای تحلیل شبکه‌ای متون انجام شده است اما هنوز بسیاری از آثار کلاسیک به صورت سیستماتیک مورد بررسی قرار نگرفته‌اند. غزلیات حافظ به دلیل تنوع مفهومی و پیچیدگی ساختار زبانی، نمونه‌ای مناسب برای چنین تحلیلی محسوب می‌شود.هدف اصلی این پژوهش بررسی ساختار هم‌رخدادی واژگان در غزلیات حافظ و تحلیل ویژگی‌های شبکه حاصل از آن است. به طور خاص، در این تحقیق سعی شده است به پرسش‌های زیر پاسخ داده شود:آیا شبکه واژگان حافظ دارای ساختار مقیاس‌آزاد است؟کدام واژگان نقش هسته‌های مفهومی را ایفا می‌کنند؟آیا واژگان مهم معمولاً در یک بیت با یکدیگر ظاهر می‌شوند؟خوشه‌های معنایی غالب در شعر حافظ کدامند؟برای پاسخ به این پرسش‌ها از ترکیبی از روش‌های پردازش زبان طبیعی و تحلیل شبکه استفاده شده است.3- ادبیات موضوع و کارهای گذشتهدر دو دهه اخیر، پیشرفت چشمگیر در حوزه‌های پردازش زبان طبیعی، علم داده و نظریه شبکه‌های پیچیده باعث شده است تحلیل متون از چارچوب‌های سنتی فاصله گرفته و وارد فازهای محاسباتی و داده‌محور شود. یکی از شاخه‌های مهم این حوزه، تحلیل ساختار شبکه‌ای زبان است که زبان را به عنوان سیستمی از عناصر مرتبط در نظر می‌گیرد.1-3- تحلیل شبکه ای زبانتحلیل شبکه‌ای زبان بر این فرض استوار است که واژگان و مفاهیم در یک متن به صورت مستقل عمل نمی‌کنند، بلکه در قالب مجموعه‌ای از روابط پیچیده ظاهر می‌شوند. در این رویکرد، واژگان به عنوان گره‌های شبکه و ارتباط میان آن‌ها به عنوان یال تعریف می‌شود. این ارتباط می‌تواند بر اساس هم‌رخدادی واژگان در جمله، پاراگراف یا سایر واحدهای متنی تعریف شود.مطالعات اولیه در این زمینه نشان دادند که شبکه‌های زبانی اغلب دارای ویژگی‌هایی مشابه شبکه‌های پیچیده طبیعی هستند. برای مثال، Ferrer i Cancho و Solé نشان دادند که شبکه واژگان زبان انسانی دارای ساختار مقیاس‌آزاد است، به این معنا که تعداد کمی از واژگان دارای ارتباطات بسیار زیاد هستند، در حالی که اکثر واژگان ارتباطات محدودی دارند [1].همچنین تحقیقات بعدی نشان دادند که شبکه‌های زبانی معمولا دارای ویژگی جهان کوچک (Small-World) هستند. این ویژگی بیان می‌کند که فاصله میان گره‌ها در چنین شبکه‌هایی نسبتا کوتاه است و در عین حال خوشه‌بندی معنایی بالایی وجود دارد [2]. چنین ساختاری در بسیاری از سیستم‌های طبیعی و اجتماعی نیز مشاهده شده است.2-3- تحلیل شبکه ای شعرشعر به دلیل ساختار فشرده و استفاده گسترده از نمادها و استعاره‌ها، یکی از پیچیده‌ترین انواع متون زبانی محسوب می‌شود. این ویژگی باعث شده است تحلیل شعر با استفاده از روش‌های محاسباتی چالش‌برانگیز باشد. با این حال پژوهش‌های متعددی نشان داده‌اند که تحلیل شبکه‌ای می‌تواند ابزار مناسبی برای بررسی ساختار شعر باشد.در برخی مطالعات، هم‌رخدادی واژگان در سطح بیت یا مصرع به عنوان معیار ارتباط در نظر گرفته شده است. این رویکرد به ویژه در تحلیل شعر کلاسیک کاربرد دارد زیرا بیت در بسیاری از سبک‌های شعری فارسی واحد معنایی مستقلی محسوب می‌شود.برخی پژوهشگران نشان داده‌اند که شبکه واژگان در شعر اغلب دارای خوشه‌های معنایی متمایز است که بیانگر موضوعات اصلی شعر هستند. برای مثال خوشه‌هایی مربوط به عشق، عرفان، طبیعت یا مفاهیم اجتماعی می‌توانند در شبکه واژگان ظاهر شوند [5].3-3- پژوهش های انجام شده در ادبیات فارسیدر حوزه ادبیات فارسی، پژوهش‌های محاسباتی نسبتا محدودتر بوده‌اند اما در سال‌های اخیر رشد قابل توجهی داشته‌اند. برخی مطالعات به تحلیل سبک‌شناسی آثار شاعران فارسی با استفاده از روش‌های پردازش زبان طبیعی پرداخته‌اند. این مطالعات نشان داده‌اند که هر شاعر دارای الگوی واژگانی و ساختار معنایی خاص خود است.در پژوهشی که بر روی آثار مولوی انجام شد، شبکه هم‌رخدادی واژگان مورد بررسی قرار گرفت و نتایج نشان داد که مفاهیم عرفانی نقش مرکزی در شبکه معنایی اشعار مولوی دارند [6]. همچنین در مطالعاتی دیگر، ساختار شبکه‌ای اشعار سعدی و فردوسی مورد بررسی قرار گرفته و تفاوت‌های سبک‌شناسی میان این شاعران تحلیل شده است.با وجود این تلاش‌ها، بررسی جامع شبکه واژگان در غزلیات حافظ هنوز به صورت محدود انجام شده است. پیچیدگی زبانی و استفاده گسترده از نمادها در شعر حافظ باعث شده است تحلیل ساختاری این آثار همچنان به عنوان یک چالش پژوهشی مطرح باشد.4-3- جمع بندی ادبیات موضوعمرور پژوهش‌های پیشین نشان می‌دهد که تحلیل شبکه‌ای می‌تواند ابزار قدرتمندی برای بررسی ساختار متون زبانی و ادبی باشد. با این حال در بسیاری از مطالعات تمرکز بر زبان‌های اروپایی بوده و ادبیات فارسی کمتر مورد توجه قرار گرفته است. همچنین در اغلب پژوهش‌ها تحلیل شبکه‌ای در سطح جمله یا متن کامل انجام شده و بررسی هم‌رخدادی واژگان در سطح بیت شعر کمتر مورد مطالعه قرار گرفته است.پژوهش حاضر تلاش می‌کند با تمرکز بر غزلیات حافظ، این خلأ پژوهشی را تا حدی پوشش دهد. در این تحقیق با استفاده از ترکیب روش‌های پردازش زبان طبیعی و تحلیل شبکه‌های پیچیده، ساختار معنایی شعر حافظ مورد بررسی قرار گرفته است. علاوه بر این با تحلیل شاخص‌هایی مانند همبستگی واژگان پرتکرار و کشف خوشه‌های معنایی، تلاش شده است تصویری جامع‌تر از ساختار مفهومی این آثار ارائه شود.4- روش تحقیقدر این پژوهش برای تحلیل ساختار واژگانی غزلیات حافظ از ترکیب روش‌های پردازش زبان طبیعی و تحلیل شبکه‌های پیچیده استفاده شده است. روند انجام پژوهش شامل چند مرحله اصلی بوده است که از جمع‌آوری داده‌ها آغاز شده و تا تحلیل ساختار شبکه واژگان ادامه یافته است. در ادامه هر یک از این مراحل به صورت جداگانه توضیح داده می‌شود.1-4- گردآوری داده هادر نخستین مرحله، لازم بود مجموعه‌ای نسبتا کامل و قابل اتکا از غزلیات حافظ تهیه شود. در ابتدا تلاش شد داده‌ها از طریق API پایگاه گنجور استخراج شوند. گنجور یکی از مهم‌ترین منابع دیجیتال شعر فارسی است که مجموعه بزرگی از آثار شاعران کلاسیک را در اختیار پژوهشگران قرار می‌دهد.با این حال استفاده مستقیم از API این سامانه با محدودیت‌هایی همراه بود. مهم‌ترین چالش‌ها شامل موارد زیر بود:زمان‌بر بودن فرآیند دریافت تعداد زیاد غزلناپایداری اتصال شبکه در برخی درخواست‌هابازگشت ناقص داده‌ها در برخی مواردمحدودیت‌های نرخ درخواست (Rate Limit)به همین دلیل برای افزایش پایداری و تکرارپذیری پژوهش از نسخه پایگاه داده SQLite که شامل مجموعه کامل غزلیات حافظ بود استفاده شد. این پایگاه داده شامل اطلاعاتی مانند شناسه شعر، شماره مصرع، موقعیت مصرع و متن آن بود.در این پژوهش فقط غزلیات حافظ مورد استفاده قرار گرفت و سایر قالب‌های شعری حذف شدند. مجموعا حدود ۴۹۵ غزل در تحلیل لحاظ شد.2-4- تعریف واحد تحلیلیکی از تصمیم‌های مهم در تحلیل شبکه‌ای متون، تعیین واحد تحلیل است. در این پژوهش واحد تحلیل بیت شعر در نظر گرفته شد. دلیل این انتخاب آن است که در شعر فارسی، بیت اغلب یک واحد معنایی نسبتا مستقل محسوب می‌شود. برای تشکیل بیت‌ها، مصرع‌های متوالی هر غزل با یکدیگر ترکیب شدند. به این ترتیب، هر بیت به عنوان یک قطعه متنی مستقل برای استخراج واژگان در نظر گرفته شد.3-4- پیش پردازش زبانیمتون خام شعری معمولا شامل انواع مختلفی از نویسه‌ها، علائم نگارشی و تنوع نوشتاری هستند. بنابراین پیش‌پردازش زبانی یکی از مراحل کلیدی در این پژوهش محسوب می‌شود.در این مرحله از کتابخانه Hazm استفاده شد که یکی از ابزارهای رایج برای پردازش زبان فارسی است. مراحل پیش‌پردازش شامل موارد زیر بود:pip install hazm from hazm import Normalizer, word_tokenize1-3-4- نرمال سازی متندر این مرحله،اشکال مختلف یک نویسه به شکل استاندارد تبدیل شد. برای مثال تفاوت‌های نگارشی حروف «ی» و «ک» یا فاصله‌های اضافی حذف شدند. این کار باعث شد واژگان مشابه به عنوان یک گره واحد در شبکه در نظر گرفته شوند.2-3-4- توکن سازیدرین بخش هر بیت به مجموعه‌ای از واژگان مجزا تبدیل شد. توکن‌سازی به ما اجازه داد ساختار واژگانی هر بیت را استخراج کنیم.3-3-4- حذف واژگان دستورییکی از چالش‌های تحلیل شبکه واژگان، حضور کلمات بسیار پرتکرار اما کم‌معنا مانند حروف اضافه و ضمایر است. وجود این واژگان باعث می‌شود ساختار شبکه تحت تأثیر عناصر غیرمفهومی قرار گیرد.به همین دلیل مجموعه‌ای از واژگان دستوری فارسی به صورت دستی تعریف و از داده‌ها حذف شد. این مجموعه شامل کلماتی مانند «و»، «به»، «از»، «در»، «که» و موارد مشابه بود:STOPWORDS = set([ "و","به","از","در","که","را","با","بر","این","آن", "تا","چو","ز","است","بود","شد","ای", "من","تو","ما","او","شان","ش","ام","ات","اش", "هر","هم","یا","اگر","نیز","جز","گر","چنین","چنان" ])4-4- ساخت شبکه هم رخدادیپس از پیش‌پردازش داده‌ها، شبکه هم‌رخدادی واژگان ساخته شد. در این شبکه:هر واژه به عنوان یک گره در نظر گرفته شداگر دو واژه در یک بیت ظاهر می‌شدند، میان آن‌ها یال ایجاد می‌شدبرای جلوگیری از ایجاد ارتباطات ضعیف یا تصادفی، تنها یال‌هایی در شبکه لحاظ شدند که تعداد هم‌رخدادی آن‌ها حداقل سه بار در کل مجموعه اشعار مشاهده شده بود. این آستانه باعث شد شبکه حاصل ساختار معنادارتری داشته باشد.DB_PATH = "hafez.db" EDGE_THRESHOLD = 3برای پیاده‌سازی شبکه از کتابخانه NetworkX استفاده شد که یکی از ابزارهای استاندارد در تحلیل شبکه‌های پیچیده محسوب می‌شود.5-4- شاخص های تحلیل شبکهپس از ساخت شبکه، چندین شاخص مهم شبکه محاسبه شد تا ویژگی‌های ساختاری آن بررسی شود.1-5-4- درجه مرکزیتاین شاخص نشان می‌دهد هر واژه با چند واژه دیگر ارتباط دارد. واژگانی که درجه بالاتری دارند، معمولا نقش مفاهیم مرکزی در متن را ایفا می‌کنند.2-5-4- بینابینی یال هااین معیار نشان می‌دهد کدام ارتباط‌ها نقش پل میان بخش‌های مختلف شبکه را دارند. یال‌هایی با مقدار بینابینی بالا معمولاً نشان‌دهنده ارتباط میان حوزه‌های معنایی مختلف هستند.3-5-4- چگالی شبکهچگالی شبکه نسبت تعداد یال‌های موجود به حداکثر تعداد یال‌های ممکن را نشان می‌دهد. این شاخص نشان می‌دهد شبکه تا چه حد متراکم یا پراکنده است.4-5-4- ضریب خوشه بندیاین شاخص میزان تمایل واژگان به تشکیل گروه‌های معنایی محلی را نشان می‌دهد. مقدار بالای این شاخص نشان‌دهنده وجود خوشه‌های مفهومی در متن است.5-5-4- طول مسیر متوسطاین معیار نشان می‌دهد فاصله میان واژگان مختلف در شبکه به طور متوسط چقدر است. این شاخص برای بررسی ویژگی جهان کوچک شبکه مورد استفاده قرار می‌گیرد.6-4- تحلیل هم بستگی واژگان مهمبرای بررسی اینکه آیا واژگان کلیدی شعر حافظ معمولاً همراه با یکدیگر ظاهر می‌شوند یا خیر، ماتریس هم‌رخدادی واژگان پرتکرار ساخته شد. سپس با محاسبه همبستگی میان این واژگان، میزان ارتباط آن‌ها تحلیل شد. نتایج این بخش به صورت نقشه حرارتی نمایش داده شد.7-4- کشف خوشه های معناییبرای شناسایی حوزه‌های معنایی غالب در شعر حافظ، از الگوریتم Louvain استفاده شد. این الگوریتم یکی از روش‌های شناخته‌شده برای تشخیص اجتماعات در شبکه‌های بزرگ است و تلاش می‌کند گره‌هایی را که ارتباط بیشتری با یکدیگر دارند در یک گروه قرار دهد.خوشه‌های استخراج شده به عنوان نماینده موضوعات مفهومی شعر حافظ مورد تحلیل قرار گرفتند.8-4- مصورسازی شبکهبرای درک بهتر ساختار شبکه، گراف واژگان مهم و همچنین ساختار کلی شبکه با استفاده از الگوریتم چیدمان فنری ترسیم شد. یکی از چالش‌های این مرحله، نمایش صحیح واژگان فارسی بود که با استفاده از ابزارهای اصلاح راست‌به‌چپ متن حل شد.9-4- محدودیت های روشاین پژوهش با وجود تلاش برای ارائه تحلیلی جامع، دارای محدودیت‌هایی نیز بوده است. مهم‌ترین محدودیت‌ها شامل موارد زیر است:استفاده از فقط یک شاعر به دلیل محدودیت منابع دادهاحتمال حذف برخی واژگان معنادار در فرآیند حذف کلمات دستوریوابستگی نتایج به آستانه انتخاب شده برای ایجاد یال‌هامحدودیت ابزارهای موجود برای پردازش زبان فارسیبا وجود این محدودیت‌ها روش ارائه شده چارچوبی مناسب برای تحلیل شبکه‌ای متون ادبی فارسی فراهم می‌کند.5- ارزیابیپس از اجرای مراحل پیش‌پردازش و ساخت شبکه هم‌رخدادی واژگان، ساختار حاصل مورد تحلیل قرار گرفت. هدف این بخش بررسی ویژگی‌های ساختاری شبکه، استخراج واژگان کلیدی، تحلیل ارتباط میان مفاهیم و ارزیابی کارایی روش پیشنهادی است.1-5- ساختار کلی شبکهپس از پردازش حدود ۴۹۵ غزل حافظ و استخراج بیت‌ها، شبکه هم‌رخدادی واژگان ساخته شد. در این شبکه، هر واژه به عنوان یک گره و ارتباط هم‌رخدادی آن‌ها در سطح بیت به عنوان یال در نظر گرفته شد.نتایج اولیه نشان داد که شبکه حاصل دارای تعداد قابل توجهی گره و یال است که بیانگر تنوع واژگانی بالا در غزلیات حافظ است. این موضوع نشان می‌دهد حافظ در عین استفاده از مفاهیم تکرارشونده، دامنه واژگانی گسترده‌ای را به کار برده است.Ghazals: 495 Total bayts: 4192 Nodes: 1218 Edges: 5908همچنین مشاهده شد که شبکه دارای ساختاری ناهمگن است؛ به این معنا که برخی واژگان ارتباطات بسیار زیادی دارند، در حالی که بسیاری از واژگان تنها با تعداد محدودی از واژگان دیگر مرتبط هستند. چنین الگویی معمولا در شبکه‌های زبانی طبیعی مشاهده می‌شود [1].ساختار شبکه غزلیات حافظ2-5- تحلیل چگالی شبکهچگالی شبکه یکی از شاخص‌هایی است که میزان اتصال میان گره‌ها را نشان می‌دهد. نتایج نشان داد که شبکه واژگان حافظ دارای چگالی نسبتاً پایین است. این موضوع نشان می‌دهد که هر واژه لزوما با همه واژگان دیگر ارتباط ندارد و شبکه دارای ساختاری پراکنده اما سازمان‌یافته است.چگالی پایین در شبکه‌های زبانی معمولا نشانه وجود ساختار معنایی پیچیده است. در چنین شبکه‌هایی، واژگان تمایل دارند در قالب خوشه‌های معنایی ظاهر شوند و ارتباط میان خوشه‌ها از طریق تعداد محدودی از واژگان برقرار می‌شود.Density: 0.0079713635376231363-5- ضریب خوشه بندی و ساختار معنایینتایج نشان داد ضریب خوشه‌بندی شبکه مقدار قابل توجهی دارد. این شاخص نشان می‌دهد واژگانی که با یک واژه خاص ارتباط دارند، معمولا با یکدیگر نیز مرتبط هستند.این ویژگی بیانگر وجود ساختارهای معنایی محلی در شعر حافظ است. به عبارت دیگر واژگان مرتبط با یک مفهوم خاص معمولا در کنار یکدیگر ظاهر می‌شوند و مجموعه‌هایی از مفاهیم مرتبط را تشکیل می‌دهند.چنین الگویی با نتایج پژوهش‌های قبلی در زمینه شبکه‌های زبانی همخوانی دارد و نشان می‌دهد زبان طبیعی تمایل دارد ساختاری خوشه‌ای داشته باشد [2].Average clustering: 0.40196915959297324-5- تحلیل طول مسیر متوسطبررسی طول مسیر متوسط میان گره‌ها نشان داد فاصله مفهومی میان واژگان در شبکه نسبتا کوتاه است. این ویژگی نشان‌دهنده وجود خاصیت جهان کوچک در شبکه واژگان حافظ است.Average path length (largest component): 2.817502228257377خاصیت جهان کوچک بیان می‌کند که هر واژه می‌تواند از طریق تعداد محدودی از ارتباط‌ها به سایر واژگان مرتبط شود. این ویژگی در بسیاری از شبکه‌های طبیعی و اجتماعی نیز مشاهده شده است و نشان‌دهنده کارآمدی ساختار شبکه در انتقال معنا است.5-5- توزیع درجه شبکه شعریکی از مهم‌ترین نتایج این پژوهش مربوط به توزیع درجه گره‌ها بود. نمودار توزیع درجه نشان داد که تعداد کمی از واژگان دارای درجه بسیار بالا هستند، در حالی که اکثر واژگان درجه پایینی دارند.توزیع درجات دم کلفت در شبکه غزلیات حافظتوزیع لگاریتمی درجهاین الگو نشان می‌دهد شبکه واژگان حافظ دارای ساختاری نزدیک به شبکه‌های مقیاس‌آزاد است. در چنین شبکه‌هایی، برخی گره‌ها نقش هسته‌های مرکزی را ایفا می‌کنند و حذف آن‌ها می‌تواند ساختار شبکه را به شدت تحت تأثیر قرار دهد. وجود چنین ساختاری در شبکه واژگان شعر حافظ نشان می‌دهد برخی مفاهیم کلیدی نقش بسیار مهمی در شکل‌دهی ساختار معنایی اشعار دارند.6-5- واژگان مرکزی در شعر حافظبر اساس معیار درجه مرکزیّت، مجموعه‌ای از واژگان به عنوان گره‌های مهم شبکه شناسایی شدند. این واژگان اغلب شامل مفاهیمی بودند که در شعر حافظ نقش محوری دارند.Top words: دل چه حافظ سر چون گل نیست دست جان باد چشم عشق نه روی کرد خوش یار خود غم جام زلف کار کن گفت دوست همه خاک دارد جهان صبا تحلیل این واژگان نشان داد که بسیاری از آن‌ها به حوزه‌هایی مانند عشق، عرفان، رندی و مفاهیم نمادین مرتبط هستند. این نتیجه با دیدگاه‌های سنتی در تفسیر شعر حافظ همخوانی دارد و نشان می‌دهد تحلیل شبکه‌ای می‌تواند به شناسایی مفاهیم مرکزی متن کمک کند.7-5- تحلیل بینابینی یال هادر مرحله بعد، یال‌هایی که دارای مقدار بینابینی بالایی بودند مورد بررسی قرار گرفتند. این یال‌ها معمولا ارتباط میان خوشه‌های معنایی مختلف را برقرار می‌کنند.Top bridging edges: حافظ <-> مشو : 0.00560636311691804 چه <-> خاتم : 0.004833010188179768 مشو <-> ایمن : 0.004833010188179768 گل <-> خار : 0.004833010188179768 عشق <-> بحر : 0.004259116997441751 چه <-> شمع : 0.004190140400875639 شراب <-> دل : 0.004040334444791181 چه <-> خیر : 0.00385926842138339 چه <-> نظر : 0.0035149072269120216 حافظ <-> نظر : 0.003234567825025546 چه <-> زنخدان : 0.00323035839129578 سر <-> کون : 0.0032247052902707003 شراب <-> حریف : 0.0032247052902707 دل <-> حرم : 0.0032247052902707 دل <-> نگه‌دار : 0.0032247052902707 یار <-> مدام : 0.0032247052902707 نه <-> آنم : 0.0032247052902707 جام <-> کنیم : 0.0032247052902707 صد <-> سال : 0.0032247052902707 زر <-> سیم : 0.0032247052902707نتایج نشان داد برخی ارتباط‌ها نقش پل مفهومی میان حوزه‌های معنایی متفاوت را دارند. برای مثال، ارتباط میان واژگان مرتبط با عشق و مفاهیم عرفانی در بسیاری از موارد از طریق تعداد محدودی واژه برقرار شده است. این موضوع نشان می‌دهد شعر حافظ دارای ساختاری چندلایه است که مفاهیم مختلف را به صورت غیرمستقیم به یکدیگر مرتبط می‌کند.8-5- همبستگی واژگان پر تکراربرای بررسی میزان هم‌ظهوری واژگان مهم، ماتریس همبستگی میان واژگان مرکزی ساخته شد. نتایج این تحلیل نشان داد که بسیاری از واژگان کلیدی الزاماً به صورت همزمان در یک بیت ظاهر نمی‌شوند.ماتریس هم بستگی واژگان پر تکرار در اشعار حافظاین یافته نشان می‌دهد مفاهیم مرکزی شعر حافظ به صورت توزیع‌شده در کل مجموعه اشعار حضور دارند و وابستگی آن‌ها به یکدیگر بیشتر در سطح کلان متن قابل مشاهده است تا در سطح یک بیت خاص.9-5- کشف خوشه های معناییبا استفاده از الگوریتم تشخیص اجتماع، چندین خوشه معنایی در شبکه واژگان شناسایی شد. بررسی واژگان هر خوشه نشان داد که این گروه‌ها اغلب نماینده حوزه‌های مفهومی مشخصی هستند.Communities: 18 Community 7 ['آسان', 'اول', 'عشق', 'زان', 'مرا', 'دم', 'راه', 'نبود', 'خود', 'همه', 'کارم', 'نهان', 'ببین', 'ره', 'کار', 'رندی', 'کاین', 'برون', 'پرده', 'راز'] Community 1 ['افتاد', 'شب', 'کجا', 'کز', 'کجاست', 'آفتاب', 'روی', 'چراغ', 'کدام', 'جمال', 'حسن', 'ماه', 'صبحگاهی', 'آینه', 'روز', 'جلوه', 'خوبت', 'رخ', 'عکس', 'کرشمه'] Community 2 ['ولی', 'چه', 'آخر', 'کی', 'تقوا', 'سماع', 'صلاح', 'دریابد', 'دوست', 'کنار', 'حاجت', 'داشت', 'لطف', 'ندانم', 'باشد', 'سود', 'ده', 'حال', 'زاهد', 'رندان'] Community 3 ['خون', 'آب', 'رنگ', 'چشم', 'سیه', 'مژه', 'مست', 'دلم', 'خانه', 'خمار', 'تیر', 'دیده', 'چوگان', 'گوی', 'ارغوان', 'شیوه', 'باز', 'ابروی', 'کمان', 'نقش'] Community 4 ['بوی', 'صبا', 'تاب', 'طره', 'منزل', 'باد', 'خوشش', 'یاد', 'خال', 'دست', 'خط', 'یار', 'خوش', 'دراز', 'مرغ', 'دام', 'سهی', 'آورد', 'بلبل', 'گل']برای مثال، برخی خوشه‌ها شامل واژگان مرتبط با مفاهیم عرفانی و معنوی بودند، در حالی که برخی دیگر به مفاهیم عشق، می و رندی اشاره داشتند. وجود چنین خوشه‌هایی نشان می‌دهد شعر حافظ از ساختاری مفهومی و نظام‌مند برخوردار است.10-5- تحلیل بصری شبکهمصورسازی شبکه واژگان و خوشه‌های معنایی دید بهتری نسبت به ساختار کلی شعر حافظ ارائه داد. در این تصاویر، خوشه‌های معنایی به صورت گروه‌هایی از گره‌های متراکم مشاهده شدند که توسط تعداد محدودی یال به یکدیگر متصل بودند.بصری سازی ساختار جوامع در شبکه شعر حافظساختار شبکه لغات پرتکرار در غزلیات حافظ11-5- چالش های داده و محدودیت های اجراییدر فرآیند انجام پژوهش، برخی محدودیت‌های عملی نیز وجود داشت. مهم‌ترین چالش‌ها شامل موارد زیر بود:کامل نبودن برخی پایگاه‌های داده شعریزمان‌بر بودن دریافت داده‌ها از API گنجورمحدودیت ابزارهای پردازش زبان فارسینیاز به تعریف دستی واژگان دستوریبه دلیل این محدودیت‌ها، تحلیل شبکه تنها بر روی غزلیات حافظ انجام شد. با این حال، چارچوب ارائه شده قابلیت تعمیم به سایر شاعران را دارد.12-5- جمع بندی نتایجنتایج کلی پژوهش نشان می‌دهد شبکه واژگان غزلیات حافظ دارای ویژگی‌های زیر است:ساختار ناهمگن و نزدیک به شبکه‌های مقیاس‌آزادوجود خوشه‌های معنایی مشخصحضور واژگان مرکزی با نقش مفهومی مهمارتباط غیرمستقیم میان حوزه‌های معنایی مختلفاین نتایج نشان می‌دهد تحلیل شبکه‌ای می‌تواند ابزار مؤثری برای درک ساختار مفهومی آثار ادبی باشد.6- جمع بندی و پیشنهاد مسیر آیندهدر این پژوهش تلاش شد ساختار واژگانی غزلیات حافظ با استفاده از روش‌های تحلیل شبکه‌های پیچیده مورد بررسی قرار گیرد. هدف اصلی این تحقیق ارائه تصویری ساختاری از روابط میان واژگان شعر حافظ و بررسی نحوه شکل‌گیری مفاهیم در این آثار بود. برای دستیابی به این هدف، ابتدا مجموعه‌ای از غزلیات حافظ استخراج و پس از انجام مراحل پیش‌پردازش زبانی، شبکه هم‌رخدادی واژگان در سطح بیت ساخته شد. سپس با استفاده از شاخص‌های مختلف تحلیل شبکه، ساختار این شبکه مورد ارزیابی قرار گرفت.نتایج به‌دست‌آمده نشان داد که شبکه واژگان حافظ دارای ساختاری ناهمگن و مشابه شبکه‌های مقیاس‌آزاد است. این ویژگی نشان می‌دهد برخی واژگان نقش بسیار مهمی در سازمان‌دهی معنایی اشعار دارند. چنین الگویی پیش‌تر در تحلیل شبکه‌های زبانی نیز مشاهده شده و نشان‌دهنده ماهیت خودسازمان‌یافته زبان طبیعی است [1].یکی دیگر از نتایج مهم پژوهش، مشاهده مقدار قابل توجه ضریب خوشه‌بندی در شبکه بود. این موضوع نشان داد واژگان مرتبط با یک مفهوم خاص تمایل دارند در قالب گروه‌های معنایی ظاهر شوند. وجود این خوشه‌ها بیانگر آن است که شعر حافظ صرفا مجموعه‌ای از واژگان پراکنده نیست، بلکه ساختاری نظام‌مند و چندلایه دارد.تحلیل توزیع درجه شبکه نیز نشان داد که تعداد محدودی از واژگان دارای ارتباطات بسیار گسترده هستند، در حالی که اکثر واژگان ارتباطات محدودتری دارند. این نتیجه با یافته‌های پژوهش‌های قبلی در حوزه شبکه‌های زبانی همخوانی دارد و نشان می‌دهد متون ادبی نیز از الگوهای ساختاری مشابه سایر سیستم‌های پیچیده پیروی می‌کنند [2].بررسی یال‌های دارای بینابینی بالا نشان داد برخی ارتباط‌ها نقش پل مفهومی میان حوزه‌های معنایی مختلف را ایفا می‌کنند. این یافته نشان می‌دهد مفاهیم موجود در شعر حافظ به صورت مجزا عمل نمی‌کنند، بلکه از طریق مجموعه‌ای از ارتباط‌های غیرمستقیم به یکدیگر متصل هستند.تحلیل همبستگی واژگان پرتکرار نیز نشان داد که واژگان کلیدی شعر حافظ الزاما در یک بیت به طور همزمان ظاهر نمی‌شوند. این موضوع نشان می‌دهد حافظ مفاهیم مرکزی خود را در سراسر مجموعه اشعار توزیع کرده است و از تکرار مستقیم آن‌ها در یک ساختار محدود پرهیز کرده است. چنین رویکردی می‌تواند یکی از دلایل عمق معنایی و چندلایه بودن شعر حافظ باشد.از دیگر دستاوردهای مهم این پژوهش، شناسایی خوشه‌های معنایی در شبکه واژگان بود. بررسی این خوشه‌ها نشان داد مفاهیمی مانند عشق، عرفان، رندی و نمادهای اجتماعی در ساختار شعر حافظ نقش محوری دارند. این نتیجه با تفسیرهای سنتی از شعر حافظ همخوانی دارد، اما تحلیل شبکه‌ای امکان مشاهده این ساختارها را به صورت کمی فراهم می‌کند.با وجود نتایج قابل توجه، این پژوهش دارای محدودیت‌هایی نیز بوده است. مهم‌ترین محدودیت مربوط به دسترسی به داده‌های کامل برای سایر شاعران بود. در ابتدا برنامه‌ریزی شده بود تحلیل مقایسه‌ای میان چند شاعر کلاسیک فارسی انجام شود، اما محدودیت‌های فنی و زمان‌بر بودن دریافت داده‌ها از API گنجور باعث شد تمرکز پژوهش بر غزلیات حافظ محدود شود. با این حال، چارچوب ارائه شده در این تحقیق قابلیت تعمیم به سایر مجموعه‌های شعری را دارد.از سوی دیگر، حذف واژگان دستوری اگرچه باعث افزایش کیفیت تحلیل معنایی شد، اما احتمال حذف برخی واژگان دارای نقش بلاغی را نیز به همراه داشت. همچنین انتخاب آستانه برای ایجاد یال‌ها می‌تواند بر ساختار نهایی شبکه تأثیر بگذارد و نتایج را تا حدی وابسته به تنظیم پارامترها کند.با توجه به نتایج این پژوهش، مسیرهای متعددی برای تحقیقات آینده قابل پیشنهاد است. یکی از مهم‌ترین این مسیرها انجام تحلیل مقایسه‌ای میان شاعران مختلف فارسی است. چنین مطالعه‌ای می‌تواند تفاوت‌های سبک‌شناسی میان شاعران را از منظر شبکه‌ای آشکار کند.مسیر دیگر، ترکیب تحلیل شبکه با روش‌های مدل‌سازی موضوعی مانند LDA است. این ترکیب می‌تواند امکان برچسب‌گذاری دقیق‌تر خوشه‌های معنایی را فراهم کند و درک عمیق‌تری از ساختار مفهومی شعر ارائه دهد.همچنین بررسی تکامل شبکه واژگان در دوره‌های مختلف زندگی شاعران می‌تواند دیدگاه جدیدی درباره تغییر سبک ادبی آن‌ها ارائه کند. علاوه بر این، استفاده از روش‌های یادگیری عمیق و مدل‌های زبانی پیشرفته می‌تواند به استخراج روابط معنایی پیچیده‌تر میان واژگان کمک کند.در مجموع، نتایج این پژوهش نشان می‌دهد تحلیل شبکه‌ای ابزار قدرتمندی برای مطالعه متون ادبی است و می‌تواند دیدگاهی مکمل برای روش‌های سنتی تحلیل ادبی فراهم کند. ترکیب این رویکردها می‌تواند به درک عمیق‌تر ساختار زبان و ادبیات فارسی کمک کند.7- مراجع[1] R. Ferrer-i-Cancho and R. V. Solé, “The small world of human language,” Proceedings of the Royal Society B, vol. 268, no. 1482, pp. 2261–2265, 2001.[2] M. Newman, Networks: An Introduction. Oxford University Press, 2018.[3] D. R. Amancio, E. G. Altmann, O. N. Oliveira Jr., and L. F. Costa, “Comparing intermittency and network measurements of words and their dependence on authorship,” New Journal of Physics, vol. 13, 2011.[4] M. Stella, M. De Domenico, and A. Baronchelli, “Network analysis of narrative structures in literary texts,” EPJ Data Science, vol. 7, no. 1, 2018.[5] J. Liu, Y. Wang, and Z. Zhang, “Complex network analysis of literary texts: A review,” Information Sciences, vol. 512, pp. 236–249, 2020.[6] H. Alikhani and M. Ghiasi, “Computational analysis of Persian poetic texts using complex networks,” Digital Scholarship in the Humanities, vol. 36, no. 3, pp. 610–624, 2021.[7] S. Bird, E. Klein, and E. Loper, Natural Language Processing with Python. O’Reilly Media, 2020.[8] T. Mikolov et al., “Efficient estimation of word representations in vector space,” arXiv preprint arXiv:1301.3781, 2013.[9] V. Blondel et al., “Fast unfolding of communities in large networks,” Journal of Statistical Mechanics, 2008.[10] A. B. Parsa and M. Amini, “Recent advances in Persian NLP and digital humanities,” ACM Computing Surveys, 2023.

مفهوم Cache چیست و سازوکار آن چگونه است؟

محمد صادقی — Sun, 11 Aug 2024 20:11:42 +0330

What is Cache?کش در واقع یک لایه ی حافظه است که مابین حافظه اصلی (RAM) و واحد پردازش (CPU)، یا هر قطعه ای که نیاز به دریافت مکرر داده دارد، قرار می گیرد و وظیفه آن دسترسی سریع تر به داده هاست.در واقع کش را مثل یک کوله پشتی 🎒 نگاه کنید که در عین حجم کم، وسایل پرکاربرد تر و حیاتی تر خود را در آن نگه میدارید تا دسترسی آسان تر و سریع تر به آن داشته باشید.سطح بندی کشاصولا مکانیزم کش دارای ۳ سطح رایج است: L1 - L2 - L3هرچه به سطوح پایین تر می رویم به حافظه اصلی نزدیک تر می شویم. طبعا با افزایش حجم حافظه کش سرعت دسترسی کمتر می شود و باید زمان بیشتری منتظر بمانیم تا داده مد نظر ما از کش خوانده شود.در تصویر زیر اطلاعات عمومی سطوح مختلف کش آورده شده است:different cache level latencyهمانطور که می بینید در سطوح پایین تر، حجم کش افزایش می یابد و مدت زمان بیشتری برای hit شدن صرف خواهد شد. حال این پرسش مطرح می شود که hit به چه معناست؟ در ادامه به این موضوع میپردازیم...مفاهیم Hit و Miss کوله پشتی را بخاطر بیاورید.🤔 وقتی شما به دنبال وسیله ای در کوله تان باشید ۲ حالت رخ میدهد:۱) آن را با صرف زمان کمی یافت میکنید (Hit)۲) آن را در کوله یافت نمی کنید (Miss) و مجبور می شوید بروید در چمدانتان آن را پیدا کرده و برای استفاده های بعدی تان آن را در کوله بگذارید.سیستم کش هم همینگونه است. اگر CPU داده مخصوصی را درخواست کند، ابتدا در کش به دنبال آن می گردد و اگر درخواستش Hit شود یعنی آن را پیدا کرده است. ولی اگر آن را یافت نکند، بدین معناست که درخواستش Miss شده و مجبور میشود به حافظه اصلی برود و آنجا با صرف زمان بیشتر به دنبال داده خود بگردد و وقتی آن را پیدا کرد، جهت استفاده های بعدی خود آن را در کش ذخیره کند.حال سوالی که پیش می آید این است که کوله پشتی ما حجم مشخصی دارد و نمی توانیم هرچقدر دلمان خواست در آن وسیله بریزیم. اگر کوله مان پر بود چگونه جایگزین کنیم؟جواب را در ادامه خواهیم دید...سیاست های Cache Writingروش های متعددی برای جایگزینی در کش وجود دارد که من اینجا چند مورد از رایج ترین ها را نام می برم:۱) سیاست LRUمخفف Least Recently Used هست بدین معنا که شما داده (ها) ای را که از نظر زمانی زودتر استفاده کرده اید را خارج می کنید. منظور از زودتر، تایمی است که آن داده توسط یک درخواست Hit شده باشد. بعنوان مثال اگر بین ۳ داده a,b,c هر کدام به ترتیب در زمان های 2s , 17s و 8s از کش خوانده شده باشند، داده b چون خیلی قبل تر از دو داده دیگر خوانده و استفاده شده است از کش خارج شده و داده دیگری جای آن را می گیرد.۲) سیاست MRUمخفف Most Recently Used هست که مشابه روش قبلی است با این تفاوت که داده ای را جایگزین میکنیم که از نظر تعدد، بیشترین درخواست را از سمت CPU داشته است.در واقع پر استفاده ترین داده را حذف میکنیم.۳) سیاست FIFOمخفف First In First Out می باشد که یعنی مثل صف نانوایی 🫓افراد به ترتیب وارد شدن در صف خارج میشوند. در کش هم همینگونه عمل میشود و در صورت پر شدن آن، داده ها به ترتیب ذخیره شدن شان در کش از آن خارج می شوند.۴) سیاست Random Replacementهمانگونه که از نامش مشخص است درین روش هر بار بصورت تصادفی داده ای را جایگزین میکنیمدرین مقاله به جزییات پیاده سازی این سیاست ها نمی پردازم و توضیح آن را به شرط حیات در مقاله دیگری شرح خواهم داد.جزییات و روش های تکمیلی را در این لینک مشاهده کنید.