https://virgool.io/feed/@m_60905393 fa 2026-06-07 12:08:09 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@m_60905393 https://virgool.io/@m_60905393/architecture-without-architects-xconf-sea-2021-mvf6qqt870up ویدئویی که در اینجا می‌توانید مشاهده کنید از سخنران اریک بیان شده استمعرفیسخنران، اریک، با بحث در مورد نقش سنتی معماران در توسعه نرم افزار شروع به صحبت می‌کند. او استدلال می‌کند که اصطلاح "معمار" اغلب به اشتباه استفاده می شود و مسئولیت های معماران در طول زمان تکامل یافته است. او همچنین پیشنهاد می کند که نقش سنتی معماران در چشم انداز توسعه نرم افزار مدرن کمتر مرتبط می شود.اریک استدلال می کند که اصطلاح "معمار" اغلب برای توصیف هر کسی که در طراحی نرم افزار نقش دارد استفاده می شود. با این حال، او معتقد است که این استفاده نادرست از این اصطلاح است. او استدلال می کند که معماران باید مسئول ساختار کلی و طراحی سیستم های نرم افزار باشند، در حالی که نقش های دیگر، مانند توسعه دهندگان و طراحان، باید مسئول اجرای ویژگی های خاص باشند. همچنین شاید بهتر باشد ما بجای کلمه معمار از کلمه باغبان استفاده کنیم ولی من فکر می‌کنم چون پرستیژ کمتری دارد استفاده نمی‌کنیم.سیر تحول نقش معماراناریک استدلال می کند که نقش معماران در طول زمان تکامل یافته است. در روزهای اولیه توسعه نرم افزار، معماران مسئول طراحی کلی سیستم های نرم افزاری بودند. با این حال، با پیچیده تر شدن سیستم های نرم افزاری، نقش معماران تخصصی تر شده است. امروزه معماران اغلب مسئول بخش های خاصی از نرم افزار هستند، مانند معماری پایگاه داده یا معماری رابط کاربری.زوال نقش سنتی معماراناریک استدلال می کند که نقش سنتی معماران در چشم انداز توسعه نرم افزار مدرن کمتر مرتبط می‌شود. او معتقد است که این به دلیل عوامل متعددی از جمله ظهور روش‌های توسعه چابک، افزایش استفاده از محاسبات ابری و محبوبیت روزافزون نرم‌افزارهای منبع باز است.نقش معماران در چشم انداز توسعه نرم افزار مدرناریک استدلال می کند که معماران هنوز نقشی در چشم انداز توسعه نرم افزار مدرن دارند. با این حال، او معتقد است که نقش آنها در حال تغییر است. او پیشنهاد می کند که معماران باید به جای تلاش برای دیکته کردن طراحی سیستم های نرم افزاری، بر ارائه راهنمایی و پشتیبانی برای توسعه دهندگان تمرکز کنند. معماری و نرم افزار دو بخش غیر قابل تفکیک هستند. یکی از کارهایی که معماران باید تصمیم بگیرند این می‌باشد که یک کاری را توسط ابزار یا منابع باز پیاده سازی کنند و یا اینکه از نیروهای کاری استفاده کنند.اهمیت عملکردهای تناسب انداماریک استدلال می کند که معماران باید بر توسعه عملکردهای تناسب اندام برای سیستم های نرم افزاری تمرکز کنند. توابع تناسب اندام معیارهایی هستند که می توانند برای اندازه گیری سلامت و عملکرد یک سیستم نرم افزاری استفاده شوند. با توسعه عملکردهای تناسب اندام، معماران می‌توانند به اطمینان از طراحی و پیاده سازی سیستم های نرم افزاری به گونه ای کمک کنند که نیازهای کسب و کار را برآورده کند.نقش معماران به عنوان راهنمااریک استدلال می کند که معماران باید به عنوان راهنما برای توسعه دهندگان عمل کنند. او معتقد است که معماران باید به توسعه دهندگان کمک کنند تا معماری کلی سیستم نرم افزار را درک کنند و در مورد طراحی و اجرای ویژگی های خاص تصمیم گیری آگاهانه بگیرند. همچنین یک راهنمایی مداوم است و باید همواره همراه پروژه باشند. همچنین معماران باید دربرابر تغییرات باید آمادگی داشته باشند زیرا نیازهای نرم‌افزار به مرور تغییر خواهند کردنتیجهاریک با این استدلال نتیجه می گیرد که نقش معماران در حال تغییر است، اما آنها هنوز نقش ارزشمندی در چشم انداز توسعه نرم افزار مدرن دارند. او پیشنهاد می کند که معماران باید بر ارائه راهنمایی و حمایت از توسعه دهندگان، توسعه عملکردهای تناسب اندام، و عمل به عنوان راهنما برای توسعه دهندگان تمرکز کنند. علیرضا صفافرد علیرضا صفافرد Wed, 27 Dec 2023 16:03:16 +0330 https://virgool.io/@m_60905393/evolutionary-architecture-from-start-up-to-scale-up-qcon-2020-lbxauwowvgxq ویدئویی که در اینجا می‌خواهم از آن صحبت کنم توسط دیوید سانتورو، مدیر ارشد فناوری carwow آمده است:سخنران در مورد اینکه چگونه معماری وب سایت شرکتش که از یک استارتاپ به یک مقیاس بزرگ تبدیل کرده سخنرانی کرده است. او قوانین زیر را برای ما به اشتراک می‌گذارد که خود در راه انتقال از حالت startup به حالت enterprise رعایت کرده است.روی محصول تمرکز کنید. درگیر جزئیات معماری نشوید. در عوض، روی ساختن محصولی تمرکز کنید که مردم بخواهند از آن استفاده کنند.چرخ را دوباره اختراع نکنید ابزارها و چارچوب های زیادی وجود دارد که می توانید از آنها برای صرفه جویی در زمان و تلاش استفاده کنید.طراحی برای آزمایش پذیری آزمایش کد خود را آسان کنید تا بتوانید با تغییر نیازهای خود، آن را به راحتی تغییر دهید.نظارت بر تولید داشته باشید. از ابزارهایی برای نظارت بر محیط تولید خود استفاده کنید تا بتوانید به سرعت مشکلات را شناسایی و رفع کنید.طراحی برای حذف: باین قانون به این معنی است که شما باید کد خود را طوری طراحی کنید که در مواقعی که دیگر به آن نیازی نیست حذف آن آسان باشد. این باعث می شود که پایگاه کد شما در دراز مدت نگهداری و تکامل یابد.چند دلیل وجود دارد که چرا باید برای حذف طراحی کنید. ابتدا، با رشد شرکت شما و تغییر نیازهای شما، ناگزیر باید برخی از کدهای قدیمی خود را حذف کنید. اگر کد شما برای حذف طراحی نشده است، این می تواند یک فرآیند بسیار دشوار و زمان بر باشد. دوم، طراحی برای حذف می تواند به شما در جلوگیری از بدهی فنی کمک کند. بدهی فنی انباشته شدن تصمیمات بدی است که در طول توسعه نرم افزار گرفته می شود. این تصمیمات می تواند حفظ و تکامل کد شما را دشوارتر کند و همچنین می تواند منجر به مشکلات عملکرد و آسیب پذیری های امنیتی شود. سوم، طراحی برای حذف می تواند به شما کمک کند تا پایه کد خود را ناب و کارآمد نگه دارید. اگر دائماً کدهای قدیمی را حذف می کنید، کد کمتری برای نگهداری خواهید داشت و درک و اشکال زدایی کد شما آسان تر خواهد بود. با رعایت موارد زیر خیلی عملیات حذف راحت می‌شوداز کوپلینگ شل و وارونگی وابستگی استفاده کنید. این کار جایگزینی یک کد با کد دیگر را آسان تر می کند. از کلاس ها و رابط های انتزاعی استفاده کنید. این کار استفاده مجدد از کد را آسان‌تر می‌کند و از اتصال تنگاتنگ جلوگیری می‌کند. از اشیاء دسترسی به داده (DAO) برای کپسوله کردن کد دسترسی به پایگاه داده استفاده کنید. این کار تغییر طرح پایگاه داده خود را بدون تأثیر بر روی کد برنامه آسان تر می کند. از صف های پیام برای جدا کردن اجزا استفاده کنید. این کار جایگزینی یک جزء با دیگری را بدون تأثیر بر سایر اجزا آسان تر می کند. از جمع آوری زباله برای حذف خودکار اشیاء استفاده نشده استفاده کنید. این به کاهش مصرف حافظه شما کمک می کند.با پیروی از این نکات، می توانید کد خود را طوری طراحی کنید که در زمانی که دیگر مورد نیاز نیست، حذف آن آسان تر باشد. این باعث می شود که پایگاه کد شما در دراز مدت نگهداری و تکامل یابد.محدودیت های عملکرد را زودتر تنظیم کنید. این به شما کمک می کند تا از مشکلات عملکردی در آینده جلوگیری کنید.قوانین سانتورو نقطه شروع عالی برای هر کسی است که سعی در تکامل معماری خود دارد. با این حال، مهم است که به یاد داشته باشید که هیچ رویکرد یکسانی برای معماری وجود ندارد. بهترین راه برای تکامل معماری شما بسته به موقعیت خاص شما متفاوت خواهد بود.سانتورو همچنین توصیه هایی را در مورد چگونگی جلوگیری از اشتباهات رایج هنگام تکامل معماری به اشتراک گذاشت. به عنوان مثال، او از همان ابتدا نسبت به تلاش برای ساخت یک معماری بی نقص هشدار داد. در عوض، با یک معماری ساده شروع کنید و با تغییر نیازهایتان آن را توسعه دهید. او همچنین نسبت به مهندسی بیش از حد کد شما هشدار داد. فقط مطمئن شوید که کد شما قابل درک و نگهداری آسانی دارد.اهمیت فرهنگ تیمیدر نهایت سانتورو بر اهمیت داشتن فرهنگ تیمی قوی تاکید کرد. تیمی که مشتاق محصول است و به کیفیت متعهد است، احتمال موفقیت بیشتری در توسعه معماری آن خواهد داشت.در اینجا چند نکته کلیدی اضافی از سخنرانی آورده شده است:معماری ایستا نیست. با رشد شرکت شما و تغییر نیازهای شما، باید تکامل یابد.اشکالی ندارد. نکته مهم این است که از اشتباهات خود درس بگیرید و به حرکت رو به جلو ادامه دهید.از آزمایش نترسید. هیچ راه درستی برای تکامل معماری شما وجود ندارد. بهترین رویکرد بسته به موقعیت خاص شما متفاوت خواهد بود.نتیجه:توسعه معماری شما می تواند یک کار دلهره آور باشد، اما یک کار مهم است. با رعایت پنج قانون سانتورو و اجتناب از اشتباهات رایج، می توانید شانس موفقیت خود را افزایش دهید. علیرضا صفافرد علیرضا صفافرد Wed, 27 Dec 2023 14:38:35 +0330 https://virgool.io/@m_60905393/software-architecture-vs-code-simon-brown-goto-2014-gplkuald2s41 خلاصه ای از ارائه انجام شده در اینجا بیان می‌کنیم. در این ویدئو سایمون تلاش می‌کند یک رابطه خوبی بین معماری و کد برقرار کند. یکی از اشتباهات رایج در درک معماری نرم افزار این است که بیشتر درباره چشم اندازه‌های دور صحبت می‌شود ولی این مورد باعث می‌شود ارتباط معماری با کد کاهش پیدا کند. در عوض سخنران می‌گوید باید به کمک نمودارها ارتباط موثر بین معماری و سطح کد ایجاد شود، او همچنین اهمیت همراستایی معماری نرم افزار با کد را مورد بحث قرار می دهد و مثالی از نحوه انجام این کار با استفاده از معماری لایه ای ارائه می دهد.باید در هنگام مستند سازی کاملا abstract بنویسید و درگیر جزئیات نشویدمعماری نرم افزار در واقع در مورد ساختار یک سیستم نرم افزاری است.معماری نرم افزار را می توان به طور موثر با استفاده از نمودارهای ساده ارتباط داد.معماری نرم افزار باید با کد هماهنگ باشد.روش های مختلفی برای تجزیه یک سیستم نرم افزاری وجود دارد.رویکردهای چابک در مورد گذشته نگر و بازرسی و تطبیق صحبت می کنند.اگر می‌خواهیم یک معماری چابک بسازیم، باید همین مانترا را در سیستم خود اعمال کنیم.اگر بدانید چه چیزی دارید و به کجا می خواهید برسید، بازسازی معماری سخت نیست.یک نگاشت صریح ساده بین نمودارها و کد واقعا کمک می کند.اگر کار با سیستم نرم افزاری شما سخت است، آن را تغییر دهید.استفاده از رویکرد C4 را پیشنهاد می‌دهد زیرا مانند یک نقشه عمل می‌کند و شما می‌توانید به راحتی به داخل هر بخش zoom کنید و مشخصات داخلی آن را مشاهده کنیدیکی از موضوعات مهم دیگری که در سخنرانی بحث می‌شود که من سعی کردم دقیق تر آن را توضیح دهم یعنی کمی بیشتر بسط دادم این موارد را.تفکیک نگرانی ها (SoC)جداسازی نگرانی ها (SoC) یک اصل اساسی طراحی نرم افزار است که از تقسیم یک سیستم نرم افزاری به ماژول ها یا اجزای مستقل و کاملاً تعریف شده حمایت می کند. هر ماژول یا جزء باید مسئولیت خاصی داشته باشد و نباید با ماژول ها یا اجزای دیگر فراتر از محدوده تعیین شده خود تعامل داشته باشد. این امر باعث ارتقای ماژولار بودن، کاهش پیچیدگی و افزایش قابلیت نگهداری با آسان‌تر کردن سیستم برای درک، اصلاح و اشکال‌زدایی می‌شود. از مزایای این رویکرد موارد زیر می‌باشد:1. مژولاریت: ماژول‌های جداگانه امکان توسعه، آزمایش و استقرار مستقل را فراهم می کند و سیستم را انعطاف پذیرتر و سازگارتر با تغییرات می کند.2.کاهش پیچیدگی: با تقسیم سیستم به واحدهای کوچکتر و قابل مدیریت، SoC ساختار کلی را ساده می‌کند و درک و پیمایش آن را آسان‌تر می‌کند.3. قابلیت نگهداری: قابلیت نگهداری بهبود می‌یابد و توانایی جداسازی و اصلاح اجزای خاص بدون تأثیر بر کل سیستم میسر می‌شود.4. آزمایش پذیری: ماژول های مجزا با فعال کردن تست متمرکز بر روی اجزای جداگانه و جداسازی مسائل احتمالی، قابلیت تست را افزایش می دهند.5.استفاده مجدد از کد: ماژول‌ها به خوبی تعریف شده این قابلیت را دارند که در پروژه‌های دیگه نیز استفاده شوندهمچنین چند نکته برای دستیابی به SOC را نیز بیان می‌کند:1.مرزهای ثابت را شناسایی کنید: مرزهای واضحی را بین ماژول ها تعریف کنید و اطمینان حاصل کنید که آنها فقط در حوزه های مربوطه خود تعامل دارند.2. استفاده از Encapulation: پیاده سازی تکنیک های encapsulation برای مخفی کردن جزئیات پیاده سازی داخلی، بسیار مهم است.3. انتزاع: از انتزاع برای ارائه رابط‌های سطح بالا برای ماژول‌ها استفاده کنید و پیچیدگی های اساسی آن‌ها را پنهان کنید.4.اصل جداسازی رابط: از واسط‌های یکپارچه که ماژول ها را مجبور به پیاده سازی روش های غیر ضروری می‌کنند، اجتناب کنید. رابط‌ها را به رابط‌های کوچکتر و خاص‌تر تقسیم کنید.5.تزریق وابستگی: از تزریق وابستگی برای از بین بردن نیاز به وابستگی های رمزگذاری شده استفاده کنید، که باعث اتصال شل و انعطاف پذیری می شود.6.سازمان کد: ساختارهای کد را به گونه ای سازماندهی کنید که منعکس کننده تفکیک نگرانی‌ها باشد، با استفاده از قراردادهای نامگذاری و ساختارهای دایرکتوری برای افزایش وضوح حتما استفاده کنید.7.مستندات: مستندسازی کامل ماژول ها و مسئولیت های آنها به حفظ درک ساختار و تعاملات سیستم کمک می کند.8.بازبینی مستمر: به طور منظم پایبندی سیستم به اصول SoC را بررسی و ارزیابی کنید و اطمینان حاصل کنید که ماژول‌ها به خوبی تعریف شده و مستقل باقی می‌مانند.با پیروی از این نکات، معماران و توسعه دهندگان نرم افزار می توانند به طور موثر جداسازی نگرانی ها را پیاده سازی کنند که منجر به سیستم های نرم افزاری قابل نگهداری، آزمایش پذیر و سازگارتر شود.به طور کلی، این ویدئو منبع ارزشمندی برای هر کسی است که می‌خواهد درباره معماری نرم‌افزار اطلاعات بیشتری کسب کند. به خوبی ارائه شده و آموزنده است و تعدادی نکته عملی را ارائه می دهد که می تواند در پروژه های دنیای واقعی اعمال شود. علیرضا صفافرد علیرضا صفافرد Wed, 27 Dec 2023 12:09:57 +0330 https://virgool.io/@m_60905393/good-enough-architecture-stefan-tilkov-goto-2019-dkoj9ynymtu8 مرور ارائه انجام شده در کنفرانس اینجا قرار دارد را می‌خواهیم انجام دهیم.سخنران، Stefan Tilkov، مفهوم معماری "به اندازه کافی خوب" را در زمینه توسعه نرم افزار مورد بحث قرار می‌دهد. او استدلال می‌کند که معماری یک راه حل یکسان نیست و بهترین معماری برای یک پروژه خاص به نیازها و محدودیت های خاص آن پروژه بستگی دارد. او همچنین تاکید می‌کند که معماری یک فرآیند مداوم است که باید با تغییر پروژه دائما در حال تغییر باشد و با رشد سازمان نیز همگام باشد.همچنین سخنران تلاش می‌کند چندین مورد را با خطاهای احتمالی و راحل‌های خود بیان کندتوسعه پذیری غیر قابل توسعه: این زمانی اتفاق می‌افتد که یک معماری بسیار سفت و سخت و غیر قابل انعطاف باشد و افزودن ویژگی‌های جدید یا انطباق با نیازهای در حال تغییر را دشوار کند. به طور کلی باید ویژگی نرم بودن یک نرم‌افزار را همواره در نظر بگیریم و بدانیم یک نرم افزار باید در برابر توسعه و یا تغییر ویژگی همواره قابلیت انعطاف را داشته باشد.اگر تلاش کنی تمام مشتریان موجود را راضی نگهداری مطمئن باشید در انتهای کار هیچ یک راضی نخواهند بود.خیلی ریزدانه شدن: یکی از ایرادات رایج معماری بیان ریزدانه معماری کلی نرم‌افزار است این موضوع خوب نیست زیرا در مرزهایی که تیم‌ها باهم کار می‌کنند این ریزدانگی‌ها مشکل ساز می شود پیشنهاد می‌شود خیلی ریز بیان نشود و بخش‌های ریز هر بخش به مسولین داخل هر تیم واگذار شود. بعدا به راحتی می‌شود موارد داخل تیم را بازسازی کرد زیاد نگران این موضوع نباشید. برخی از پارامتر‌های سازمان را با مسئولیت خودتان نادیده بگیرید. تغییرات بزرگ بسیار سخت تر از تغییرات داخل هر تیم است پس سعی کنید درشت دانه دسته بندی کنید تا مرزهای بین تیم‌ها شفاف تر باشد.سیستم شما باید پویا باشد: دلیلی وجود ندارد تمام اتفاقات در معماری قرار گیرد به عنوان مثال اگر یک فیلد از دیتا دیاگرام تغییر کرد ثبت بشود باید مواردی که ضروری هستند در سند قرار بگیرند. نباید مسئولیت سیستم متمرکز باشد بلکه این یک کار تیمی است و باید با بقیه اعضا تیم مورد بررسی قرار گیرد. اگر کار سخت شده است و بسیار پیچیده باید راه دیگری پیدا کنید.اگر به کاری عادت کردید دلیل بر این نیست که این مسیر درست است.معماری آزادانه: این مورد نیز اصلا خوب نیست و زمانی رخ می‌دهد که شما در معماری نرم افزار هیچگونه قیدی قرار ندهید و بدون ساختار نرم‌افزار را تولید کنید. نگهداری و پشتیبانی چنین معماری بسیار سخت است. در رویکرد میکروسرویس اگر قوانین و نحوه ارتباطات استاندارد نباشد شما یک ادغام بسیار ناکارآمد در بخش UI و frontend خواهید داشت. و frontend یک نقطه بحرانی پروژه خواهد شد. در بسیاری از موارد تنوع و استفاده از ابزارهای متنوع کار خوبی است ولی به شرط اینکه تمام این‌ها از قوانین معماری پیروی کنند نباید بگذارید هرج و مرج ایجاد شود. بین هرج و مرح و تنوع مرز باریکی وجود دارد که باید رعایت شود.رشد سرطانی: سیستم‌های موفق از نظر کسب و کاری چون با یک توسعه ساده شروع می‌شوند و به مرور زمان تکامل پیدا می‌کنند لذا بسیار باید مراقب این موضوع باشند زیرا اگر یک مشکلی در ابتدا قرار گیرد تمام مواردی که در ادامه توسعه پیدا می‌کنند بر پایه مورد اول توسعه پیدا می‌کنند و ممکن است به یک معماری مشکل دار تبدیل شود به نوعی تکامل مدیریت نشده منجر به ایجاد هرج و مرج در سیستم خواهد شد. لذا از حاکمیت سبک معماری و محدودیت‌های آن نترسید و سعی کنید آن را رعایت کنید تا دچار هرج و مرج نشوید.با هوش کمتر پیشرفت کنید: سخنران سه مدل مثال از شرکت‌های بزرگ می‌آورد و به کمک این سه مثال ما نکات زیر را برداشت می‌کنیم.برای ایجاد معماری انعطاف‌پذیرتر و سازگارتر، از یک ریزمعماری با نقشه‌های اولیه استفاده کنید. به توسعه دهندگان نقشه هایی ارائه دهید تا به آنها کمک کند تا به سرعت اجزای جدید را ایجاد کنند. در صورت لزوم آماده باشید تا کد سفارشی را به یک راه حل منبع باز اضافه کنید.مطمئن شوید که معماری شما قابل توسعه و مستند است. علیرضا صفافرد علیرضا صفافرد Tue, 26 Dec 2023 20:54:44 +0330 https://virgool.io/@m_60905393/%D9%85%D8%B1%D9%88%D8%B1-%D8%A7%D8%B1%D8%A7%D8%A6%D9%87-%D8%AC%D8%AF%DB%8C%D8%AF-goto-2023-k6lwiv6byeye در این متن هدف بر این است که کنفرانس Energy-Efficient Software Architecture for Developers • Henrik Bærbak Christensen • GOTO 2023 را که در لینک زیر توضیحات و اسلاید‌ها و فایل ویدئو آن آمده است توضیح دهم.https://gotoaarhus.com/2023/sessions/2544/energy-efficient-software-architecture-for-developersدر این ارائه تلاش بر این است که نشان دهند چندین راه برای کاهش مصرف انرژی در حوزه تولید نرم‌افزار وجود دارد و چند ویژگی برای رویکرد خود بیان می‌کند تا مصرف انرژی کاهش پیدا کند به عنوان مثال می‌گوید:یکی از ساده‌ترین راه‌های کاهش مصرف انرژی، خاموش کردن دستگاه‌هایی است که در حال استفاده نیستند. این شامل کامپیوترها، لپ‌تاپ‌ها، تلفن‌های هوشمند، تبلت‌ها و سایر دستگاه‌های الکترونیکی است. اگر دستگاه‌ها در حالت آماده به کار باشند، همچنان مقداری انرژی مصرف می‌کنند. به عنوان مثال، یک کامپیوتر شخصی در حالت آماده به کار می‌تواند حدود 10 وات انرژی مصرف کند. اگر کامپیوتر شخصی خود را هر شب خاموش کنید، می‌توانید سالانه حدود 100 دلار در هزینه‌های انرژی صرفه‌جویی کنید. در ادامه ۷ تاکتیکی که در سخنرانی دکتر کریستینس ارائه می‌شود را به تفکیک توضیح می‌دهم و در ادامه نیز چند نکته اضافی را بیان می‌کنمخاموش کردن دستگاه‌ها در هنگام بی‌کارییکی از ساده‌ترین و موثرترین راه‌های کاهش مصرف انرژی، خاموش کردن دستگاه‌هایی است که در حال استفاده نیستند می‌باشد. این شامل کامپیوترها، لپ‌تاپ‌ها، تلفن‌های هوشمند، تبلت‌ها و سایر دستگاه‌های الکترونیکی است. حتی اگر دستگاه‌ها در حالت آماده به کار باشند(sleep)، همچنان مقداری انرژی مصرف می‌کنند. اگر برنامه کاربردی یک گوشی همراه را ایجاد کرده‌اید در زمانی که کاربر نرم افزار شما را متوقف می‌کند شما نرم‌افزار خود را متوقف کنید زیرا استفاده از سنسورهای دستگاه در زمانی که نیاز ندارید مصرف انرژی را به همراه خواهد داشت.استفاده از معماری میکروسرویس و پرهیز از استفاده از منابع غیر ضروریمیکروسرویس‌ها یک معماری نرم‌افزاری هستند که در آن برنامه به چندین سرویس کوچکتر تقسیم می‌شود. این سرویس‌ها به طور مستقل اجرا می‌شوند و می‌توانند به صورت خودکار مقیاس‌بندی شوند. استفاده از میکروسرویس‌ها می‌تواند به کاهش مصرف انرژی کمک کند زیرا سرویس‌های غیرفعال می‌توانند به راحتی متوقف شوند. به عنوان مثال، اگر یک برنامه وب از میکروسرویس‌ها برای ارائه محتوای مختلف استفاده کند، می‌توان سرویس‌هایی که در حال حاضر مورد نیاز نیستند را متوقف کرد. این کار می‌تواند به کاهش مصرف انرژی سرور برنامه وب کمک کند. همچنین استفاده از سرویس FAAS در سرویس‌های ابری بسیار مفید است زیرا یکی از ویژگی‌های این نوع سرویس آماده سازی سریع و آزاد سازی منابع بعد از اجرا توابع می‌باشد. این رویکرد بسیار کارایی را افزایش می‌دهد. لذا لازم نیست ما مصرف انرژی برای ایجاد محیط برای اجرای سرویس را فراهم کنیم بلکه این ویژگی را سرویس دهندگان ابری به خوبی برای ما فراهم می‌کنند. همچنین تاجای ممکن باید سعی بشود کد کمتری را در داخل فایل exe خود قرار دهیم به عنوان مثال ممکن است ما کتابخانه بسیار بزرگی را برای کار بسیار کوچکی استفاده کرده باشیم ولی در هنگام ساخت فایل خروجی نرم‌افزار تمام کتابخانه در این فایل قرار میگیرند و خود این موضوع باعث می‌شود فایل حجیمی ارسال شود و اینترنت بیشتری مصرف شود که اصلا ضروری نیست.همچنین کاهش مصرف انرژی در زمینه شبکه بسیار مهم است هر یک بایتی که از سمت مشتری به سمت سرور ارسال می‌شود یک عامل موثر در تولید کربن می‌باشد به عنوان مثال دیتایی مانند "version identifier" لازم نیست در تمام ریکوست‌های ما باشد. اگر دیتایی را کاربر هنوز لازم ندارد همان ابتدا دانلود نکن سعی کن تا زمانی که کاربر کلیکی انجام نداده است از آن پرهیز کنیاستفاده از اتصال‌های مشترک به پایگاه داده یا اجماع سازی درخواست‌هاهر بار که یک برنامه به پایگاه داده متصل می‌شود، مقداری انرژی مصرف می‌کند. بنابراین، استفاده از اتصال‌های مشترک به پایگاه داده می‌تواند به کاهش مصرف انرژی کمک کند. اتصال‌های مشترک به پایگاه داده به برنامه‌ها اجازه می‌دهد تا از یک اتصال موجود به پایگاه داده استفاده کنند، به جای اینکه هر بار یک اتصال جدید ایجاد کنند. این کار می‌تواند در برنامه‌هایی که به طور مکرر به پایگاه داده دسترسی نیاز دارند بسیار موثر باشد. یک مثال دیگر که بیان می‌شود این است اگر کاربر هر ۱ ثانیه به سرور متصل می‌شود برای دریافت آخرین تغییرات اگر می‌شود این سرعت را کاهش بدهیم و تبدیل به ۱۵ ثانیه یکبار کنیم و جمیع داده‌های اتفاق افتاده را ارسال کنیم.کاهش کیفیت تصاویر و ویدئو‌ها و یا استفاده از منابع نزدیکتصاویر و ویدئو‌ها می‌توانند مقدار زیادی انرژی مصرف کنند. به عنوان مثال، یک فیلم 1080p می‌تواند به طور متوسط ​​حدود 2 گیگابایت داده مصرف کند. اگر کیفیت تصاویر و ویدئو‌ها را کاهش دهید، می‌توانید مصرف انرژی را کاهش دهید. این کار را می‌توانید با استفاده از فرمت‌های فشرده‌تر مانند JPEG 2000 یا HEVC انجام دهید. همچنین اگر از تکنیک‌هایی مانند catch و یا CDN استفاده کنیم لازم نیست دیتاهای مورد نیاز کاربران از سرور اصلی برطرف گردد و از منابع نزدیک‌تر به کاربر می‌توانیم استفاده کنیم.کاهش استفاده از قفل‌ها و یا اسفتاده از یک فناوری کارآمد استفاده کنید قفل‌ها برای جلوگیری از دسترسی همزمان چند برنامه به داده‌های مشترک استفاده می‌شوند. با این حال، قفل‌ها می‌توانند مقدار زیادی انرژی مصرف کنند. بنابراین، کاهش استفاده از قفل‌ها می‌تواند به کاهش مصرف انرژی کمک کند. این کار را می‌توانید با استفاده از الگوریتم‌های قفل‌گیری کارآمدتر مرتفع گردد. همچنین اگر از زبان برنامه نویسی موثر تر استفاده کنید مانند c++ و یا GO بسیار تاثیر مثبتی در مصرف انرژی خواهد داشت و همچنین الگوریتم‌هایی کارآمد تر به عنوان مثال چندین روش sorting وجود دارد اما برخی از آن‌ها مصرف انرژی کمتری را به همراه دارد سعی کنید الگوریتم‌های خود را بهبود بدهید. همچنین بجای استفاده از الگوی XML از الگوی json استفاده کنید زیرا اطلاعات بسیار کارآمدتر و موثرتر ارسال می‌شوند. همچنین در یک تستی که خودش انجام داده است استفاده از دیتابیس redis بسیار مصرف انرژی کمتری داشته است نسبت به mongoDBجلوگیری از رشد غیرقابل کنترل ویژگی‌هاویژگی‌های جدید می‌توانند باعث افزایش پیچیدگی نرم‌افزار شوند. پیچیدگی بیشتر می‌تواند باعث افزایش مصرف انرژی شود. بنابراین، مهم است که از رشد غیرقابل کنترل ویژگی‌ها جلوگیری کنید. این کار را می‌توانید با استفاده از فرآیندهای توسعه‌ای چابک و با کیفیت انجام دهید. به عنوان مثال، می‌توانید از تکنیک‌های مهندسی معکوس برای شناسایی ویژگی‌های غیر ضروری استفاده کنید. طبق نمودار زیر مصرف انرژی یک کامپیوتر idle برابر ۲۰٪ درصد انرژی یک کامپیوتر زیر بار است و استفاده از منابع اشتراکی در این موضوع بسیار حائز اهمیت است.استفاده از پردازنده‌های کم‌مصرف مانند پردازنده‌های ARMپردازنده‌های کم‌مصرف مانند پردازنده‌های ARM می‌توانند به کاهش مصرف انرژی کمک کنند. این پردازنده‌ها به طور خاص برای کاهش مصرف انرژی طراحی شده‌اند و می‌توانند در دستگاه‌های کوچک و قابل حمل مانند تلفن‌های هوشمند و تبلت‌ها استفاده شوند.در اینجا چند نکته اضافی برای کاهش مصرف انرژی نرم‌افزار آورده شده است:از زبان‌های برنامه‌نویسی کم‌مصرف مانند Go، C++، Java و C# استفاده کنید.از کتابخانه‌ها و فریم‌ورک‌های کم‌مصرف استفاده کنید.از الگوریتم‌های کم‌مصرف استفاده کنید.از تست‌های عملکردی برای شناسایی مشکلات مصرف انرژی استفاده کنید.با پیروی از این تاکتیک‌ها، می‌توانید به کاهش مصرف انرژی نرم‌افزار خود کمک کنید علیرضا صفافرد علیرضا صفافرد Tue, 26 Dec 2023 18:34:43 +0330 https://virgool.io/@m_60905393/%D8%AA%D9%88%D8%B6%DB%8C%D8%AD-%DA%86%D9%86%D8%AF-%D9%85%D9%88%D8%B6%D9%88%D8%B9-%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-n7mxq3sadhef معرفی Modular Monolithic:به طور کلی ما سه دسته الگوی monolithic داریم۱.الگوی single monolithic که الگوی متداول و معمولی هست که برنامه نویسان در ابتدای شروع کار خود معمولا بدون اینکه بدانند از این الگو استفاده می‌کنند. به طور کلی به این صورت است که شما تمام پروژه را در داخل یک فولدر نگهداری می‌کنید و بخش‌های پروژه به یک دیگر وابسته هستند و اگر بخشی تغییر کند بقیه بخش‌ها هم ممکن است تغییر کند.۲.الگوی modular monolithic یا همون ماژولار مونولوتیک: این الگو مانند الگوی قبل است ولی با این تفاوت که هر بخش به صورت ماژولار توسعه داده می‌شود و حتی می‌توانیم تیم‌های متفاوتی را مسئول انجام هر ماژول قرار بدهیم.توسعه پروژه در این رویکرد راحت‌تر از رویکرد قبلی است و همچنین هر ماژول را می‌توانیم در پروژه‌های دیگه نیز استفاده کنیم و به نوعی این رویکرد یک رویکردی بین single monolithic و micro service هست. یکی از کاربردهای این الگو این می‌باشد که شما در زمان توسعه اولیه یک نرم‌افزار می‌توانید از این الگو استفاده کنید و بعد از اینکه به نسخه اولیه رسیدید و لازم شد پروژه خود را scale کنید می‌توانید از این الگو به الگوی micro service مهاجرت کنید.۳.الگوی layeres monolithic یا همون مونولوتیک لایه بندی شده:در این رویکرد مانند قسمت قبل است فقط با این تفاوت که رویکرد لایه‌ای به معماری نرم‌افزار خواهیم داشت. به عنوان مثال معماری MVC یک معماری است بر پایه Model-view-controler که در طراحی نرم‌افزارهای وب و اپلیکیشن‌ها استفاده می‌شود.معرفی AWSکلمه AWS که مخفف Amazon Web Services است یک سرویس ابری امن است که خدماتی مثل قدرت محاسبه،ذخیره سازی پایگاه داده،تحویل محتوا و سایر قابلیت هایی که به رشد کسب و کار شما میکند ارائه میدهد. این سرویس بر اساس قراردادی که شما با آن دارید می‌تواند مواردی مانند امنیت و افزایش منابع در زمان پیک درخواست ها را برای شما فراهم کند.به کمک این سرویس شما دیگر لازم نیست که تمرکز خود را بر روی زیرساخت و خنک سازی سرورهای خود قرار دهید تمام این موارد را سرویس ابری انجام می‌دهد و شما تمرکز خود را بر روی نرم‌افزار خود قرار می‌دهید.معرفی API-first Approachدر این رویکرد توسعه نرم‌افزار تلاش بر این است که API های بین سرویس‌ها را در ابتدا پیاده‌سازی کند. مزیت این رویکرد این است که هر تیمی بعد از این فاز دیگر می‌تواند به معماری داخلی سرویس‌های خود تمرکز کند و ارتباط بین تیمی کمتر می‌شود و همچنین تاثیری غیر مستقیم بر طراحی ساختار کلی نرم‌افزار نیز دارد زیرا وقتی که یک سرویس می‌داند که چه خروجی هایی یا ورودی‌هایی دریافت می‌کند طراحی بهتری نسبت به دیتابیس و فرایندهای داخلی خود خواهد داشت. بر اساس گزارش وضعیت API 2022 Postman که بیش از 37000 متخصص API را مورد بررسی قرار داد، در واقع، 58 درصد از APIهایی که توسعه دهندگان با آنها کار می کنند، فقط برای استفاده داخلی هستند. و این نشان می‌دهد که این رویکرد فقط برای ارتباط با مشتریان نیست بلکه برای ارتباط بین ماژول‌های داخلی یک نرم‌افزار نیز استفاده می شود.معرفی NoSQL Databasesیک رویکرد در طراحی دیتابیس می‌باشد که برای ساختار دیتاهایی که از نظم خاصی پیروی نمی‌کنند استفاده می‌شود در پروژه‌های تحلیل لاگ سیستم و یا big-data استفاده می‌شود. خود این رویکرد به چندین دسته تقسیم می شود که شامل document، key-value، wide-column و graph می‌شوند. به عنوان مثال، پایگاه داده‌های document-based، از ساختارهای JSON یا XML برای ذخیره داده استفاده می‌کنند.برخی از مزایای آن شامل امکان ذخیره و بازیابی داده‌های نامنظم و بزرگ، قابلیت مقیاس‌پذیری بیشتر نسبت به پایگاه‌های داده رابطه‌ای، قابلیت ذخیره سازی انواع مختلف داده‌ها، سهولت در استفاده و انعطاف‌پذیری آن است.اما برخی از معایب آن شامل کمتر بودن امکانات پشتیبانی، کمتر بودن امکانات پرس‌وجو، عدم پشتیبانی از تراکنش‌های چندگانه و پایداری پایین‌تر آن نسبت به پایگاه‌های داده رابطه‌ای است.معرفی Serverless Architecture:این معماری بر این معنی نیست که نرم‌افزار شما اصلا نیازی به ارتباط با اینترنت نداشته باشد بلکه منظور بر این است که شما سرور فیزیکی و تنظیم کردن آن را نیاز نداشته باشید بلکه تمرکز خود را بر روی کسب و کار خود قرار بدهید. این رویکرد هزینه‌های عملیاتی را کاهش می‌دهد زیرا نیرویی که سرور را مدیریت بکند لازم ندارید و سرویس ابری عملیات‌هایی مانند مدیریت منابع و امنیت را برای شما ایجاد می‌کند. همچنین هزینه‌ها عملیاتی کمتر می‌شود زیرا بر اساس نیاز و مصرفی که دارید به سرویس دهنده ابری پول می‌دهید. البته این معماری مشکلاتی نیز دارد زیرا زمانی که شما از این سرویس‌ها استفاده می‌کنید باید مراقب قوانین داخلی ابر‌ها باشید به عنوان مثال فرض کنید شما یک port برای ارتباط خود با سرور نیاز دارید ولی سرویس‌دهنده ابری ممکن است بگوید در سیاست‌های کلی ما نیست که این port را به شما بدهد.معرفی Domain Driven Design:در این رویکرد تلاش بر این است که توسعه دهندگان با متخصصین دامنه کسب وکار آشنا بشوند و از متخصصین کلمات کلیدی حوزه کسب وکار را همراه با مفهوم عملی آن دریافت کنند و در کد نویسی خود نام کلاس‌ها و توابع را بر اساس دامنه حوزه کسب وکار بنویسند این رویکرد برای تمامی پروژه‌ها خوب نیست زیرا هزینه توسعه نرم‌افزار را افزایش می‌دهد(چون شما باید یک دانش اولیه از کسب و کار خود را به برنامه نویسان خود بدهید).به طور خلاصه، مزایای DDD عبارتند از:ارتباطات بهتر بین توسعه‌دهندگان و متخصصان دامنهانعطاف‌پذیری بیشتر در برابر تغییراتقابلیت نگهداری بیشترمعایب DDD عبارتند از:منحنی یادگیری بالازمان و تلاش بیشتر برای پیاده‌سازینمی‌توان برای هر پروژه از DDD استفاده کرد.معرفی Hexagonal architectureبه طور کلی این رویکرد تلاش بر این دارد برنامه را به ماژول‌هایی تقسیم بندی بکند که هر جفت این ماژول ها کمترین سطح ارتباطی را با یکدیگر داشته باشند همچنین باید قابلیت تعویض هر بخش وجود داشته باشد (بدون تغییر بخش دیگر)این رویکرد.به عبارت دیگر، Hexagonal architecture یک الگوی معماری لایه‌ای است که برای جداسازی لایه‌های مختلف برنامه‌ای به کار می‌رود. در این الگوی معماری، هر لایه به صورت مجزا پیاده‌سازی می‌شود و با استفاده از پورت‌ها و آداپتورها به لایه‌های دیگر متصل می‌شود.به عنوان مزیت‌های Hexagonal architecture می‌توان به موارد زیر اشاره کرد:جداسازی لایه‌های مختلف برنامه‌ایافزایش قابلیت تستافزایش قابلیت تغییرافزایش قابلیت توسعهبه عنوان معایب این الگوی معماری می‌توان به موارد زیر اشاره کرد:پیچیدگی بیشتر در پیاده‌سازیافزایش تعداد کدهای تکراری زیرا هر لایه به صورت مستقل ممکن است یک عملکرد را تکرار کندمعرفی Event Sourcingدر این الگو، هدف بر این است که تمام رویدادهایی که در سیستم اتفاق می‌افتد به همراه زمان وقوع در یک دیتابیس ذخیره‌سازی شود این باعث می‌شود مسیر حرکت کاربران و اتفاقاتی که برای سیستم اتفاق می‌افتد ضبط شود و در صورت نیاز یک اتفاقی بازگردانی شود و به حالت قبل خود برگردد. این رویکرد مزایا و معایبی به شرح زیر دارد:مزایایی همچون:افزایش قابلیت اطمینانافزایش قابلیت تغییرپذیریافزایش قابلیت پیش‌بینیافزایش قابلیت بازیابی داردو معایبی مانند:این الگو، برای پیاده‌سازی نیاز به تغییر در روش‌های طراحی و پیاده‌سازی دارد.به دلیل اینکه تمامی رویدادها در پایگاه داده ذخیره می‌شوند، نیاز به پایگاه داده‌های بزرگ و پرقدرت است.هزینه نگهداری دیتابیس و ذخیره سازی آن به مرور زمان به صورت نمایی افزایش پیدا می‌کندهمچنین، برای پیاده‌سازی این الگو، نیاز به تغییر در روش‌های طراحی و پیاده‌سازی داردمعرفی Low code platformsکلمه Low-Code یا کد کم، یک روش توسعه نرم‌افزار است که در آن از ابزارها و ماژول‌های پیش‌ساخته برای انجام عملیات‌های مورد نیاز استفاده می‌شود. این روش، به کاربران اجازه می‌دهد تا بدون نیاز به دانش برنامه‌نویسی، برنامه‌های کاربردی خود را طراحی و پیاده‌سازی کنند. این روش، سرعت توسعه نرم‌افزار را به شدت افزایش می‌دهد و هزینه‌های توسعه را کاهش می‌دهد. همچنین، این روش، به کاربران اجازه می‌دهد تا بدون نیاز به دانش برنامه‌نویسی، برنامه‌های کاربردی خود را طراحی و پیاده‌سازی کنند. این روش، سرعت توسعه نرم‌افزار را به شدت افزایش می‌دهد و هزینه‌های توسعه را کاهش می‌دهد. از دیگر مزایای این روش می‌توان به افزایش قابلیت تغییرپذیری و افزایش سرعت توسعه نرم‌افزار اشاره کرد. با این حال، این روش نیز دارای معایبی است. به عنوان مثال، این روش، برای پیاده‌سازی، نیاز به تغییر در روش‌های طراحی و پیاده‌سازی دارد.همچنین این روش می‌تواند مشکلاتی را به همراه خود داشته باشد به عنوان مثال اگر ابزاری که استفاده کردید باگی داشته باشد یا حفره امنیتی داشته باشد نرم افزار شما هم دچار مشکل می‌شود همچنین اگر ماژول‌ها از نظر استفاده منابع به تضاد بخورند شما مجبور هستید که یکی از ماژول‌ها را از نرم افزار خود جدا کنید. همچنین این رویکرد ممکن است بر معماری کلی نرم‌افزار شما تاثیر منفی بگذارد و شما را محدود بکند به پیاده‌سازی معماری خاصی.معرفی Business Process Management Systems (BPMS)به کمک این دسته از ابزارها شما می‌توانید بدون داشتن دانش برنامه نویسی به تجزیه و تحلیل کسب وکار خود و پیاده‌سازی و نظارت بر فرایندهای کسب و کار خود بپردازید.این مجموعه برنامه، نقاط ضعفی که باعث از بین رفتن زمان و سرمایه می‌شود را درکسب و کارها شناسایی می‌کند و به کنترل آن‌ها کمک می‌کند تا کارآمدی کارکنان شرکت را افزایش دهد.این روش، سرعت توسعه نرم‌افزار را به شدت افزایش می‌دهد و هزینه‌های توسعه را کاهش می‌دهد. البته این رویکرد مشکلاتی را نیز دارد به عنوان مثال شما بسیار وابسته به کد ابزار می‌شوید و اگر زمانی ابزار شما آپدیت ورژن جدید ندهد تمام سرمایه گذاری شما از بین خواهد رفت. همچنین در کتاب clean architecture این موضوع بسیار نفی شده است زیرا وابستگی شدیدی برای کسب و کار شما ایجاد می‌کند.معرفی Message Queue (such as Kafka and RabbitMQ)یک ابزاری است برای مدیریت load سیستم و توضیع پیام‌های سیستم شما فرض کنید که چندین ابزار برای مدیریت دیتا دارید که هر ابزار مسئولیت اجرا و نمایش یکسری از ویژگی‌های سیستم شما است به کمک این صف شما می‌توانید تمام این ابزارها و برنامه ها را به یکدیگر متصل کنید. در این سیستم پیام‌ها به صورت یک صف قرار می‌گیرند و برنامه‌های مختلف می‌تواند پیام‌های مورد نظر خود را انتخاب کنند و بردارند.این سیستم، مزایایی همچون افزایش قابلیت توسعه، افزایش قابلیت پیش‌بینی، افزایش قابلیت بازیابی و افزایش قابلیت تغییرپذیری دارد.دو سیستم Message Queue محبوب که در حال حاضر استفاده می‌شوند، Apache Kafka و RabbitMQ هستند.به عنوان مثال، Kafka برای پردازش داده‌های بزرگ و پیام‌های بسیار زیاد مناسب است، در حالی که RabbitMQ برای پردازش پیام‌های کوچک و بسیار زیاد مناسب است.معرفی Container orchestration (such as Kubernetes)یکی از ابزارهای مهم برای مدیریت و اجرای container ها kubernetes است. شما می‌توانید هر مدل contain را با هرگونه شرط و قیدی که نیاز دارید در kubernetes پیاده سازی کنید.Kubernetes یک پلتفرم متن باز و آماده تولید است که با تجربه انباشته Google در ارکستراسیون کانتینر طراحی شده است و با بهترین ایده های جامعه ترکیب شده است. به کمک این ابزار شما فقط مانند docker یک container را بالا نمی‌آورید بلکه توانایی مدیریت و ساخت mirror هم دارید. در نتیجه به راحتی می‌توانید performance نرم افزار خود را افزایش بدهید.مزایا این ابزار به شرح زیر است:مدیریت و کنترل برنامه‌های کانتینری در مقیاس بزرگافزایش قابلیت اطمینان و پایداری برنامه‌های کانتینریافزایش سرعت و کارایی در اجرای برنامه‌های کانتینریمعایب این ابزار به شرح زیر است:پیچیدگی بالای این ابزارنیاز به تجربه و دانش کافی برای استفاده از این ابزارنیاز به سرورهای قدرتمند برای اجرای Kubernetesمعرفی Log Management Tools (such as ELK):برای مدیریت لاگ‌ها ابزارهای مدیریت لاگ مانند ELK Stack بسیار مفید هستند. ELK Stack شامل سه پروژه متن‌باز Elasticsearch، Logstash و Kibana است. Elasticsearch یک موتور جستجوی متن و تحلیلی است.Logstash یک مجمع لاگ است که داده‌ها را از منابع مختلف جمع‌آوری، پردازش و به مقاصد مختلفی مانند Elasticsearch ارسال می‌کند. و در نهایت، Kibana یک رابط کاربری فراهم می‌کند که انواع نمودار‌ها و نمایشگرها را در دل خود دارد، که به کاربران اجازه می‌دهد داده‌های خود را از طریق نمودارها مشاهده، پرس و جو و تجزیه و تحلیل کنند. این ابزارها به کاربران اجازه می‌دهند تا میزان بزرگی از داده‌های لاگ را از هر جایی در زیرساخت خود جمع‌آوری کنند، سپس در آنها را جستجو، تجزیه و تحلیل کنند و آنها را به نمایش بگذارند.مزایای استفاده از این ابزار:قابلیت جمع‌آوری داده‌های لاگ از منابع مختلف.قابلیت جستجوی داده‌های لاگ در زمان واقعی.قابلیت تجزیه و تحلیل داده‌های لاگ با استفاده از الگوهای پیش‌فرض یا سفارشی.قابلیت نمایش داده‌های لاگ در قالب نمودارها و نمودارها.قابلیت ارسال داده‌های لاگ به مقاصد مختلفی مانند Elasticsearch.قابلیت افزایش قابلیت اطمینان و امنیت با استفاده از Beats.معایب استفاده از این ابزار:نیاز به تنظیمات پیکربندی پیچیده.نیاز به تجربه کاربری برای استفاده از این ابزارها.نیاز به سرورهای قدرتمند برای پردازش داده‌های لاگ.هزینه‌های بالای پشتیبانی و نگهداری.معرفی Monitoring tools (such as Prometheus): برای مانیتورینگ سیستم‌ها، ابزارهای مانیتورینگ مانند Prometheus بسیار مفید هستند. Prometheus یک ابزار مانیتورینگ و هشدار دهی منبع باز است که ابتدا در SoundCloud ساخته شد. این ابزار متن‌باز، مجموعه‌ای از ابزارهای مانیتورینگ و هشدار دهی است که برای جمع‌آوری داده‌های متن‌باز و مانیتورینگ سیستم‌های مختلف استفاده می‌شود. Prometheus از زبان Go برای پیاده‌سازی خود استفاده کرده است.این ابزار از مدل جمع‌آوری داده‌های pull برای جمع‌آوری داده‌های متریک استفاده می‌کند و داده‌های متریک را به صورت سری زمانی ذخیره می‌کند. Prometheus از زبان PromQL برای پرس و جوی داده‌های متریک استفاده می‌کند. در تصویر زیر نمایی از یک معماری آمده استمزایا:قابلیت جمع‌آوری داده‌های متریک از منابع مختلف.قابلیت جستجوی داده‌های متریک در زمان واقعی.قابلیت تجزیه و تحلیل داده‌های متریک با استفاده از الگوهای پیش‌فرض یا سفارشی.قابلیت نمایش داده‌های متریک در قالب نمودارها و نمودارها.قابلیت ارسال داده‌های متریک به مقاصد مختلفی مانند Elasticsearch.قابلیت افزایش قابلیت اطمینان و امنیت با استفاده از Beats.معایب:نیاز به تنظیمات پیکربندی پیچیده.نیاز به تجربه کاربری برای استفاده از این ابزارها.نیاز به سرورهای قدرتمند برای پردازش داده‌های متریک.هزینه‌های بالای پشتیبانی و نگهداری.معرفی Static Code Analysis (such as SonarQube)تحلیل کد استاتیک یا Static Code Analysis برای تشخیص آسیب‌پذیری‌های احتمالی در کد، ابزارهای Static Code Analysis مانند SonarQube می‌توانند به شما کمک کنند. این ابزارها با استفاده از الگوریتم‌های خود، کد شما را بررسی کرده و به شما اطلاعاتی درباره‌ی مشکلات و آسیب‌پذیری‌های موجود در کد شما ارائه می‌دهند. با استفاده از این ابزارها، می‌توانید به راحتی مشکلات و آسیب‌پذیری‌های موجود در کد خود را شناسایی کرده و آن‌ها را برطرف کنید.مزایایی همچون شناسایی مشکلات و آسیب‌پذیری‌های موجود در کد، افزایش کیفیت کد، افزایش سرعت توسعه و کاهش هزینه‌های توسعه را به همراه دارد. همچنین، با استفاده از این ابزارها، می‌توانید به راحتی مشکلات و آسیب‌پذیری‌های موجود در کد خود را شناسایی کرده و آن‌ها را برطرف کنید.از معایب استفاده از این ابزارها می‌توان به این نکته اشاره کرد که این ابزارها نمی‌توانند به صورت کامل به جای انسان، کد شما را بررسی کنند. همچنین، استفاده از این ابزارها ممکن است به دلیل تعداد زیاد پیام‌های خطا، باعث ایجاد اشکال در فرآیند توسعه شود. علیرضا صفافرد علیرضا صفافرد Fri, 24 Nov 2023 13:33:17 +0330 https://virgool.io/@m_60905393/%D9%85%D8%B1%D9%88%D8%B1-%D9%81%D8%B5%D9%84-%D9%87%D8%A7%DB%8C-%DB%B1%DB%B5-%D8%AA%D8%A7-%DB%B2%DB%B9-%D9%88-%D9%81%D8%B5%D9%84-%D9%87%D8%A7%DB%8C-%DB%B3%DB%B0-%D8%AA%D8%A7-%DB%B3%DB%B4-%DA%A9%D8%AA%D8%A7%D8%A8-clean-architecture-x9sbdprxdyhh معماری (۱۵)یک نکته بسیار حائز اهمیت در این بخش این است که یک معمار نرم‌افزار کسی نیست که از کدنویسی عقب کشیده‌ باشد و دیگر برنامه نویسی انجام ندهد.ممکن است که آن‌ها از بقیه برنامه نویسان کمتر کدنویسی انجام دهند ولی همچنان آن‌ها کدنویس‌های خوبی هستند و یکی از اهدافشان هدایت بقیه به برنامه نویسی با اصولی مشخص و معماری بهینه نرم‌افزار است. یکی از دلایلی که معماران نرم‌افزار نیز کدنویسی انجام می‌دهند این است که آن‌ها بهتر بتواند مسائل و مشکلات برنامه‌نویسی را درک بکنند.تعریف شکل نرم‌افزار یا معماری نرم‌افزار این است که ساختار و شکلی که برنامه‌نویسان به آن می‌دهند. به طور کلی شکل معماری در تقسیم آن سیستم به اجزا و جزئیات، چیدمان آن اجزا و راه‌های ارتباطی بین این اجزا و نحوه ارتباط این اجزا با یکدیگر است. هدف این شکل راحت‌تر کردن توسعه نرم‌افزار، استقرار(استقرار در یک سرور)، بهره‌برداری و نگهداری سیستم نرم‌افزاری موجود در آن است. هدف نهایی یک معمار نرم‌افزار افزایش بهره‌وری برنامه‌نویسان و به حداقل رساندن هزینه طول عمر سیستم است.در ادامه به صورت خلاصه ابعاد مختلف معماری را بیان می‌کنیمتوسعهیک رابطه مهمی که در این موضوع حائز اهمیت است این است که هر چقدر توسعه یک نرم‌افزاری سخت باشد عمر طولانی و سالمی نخواهد داشت بنابرین باید معماری نرم‌افزار به گونه‌ای باشد که توسعه نرم‌افزار را برای برنامه‌نویسان و کارمندان راحت‌تر بکنداستقراریک رابطه مهمی که در این بخش مهم است آن است که هر چقدر استقرار یک نرم‌افزار هزینه کمتر و زمان کمتری باشد می‌شود گفت که نرم‌افزار مفید‌تر است. این بخش معمولا در فاز‌های اولیه پروژه در نظر گرفته نمی‌شود و بعدها به مشکل برخواهند خورد. به عنوان مثال شما برای اینکه توسعه یک نرم‌افزار بهتر و راحت‌تر باشد ممکن است به سمت معماری میکروسرویس بروید و سعی کنید تعداد سرویس‌های سیستم را بیشتر بکنید اما در نظر داشته باشید که ارتباط بین این سرویس‌ها می‌تواند خود منشا بروز مشکلاتی شود.عملکردتقریبا هر مشکل عملیاتی را می‌شود با افزایش کیفیت سخت‌افزار بهبود بخشید و در برخی موارد این افزایش سخت افزار تاثیری بر معماری نرم‌افزار ندارد. برخی از افراد نیز این موضوع را را در نظر دارند که نگهداری افراد شرکت بسیار پرهزینه‌تر و ارزشمند‌تر از خرید سخت‌افزار و نگهداری آن می‌باشد و حاضر هستند کمی عملکرد سیستم کاهش بیابد ولی توسعه و استقرار و نگهداری که در بخش بعدی خواهیم گفت کیفیت بیشتری را برخوردار باشند. و سعی بر آن می‌کنند که سخت افزار را ارتقا دهند تا عملکرد کلی نرم‌افزار نیز بهبود بیابد.نگهداریاین بخش جزو پرهزینه‌ترین بخش‌های شرکت است زیرا همواره ما با تعداد زیادی اصلاحات مواجه هستیم و همچنین تعداد زیادی درخواست جدید برای توسعه ویژگی‌های جدید و اینکار باعث مصرف حجم عظیمی از منابع انسانی می‌شود. ما به کمک یک معماری خوب می‌توانیم تا حد خوبی هزینه‌های این بخش‌ را کاهش بدهیم به عنوان مثال اگر بخش‌های مختلف نرم‌افزار را از یکدیگر بتوانیم جدا کنیم و هر بخش مسیر توسعه خود را جداگانه جلو ببرد بسیاری از هزینه‌های نگهداری و پیچیدگی محصول کاهش پیدا می‌کند.یکی از ویژگی‌های نرم‌افزار نرم بودن آن است این ویژگی با باز گذاشتن گزینه‌های مختلف در نرم‌افزار است اما موضوعی که مطرح است این است که چه گزینه‌هایی باز نگهداشته بشوند؟ آن‌ها جزئیاتی هستند که اهمیت خاصی ندارند. تمام سیستم‌های نرم‌افزاری را می‌توان به دو عنصر اصلی تقسیم کرد: سیاست‌ها و جزئیات.سیاست‌: این بخش معمولا از قوانین حاکم بر کسب‌وکار گرفته می‌شود و ارزش واقعی سیستم در آن قرار داردجزئیات:جزئیات زیربخش‌هایی هستند که برای توانمندسازی انسان‌ها، سایر سیستم‌ها و برنامه‌نویسان برای برقراری ارتباط با سیاست‌ها ضروری هستند، یعنی به نوعی ارتباط بین کاربران و سهامداران را با سیاست‌های نرم‌افزار برقرار می‌کند ولی به هیچ وجه بر سیاست‌ها تأثیر نمی‌گذارند. اگر بخواهیم چند مثال نام ببریم می‌توانیم بگویم دستگاه‌های IO، پایگاه‌های داده، سیستم‌های وب، سرورها، چارچوب‌ها، پروتکل‌های ارتباطی و ... هستند.یک معمار خوب وظیفه این را به عهده دارد که تا جای ممکن جزئیات را از سیاست‌ها جدا کند.معماران خوب سیاست را طوری طراحی می‌کنند که تصمیم‌گیری در مورد جزئیات را می‌توان تا زمانی که ممکن است به تعویق انداخت.یک مثالی نیز نویسنده از تاریخچه زندگی خود میزند و آن این است که در زمان قدیم آنها یک برنامه‌ای نوشته بودند که سیاست‌ها متصل به جزیئات (ماشین چاپ)بودند و زمانی که آن‌ها می‌خواستند به نحو دیگری تبلیغات خود را انجام‌دهند باید کل کد را مجددا می‌نوشتند لذا شرکت زیر بار این هزینه‌ نمی‌رفت و مدت‌های زیادی شرکت به همان روال پرهزینه و قدیمی خود تبلیغات را انجام می‌دادهمچنین یک مثال دیگه نویسنده درباره استفاده از آدرس‌دهی مستقیم و آدرس دهی نسبی می دهد و می‌گوید که بخاطر آدرس دهی مستقیم چقدر ما کارمان سخت بود ولی یک برنامه‌نویس پرتجربه آمد و به آن‌ها آدرس دهی نسبی را توضیح داد. همکار با تجربه ما پیشنهاد داد که دیسک را به عنوان یک آرایه‌ی خطی بزرگ از سکتورها در نظر بگیریم که هرکدام با یک عدد صحیح متوالی قابل دسترس باشند. سپس با استفاده از یک روش تبدیل راحت ما می‌توانستیم ساختار فیزیکی دیسک را بشناسیم این برنامه تبدیل کافی بود بتواند آدرس نسبی را به شماره سیلندر/هد/سکتور در حین اجرا تبدیل کند.خوشبختانه، ما از نصیحت او استفاده کردیم. ما سیاست سطح بالای سیستم را تغییر دادیم تا بی‌تفاوت نسبت به ساختار فیزیکی دیسک باشد(بخش‌های جزئی سیستم). این به ما امکان می‌داد تصمیم در مورد ساختار درایو دیسک را از برنامه جدا کنیم.استقلال (فصل ۱۶)استفاده‌ها(use case)تقریبا می‌شود گفت اولویت اصلی معمار نرم‌افزار این است که نرم‌افزار در راستای استفاده‌های نرم‌افزاری باشد.اگر سیستم یک برنامه سبد خرید است، معماری باید مورد استفاده‌های سبد خرید را پشتیبانی کند.البته همانطور که در گذشته نیز بحث کردیم معمار تاثیر زیادی بر رفتار نرم‌افزار ندارد ولی روشن کردن و بیان آن رفتار به گونه‌ای است که قصد سیستم در سطح معماری قابل مشاهده باشد.و سعی بر این باید داشته باشد که رفتار‌های اصلی یک نرم افزار در عناصر سطح بالای سیستم قابل مشاهده باشندعملکردبه عنوان مثال اگر باید سیستم توان پاسخگویی به ۱۰۰۰۰۰ مشتری را در ثانیه داشته باشد باید معماری سیستم به گونه‌ای باشد که تمام بخش‌هایی که با این درخواست سرکار دارند این موضوع را پشتیبانی بکند. به عنوان مثال شاید برای پاسخگویی به این نیاز شما باید به سمت معماری میکروسرویس بروید و بتوانید یک آرایه از سرویس‌های کوچک را در کنارهم قرار بدهید تا بتوانید به این درخواست پاسخ مناسب بدهید.به عنوان مثال اگر معمار به این موضوع فکر نکرده باشد و برنامه را برای ایجاد چندین نخ آمده سازی نکرده باشد در زمانی که کسب‌وکار رشد کند دیگر معمار نمی‌تواند به راحتی این درخواست را مرتفع کند و با گذشت زمان‌های زیادی و هزینه‌ زیادی می‌تواند به این درخواست جواب دهد.توسعهیک قانون مهم در این بخش قانون Conway’s هست که می‌گوید:هر سازمانی که یک سیستم را طراحی می‌کند، به نوعی ساختار سازمان خود را در آن کپی کرده است. سیستمی که باید توسط یک سازمان با تعدادی تیم و نگرانی‌های مختلف توسعه داده شود، باید یک معماری داشته باشد که به تیم‌ها اجازه عملیات مستقل در طول توسعه را می‌دهد تا تداخلی با یکدیگر نداشته باشند. این امر از طریق تقسیم صحیح سیستم به اجزای مستقل و قابل توسعه به صورت مستقل انجام می‌شود. سپس این اجزا به تیم‌هایی اختصاص داده می‌شوند که مستقل از یکدیگر کار می‌کنند.لذا شما خواهید دید که تعداد ماژول‌های توسعه داده شده یا بخش‌های مستقل به نوعی به تعداد تیم‌های موجود در شرکت ربط داردراه‌اندازی همچنین، معماری نقش بزرگی در تعیین آسانی راه‌اندازی سیستم دارد. هدف "راه‌اندازی فوری" است. یک معماری خوب به این موضوع کمک می‌کند که بلافاصله پس از ساخت سیستم شما به راحتی آن را راه‌اندازی کنید.این از طریق تقسیم و جداسازی صحیح اجزای سیستم، از جمله آن هسته که کل سیستم را به هم متصل می‌کند و اطمینان حاصل می‌کند که هر اجزا به درستی آغاز به کارکرده است قابل دستیابی خواهد بودگذاشتن گزینه‌ها بازاین یکی از کارهای سخت در معماری است زیرا دستیابی به این تعادل که کدام گزینه‌ها باز باشند بسیار انتخاب سختی است.زیرا خیلی از این گزینه‌ها وابسته به ابزار و ساختار تیم است که در طول عمر سیستم تغییر می‌کنند به طور خلاصه اهدافی که باید بر روی آن‌ها تمرکز کنیم قابل تغییر و تاحدی نیز غیر مشخص می‌باشند. در انتها می‌توانیم بگویم یک معماری خوب سیستم را در تمامی جهاتی که باید تغییر کند، با گذاشتن گزینه‌های باز ساده می‌کند.لایه بندی مستقل در این بخش می‌خواهیم درباره معماری لایه‌ای صحبت بکنیم در این جا معمار قصد دارد که از اصل‌های زیر نیز استفاده بکنداصل مسئولیت‌های تکی (Single Responsibility Principle)اصل اتمام مشترک (Common Closure Principle)تا آنچه که به دلایل مختلف تغییر می‌کند را جدا کند و آنچه که به دلایل یکسان می‌تواند تغییر کند را جمع‌آوری کند - با توجه به متن واقعی سیستم معمار باید رابط‌کاربری را که به دلایل مختلف ممکن است تغییر کند را با بخش قوانین حاکم بر تجارت را جدا کند تا بتواند آن‌ها را به صورت مستقل از هم تغییر دهد. همچنین پایگاه داده و زبان جستجویی که می‌خواهیم استفاده بکنیم خود نیز جزو جزئیات فنی سیستم هستند که ارتباطی با قوانین تجارت ندارند لذا این‌ها نیز باید جدا شوند لذا سیستم ما اگر قرار باشد به صورت لایه‌های افقی جدا شوند می‌شود: رابط کاربری، قوانین تجاری مخصوص به سیستم، قوانین تجاری مستقل از برنامه و پایگاه دادهجداسازی از طریق موارد استفادهخود موارد استفاده یک سیستم می‌تواند خط کش خوبی برای جدا کرند سیستم باشد زیرا هر بازیگر درخواست متفاوت و سفارش و نحوه استفاده متفاوتی دارد لذا هر کدام می‌تواند درخواست تغییر بخش‌هایی از سیستم را داشته باشند لذا یکی از معیار‌های جداسازی می تواند این مورد باشد. لذا می‌توانیم ما بعد از لایه بندی‌افقی که در بخش قبلی توضیح دادیم در این بخش هر کدام از آن لایه‌ها را براساس مورد استفاده نیز برش عمودی ایجاد کنیم و جداکنیم. به کمک این موضوع اگر مورد استفاده جدیدی نیز تولید شود شما به راحتی می‌توانید سیستم خود را توسعه بدهید و نیاز جدید را نیز پشتیبانی کنید.وضعیت جداسازیاگر موارد بالا رعایت شده باشد دیگر دیتابیس و قوانین و رابط کاربری از یکدیگر جدا هستند و هر یک می‌تواند در سروری با مشخصات فنی متفاوت و مورد نیاز خود قرار بگیرند و آن‌هایی که نیاز به پهنای باند بالاتری دارند می‌تواند در چندین سرور کپی شوند. بسیاری از معماران این رویکرد را میکروسرویس‌‌ها می‌نامند.یک معماری مبتنی بر سرویس‌ها اغلب معماری مبتنی بر سرویس (Service-Oriented Architecture) نامیده می‌شود.توانایی توسعه مستقلبه وضوح معلوم است که اگر اجزا به طور قوی از یکدیگر جدا باشند تداخل بین تیم‌ها بسیار کاهش می‌یابد و توسعه نرم‌افزار بسیار راحت‌تر می‌شود.لذا تا زمانی که لایه‌ها و مورد استفاده‌ها جدا شوند(معماری لایه‌ای که برش افقی را ایجاد می‌کردند و جداکننده عمودی که استفاده موردی نام داشت)، معماری سیستم پشتیبانی از سازماندهی تیم‌ها را به هر شکلی که باشد (تیم‌های ویژگی، تیم‌های اجزا، تیم‌های لایه، یا ترکیبی از آن‌ها)، ارائه خواهد داد.قابلیت انتشار مستقلاگر جداسازی به درستی انجام شود شما امکان انعطاف بالایی در انتشار هر بخش‌ خواهید داشت و شما به راحتی می‌توانید در یک سیستمی که در حال اجرا است تغییرات جدید را اعمال کنید زیرا کافی است که لایه‌های جدید را جایگزین لایه‌های قدیمی‌تر بکنید.تکثیرمعماران اغلب در یک تله گرفتار می‌شوند و آن این است که آن‌ها ترس از تکثیر دارند به عنوان یک برنامه نویس ما از تاکثیر کد بسیار نگران هستیم زیرا اگر تغییری در یک بخش لازم باشد انجام شود باید این تغییر در بخش دیگر نیز انجام شود. نکته‌ای که وجود دارد برخی از تکثیر‌ها خوب هستند به عنوان مثال اگر این دو فایل با نرخ متفاوتی لازم است تغییر کنند ممکن است این تاکثیر خوب باشد زیرا به مرور زمان این تغییرات متفاوت خواهد شد و هر کدام به بلوغ خود خواهند رسید. به عنوان مثال، اگر دو مورد استفاده دارای ساختارهای صفحه مشابهی باشند، ممکن است معماران تمایل داشته باشند کد مربوط به آن ساختار را به اشتراک بگذارند. اما در طول زمان، احتمالاً این دو صفحه تفاوت‌های زیادی را تجربه خواهند کرد. بنابراین، باید از یکپارچه‌سازی آن‌ها خودداری کرد تا در آینده به راحتی قابل جداشدن باشند.کاهش اتصال حالت‌ها (دوباره)باید تلاش کنیم که اتصال بین لایه‌ها و موردهای استفاده کمترین حد ممکن باشد زیرا ممکن است با تغییر یک بخش بخش‌های دیگر نیز تغییر کنند و هر چه این وابستگی کمتر باشد بهتر استسطح کد منبع: باید سعی کنیم ماژول‌ها بگونه‌ای نباشند که با تغییر یکی از آن‌ها بقیه کد نیز باید بازکامپایل شوند در این حالت کاهش اتصال خیلی مهم می‌باشد و فراخوانی توابع یکدیگر و استفاده غیر مستقیم از متغییر‌ها کمک بسیار زیادی می‌کندسطح نصب:اگر وابستگی‌های بین فایل‌های DLL ,Jar را کنترل کنیم و با تغییر یک فایل بقیه موارد لازم نباشد تغییر کنند ما شاهد این خواهیم بود که بسیاری از مولفه‌ها همچنان در فضای آدرس گذشته خود قرار خواهند داشت.سطح سرویس:می‌توانیم وابستگی‌ها را به سطح ساختارهای داده کاهش بدهیم و فقط از طریق بسته‌های شبکه بخش‌های مختلف با یکدیگر ارتباط برقرار کنند و به نوعی که هر واحد مستقل از بقیه واحد‌ها اجرا شود به نوعی می‌شودگفت مانند سرویس‌های موجود یا میکروسرویس‌ها باشند البته یکی از مشکلات اساسی این رویکرد این است که هزینه‌ ایجاد آن بالاتر بوده و همچنین هر چقدر هم سرویس‌ها کوچکتر بشوند باز ارتباط بین سرویس‌ها باقی می ماند. لذا برای توسعه بهتر است که کد‌ها در سطح کد به صورت سرویس‌های مختلف توسعه داده‌شوند و در صورت نیاز با هزینه‌ای شروع به تفکیک آن‌ها و ایجاد سرویس‌های مستقل شکل بگیرد و سیستم به آرامی در این جهت حرکت کندمرزها: رسم خطوط (فصل ۱۷)ایجاد مرز بین بخش‌های سیستم‌ را می‌توانیم به نوعی هنر یک معمار نرم‌افزار خوب بدانیم.برخی از این خطوط در اوایل زندگی یک پروژه ترسیم می شوند - حتی قبل از اینکه هر کدی نوشته شود.تصمیم گیری در مورد چارچوب ها، پایگاه های داده، سرورهای وب، کتابخانه های ابزار، تزریق وابستگی و موارد مشابه است.این موارد باید تا جای ممکن به تعویق بیوفتد و معماری نرم‌افزار به آن‌ها وابسته نباشدکدام خطوط را در چه زمانی بکشیم؟بین هر دو موردی که نسبت به یک دیگر از اهمیت یکسانی برخوردار نیستد باید خط کشید به عنوان مثال بین رابط کاربری و قوانین تجارتآیا خروجی و ورودی های سیستم نیز مهم هستند؟به طور کلی بله ولی آن‌ها بسیار بخش بدون اهمیت سیستم را تشکیل می‌دهند ولی اقلب کاربران انتظار دارند که این بخش اصلی نرم افزار باشد ولی اگر شما موس یا کیبورد را نداشته باشید باز‌هم سیستم بخش مدلینگ یک بازی را انجام می‌دهد و به درستی کار می‌کند لذا خوب است یک خط بین این دو هم قرار بدهیم.(IO , قوانین تجارت)معماری پلاگیندر واقع، تاریخچه فناوری توسعه نرم افزار داستان چگونگی ایجاد آسان پلاگین ها برای ایجاد یک معماری سیستم مقیاس پذیر و قابل نگهداری است. قوانین اصلی کسب و کار جدا و مستقل از اجزایی که اختیاری هستند یا می توانند به اشکال مختلف اجرا شوند، نگهداری می شوند. لذا در این رویکرد ما به راحتی می توانیم مدل دیتابیس خود را تغییر بدهیم یا زبان جستجو را زیرا رویکرد براساس معماری پلاگین می‌باشد.اگر معماری دو شرکت visiual studio , ReSharper را در نظر بگیرید این دو وابستگی نامتقارن دارند یعنی اگر ماکروسافت بخواهد می‌تواند شرکت دیگر را زمین بزند و این اصلا برای ما مطلوب نیست و باید از این حالت پرهیز کنیم.آناتومی مرزی(فصل ۱۸)در این فصل به چند مثال از کشیدن خط‌های جداساز می‌پردازیم.شما ممکن است به کمک یک تابع از این مرزها عبور کنید ولی باید حتما یک فایروالی داشته باشید تا تغییرات کد منبع باعث تغییر بقیه کدها نباشد. و الگوی پولیمورفیس باعث برعکس کردن حرکت نیازمندی است و می‌شود از آن استفاده کرد.همچنین راه ارتباطی بین چند پروسس را بیان می‌کند و می‌گوید می‌شود از socket استفاده کرد تا کمی ایزولاسیون بهتر باشد.و همچنین ارتباط بین سرویس‌ها را بیان می‌کند و می‌گوید معمولا این ارتباط از طریق شبکه انجام می‌شود و می‌گوید این ارتباط نباید وزن زیادی داشته باشد زیرا تاخیر در این مدل زیاد است و مانند فراخوان یک تابع نیست.خط مشی و سطح(فصل ۱۹)یک نرم‌افزار به نوعی نمایانگر یک خط مشی است به نوعی با قوانین و راه‌های تبدیل یک ورودی به خروجی مورد نظر در‌حال نمایش خط‌مشی‌های نرم‌افزار هستیم. به عنوان مثال خط‌مشی ورودی معتبر و ... خود نوعی از مثال هستند. یکی از توانایی‌های معمار و برنامه‌نویسان دسته‌بندی این خط مشی‌ها و آمدگی نرم‌افزار برای به روزرسانی آن‌ها است. یک راحل به عنوان تعریف مرحله در این فصل بیان‌ می‌کند می‌گوید شما ورودی و خروجی های سیستم را سطح پایین نرم‌افزار در نظر بگیرید و هر چقدر یک چیزی از این دو فاصله دارد به نوعی سطح بالاتر قرار دارد.قوانین کسب و کار فصل ۲۰اگر بخواهیم قوانین موجود در کسب و کار را دسته بندی کنیم و در نرم‌افزار خود بر این اساس بخش‌بندی بکنیم لازم است که در مرحله اول اشراف خوبی نسبت به مطالب موجود در کسب‌و‌کار داشته باشیم. معمولا قوانین اصلی هر کسب‌وکاری به اطلاعات بیرونی وابسته است به عنوان مثال یکی از قوانین اصلی بانک‌داری بحث وام و سود آن است به عنوان مثال باید سیستم به عنوان ورودی بداند که سود یک وام چند درصد باید باشد و یا زمان‌بندی پرداخت آن به چه صورت است. به این دیتا‌های بیرونی در کتاب (Critical Business Data) می‌نامند. به مجموعه قوانین مرتبط به دیتاهای خاص می‌توانیم یک (Entities) نام‌ببریم. یک مثال از نحوه نمایش آن در شکل زیر آمده استالبته همه چیز و قوانین کسب‌وکار لزوما یک (Entities) نیست برخی از آن‌ها به صورت یک چرخه و مسیر هستند که لازم است اتوماسیون برایشان انجام شود و آن‌ها را با اسنادی به نام use case به نمایش می‌گذارند. ساختار آن به این صورت است که ورودی‌های این پروسه را نوشته و خروجی‌های آن و قوانین حاکم بر نحوه تولید خروجی و سپس به عنوان یک سند ضبط می‌شود و برای تولید این سند لازم به داشتن اطلاعاتی از نحوه تولید و کد‌نویسی آن نیست.معماری فریاد (فصل ۲۱)باید معماری فایل‌ها و پوشه‌های کد‌های سطح بالا به نوعی باشد که به نوعی فریاد بزند که پروژه چیست و قرار است چه کاری را انجام دهد مانند سند معماری آبی رنگ ساختمان و نقشه‌کشی. لذا در نرم‌افزار نیز ما باید براساس موارد استفاه نرم‌افزار فایل‌های سطح بالای خود را بسازیم.همچنین یک معمار خوب سعی می‌کند موارد استفاده را معلوم کند و براساس آن تصمیم بگیرد و تصمیماتی که مرتبط به ابزار و نحوه تولید است را تا جایی‌ که بتواند به تاخیر‌ می‌اندازد. همچنین فریمورک‌ها صرفا یک ابزار هستند برای راحت تر شدن کدنویسی نباید به آن‌ها وابسته باشیم باید به موارد استفاه وابسته باشیم. اگر معماری را درست انجام داده‌باشیم باید بدون پیاده‌سازی کد و فریمورک بتوانیم آن را تست بکنیم و بررسی بکنیم که آیا Entities با کلاس‌ها سازگاری دارد یا خیرمعماری تمیز ( فصل ۲۲)در سال‌های اخیر این موضوع خیلی مهم شده‌‌است و کتاب‌های زیادی در این باره نوشته شده است و تقریبا همه به نوعی به دنبال اهداف زیر هستندبه فریمورک‌ها وابسته نباشدنرم‌افزار قابلیت تست‌پذیری داشته باشدبه ظاهر UI وابسته نباشدبه دیتابیس و مدل‌های آن وابسته نباشد مستقل از هر آژانس خارجی باشددر شکل بالا هر چقدر به مرکز دایره نزدیک بشویم خط مشی‌ها مهم تر می‌شوند و هر چقدر دورتر بشویم فریمورک‌ها و مکانیزم‌ها مهم می‌شوند. در این مدل نباید کدهای مرکزی از کدهای بیرونی و لایه‌های بیرونی استفاده کنند حتی اسم آن‌ها هم نباید باشد.تعریف interface adapter: به طور کلی این بخش وظیفه دارد به نوعی دیتاهای خروجی را به فرمت دلخواهی که سیستم و مشتری نیاز دارد به نمایش بگذارد و شاید به نوعی GUI از این دسته قرار بگیرند.اگر بخشی از موارد استفاده لازم بود یک استفاده از لایه‌های بیرونی در هسته انجام شود بهتر از از dynamic polymorphism استفاده شودارائه دهندگان و اشیاء فروتن (فصل ۲۳)در این بخش یک پترن معرفی می‌کند که کار را برای تست آسان می‌کند می‌گوید ما چند مدل بخش داریم برخی هستند که به راحتی تست می‌شوند که هیچی آن‌ها را تست می‌کنیم ولی برخی مثل GUI کار بسیار سختی است که تست کنیم لذا می‌گوید آن‌ها را به عناصر داده‌ای که آن‌ها را میسازند تجزیه کنیم و آن‌ها را تست کنیم به عنوان مثال متنی که قرار است به نمایش گذاشته شود را قبل از به نمایش گذاشتن اندازه گیری کنیم. در دیتابیس نیز برای اینکه این موضوع برطرف گردد از یک gateway استفاده می‌شود.مرزهای جزئی (فصل ۲۴)در برخی از موارد ایجاد مرز‌ها بسیار کار سخت و دشواری است و نگهداری و تولید این مرز در حال حاضر ضرورتی ندارد لذا معماران سعی می‌کنند یک مرز جزئی را ایجاد کنند که بعدا اگر لازم شد آن را عمیق‌تر بکنند.به عنوان مثال ما تمام کارها را برای جداسازی دو بخش از کد انجام دادیم ولی فعلا آن‌ها را در دل یک کامپوننت قرار می‌دهیم تا بعدا در صورت نیاز بتوانیم آن‌ها را از یک دیگر جدا کنیم.البته یکی از مشکلات این رویکرد این است که به مرور زمان این مرزهای جزئی شروع به شکستن می‌شود و fitness رخ می‌دهد که در این صورت دیگر جداسازی و تشکیل دو کامپوننت مجزا کار بسیار سختی می‌شود.در این فصل سه مدل متفاوت توضیح داده‌ می‌شود که هر کدام از آن‌ها مزایا و خطراتی را در پی دارندلایه‌ها و مرزها ( فصل ۲۵)شاید در یک نرم‌افزار ساده شما فقط سه لایه دیتابیس و UI و قوانین کسب و کار را داشته باشید اما در بسیاری از نرم‌افزارها این لایه‌ها به شدت زیاد می‌شوند به عنوان مثال در یک بازی کامپیوتری این موضوع عوض می‌شود.همچنین در این فصل بیان می‌کند که ایجاد یک مرز گران است اما گران‌تر از آن ایجاد یک مرز بعد از انجام‌کار است زیرا تفکیک آن‌ها بسیار سخت است همچنین چندین مثال کاربردی بیان می‌شود که دسته‌بندی آن‌ها را در نمودارهایی آورده است.لذا شما به عنوان یک معمار خوب بیاد یک مقایسه و trade off انجام دهید شما باید هزینه ها را بسنجید و تعیین کنید که مرزهای معماری کجاست، و کدام مرزها باید کامل اجرا شوند و کدام یک به صورت جزئی و کدام یک بخاطر هزینه انجام نشوند و همه این‌ها در اول کار معلوم نیست بلکه بعد از گذشت زمان به مرور شفاف می‌شوندکامپوننت اصلی (فصل ۲۶)به طور کلی در بیشتر نرم‌افزار‌ها یک بخشی دارد که بقیه بخش‌ها را می‌سازد و فراخوان می‌کند ما به این بخش کامپوننت اصلی می گوییم و به نوعی نقطه شروع سیستم است. به طور کلی ممکن است که شما برای سناریو‌های مختلف مثل تست یا محصول یا توسعه خود main های مختلفی داشته باشید که inistal اولیه را به طور خاص اجرا کند و ریسورس‌های لازم را برای اجرای نرم‌افزار فراهم کند یا برای مشتریان و یا کشورهای مختلف نیز ما می‌توانیم Main متفاوتی را اجرا کنیمخدمات:کوچک و بزرگ (فصل ۲۷)این تصور که اگر ما بخش‌های مختلف را به صورت سرویس در نظر بگیریم یک معماری است کمی غلط است زیرا نحوه مرز قرار دادند و اینکه چه چیز‌هایی از هم جدا شوند بسیار مهم تر است به طور دیگر سرویس‌ها بیانگر معماری نیستند.از طرف دیگر، یک سرویس ممکن است از چندین جزء تشکیل شده باشد که با مرزهای معماری از هم جدا شده اند.یکی از خوبی‌های استفاده از سرویس این است که هر سرویس به صورت مستقل توسعه و راه‌اندازی می‌شود و مسئولیت آن را یک تیم مستقل به عهده دارد. البته این توسعه به طور کامل نیز مستقل نیست زیرا اگر این توسعه نیازمند یک دیتایی باشد شاید باید منتظر توسعه بخش دیگر باشد تا بتواند کار خود را ادامه‌ دهد.همچنین در کتاب یک نمودار از یک نرم‌افزار برپایه mico_service بیان کرده است ولی با درخواست جدید مدیرعامل تمام این بخش‌ها باید تغییر کنند و این نشان می‌دهد که این سرویس‌ها در واقعیت نسبت به یک دیگر مستقل نیستند. و یک راحلی که برای برون رفتن از این مشکل است را بیان می‌کند و می‌گوید که باید از اصول solid استفاده کنیم و معماری کلی نرم‌افزار را به شکل زیر تغییر بدهیم.مرز آزمون (فصل ۲۸)بخش تست جزوی از سیستم است و اهمیت آن مانند بقیه بخش‌های یک سیستم نرم‌افزاری است. در معماری ما تمام مدل‌های تست را یک مدل در نظر می‌گیریم لذا وارد جزئیات این بخش‌ها نمی‌شویم. همواره تست است که به کد وابسته است و رابطه برعکس هرگز وجود ندارد به نوعی دیگر تست را شما می‌توانید در بیرونی‌ترین لایه در نظر بگیرید همچنین آن‌ها برای عملکرد کامل سیستم توسعه نیافتند و ضرروی نیستند و آمده‌اند که به برنامه‌نویسان کمک کنند نه به کاربران. تست هایی که به خوبی در طراحی سیستم ادغام نشده اند، معمولا شکننده هستند و سیستم را سفت و سخت می کنند و تغییر آن را دشوار می کنند. یعنی به نوعی تست‌ها با نرم‌افزار رشد و تغییر می‌کنند و هیچگاه رشد‌ آنها نباید از رشد نرم‌افزار عقب بیوفتد. تست نباید به GUI وابسته باشد زیرا این بخش بسیار آسیب‌پذیر و تغییر پذیر استمعماری جاسازی شده پاک (فصل ۲۹)داگ ادعای زیر را داشت:"اگرچه نرم افزار فرسوده نمی شود، سیستم عامل و سخت افزار منسوخ می شوند و در نتیجه نیاز به تغییرات نرم افزاری دارند." اگر شما بر روی سیستم‌های سخت‌افزاری کد نوشته باشید این را به خوبی درک‌ می‌کنید و متوجه می‌شوید که به سرعت این تغییر‌ها به نرم‌افزار شما اعمال می‌شود لذا شما برای ایجاد عمر طولانی برای نرم‌افزار خود باید این نکته را به خوبی در نظر داشته باشید شاید جمله بهتری که می‌توانیم بگوییم این باشد:"اگرچه نرم افزار فرسوده نمی شود، اما می تواند از درون توسط وابستگی های مدیریت نشده به سیستم عامل و سخت افزار از بین برود."یک تعریفی نیز درباره سیستم‌عامل بیان می‌کند:سیستم عامل به این معنی نیست که کد در ROM ذخیره سازی می‌شود و به دلیل جایی که ذخیره می شود، سیستم عامل است. بلکه به دلیل اینکه به چیزی بستگی دارد و تغییر آن با تکامل سخت افزار است، یک سیستم عامل است. سخت‌افزار تکامل می‌یابد ، بنابراین باید کد تعبیه‌شده‌مان را با در نظر گرفتن این واقعیت مجددا ساختار دهیم. و در انتها یک معماری لایه‌ای را نشان می‌دهد که در پایین سخت افزار و سپس لایه بعدی نحوه درایو آن و در لایه بعدی ارتباطات و در لایه بعدی سیستم عامل و در انتها نرم‌افزار شما قرار میگیرد که با این رویکرد شما بدون در نظر گرفتن سخت افزار می‌توانید نرم‌افزار خود را تست کنید و شاید برایتان سوال شود که چه مدل OS مدنظر است در این بخش اقلب RTOS ها قرار می‌گیرندپایگاه داده به عنوان یک جزئیات (فصل ۳۰)رابطه پایگاه داده با معمار نرم‌افزار بسیار ناچیز است و چیزی شبیه به ارتباط دستگیره در ساختمان با معمار نرم‌افزار است. و پایگاه داده صرفا یک ابزار است برای رسیدن به داده‌ها نه چیز بیشتری و یک معمار خوب هیچگاه اجازه نمی‌دهد که یک جزئیات تغییراتی در معماری نرم‌افزار ایجاد کند.سپس تاریخچه شروع دیتابیس‌ها از نوشتن بر روی دیسک تا ایجاد RDBMS را مطرح می‌کند که وظیفه ذخیره‌سازی دیتاها در فایل‌های داکیومنت را بر عهده داشت. و بیان می کند که پایگاه داده رابطه‌ای نیاز به جدول دارد و به کمک زبان sql شما می‌توانید اطلاعات را بدست بیاورید و در زمان قدیم که این موضوع نبود ما به کمک ساختار‌هایی مانند linklist و pointer می‌توانستیم اطلاعات مورد نیاز را از داخل رم استخراج کنیم.وب یک جزئیات است (فصل ۳۱)وب یک حرکت نوسانی است در ابتدا ما سعی کردیم تمام قدرت را از کامپیوتر‌ها به سمت سرور‌ها ببریم سپس مرورگرها آمدند و برخی موارد مجدد برگشتند به این سمت مثل js ولی حالا سعی داریم این بخش را به کمک node به سمت back بازگردانیم و این مدل شبیه به یک آونگ است.به نظر نمی رسد ما بفهمیم که قدرت کامپیوتر را کجا می خواهیم. ما بین متمرکز کردن و توزیع آن به عقب و جلو می رویم. به عنوان مثال در قدیم معماری بر روی کامپیوترهای شخصی بود و سپس سعی شد مرکز گرا بشوند و الان تلاش بر این است که توزیع شده باشد آیا واقعا معماری باید وابسته به این باشد؟ به طور کلی کتاب می‌گوید که وب نوعی از GUI است و GUI خیلی به مرور زمان تغییر می‌کند و خود نیز جزوی از جزئیات است پس وب هم جزوی از جزئیات است و نباید به آن وابسته باشیم.فریمورک یک جزئیات است (فصل ۳۲)فریمورک‌ها بسیار محبوب شده‌اند و پر استفاده و بسیاری از آن‌ها رایگان است. نویسندگان این فریمورک‌ها بر اساس نیاز خود و دوستان خود آن را توسعه می دهند و دقیق با مشکلات و موضوع کاری شما آشنا نیستند لذا لزومی ندارد که این کدها برای کار شما بهینه باشد. ارتباط کد شما با یک فریمورک مانند یک ازدواج نامتقارن است شما بسیار تعهد دارید و خیلی از موارد را رعایت می‌کنید ولی نویسنده فریمورک هیچگونه تعهدی به کد شما ندارد! و به نوعی شما را نیز مجبور می‌کند که به توصیه‌های او توجه کنید و به نوعی کد او را به مرکز معماری خود منتقل کنید همان جایی که قوانین کسب‌وکار قرار گرفته‌اند.همچنین ممکن است که فریمورک در نسخه جدید خود برای شما مشکل ساز بشود و به ضرر شما باشد همچنین ممکن است که یک فریمورک دیگری بیاید و شما آرزو کنید که کاشکی می‌توانستم فریمورک خود را تغییر بدهم.راه‌حل کتاب این است که به هیچ عنوان با یک فریمورک ازدواج نکنید اگر فریمورک اهداف بیزینس شما رو تحت تاثیر قرار می‌دهد شما نباید از آن استفاده کنید در واقع نباید کد‌های لایه بالای شما متوجه این موضوع بشوند که شما از چه فریمورکی استفاده می‌کنیدمطالعه موردی: فروش ویدئو (فصل ۳۳)در این بخش یک مورد را بررسی می‌کند یک وب‌سایت که فروش ویدئو را انجام می‌دهد افراد به دو صورت می‌تواند فیلم‌ها را تهیه کنند نوع اول پخش آنلاین آن‌ها است و حالت دوم این است که آن‌ها پول بیشتری بدهند و بتواند کل فیلم را دانلود بکنند و به صورت دائم استفاده کنند. اگر کسی چند فیلم را همزمان لازم داشته باشد و تهیه کند مقداری هم تخفیف دریافت می‌کند.همچنین تهیه کننده هر ویدئو باید این موارد را نیز در سایت بارگزاری کند توضیحات نوشته شده و فایل‌های جانبی خود همراه با آزمون‌ها، مشکلات، راه‌حل‌ها، کد منبع و سایر مطالب ارائه کنند. ادمین سامانه هم بتواند مدیریت‌های کلی بر روی سامانه و فیلم‌ها داشته باشد.در عکس بالا تمام بازیگران و ویژگی‌هایشان به نمایش گذاشته شده است.بخش view catalog یک بخش کلی است که ما می‌توانیم به صورت abstract از آن استفاده کنیم برای دو دسته از بازیگران. در عکس زیر نیز دیاگرام کلی برای کامپوننت‌ها طراحی شده استهمانطور که مشاهده می‌کنید برای هر بازیگر یک سری کامپوننت تعریف شده است همچنین در کتاب برای راحت‌تر شدن کد و توسعه آن پنج فایل jar-یکی برای نماها، ارائه‌کنندگان، تعامل‌کننده‌ها، کنترل‌کننده‌ها و برنامه‌های کاربردی تخصیص می‌دهد(البته مدل‌های دیگر نیز می‌شود دسته بندی کرد).فصل گم شده (فصل ۳۴)در ابتدا یک معماری لایه‌ای مثال می‌زند و می‌گوید این معماری برای پروژه‌های کوچیک که لازم است خیلی سریع راه‌اندازی شوند بسیار خوب است اما وقتی نرم‌افزار با پیچیدگی‌های جدید قرار است ترکیب شود شما خواهید فهمید که فقط سه سطح که در معماری لایه‌ای مطرح است کافی نیست و شما باید چند بخش دیگر نیز داشته باشید از طرف دیگر اصلی که در فصل‌های گذشته خواندید که کدهای سطح بالا باید نشان دهنده کسب‌وکار باشند و کمتر درگیر کدهای جزئی باشند رعایت نمی‌شود و بعد از مدتی نرم‌افزار شما در معماری لایه‌ای به مشکل خواهد خورد. مدل دیگر معماری عمودی است یعنی براساس ویژگی‌های نرم‌افزاری و کاربرد هر بخش از کد جداسازی انجام شود اما با این رویکرد کدهای سطح بالا که قرار بود ویژگی‌های کسب‌وکار را فریاد بزنند دیگر وجود ندارند البته این رویکرد برای اصلاح و تغییر ویژگی‌ها خوب است زیرا هر گروه یا بخش مسئولیتی مشخص را بر عهده دارد. اما معماری کتاب یک چیزی بینا بین این دو حالت است و سعی کرده خوبی‌های برش افقی و عمودی را با یکدیگر داشته باشد و هر چقدر کدها به مرکز نزدیک‌تر باشند یعنی کدهای مرتبط تری به کسب‌وکار هستند و هر چقدر دورتر باشند یعنی به محیط بیرونی اتصال پیدا می‌کند به عنوان مثال دیتابیس و UI ,....در معماری لایه‌ای تمام فلش‌ها همیشه به سمت پایین است و اگر یک نیرو جدید و تازه نفس بیاید و بخواهد یک ویژگی جدید توسعه دهد شاید معماری لایه‌ای را خراب کند و معماری کتاب کمی در این باره بهتر عمل می‌کند زیرا هر چرخه یا ویژگی از لایه بیرونی به داخل و سپس به خارج میرود و می‌شود. سعی کنید تا جایی که میشه وابسته به جزئیات نباشید زیرا تمام خطرات و نگرانی‌ها در این بخش از کد هستند و به گفته کتاب شیطان در این بخش است. علیرضا صفافرد علیرضا صفافرد Wed, 18 Oct 2023 14:48:21 +0330 https://virgool.io/@m_60905393/%D8%A2%D9%86%D8%A7%D9%84%DB%8C%D8%B2-%D8%A7%D8%AD%D8%B3%D8%A7%D8%B3-%D8%AC%D9%85%D9%84%D8%A7%D8%AA-%D8%A8%D8%A7-%D8%B1%D9%88%DB%8C%DA%A9%D8%B1%D8%AF-%D8%B4%D8%A8%DA%A9%D9%87-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-%D9%BE%D9%88%DB%8C%D8%A7-l8di09lhu8h6 آنالیز احساس جملات با رویکرد شبکه پیچیده پویاچیکیده:ادبیات موضوع و کارهای گذشته:پیش‌بینی احساس جملات با استفاده از گراف یک موضوع مورد مطالعه در زمینه ادبیات و پردازش زبان طبیعی است. این موضوع معمولاً به عنوان "تحلیل احساس متن" شناخته می‌شود و در زمینه‌هایی مانند متن‌کاوی و یادگیری ماشین مورد بررسی قرار می‌گیرد.فعالیت های حوزه تحلیل احساس جملات شامل مواردی مثل تشخیص احساس مثبت، منفی یا بی‌طرف بودن جملات است و در این موضوع وابستگی بین احساسات و کلمات مورد بررسی قرار می‌گیرد.روش‌ معمول در حوزه تحلیل احساس جملات با گراف، استفاده از گراف‌ واژگان جملات است. در این روش، هر واژه به عنوان یک گره در گراف مدل‌سازی می‌شود و ارتباطات بین واژگان با استفاده از یال‌ها نمایش داده می‌شوند سپس با استفاده از الگوریتم‌های تحلیل گراف، می‌توان احساس جمله را بر اساس ارتباطات بین واژگان پیش‌بینی کرد.پس از آن با استفاده از گراف و الگوریتم‌های یادگیری ماشینی، می‌توان پیش‌بینی احساس جملات را انجام داد.در سال‌های اخیر، تجزیه و تحلیل احساسات به عنوان یک ابزار ضروری در بازاریابی و دامنه‌های مشابه به شمار می‌رود.در این موضوع مقالات زیادی در سال های اخیر منتشر شده که با رویکرد گراف، در تشخیص احساس جملات اقدام کرده اند که در ادامه به طور خلاصه یک رویکرد کلی از مراحل کار را شرح می دهیم.در این مدل ساختار گراف با استفاده از معیارهای شباهت گراف و روش‌های طبقه‌بندی تجزیه و تحلیل می‌شود. در این مدل، کلمات موجود در یک عبارت به عنوان گره‌ها نمایش داده می‌شوند و ارتباط بین کلمات به عنوان یال‌ها نمایش داده می‌شود.در این مدل ابتدا دسته‌های احساسی براساس مجموعه داده‌های آموزشی توصیف می‌شود. سپس یک تکنیک شباهت گراف برای مقایسه هر گراف از جملات با سه گراف احساسی به کار می‌رود. نتایج مقایسه شامل نمایش جدیدی به عنوان بردارها است.در نهایت، پیش‌بینی احساس با استفاده از یک روش طبقه‌بندی بردار مانند SVM انجام می‌شود.هر یک از مراحل فوق در ادامه توصیف و تجزیه شده است. گزینه‌های بسیاری برای هر مرحله وجود دارد و باید تنظیمی را پیدا کنیم که دقت پیش‌بینی‌ها را بیشترین میزان داشته باشد.نزدیکی یا betweenness بین کلمات توسط یال‌هایی که گره‌ها را به یکدیگر متصل می‌کنند نمایش داده می‌شود و توسط تعداد کلماتی که پس از کلمه هدف قرار دارند تعیین می‌شود.همانطور که در شکل زیر نشان داده شده است یک قاب در سراسر متن حرکت می‌کند و ارتباط بین کلمات را مشخص می‌کند . اندازه قاب یک پارامتر است که دقت روش را تحت تأثیر قرار می‌دهد.ما آزمایش‌هایی با اندازه قاب های از ۲ تا ۱۰ انجام داده‌ایم. جملاتی مانند توییت ها و جملات شبکه های اجتماعی معمولاً شامل تعداد کمی کلمه هستند، این معمولا یا به دلیل محدودیت در تعداد کاراکترهاست (مانند توییتر) و یا به خاطر مفهوم کوتاهی که آنها در بر می‌گیرند. این نشان می‌دهد که مطالعه قاب های بزرگتر از ۱۰ تقریبا بی‌معنی است و موضوعیتی ندارد.در شکل زیر مراحل ساخت گراف یک جمله با اندازه قاب فرضی 2 نشان داده شده است.پس از دسته بندی جملات به کلاس های احساسی تمام گراف‌های ساخته شده که در یک دسته قرار دارند با یکدیگر ترکیب می‌شوند تا در نهایت گراف نمایندهٔ کلاس احساسی شکل بگیرد. ساخت این ترکیب بسیار ساده است یال‌ها و گره‌های مشترک یک بار در گراف جدید نگه داشته می‌شوند و هر عنصر غیر مشترک با ارجاع به عناصر مشترک اضافه می‌شود.پس از این که گراف های بزرگ کلاس های احساسی تشکیل شوند، هر جمله جدید ورودی به عنوان یک گراف با توجه به معیار شباهتی که با هر دسته دارد می تواند به دسته ای که بیشترین شباهت را دارد نسبت داده شود و به این ترتیب حس یک جمله ورودی جدید پیش بینی شود.روش‌هایی برای تخمین شباهت گراف وجود دارند. رویکرد معمول برای این کار شناخت زیرگراف حداکثر مشترک یا تطبیق گره‌های مجاور است. در موضوع مورد مطالعه، ما به یک روش شباهت گراف نیاز داریم که با استفاده از پارامترهای برچسب گره‌ها، جهت یال‌ها و تعداد یال‌های مشترک، عمل کند.شکل زیر نشان می‌دهد که گراف یک جمله می‌تواند با گراف هر کلاس احساس مقایسه شود تا سه عدد تولید شود. هر عدد، همبستگی جمله هدف با سه کلاس احساس را تعیین می‌کند. این سه عدد برداری را تشکیل می‌دهند که در ادامه با استفاده از یک مدل مانند SVM برای پیش‌بینی احساس مناسب استفاده شود. در ادامه، شرحی از معیارهای شباهتی که در روش ما استفاده کرده‌ایم، ارائه خواهیم داد.Containment Similarity (CS):یک اندازه شباهت گراف است که در سنجش شباهت بین گراف‌های استفاده شده است. این اندازه شباهت تعداد یال‌های مشترک بین دو گراف را تقسیم بر تعداد یال‌های گراف کوچکتر کرده و نتیجه را محاسبه میکند.[5]Maximum Common Subgraph :به صورت خلاصه این معیار بزرگترین زیرگراف مشترک بین دو گراف است.MCS دو گراف، بزرگترین زیرگرافی است که هر دو گراف اصلی حاوی آن هستند و تعداد گره‌ها و یال‌های آن بیشترین مقدار ممکن است. MCS در اندازه‌گیری شباهت بین گراف‌ها مورد استفاده قرار می‌گیرد. در فرمول های زیر از این معیار استفاده می شود.Maximum Common Subgraph (MCS)-based similarity metrics:ما همچنین میتوانیم اندازه‌های شباهتی که بر اساس اندازه MCS بین دو گراف است را بررسی کنیم. شناسایی MCS در گراف‌های بدون برچسب یک مسئله NP-complete است. خوشبختانه، شناسایی MCS در گراف‌های با گره‌های برچسب‌دار یک فرآیند با پیچیدگی خطی است.[6]سه نوع روش محاسبه شباهت بین دو گراف با در نظر گرفتن MCS وجود دارد که در زیر به آن می پردازیم.که در این فرمول صورت کسر در واقع تعداد گره های موجود در بزرگترین زیرگراف مشترک بین دو گراف و مخرج کسر اندازه گراف کوچکتر است.که در این فرمول صورت کسر تعداد یال های مشترک بین دو گراف در بزرگترین زیرگراف مشترک بین دو گراف بدون در نظر گرفتن جهت یال های دو گراف و مخرج کسر اندازه گراف کوچکتر است.در این فرمول صورت کسر تعداد یال های مشترک بین دو گراف در بزرگترین زیرگراف مشترک بین دو گراف است که جهت یال ها هم در نظر گرفته شده و یال های هم جهت را در نظر میگیرد و مخرج کسر اندازه گراف کوچکتر است.معیارهای MCSNS، MCSUES و MCSDES بر اساس MCS بین دو گراف هستند، اما هر کدام از آنها شباهت نمودار را به روشی متفاوت محاسبه می‌کنند. MCSNS از تعداد گره هایی که در MCS وجود دارد استفاده می کند. در یک بررسی دقیق تر چون گره ها در گراف همان کلمات هستند، این بدان معنی است که تعداد کلمات مختلف مرتبط با یکدیگر را در نظر می گیرد.معیارهای MCSUES و MCSDES از یال هایی استفاده می کنند که در MCS وجود دارد. در مورد MCSDES ما جهت یال ها را در نظر می گیریم در حالی که در مورد MCSUES جهت در نظر گرفته نمی شود. تحقیقات بیشتر نشان می‌دهد که این معیارها این مفهوم را نشان می‌دهند که رابطه کلماتی که در گراف وجود دارند چقدر قوی است.روش تحلیل احساسات پیشنهادی، داده‌های آموزشی را به دو بخش تقسیم می‌کند. بخش اول برای ساختن گراف هر کلاس احساس استفاده می شود. بخش دوم برای آموزش یک طبقه بندی کننده برداری مانند SVM و Bayes استفاده می شود.هر جمله از بخش دوم مجموعه داده آموزشی با یک گراف از کلمات نمایش داده می شود. سپس گراف کلمه های این جملات با گراف های سه کلاس احساسی با استفاده از یکی از معیارهای شباهت نمودار که توضیح داده شده است مقایسه می‌شوند. نتایج مقایسه یک بردار سه بعدی را تشکیل می دهد که میزان شباهت جمله را به هر دسته از احساس نشان می دهد. بردارهای این قسمت از مجموعه داده آموزشی برای آموزش طبقه بندی کننده SVM استفاده می شود.هرجمله در آینده به عنوان یک ورودی جدید دوباره به عنوان یک گراف از کلمه نشان داده می شود و با گراف های سه کلاس احساسی به روشی مشابه با بخش دوم مجموعه داده آموزشی مقایسه می شود. این عمل همان بردار را تولید می کند که در نهایت میتواند توسط طبقه بندی کننده آموزش دیده در یکی از سه کلاسی که هر کلاس احساسی را نشان می دهد طبقه بندی شود.در بخش‌های قبلی ساخت گراف های کلمه برای جملات و کلاس‌های احساسات، معیارهای شباهت نمودار، نمایش برداری احساسات و ساخت طبقه‌بندی‌کننده احساسات را توضیح دادیم.در ادامه کل روش را به طور خلاصه توضیح می دهیمکه چگونه می توان احساسات یک جمله هدف جدید را شناسایی کرد.شکل زیر تمام مراحل روش تحلیل احساسات گراف کلمه را نشان می دهد.مرحله اول:یک گراف برای داده های Train از توییت ها یا جملات منفی و مثبت و خنثی جمع آوری میکنیم.مرحله دوم:مجموعه داده به دو قسمت مساوی تقسیم می شود که هر قسمت به روشی متفاوت استفاده می شود. در بخش اول، جملاتی که احساسات یکسانی را بیان می کنند با هم گروه بندی می شوند.مرحله سوم:گروه‌هایی از توییت‌هایی که به یک احساس تعلق دارند برای ساختن گراف بزرگ نماینده برای سه کلاس احساس استفاده می‌شوند.هر گراف کلاس از جملاتی ساخته می شود که گرایش احساسات مربوطه را بیان می کند. در ادامه هر جمله از بخش دوم نیز به عنوان یک گراف کلمه نمایش داده می شود.مرحله چهارم:گراف های جملات قسمت دوم با یک متریک شباهت گراف با سه گراف احساسات مقایسه میشود. این مقایسه در سه عدد به دست می آید. هر عدد شباهت نمودار جمله مورد نظر را با نمودار کلاس احساسات بیان می کند. از این به بعد، هر جمله از قسمت 2 را می توان به عنوان برداری از این سه عدد نشان داد.مرحله پنجم:بردارهای جملات مجموعه داده آموزشی همراه با احساسی که بیان می کنند برای آموزش یک طبقه بندی کننده SVM استفاده می شوند.در نهایت هر جمله جدید با استفاده از SVM جمله را به کلاس های احساسی نسبت می دهد و هر جمله به بیشترین امتیازی که از هر کدام از سه دسته احساسات داشته باشد نسبت داده خواهد شد.رویکرد ما با بسیاری از رویکردهای دیگر یادگیری ماشین با استفاده از مجموعه داده مشابه مقایسه شد. که نتایج دقت آن ها در جدول زیر ارائه شده است.بالاترین دقت به دست آمده با رگرسیون لجستیک (LR) حدود 71 درصد بود.در شکل زیر دقت های بدست آمده از روش پیشنهادی با تمام روش های شباهت گراف که بالاتر توضیح داده شد آمده است که در این آزمایش ها با یک قاب که عددی بین دو تا ده بود انجام شد. البته در مقاله [8] نیز جملات ابتدایی را در ۲ دسته کلی تحلیل کرده است و جمع آوری تمام ایدهای برپایه الگوریتم بوده است و دقت حدود ۷۰ الی ۸۰ درصد را رسیده بودند.همانطور که در جدول فوق مشاهده میشود دقت به دست آمده از روش های پیشنهادی و بر مبنای گراف کلمات قابل رقابت با روش های مبتنی بر یادگیری ماشین بوده و در موارد بسیاری دقت بالاتری خواهد داشت.BERTBidirectional Encoder Representations from Transformersدر وبلاگ گوگل در لینک [4] این معماری به این صورت توصیف شده است کهیک معماری شبکه عصبی است که برای پردازش زبان طبیعی و متن استفاده می‌شود. این معماری توسعه داده شده توسط شرکت Google و به صورت اولیه در سال ۲۰۱۸ معرفی شد.با استفاده از مدل BERT قادر خواهیم بود بهبود قابل توجهی در فهم مفهوم جملات و کلمات به دست آوریم.BERT قادر است بهبود قابل توجهی در وظایف مختلفی مانند تشخیص احساس، ترجمه ماشینی، پرسش و پاسخ و دیگر وظایف پردازش زبان طبیعی داشته باشد. به علاوه، با قابلیت تنظیم مدل به مسائل خاص و تمرین روی داده‌های مخصوص، BERT قابلیت انطباق با داده‌های مختلف را نیز داراست.در مقالات و مطالعاتی که از مدل BERT برای تشخیص احساس جملات استفاده می‌کنند، دقت‌های متفاوت گزارش شده‌اند. این دقت‌ها معمولاً در محدوده‌هایی مانند 80% تا 90% قرار می‌گیرند، اما برای هر مجموعه داده، دقت میانگین ممکن است متفاوت باشد.کاری که ما انجام دادیم:در ابتدای کار ما یک دیتاست از جملات همراه با احساسات از لینک[1] برداشت کردیم در این دیتاست تمام جملات با یکی از سه احساس زیر دسته‌بندی شده‌اند.fear = "fear",joy = "joy",love = "love",anger = "anger",sadness = "sadness",surprise = "surprise",سه دسته فایل برای ارزیابی جملات وجود دارد ما از دو دیتاست آن استفاده کردیم یکی فایل train و دیگری test با فایل train ما مدل گراف‌ها را ایجاد کردیم و با مدل train ارزیابی انجام دادیم. به طور کلی به کمک دیتاست موجود در لینک [1] ما دو سری دیتاست ایجاد کردیم و هر کدام را ارزیابی کردیم و به مقادیر جداگانه ای از دقت رسیدیم.گراف‌هایی که در ادامه مقاله بررسی شده‌اند به کمک ایده مطرح شده در مقاله [2] شکل گرفته اند و ارزیابی شده‌اند البته در مقاله [3] نیز بیان شده است که گراف کلمات و ساختار جمله نیازمند یک گراف جهت دار نیز می‌باشد لذا ما هر کسی را فقط به ۱۰ کلمه بعدی خودش اتصال داده‌ایم.هر گراف ساختار زیر را در دل خود دارد:هر node نماینده از یک کلمه می‌باشدهر یال وزندار نشان دهنده این است که دو کلمه در یک جمله آیا با هم آمده‌اند یا خیر و تعداد دفعاتی که با یکدیگر آمده‌اند را وزن یال قرار میدهیم.ما در ادامه به کمک تعریف و فایل train بالا ۶+۱ مدل گراف ایجاد کردیم تمام جملاتی که در یکی از ۶ صفت (fear,joy,love,anger,sadness,surprise) آمده‌اند را دسته‌بندی کرده‌ایم و سپس برای هر دسته یک گراف با نام خود احساس ایجاد کردیم از طرف دیگر ۱ مدل گراف ایجاد کردیم که تمام جملات را در کنار هم بدون در نظر داشتن بار احساسات در یک دسته قرار دادیم و گراف مورد نظر آن را ایجاد کردیم. و اسم این گراف را all قرار دادیم.در ابتدای کار برای پی‌بردن و پیدا کردن شناخت نسبت به گراف تمام مقادیر و ویژگی‌های گراف fear را پیدا کردیم و بررسی کردیم :انتظار ما به این صورت بود که کلمات کلیدی که بار احساسی بیشتری دارند در ارزیابی‌های centrality پیدا شوند اما همانطور که از جدول پیدا می‌باشد کلماتی که بار احساسی کمی دارند بعد از بررسی ما متوجه مطالب زیر شدیم:در جملات احساسی احتمال به کار رفتن دو کلمه احساسی بسیار کم می‌باشد. به عنوان مثال فرض کنید کلمه x , y دارای بار احساسی هستند و به عنوان مثال احساس fear را از داخل جمله به ما میدهد احتمال استفاده x , y در یک جمله بسیار کم می‌باشد لذا هیچگاه این کلمات در ۷ گراف ساخته شده به یکدیگر یال ندارند و اگر هم یالی وجود داشته باشد وزن آن یال بسیار پایین می‌باشد.از طرفی دیگر وقتی شما جملات را مشاهده می‌کنید کلمه( I و i )تقریبا در تمام جملات استفاده‌شده است لذا این گره در تمامی ۷ گراف ساخته شده از مرکزیت بالایی برخوردار است.پس ما تلاش کردیم گره‌هایی که در تمام ۷ مدل گراف ایجاد شده از یک اولویت betweenness centrality هستند را از گراف حذف کنیم. البته این باعث شد همبندی در گراف ها کمی به مشکل بخورد لذا ما کمی گراف را تغییر دادیم و تمام ۶ گراف احساسات را به صورت زیر تغییر دادیم:ما از تمام ۶ مدل گراف یک کپی ایجاد کردیم و سپس یک گره برای این گراف ها اضافه کردیم که به تمام گره های دیگر یال دارد و وزن این یال برابر است با تعداد تکرار این کلمه در جملات با بار احساسی مطرح شده در گراف.و در این گراف سعی کردیم گرهایی که از مرکزیت یکسانی در ۶ مدل گراف برخوردار هستند را حذف کنیم تا بیشتر کلماتی که از نظر احساساتی بار معنایی ایجاد می‌کنند از هر گروه در گراف‌ها باقی بمانند.این حذف گرها را ما تاجایی ادامه دادیم که در الگوریتم Louvain ما به پارامترهای زیر رسیدیم.Modularity: 0.41440865613294325Coverage: 0.4669390292641769Performance: 0.9302603189493434و این نشان میدهد دسته بندی احساسات تا حد معقولی بهبود پیدا کردند. پس ما در حال حاضر ۷*۲ عدد گراف ساختیم (۱ گراف که تمام گره ها و جملات را در دل خود داشته است و ۶ گراف که از روی جملات هر احساس ساخته شده است و این ۷ گراف یکبار دیگر کپی شدند و گرهایی با اهمیت مرکزی بالا حذف شدند پس در کل از این جا به بعد ۱۴ عدد گراف خواهیم داشت) در مقاله [7] نیز اهمیت کلمات را بر اساس مرکزیت درجه و نزدیکی (Closeness) بررسی کرده است.علاوه بر این ما گراف احساسات را با الگوریتم‌های مدل سازی بررسی کردیم تا از ساختار داخلی این گراف‌ها بیشتر آشنا شویم بعد از شبیه‌سازی و بررسی گراف ما بیشترین شباهت را با گراف watts-strogatz داشت و این نشان می‌دهد ساختار داخلی این گراف‌ها اصلا خاصیت community بالایی ندارد زیرا شباهت گراف ما با مدل barabasi albert بسیار کم بود و این نشان میدهد کلمات احساسی در دل خود گروه بندی خوبی ندارند.بعد از مراحل بالا ما برای هر جمله ۵*۶ تا پارامتر ایجاد کردیم پارامترها به این صورت ایجاد می‌شوند که برای هر احساس ما ۵ پارامتر را برحسب گراف مدل شده و ساختار جمله ارزیابی می‌کنیم و سپس در بخش train مدل برحسب این ۳۰ پارامتر دسته‌بندی‌ها شکل گیری می‌شوند و سپس در بخش test جملات را دریافت می‌کنیم و ۳۰ پارامتر را ارزیابی می‌کنیم و سپس در دسته‌ای که شباهت بیشتری داشته باشد قرار میگیرد و این دسته‌ها نشان دهنده یکی از ۶ احساس کلی ما می‌باشدبرای شکل گیری این دسته‌ها ما سه مدل الگوریتم دسته بندی را پیاده سازی کردیم یک الگوریتم svm و سپس الگوریتم bayesian و الگوریتم random forest چون پارامترهای ارزیابی ما از یک جمله ۳۰ مورد می باشد و آنها را نمی توانیم به صورت یک تابع خطی باهم ترکیب کنیم و ضریب ارزش هر پارامتر را به راحتی نمی‌توانیم بدست بیاوریم لذا الگوریتم‌های k-means , bayesian اصلا برای دسته‌بندی جملات ما خوب نیستند و الگوریتم جنگل رندم و svm دقت بیشتری را به ما می‌دهند.ارزیابی:در ابتدای کار ما از دیتاست [1] دو دیتاست مختلف ایجاد کردیم اولین دیتاست ما نرمال نبود در کل ۲۰۰۰ جمله در اختیار داشتیم و به دقت ۶۸.۱ درصد رسیدیم که در مقایسه با مقاله [2] بسیار بهتر عمل کرده‌است. و ما در این ارزیابی تمام مراحل مقاله [2] را پیاده سازی کردیم و یک ایده خلاقانه دیگر به آن اضافه کردیم تا به این درصد رسیدم و آن اینکه اگر ارزش بار معنایی گرها بالا بود میزان ارزش را جمع می کردیم با وزن بین یال آنها. به عبارت بهتر ما یک جمله وقتی دریافت می‌کنیم آن را به شکل یک گراف مانند مقاله [2] ایجاد می کنیم. سپس سعی می‌کنیم این گراف را در ۶ گراف موجود از احساسات match کنیم و میزان شبهات را ارزیابی کنیم طبق مقاله[2] و نقطه قوت ما نسبت به مقاله [2] در این ارزیابی اولیه این می‌باشد که ما گرهایی که ارزش معنایی یا مرکزیت بالایی دارند را به صورت خطی در وزن یال بین این دو مورد تاثیر قرار می‌دهیم.بعد از آزمایش بالا ما تعداد جملات خطایی که در آزمایش بالا انجام داده‌ایم را مورد بررسی قرار دادیم و خطاها به شرح زیر بودند:Falt:{ { 'joy':{ 'sadness': 31, 'fear': 5, 'anger': 10, 'love': 15, 'surprise': 1 }, 'fear': { 'joy': 61, 'anger': 6, 'sadness': 69, 'love': 1, 'surprise': 1 }, 'anger': { 'joy': 78, 'sadness': 66, 'love': 1, 'fear': 3 }, 'sadness': { 'joy': 104, 'love': 1, 'anger': 17, 'fear': 5 }, 'love': { 'sadness': 23, 'joy': 88, 'anger': 4, 'fear': 2 }, 'surprise': { 'joy': 30, 'sadness': 17, 'love': 1, 'fear': 7, 'anger': 1 } }}در اینجا متوجه شدیم بیشتر خطاها بخاطر این می‌باشد که ما اشتباه تشخیص دادیم که جمله احساس joy را در دل خود دارد و بعد از بررسی متوجه شدیم تعداد جملات joy بسیار زیاد می‌باشد و بعد از آن متوجه این شویم که گراف joy بسیار سنگین می‌باشد به عبارت بهتر وزن یال‌های موجود در آن بسیار زیاد می‌باشد پس سعی کردیم سپس تعداد جملات درستی که تشخیص دادیم را بررسی کردیم در این جا هم متوجه این موضوع شدیم که joy را با احتمال بیشتری تشخیص میدهیم که در زیر تعداد جملات درست تشخیص داده شده معلوم شده است.Correct sentences:{ 'sadness': 454, 'joy': 633, 'fear': 86, 'anger': 127, 'love': 42, 'surprise': 10}پس ما یک دیتاست دیگر ایجاد کردیم با این تفاوت که تعداد جملات از هر احساس برابر دقیق ۱۱۰۰ عدد باشد. بعد از انجام این کار تمام گراف های ما به صورت نرمال تبدیل شدند و قابلیت قیاس بین آنها بهتر شکل گرفت و ما در این دیتاست با کمک الگوریتم قبل به دقت ۲۰ درصد رسیدیم و این برای ما اصلا مورد قبول نبود.پس تصمیم گرفتیم تعداد پارامترهای متنوع‌تری را نسب به گذشته ارزیابی کنیم و به کمک الگوریتم های مطرح شده در بخش گذشته که عبارت هستند از الگوریتم svm و سپس الگوریتم bayesian و الگوریتم random forest پیشرفت خود را ارزیابی کنیم.همانطور که در بخش قبل هم بیان کردیم ما ۵*۶ پارامتر را برای هر جمله ارزیابی میکنیم مقدار این پارامترها به صورت زیر می‌باشد:ما برای هر جمله یک گراف ایجاد می‌کنیم سپس سعی میکنیم این گراف را در ۶گراف احساسات match کنیم که برای این کار ۵ پارامتر زیر رو ارزیابی می‌کنیم برای هر گراف جمله و احساس که در کل می‌شود ۵*۶ پارامتر برای یک جمله.نکته‌ای که در ادامه مهم است ما گراف احساس را از این به بعد F مینامیم و گراف جمله را S می نامیمارزش راس‌های موجود در s را در f بر اساس درجه کلی آن ها ارزیابی میکنیم و جمع همه آن را به عنوان یک پارامتر مدنظر قرار می‌دهیمتمام یالهای موجود در گراف s را در f پیدا می کنیم و سپس وزن های آنها را جمع میکنیم و این نیز می شود پارامتر دیگر ماتعداد راس هایی که قابلیت match شدند نداشتند را جمع می‌کنیم.(البته این تعداد در صورتی افزایش پیدا می کند که این راس در بقیه ۵ گراف دیگر F قابلیت match را داشته باشد)تعداد یالهایی که قابلیت match شدن نداشته باشند را جمع می‌کنیم(البته این تعداد در صورتی افزایش پیدا می‌کند که این یال در گراف‌های دیگر قابلیت match شدن را داشته باشد)در گراف‌هایی که copy ایجاد کردیم و سپس راس هایی که از betweenness centrality بالایی برخوردار بودند را حذف کرده بودیم میزان مرکزیت راس‌های s را در این گراف‌ها بررسی میکنیم و جمع تمام مقادیر مرکزیت ها را در کنار هم به عنوان یک پارامتر ارزیابی قرار میدهیم.به کمک پارامترهای مطرح شده بالا ما مدل‌های زیر را ساختیم:SVMRandom forestBayesianو دادهای تست را به این سه مدل دادیم و در انتها به نتیجه‌گیری زیر رسیدیم جالب بر این است که چون ساختار منطقی جملات خیلی شرایط ادبی در آنها مطرح می‌باشد لذا الگوریتم random forest و سپس svm و سپس Bayesian بهتر عمل می کند و این نشان میدهد بسیار شرط های دستور زبان وجود دارد تا ما احساس یک جمله را متوجه بشویم و دقت ها به شرح زیر است:Accuracy random forest: 41.45٪Accuracy SVM: 34.25٪Accuracy naveBayesian: 29.9٪اما وقتی داده‌ها را به صورت غیر نرمال به این مدلها میدهیم تا train شوند به شرایط دیگری می رسیم که بسیار جالب می‌باشد.Accuracy naveBayesian: 61.05٪Accuracy SVM: 55.9٪Accuracy random forest: 41.65٪که این نشان میدهد که داده ها بیشتر در احساس joy تمرکز دارند و الگوریتم Bayesian توانسته است این تمرکز را به خوبی تشخیص بدهد البته دادهای تست ما نیز بیشتر بر این احساس تمرکز دارند و این نیز مزید بر علت این اتفاق می‌باشد.جمع بندی:در ابتدای کار ما چندین مقاله در این حوزه را مورد بررسی قراردادیم و سپس ما بهترین دقتی که یافت کردیم در این مقالات دقت ۷۴ درصد بوده است که این دقت برای دسته بندی جملات در + و - و خنثی صرفا بوده است اما ما در کاری که انجام دادیم این بوده است که جملات را در ۶ دسته متفاوت قراردادیم (fear , joy , love , anger , sadness , surprise) و به دو صورت متفاوت الگورتیم خود را اجرا کردیم ایده مقاله [2] به همراه ایده خلاقانه وزن دهی گره‌ها بر اساس میزان مرکزیت آنها و به دقت ۶۸ درصد رسیدم البته جملات در این مورد نرمال نبودند و بعد از آن الگوریتم این مقاله را برای دیتاست نرمال مورد ارزیابی قرار دادیم و متوجه این موضوع شدیم که ایده این مقاله بسیار به داده‌ها و حجم اطلاعات تست وابستگی دارد زیرا به دقتی در حدود ۲۰ درصد رسیدم و سپس با رویکرد های ۵ گانه برای هر احساس و استفاده از الگوریتم random forest ما دقت را به ۴۱ درصد رساندیم و این پارامترهای ۵ گانه به کمک الگوریتم های شبکه‌های پیچیده پویا مورد ارزیابی قرارگرفته شدند الگوریتم هایی از قبیل community detection توسط الگوریتم Louvain مورد ارزیابی قرار گرفت و به کمک حذف راس هایی که از betweenness بالایی داشتند گراف را بهبود دادیم و کلمات با بار احساسی بیشتر را پیدا کردیم و همچنین به کمک الگوریتم و پارامترهای ارزیابی مرکزیت اهمیت معنایی کلمات را پیدا کردیم و سپس از الگوریتم های matching گراف ها استفاده کردیم تا بتوانیم میزان شباهت یک جمله را در یک گراف بدست بیاوریم. علاوه بر این برای شناخت ساختار داخلی گراف‌های ایجاد شده با مدل های WS و BA و forest fire گراف‌ها را شبیه‌سازی کردیم و متوجه این موضوع شدیم که ساختار داخلی ۶ مدل گراف احساسات ما ساختار commuinity در دل خود ندارند و بیشتر از آن شبیه به مدل ws هستند ولی خاصیت جهان کوچک در دل آنها قرار دارد.مراجع:1)https://www.kaggle.com/datasets/praveengovi/emotions-dataset-for-nlp?select=test.txt2)Violos, John, et al. "Sentiment analysis using word-graphs." Proceedings of the 6th International Conference on Web Intelligence, Mining and Semantics. 2016.3)Oerder, Martin, and Hermann Ney. "Word graphs: An efficient interface between continuous-speech recognition and language understanding." 1993 IEEE International Conference on Acoustics, Speech, and Signal Processing. Vol. 2. IEEE, 1993.‏4)https://blog.google/products/search/search-language-understanding-bert/5) Aisopos, F. et al. 2012. Content vs. Context for Sentiment Analysis: A Comparative Analysis over Microblogs. Proceedings of the 23rd ACM Conference on Hypertext and Social Media (New York, NY, USA, 2012), 187–196.6) Conte, D. et al. Challenging Complexity of Maximum Common Subgraph Detection Algorithms: A Performance Analysis of Three Algorithms on a Wide Database of Graphs.7)Castillo, Esteban, et al. "UDLAP: sentiment analysis using a graph-based representation." Proceedings of the 9th international workshop on semantic evaluation (SemEval 2015). 2015.‏8)Rosenthal, Sara, et al. "Semeval-2015 task 10: Sentiment analysis in twitter." Proceedings of the 9th international workshop on semantic evaluation (SemEval 2015). 2015.‏ علیرضا صفافرد علیرضا صفافرد Thu, 22 Jun 2023 16:54:13 +0330 https://virgool.io/@m_60905393/%D8%B4%D8%A8%DA%A9%D9%87-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-%D9%BE%D9%88%DB%8C%D8%A7-%DA%86%DB%8C%D8%B3%D8%AA-xkiuukzzk5hn علم شبکه و شبکه پیچیده پویا چیست؟این علم نوینی هست و بر پایه گراف‌ها (graph) بنا شده‌است. در این علم ما تمام گراف‌های موجود را بررسی نخواهیم کرد. گراف‌هایی که برپایه رندم شکل گرفته‌باشند و خصوصیاتی ویژه نداشته‌باشند اصلا مورد بحث مانیستند. به عنوان مثال گراف موجود در شجره نامه ویژگی خاصی ندارد و صرفا یک درخت ساده هست و تحلیل آن نکته خاصی ندارد. ویژگی‌هایی که ما مدنظر داریم ویژگی‌هایی هست که در گراف های واقعی به صورت معمول وجود دارند اما در گراف‌های رندم مشاهده نمی شوند.گراف‌هایی که به صورت معمول در این علم بررسی می‌شوند معمولا از جنس گراف‌های موجود در شبکه اینترنت یا شبکه موجود در شبکه‌های اجتماعی و دوستی و یا شبکه‌های موجود سازنده پروتئین ها مدنظر قرار میگیرد. ویژگی‌های منحصر به فرد گراف‌ها که ما در این علم مورد بررسی قرار میدهیم به شرح زیر هستند:توزیع درجه: به عنوان مثال ما در دنیای واقعی گراف‌هایی را مشاهده می‌کنیم که با توجه به اینکه تعداد یال ها بسیار کم هست تعدادی از راس‌های گراف هستند که درجه بسیار زیادی دارند و بقیه افراد بیشتر به این راس ها اتصال دارند توزیع درجه ها به صورت نمایی شکل می گیرند.به عنوان مثال در اینستاگرام تعداد کمی از افراد بالای ۱ میلیون دنبال کننده دارند و تعداد زیادی آدم هستند که زیر ۱۰۰۰ کاربر دارند یعنی اصلا قدرت به صورت نرمال توزیع نشده است.ضریب خوشه بندی:این پارامتر یک عدد هست بین ۰ تا ۱ که هر چقدر بالاتر باشد یعنی گراف ما می تواند به دسته های جدا از هم تبدیل شود. به عنوان مثال در شبکه اجتماعی facebook افراد در گروهای مختلفی عضو هستند و با افراد موجود در هر گروه دوست می شوند. اگر ما گراف دوستی موجود در facebook را نمایش بدهیم افراد خیلی از دوستانشون داخل یک گروه هستند و کمتر با افراد بیرون گروه‌هایی که دوست دارند دوست هستند.ضریب نزدیکی (closeness):این ضریب هم نشان میدهد چقدر یک راس در نزدیکی بقیه راس‌ها قراردارد. به عنوان مثال ما یک شبکه دوستی بین مردم را داریم و می خواهیم یک شایع یا یک خبر را به سرعت بین افراد جامعه پخش کنیم. برای اینکار ما باید راس‌هایی را انتخاب بکنیم که مرکزیتی از جنس نزدیکی داشته باشند و به طور میانگین با کمترین حرکت بتواند پیام خود را به راس های دیگر گراف ارسال کنند. به عنوان مثال در زمان بیماری covid-19 این مسائل بسیار حائز اهمیت بود. افرادی که ضریب نزدیکی بالایی دارند باید بسیار مراقبت شدید بشوند زیرا اگر این افراد مریض شوند به سرعت مریضی بین افراد موجود در گراف پخش می شود.ضریب بینی (betweenness):این ضریب بسیار ضریب جالبی هست در این بخش ما به عنوان راس‌هایی هستیم که اگر نباشند گراف دیگر متصل نمی ماند. به عنوان مثال فرض کنید اگر ما برج میلاد را مورد هدف قرار بدهیم و تخریب بکنیم کل شبکه اینترنت بین استانی مختل می شود پس این راس بسیار مهمی هست در شبکه اینترنتی داخل کشوری.یا در شبکه تلفن ثابت اگر چند مرکز خاص تخریب شود ممکن هست کل ارتباط تلفنی بین استانی به مشکل بخورد و افراد نتواند ارتباط برقرار بکننداین ویژگی های بالا بسیار ویژگی های جالبی هستند و تحلیل‌های بسیاری بر پایه این ویژگی‌ها در مقالات و مجلات ذکر می شود.ضریب رتبه صفحه (page rank):پیج‌رنک یا رتبه صفحه، به الگوریتمی گفته می‌شود که بر پایه آن موتورهای جستجو، صفحات وبی که به هدف جستجوگر نزدیکترند را در رده‌های بالاتری نسبت به دیگران قرار می‌دهد. الگوریتم Page Rank اولین بار در سال ۱۹۹۸ توسط Larry Page و Sergey Brin در دانشگاه استنفرد ارائه شده است. با این روش کاربرانی که کلمه ویژه‌ای را جستجو می‌کنند می‌توانند ابتدا صفحات وبی را ببینند که هم به خواسته آن‌ها نزدیکتر است و هم بازدید بیشتری داشته‌است.این الگوریتم به هر صفحه وب، امتیازی اختصاص داده و از این امتیاز با درنظر گرفتن پرس و جوی کاربر، جهت رتبه بندی صفحات وب استفاده می کند. رتبه هر صفحه با اختصاص وزن به لینکی که به آن صفحه داده شده است به دست می آید که مقدار این وزن به کیفیت صفحه ای که لینک در آن قرار گرفته بستگی دارد. بدین صورت لینک های صفحات مهم تر وزن بیشتری می گیرند. جهت مشخص کردن کیفیت صفحه های رجوع کننده، از رتبه آن صفحه که به صورت بازگشتی تعیین می شود، استفاده می گردد.کوچیکی جهان :یکی از ویژگی های جالب گراف‌های واقعی small-word هستش که به طور اختصار در ادامه توضیح خواهیم داد. برای توضیح این مورد باید چند نکته از گراف ها بیان شود. همان طور که می دانید قطر گراف تعریفش به این صورت است که شما یک گراف مدنظر خود بیاورید کوتاه ترین فاصله بین هر دو راس را مد نظر بگیرید بیشترین مقدار فاصله بین این مجموعه را می گویم قطر گراف. حالا اگر قطر گراف عددی در حدود Log(n) باشد می توانیم بگویم آن گراف ویژگی small-word را دارد. این ویژگی در زمانی جالب می شود که تعداد یال های موجود در گراف حدودا برابر تعداد راس ها هست یعنی تعداد یال های موجود در گراف بسیار کمتر از انتظار ما هست ولی گراف ما قطر بسیار کوچیکی دارد. برای اینکه این ویژگی را بیشتر متوجه شوید و کمی هیجان زده بشوید یکی از آزمایشات ملموس بر پایه این ویژگی را بیان می کنم که در سال ۱۹۶۷ توسط Stanley Milgram انجام شده است آزمایش به این صورت هست که آقای Milgram تعدادی پاکت نامه ایجاد کرد و داخل آنها مقداری پول قرار داد و یک آدرس جغرافیایی بر روی آنها نوشته بود و این نامه ها را به دوستان خود داد و گفت این نامه ها را به مقصد برسانید به این صورت که اگر مقصد را می شناسید برسانید بدستشان و اگر نمیشناسید بدهید به دوست دیگرتون که فکر می کنین نزدیک به آن محل هست و در انتها تمام نامه ها را جمع آوری کرد و چند نکته جالب بدست آورد اول از همه اینکه تعدادی از این نامه ها به مقصد رسیده بودند ( بدون اینکه افراد دید کاملی نسبت به گراف دوستی داشته باشند توانستند نامه را برسانند) دوم اینکه این نامه ها با ۶ بار دست به دست شدن به مقصد رسیدند و این نشان میدهد که جهان بسیار کوچک هست یعنی ما شاید با تعداد انگشت شماری واسطه بتوانیم یک پیام را به دست سناتور آمریکا برسانیم!!!! این نکته بسیار جالب هست که در عین بزرگی جهان چقدر به واسطه ارتباطات جهان کوچک شده است. این نکته هم حائزه اهمیت هست که هر کسی شاید ۱۰۰ دوست یا حداکثر ۵۰۰ دوست داشته باشد و این میزان درجه بسیار گم هست در تعداد کل آدم های موجود در کره زمیناگر گراف ما یک گراف واقعی باشد یکی از ویژگی‌های جالبی که در آن شکل میگرد سرچ کردن و جستجو کردن در گراف است . در گراف های عادی ما زمانی که دنبال یک راس میگردیم از الگوریتم های کلاسیکی استفاده می کنیم مانند BFS یا DFS اما این مدل گشتن در گراف ها بسیار زمان بر هست و ما بدون توجه به ویژگی های گراف این الگوریتم ها را اجرا می کنیم تا به جواب برسیم در اصل این الگوریتم ها همواره جواب را پیدا می کنند و شما می توانید هر مدل گرافی را به آنها بدهید اما الگوریتم سرچ کردن در گراف های واقعی بسیار متفاوت هست و اصلا با مدل کلاسیک جلو نمیروند الگوریتم هایی که مطرح شدند دو مدل هستند مدلی که ما مدنظر داریم decentral search هستش این مدل سرچ به این منظور هستش که شما بدون داشتن دانشی درباره کل گراف از یک راس رندم شروع می کنین و سعی می کنید به گره هدف نزدیک تر شوید چون میدانیم قطر گراف مضربی از log(n) می باشد پس انتظار میرود اگر خوب حرکت کنیم به log(n) ما به مقصد خود برسیم. درباره این مدل سرچ چندین مدل بیان شده است شاید بتوانیم بگویم الگوریتم page rank به نوعی برپایه این مدل الگوریتم ها سوار هست. این الگوریتم ها هزینه جستجو در شبکه را به شدت کاهش داده اند و سرعت پاسخ را بیشتر کرده اند.کاربردهای علم شبکه؟کاربرد های این علم بسیار زیاد هست. علمی بسیار به روز هست زیرا در قدیم ابزار های تحلیل این شبکه ها وجود نداشت. و حتی می‌توان گفت این مدل شبکه‌ها بیشتر بعد از به ظهور آمدن شبکه‌های اجتماعی به بلوغ خود رسیده‌است. کاربرد های که می توان برای این علم نام برد به شرح زیر هست:تحلیل ترافیک:می توانیم تمام مسیرهای موجود در شهر تهران را به عنوان ساختار گراف به عنوان ورودی مدنظر داشته باشیم و سعی کنیم تقاطع‌های(راس های گراف) که از نظر ضریب بینی بیشترین مقدار را دارند کاهش بدهیم تا ترافیک در یک نقطه از شهر قفل نشود. یعنی در فاز توسعه شهری کاری بکنیم که این نقاط کمتر شوند. یا حتی ما می توانیم موج حرکت ترافیک را بررسی کنیم و پیش بینی نسبت به وضعیت آینده گراف داشته باشیم که ترافیک در آینده به چه صورت خواهد شد و پیشاپیش پلیس به آن محل ها ارسال کنیم تا بتوانیم از بروز تصادف در آن محل ها جلوگیری کنیم.تحلیل شبکه برق رسانی کشور:این شبکه یک شبکه زنده هست و بسیار برای ما مهم هست که نقاطی که مصرف بالایی دارند را شناسایی کنیم و بررسی کنیم یک موقع شبکه در آن نقاط دچار خرابی نشده باشد و اگر این اتفاق افتاده است آن بخش از گراف را جدا کنیم تا خرابی به کل شبکه وارد نشودتحلیل شبکه توزیع یک محصول:این مسئله بسیار شبیه مسئله فروشنده دورگرد می باشد البته با این تفاوت که ما چند فروشنده دورگرد داریم که انتظار داریم اجتماع فروشنده‌های دورگرد بتواند تمام مغازه‌های سطح شهر را بروند با کمترین زمان و مسافت طی شونده. این مسئله بسیار از نظر سوددهی مالی مهم هست و بیشتر شرکت‌های موجود در ایران نیازمند این مدل سیستم‌ها می باشند تا هزینه های انتقال کالای آنها کاهش پیدا کند.سیستم پیشنهادی :این کاربرد علم شبکه بسیار جنجال برانگیز است شما فرض کنید رئیس شرکت دیجیکالا هستید و تمام خرید‌های یک نفر به نام A را دارید و خریدهای بقیه افراد را هم دارید شما می توانید یک گراف ایجاد کنید به این صورت که افرادی که کالای مشترکی تا به حال خرید کردند به هم دیگر یال داشته باشند فرض کنید فرض A تور ماهی گیری خریده و فرد B هم همینطور در این صورت یک یال ما از A به B وصل می کنیم. این گراف که ما الان ایجاد کردیم را می توانیم تحلیل های ویژه ای را انجام دهیم و خرید یا نیاز آتی مشتری ها را متوجه شویم و به آنها از جلوتر پیشنهاد بدهیم. به این صورت که اگر ما الگوریتم community را بر این گراف اعمال کنیم می توانیم به افراد داخل یک گروه پیشنهاد های مشابه با افراد دیگر گروه را بدهیم یا خرید هایی که در یک گروه زیاد انجام شده است را به بقیه افراد داخل گروه که آن وسیله را نخریده اند پیشنهاد بدهیم. با این کار فروش ما به شدت زیاد می شود. البته ما می توانیم موج نیاز‌های جدید مردم یک کشور را هم در این مدل گراف ها تحلیل کنیم و به نتایج جالبی برسیم به عنوان مثال ما اگر ببینیم خرید لپ تاب افزایش پیدا کرده است می توانیم بگویم که در آینده نیاز به خرید هارد یا حافظه زیاد خواهد شد پس ما به عنوان تامین کننده به سراغ وارد کردن حافظه به ایران خواهیم رفت زیرا موج حرکت خرید مردم را تشخیص داده‌ایم.مانند کاربرد های بالا بسیار می توانیم نام ببریم در صنایع نظامی و مخابراتی می توانیم نام ببریم تا صنایع غذایی و دارویی همان طور که معلوم است این یک علمی کاربردی در تمامی رشته ها هست حتی ما می توانیم در روانشناسی هم این علم را استفاده کنیم و ارتباط خصوصیات اخلاقی یک شخص را ویژگی های فردی هر شخص مقایسه کنیم و یک گراف تشکیل دهیم و یک سری دوست به هم دیگر معرفی کنیم که از نظر ساختار روانی بسیار باهم متشابه هستند و یکدیگر را درک می کنند.ابزارهای مناسب برای تحلیل شبکه؟چندین ابزار برای تحلیل شبکه ها وجود دارد اما هنوز این ابزار‌ها دربرابر گراف‌های بزرگ مقاوم نیستند و بسیار کند عمل می کنند پیشنهاد من این هست که حتما برای تحلیل شبکه‌های خود از یک برنامه نویس که مسلط به زبان برنامه نویسی پایتون هست استفاده نمایید. بهترین کتابخانه موجود در این زبان هم networkx نام دارد.این کتابخانه تقریبا تمام الگوریتم های موجود که شما مورد نیازتان باشد را در دل خود پیاده سازی کرده‌است و شما می توانید به راحتی از آن استفاده نمایید.نرم افزار gephi بسیار جالب هست برای بحث نمایش دادن گراف و نمایش نموداری این نرم افزار opensource هست و شما می توانید به راحتی آن را ادامه بدهید با زبان برنامه نویسی java هم این برنامه توسعه یافته است. شما به کمک این نرم افزار می توانید گراف خود را به نمایش بگذارید و از ابزار‌های اولیه که در نرم افزار قرارداده شده است استفاده کنید و در ادامه در صورت نیاز این نرم افزار را توسعه بدهید. البته این نرم افزار برای گراف های بزرگ و نمایش آن اصلا مطلوب نیست و بسیار به مشکل می‌خورد. فرمت فایل های خروجی برای گفی:CSVPAJEK NETGUESS GDFGEXF(Graph Exchange XML Format)GRAPHMLEXCEL SPREADSHEETSVGPDFPNGابزار دیگری که می توانیم نام ببریم نرم افزار cytoscape هستش این نرم افزار نسبت به دو نرم افزار دیگر از اهمیت کمتری برخوردار هستش. و بهتر هست برای ترسیم شبکه بین پروتئین ها و یا ژن ها استفاده کنید. این نرم افزار هم opensurce هست و قابلیت توسعه برای شما دارد.اگرچه Cytoscape در ابتدا برای تحقیقات بیولوژیکی طراحی شده بود، اما اکنون یک پلت فرم کلی برای تجزیه و تحلیل شبکه پیچیده و تجسم و نمایش گراف ها است. این نرم افزار در بخش توسعه یک ویژگی جالبی که قرار داده است ویژگی open API هست. این ویژگی باعث می شود شما نرم افزار خود را توسعه بدهید و در انتها از طریق API این دو نرم افزار را به یکدیگر متصل کنید به طور معمول این ویژگی را در نرم افزارها قرار میدهند تا اتصال بین ماژول‌ها بهتر شود.کاربردهای نوین علم شبکه چیست؟می توانیم بگویم علم شبکه یک علمی هست که در تمام رشته‌ها کاربرد منحصر به فرد خود را دارد. به عنوان مثال رشته محیط زیست را مدنظر داشته باشید شما می توانید یک گراف تشکیل بدهید از تمام موجودات و خوراک آنها نحوه تشکیل گراف به این صورت هست که اگر یک حیوانی غذای حیوان دیگر هست بین این دو یک یال جهت دار قرار میدهیم و در این گراف می توانیم گیاهان و انواع پوشش گیاهی را به عنوان یک راس در گراف اضافه کنیم و اگر خوراک حیوان خاصتی هستند یک یال بین گیاه و حیوان مورد نظرمان رسم کنیم. (این گراف به نوعی چرخه حیات موجود در جهان هست) چندین تحلیل می توانیم از دل این گراف بیرون بیاوریم به عنوان مثال فرض کنین ما به عنوان یک شخص دوستدار محیط زیست هستیم و دوست داریم این شبکه تقویت بشود و دربرابر حوادث محیط زیستی مقاوم باشد به عنوان مثال اگر پوشش گیاهی به دلیل تغییر اقلیم تخریب شد حیوانات و حیات وحش به مشکل نخورند و غذایی جایگزین داشته باشند. پس ما باید این گراف را تحلیل کنیم به عنوان مثال سعی می کنیم راسی را که درجه بالایی دارد را حفاظت بیشتری انجام دهیم چون جان بسیاری از حیوانات به آن راس وابسته است. اینگونه تحلیل ها بسیار پرکاربرد شده است.حتی می توان گفت در رشته اقتصاد کاربرد های این علم بسیار زیاد هست شما می توانید یک گراف بین تولید کنندگان و مصرف کنندگان و مواد اولیه شکل دهید و اگر شما یک شرکت تولیدی هستید سعی کنید مواد اولیه را از چندجای مختلف تهیه کنید تا در صورت بروز مشکل بتوانید شرکت خود را اداره کنین و به مشکل نخورید.کاربردهای هوش مصنوعی در علم شبکه:یکی از کاربرد های اصلی هوش مصنوعی این هست که ما یک مدلی از شبکه ایجاد کنیم یعنی یک مدلی که رفتاری مشابه با گراف اصلی باشد امّا خود گراف نباشد. برای اینکه این موضوع را بهتر متوجه شوید بزارید چند روش مدلینگ پایه را توضیح بدهم تا سختی کار را متوجه شوید. در سال ۱۹۶۰ دانشمندی به نام Erdos مدلی ارائه دادند که در این مدل تعداد روس گراف برابر با گراف اصلی هست و هر یالی به احتمال p وجود دارد یا وجود ندارد شاید می توانیم بگویم این گراف یک گراف رندم هست و خواص گراف های رندم را در دل خود دارد. بعدها که ویژگی های گراف های واقعی مطرح شد متوجه نواقص این مدل شدند و مدل watts-strogatz مطرح شد در این مدل ویژگی small-word اضافه شد و گرافی جدید ایجاد که کمی بحث کردن راجب این مدل گراف از حوصله این مطلب خارج هست لذا پیشنهاد می کنم لینک ساخت گراف را مشاهده کنید اگر علاقه‌مند هستید. این مدل یک p و یک n که نماد تعداد راس‌های گراف هست را نمایش میدهد. این مدل هم مشکلاتی داشت به عنوان مثال برای شبکه instagram اصلا خوب نبود زیرا در گراف اینستاگرام یک سری از راس ها هستند که درجه بسیار زیادی دارند ولی بقیه راس ها درجه کمی دارند و این اصلا مدل مطلوبی نیست برای این مدل گراف های واقعی لذا مدل جدیدی ظهور کرد به نام Barabási–Albert این مدل خاصیت ایجاد راس های با مرکزیت بالا را ایجاد کرد در دل خودش و نحوه ساخت این مدل گراف کمی پیچیده هست که در لینک قبلی توضیح داده شده است. این مدل یکی از مشکلات جدی که دارد این هست که اگر تعداد راس‌ها بسیار زیاد باشد ممکن هست زمان زیادی طول بکشد تا گراف ساخته شود و بسیار کند هست. زیرا به صورت بازگشتی و مرحله ای گراف ساخته می شود. لذا پس از این مدل های دیگری نیز ظهور کردند که ویژگی‌های دیگر شبکه‌های واقعی را مدنظر گرفتند به عنوان مثال شما فرض کنین گراف موجود بین مولکول یخ را می خواهید مدل کنین اگر دیده باشید این مدل گراف ها یک ساختار تکرار شوندگی دارند یعنی اگر یک دونه برف را در زیر میکروسکوپ مشاهده کنیم مانند یک ستاره می بینم و اگر بیشتر زوم کنیم همین مدل را خواهیم دید به عبارت بهتر می توانیم بگویم یک ساختار گرافی در حال تکرار هست در کل گراف و به نوعی زیر گراف‌ها ساختاری شبیه به گراف بزرگتر را دارند یا مثال بهتری بخواهیم بزنیم اگر گراف اینستاگرام را به صورت جهانی بررسی کنیم تعدادی از افراد هستند که influencer instagram هستند و اگر ما گراف را کوچکتر بکنیم و فقط زیر گراف ایران را هم بررسی کنیم تعدادی از افراد influencer instagram هستند و این نشان میدهد که یک ساختار یا یک مدل ویژگی در حال تکرار شدن می باشد. این ویژگی را به اصطلاح می گویند خاصیت Fractal. این ویژگی در گراف های قبلی وجود نداشت البته نکته دیگری که در مدل های قبلی وجود نداشته این هست که یک یالی از بین برود یا به مرور زمان حذف شود یعنی ما این رفتار را زیاد در شبکه‌های اجتماعی می بینیم به عنوان مثال شما در اینستاگرام یک نفر را unfollow می کنین این یعنی یال بین شما دو نفر حذف شده است. این ویژگی طول عمر برای یال ها هم در مدل های قبلی توضیح داده نشده اند. لذا مدل‌ها به مرور زمان پیچیده‌تر شدند و ویژگی های بیشتری را تحت پوشش قرار دادند به عنوان مثال مدل copying model ایجاد شدند که ویژگی community را در گراف‌ها ایجاد کرده است و مدل بعدی که آمده است forest fire ایجاد شد که این ویژگی بسیار آپدیت شدند در آن مطرح هست و اینکه طول عمر رشد یک گراف را مدنظر دارد به این صورت که قطر گراف در این مدل گراف به مرور زمان کاهش پیدا می کند. بعد از این مدل Kronecker مطرح شده که این مدل ویژگی fractal را بسیار مورد نظر قرار داده است البته این مدل مشکلات خاص خود دارد به عنوان مثال شما فقط گراف هایی می توانید بسازید که تعداد راس‌های موجود در آن توانی از ۲ باشد تا الگوریتم آن کار کند. این مدل کمی پیچیدگی های ریاضی هم دارد که پیشنهاد می کنم در مورد آن سرچ کنین و مطالب مرتبط به آن را پیدا کنید. با توجه به تمام این مدل هایی که بیان شدند در سال های بعد مدل‌هایی آمدند که ترکیبی از مدل‌های گفته شده بودند و ضرایب مخلوط کردن این مدل ها بسیار مرحله مدل کردن را پیچیده کرده بود و این پیچیدگی به مرور زیادتر از حالات عادی شد و حتی رگرسیون خطی هم برای تنظیم این ضرایب جوابگو نبود. بعد از این رویکرد جدیدی شکل گرفت که هوش مصنوعی را وارد مبحث مدلینگ کرد. برای این موضوع یک پارامتر تعریف شد به که بیان میکرد چقدر دو گراف از نظر ویژگی نسبت به هم شبیه هم هستند و چقدر این دو گراف از هم دیگر فاصله دارند یک شبکه عصبی ساخته می شد که کارش ایجاد گرافی بود که کمترین فاصله را با گراف اصلی ایجاد کند اما برای این مدل هم ما باید ویژگی های گراف را استخراج می کردیم اما بعد از این با به وجود آمدن deep learning دیگر ما ویژگی های گراف را معلوم نمی کردیم بلکه صرفا گراف را به عنوان ورودی به برنامه میدادیم و هوش مصنوعی ما یک گرافی مشابه گراف اصلی برای ما ایجاد میکرد و کار بسیار راحت تر از قبل شد و به طور کلی دیگر مدل های گذشته منسوخ شدند و جدیدتر ها از این مدل استفاده می شود.چند مثال از کاربردهای نوین شبکه های پیچیدهدر بیماری واگیردار covid کاربردهای بسیار مهمی از شبکه پیچیده پویا رو نمایی شد به عنوان مثال ما می توانسیم موج‌های جدید کرونا را پیش‌بینی کنیم و هشدارها لازم را به عموم مردم بدهیم. زیرا در تحلیل گراف ما می توانیم سیر حرکت و پخش شدن ویروس را شناسایی کنیم و بدانیم سرعت حرکت آن به چه صورت هست تا بدانیم در آینده این ویروس به کدام سمت از گراف حرکت خواهد کرد. به عنوان مثال شما گرافی وزن دار را تصور نمایید که هر راس برابر هست با یکی از محلات موجود در ایران و یال بین راس ها جاده های بین شهری را مدنظر داشته باشد و وزن هر یال برابر مقدار فاصله بین دو شهر باشد. حال اگر ویروس در یک محله رویت شود و در زمان بعدی در محلات اطراف دیده شود می توانیم سرعت شیوع بیماری را بدست بیاوریم و متوجه بشویم در گام بعدی این ویروس به کدام سمت و چه زمانی به هر راسی از گراف خواهد رسید و پیشاپیش عملیات‌های پیش‌گیری را در آن محله‌ها افزایش بدهیم. این نکته بسیار حائز اهمیت هست.یکی از کاربرد های مدرن این شبکه پیچیده پویا این هست که ما می توانیم گراف پروتئین موجود در یک ویروس را شناسایی کنیم و نقاط ضعف این پروتئین را شناسایی کنیم. به عنوان مثال فرض کنین ما ویروس covid-19 را بررسی می کنیم و گراف ساختار داخلی آن را ایجاد می کنیم اگر ما بتوانیم راس هایی که در این گراف خاصیت ضریب بینی (betweenness) که در بندهای قبلی توضیح داده‌ام را پیدا کنیم و سعی کنیم این ویروس را در این نقاط شکست بدهیم بسیار نکته جالبی می شود به عبارت بهتر یک دارو یا واکسنی تولید بکنیم که مقاومت شبکه ویروس را کاهش بدهد تا ویروس توان درگیر کردن سیستم دفاعی بدن را نداشته باشد.شاید خالی از لطف نباشد که این مثال را هم بزنم برای تحلیل اتفاقات روز همانطور که میدانید تحریم های آمریکا به مرور زمان سخت تر از قبل شده است شاید جالب باشه بدانید که در این موضوع هم شبکه پیچیده پویا بسیار حائز اهمیت هست شما فرض کنید یک کشور ایران را به عنوان یک راس داشته باشید و ما یک گراف ایجاد می کنیم از شبکه توضیع و تامین کالاهای هر کشور و صادرات و واردات هر کشور و مشتری‌های موجود هر کالا و فروشندگان هر کالا را در سطح جهانی داشته باشیم. با ایجاد این گراف ما به راحتی حرکت پول را می توانیم مشاهده کنیم و برای ادامه جلوی رشد یک کشور را بگیرم و یا یک کشور را رشد بدهیم. به عنوان مثال ما یال های خروجی کشور ایران را پیدا می کنیم و مسیر حرکت پول را معلوم میکنیم و راسی که در این مسیر از مقاومت کمتری برخوردار باشد را تحریم میکنیم و یا ترور می کنیم تا مسیر حرکت پول به سمت کشور ایران کند تر شود. در اصل ما بسیار هوشمندانه عمل کردیم یک شخص کلیدی را از گراف حرکت پول حذف کردیم که درآمد ایران را مختل کرده است از طرف دیگر ایران باید برعکس این کار را انجام دهد به عنوان مثال اگر وارد کننده گندم کشور دست یک نفر هست خوب هست که ما چندین تامین کننده مختلف ایجاد کنیم تا زیر گراف تامین گندم ما مقاوم شود دربرابر حمله و هزینه حمله به این زیر گراف را افزایش بدهیم زیرا آمریکا باید چندین یال را قطع کند و یا چندین نفر را ترور کند تا زنجیره تامین ایران قطع شود. شاید اینجا می توانیم بگویم که اقتصاد مقاومتی اگر معنی این را دارد که ما خودکفای کامل بشویم بسیار کار اشتباه است و ما باید سعی کنیم راسی موثر در گراف باشیم تا اگر ما حذف بشویم زنجیره تامین چندین کشور به مشکل بخورد. علیرضا صفافرد علیرضا صفافرد Sat, 20 May 2023 22:26:23 +0330