<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های amirasali1997</title>
        <link>https://virgool.io/feed/@amirasali1997</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-06-17 11:03:05</pubDate>
        <image>
            <url>https://static.virgool.io/images/default-avatar.jpg</url>
            <title>amirasali1997</title>
            <link>https://virgool.io/@amirasali1997</link>
        </image>

                    <item>
                <title>معماری نرم افزار در سیستم های کلان داده (BigData)</title>
                <link>https://virgool.io/@amirasali1997/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%D8%B1-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7%DB%8C-big-data-tbzuijpp1qug</link>
                <description>کلان داده (Big Data)  به حجم عظیمی از داده های ساختاریافته، نیمه ساختاریافته و حتی بدون ساختار اشاره دارد که میتواند توسط منابع مختلفی مانند رسانه های اجتماعی، تراکنش های آنلاین و دستگاه های مبتنی بر حسگر تولید شوند. این داده ها بیش از حد بزرگ و پیچیده هستند و نمی توان آنها را با استفاده از تکنیک های مدیریت و پردازش سنتی داده ها پردازش و تجزیه و تحلیل کرد. در نتیجه، سازمان ها برای مدیریت، ذخیره سازی، پردازش و تجزیه و تحلیل این داده ها به سیستم های تخصصی Big Data روی می آورند.    سیستم‌های کلان داده برای رسیدگی به مقیاس و پیچیدگی عظیم داده‌های بزرگ و ارائه پردازش و تحلیل سریع و کارآمد طراحی شده‌اند. این سیستم ها معمولاً از ترکیبی از فناوری های ذخیره سازی و پردازش توزیع شده مانند Hadoop و Spark برای توزیع داده‌ها و اجرای وظایف پردازش در چندین ماشین استفاده می کنند. همچنین از الگوریتم ها و تکنیک های تخصصی مانند MapReduce و یادگیری ماشینی برای پردازش و تجزیه و تحلیل داده‌ها نیز، در این سیستم ها استفاده میشود.نمونه ای اجزای پردازش و ذخیره سازی دریک سیستم  کلان داده    هدف معماری نرم‌افزار داده‌های بزرگ، ارائه چارچوبی مقیاس‌پذیر و انعطاف‌پذیر برای مدیریت حجم زیادی از داده‌ها در قالب‌های مختلف، و امکان پردازش و تحلیل کارآمد و مؤثر آن داده‌ها است.چند مؤلفه کلیدی که باید در معماری نرم افزار کلان داده به آنها توجه شود:۱- ذخیره سازی داده ها: این مؤلفه وظیفه ذخیره و مدیریت حجم زیادی از داده ها را در قالب های مختلف از جمله داده های ساختار یافته، نیمه ساختاریافته و بدون ساختار بر عهده دارد. نمونه‌هایی از راه‌حل‌های ذخیره‌سازی داده برای داده‌های بزرگ عبارتند از Hadoop HDFS، پایگاه‌های داده NoSQL و راه‌حل‌های ذخیره‌سازی داده مبتنی بر ابر.۲- پردازش داده ها: این مؤلفه وظیفه پردازش و تجزیه و تحلیل حجم زیادی از داده ها را در زمان واقعی یا تقریباً واقعی بر عهده دارد. نمونه هایی از چارچوب های پردازش داده برای داده های بزرگ عبارتند از Apache Spark، Apache Flink و Apache Storm.۳- تجزیه و تحلیل داده ها: این جزء مسئول انجام وظایف پیچیده تجزیه و تحلیل داده ها، مانند یادگیری ماشین، تجزیه و تحلیل پیش بینی و تجسم داده ها است. نمونه هایی از ابزارهای تجزیه و تحلیل داده برای داده های بزرگ عبارتند از Apache Mahout، Apache Hadoop MapReduce و Apache Spark MLlib.۴- حاکمیت داده (Data Governance): این مؤلفه مسئول مدیریت چرخه عمر داده ها، از ابتدا تا بایگانی است. این مولفه همچنین مسئول کیفیت داده، مدیریت متادیتا و امنیت داده ها نیز میباشد.ویژگی های کیفی  دو مسئله مهم که در سیستم های کلان داده مورد توجه است یکی آسانی مدیریت پردازش و ذخیره سازی و دیگری توانایی گسترش است. همچنین مهم است که تأثیر معماری بر سیستم کلی و همچنین هرگونه خطرات احتمالی یا ملاحظات امنیتی در این طراحی در نظر گرفته شود. طراحی و پیاده سازی صحیح یک معماری نرم افزار برای سیستم های کلان داده کمک میکند این سیستمابزاری ارزشمند برای پردازش و تحلیل داده ها باشد. نکته مهم در انتخاب و طراحی یک معماری نرم‌افزار مناسب  پیدا کردن ویژگی های کیفی مورد نیاز در سیستم و تمرکز بر روی آنهاست و با توجه به این دو مسئله در سیستم های کلان داده مهمترین ویژگی های کیفی را اینگونه میتوان تحلیل کرد:کارایی (performance): کارایی در سیستم های کلان داده اهمیت بالایی دارد و یکی از اهداف مهم در این سیستم با توجه به حجم عظیم داده ،سرعت پردازش و ذخیره سازی و مشاهده داده‌هاست.دسترس پذیری (availability) : با توجه به این که در اکثر سیستم های کلان داده جریان اطلاعات همواره به سمت سیستم وجود دارد و نیاز به پردازش آنها یک نیاز همیشگی است، در صورت عدم وجود قابل قبول دسترس پذیری،کل سیستم دچار مشکل میشود.مقیاس پذیری (scalability) : ویژگی کیفی مهم دیگر مقیاس پذیری است چرا که با توجه به رشد داده‌ها و نیاز به ذخیره سازی و گسترش سیستم مهم است که به این ویژگی اهمیت داده شود. نکته‌ای که در مسئله مقیاس پذیری حائز اهمیت است هزینه گسترش سیستم میباشد و طراحی معماری نرم‌افزار این سیستم ها باید بگونه‌ای باشد که در صورت نیاز به رشد نمایی ظرفیت هزینه ها به شکل خطی افزایش یابند.علاوه بر ویژگی های کیفی ذکر شده در بالا برای معماری نرم افزار سیستم های کلان داده ویژگی های انعطاف پذیری و قابلیت نگهداری نیز بسیار مهم است. این تضمین می‌کند که معماری می‌تواند حجم زیادی از داده‌های تولید شده و پردازش شده را در خود جای دهد و می‌تواند با نیازها و فناوری‌های در حال تغییر در طول زیست خود سازگار شود.    چندین رویکرد مختلف برای طراحی معماری نرم افزار برای سیستم های داده های بزرگ وجود دارد و انتخاب رویکرد به نیازهای خاص سازمان و داده های در حال پردازش بستگی دارد. در ادامه این مطلب به بررسی دو معماری معروف و کارآمد در سیستم های کلان داده و مقایسه این دو میپردازیم.معماری لامبدا (Lambda Architecture) :معماری لامبدا یک الگوی طراحی برای سیستم‌های کلان داده است که قابلیت‌های پردازش همزمان و  دسته‌ای را ارائه می‌کند.در این معماری داده‌ها را به دو جریان، یکی برای پردازش بلادرنگ و دیگری برای پردازش دسته‌ای جدا می‌شوند و سپس نتایج را ترکیب می‌کند تا دید یکپارچه‌ای از داده‌ها را ارائه دهد. این معماری به مدیریت مقیاس عظیم و پیچیدگی سیستم‌های کلان داده کمک می‌کند و پردازش با تأخیر کم و پردازش با سرعت بالا را فراهم می‌کند. معماری لامبدا برای رسیدگی به مجموعه داده های کوچک و بزرگ و همچنین برای تطبیق منابع داده جدید و نیازهای متغیر طراحی شده است. جریان داده در معماری لامبدااین معماری مشکل محاسبه توابع مختلف روی داده های دلخواه را در زمان واقعی (real time) با تجزیه مسئله به سه لایه حل می کند:  لایه دستهای (batch layer)، لایه سرویس دهنده (serving layer) و لایه سرعت  (speed layer). در این معماری مولفه پردازش بلادرنگ می تواند مجموعه داده های کوچک را مدیریت کند و نتایج سریع ارائه دهد، در حالی که جزء پردازش دسته ای می تواند مجموعه داده های بزرگ را مدیریت کند و نتایج دقیق تری ارائه دهد. داده های دریافتی برای پردازش به هر دو لایه دسته ای و لایه سرعت ارسال می شوند که آپاچی کافکا فناوری اجرای این فرآیند است. وظایف هر کدام از این لایه ها به شرح زیر است: لایه دسته ای (batch layer) شامل مجموعه داده های اصلی در حال رشد است که در یک سیستم فایل توزیع شده مانند HDFS ذخیره شده و نماهای دسته ای تولید می کند. برای پردازش داده های دسته ای از MapReduce استفاده می شود که مدل برنامه نویسیHadoop است.لایه سرویس دهنده (serving layer) کار بارگذاری و نمایش داده‌ها و نماهای دسته‌ای را بر روی یک مخزن داده بر عهده دارد، که در آنجا بتوان اطلاعات را جستجو کرد و روی آنها پرس و جو انجام داد . این ذخیره‌سازی داده لایه سرویس‌دهنده نیازی به نوشتن تصادفی ندارد، اما باید به‌روزرسانی‌های دسته‌ای و خواندن تصادفی را پشتیبانی کند و بنابراین می‌تواند فوق‌العاده ساده باشد. آخرین لایه، لایه سرعت (speed layer) است که فقط با داده های جدید سروکار دارد و به روز رسانی های با تاخیر بالا در لایه سرویس دهنده را جبران می کند. در این لایه از سیستم پردازش جریانی مانند Storm استفاده می‌شود که با داده های اخیر، فقط برای محاسبه نماهای زمان واقعی سروکار دارد. این نماهای محاسبه‌شده تا زمانی که داده‌ها راه خود را از طریق لایه دسته‌ای و سرویس‌دهی پیدا نکنند، باقی می‌مانند.معماری لامبدا را می توان با استفاده از ابزارها و فناوری های مختلفی پیاده سازی کرد، از جمله:سیستم های ذخیره سازی توزیع شده داده ها مانند Apache Cassandra، Apache HBase .فریمورک‌های پردازش جریان مانند Apache Kafka, Apache Flink, and Apache Spark Streaming.فریمورک‌های پردازش دسته ای مانند Apache Hadoop MapReduce و Apache Spark.نمایه سازی و موتورهای جستجو مانند Apache Solr و Elasticsearch.نمایه سازی و موتورهای جستجو مانند Apache Solr و Elasticsearch.بزارهای پردازش و تبدیل داده مانند Apache Pig و Apache Hive.ابزارهای پرس و جو و تجسم مانند Apache Drill و Tableau.این ابزارها را می توان به روش های مختلف ترکیب و پیکربندی کرد تا یک سیستم معماری لامبدا بسازد که الزامات خاصی را برآورده کند.معماری لامبدا به طور گسترده در حوزه های مختلفی مانند خدمات مالی، تجارت الکترونیک و تبلیغات آنلاین استفاده می شود. این معماری یک انتخاب محبوب برای ساخت سیستم های داده های بزرگ مقیاس پذیر و انعطاف پذیر است که می تواند انواع موارد استفاده و نیازهای متغیر را مدیریت کند. این معماری از توابع لایه دسته ای و لایه جریان استفاده می کند و همچنان داده های جدید را به حافظه اصلی اضافه می کند و در عین حال اطمینان می دهد که داده های موجود دست نخورده باقی می مانند. شرکت هایی مانند توییتر، نتفلیکس و یاهو از این معماری برای رعایت استانداردهای کیفیت خدمات استفاده می کنند.معماری کاپا (Kappa Architecture)معماری کاپا نیز یک الگوی طراحی برای ساخت سیستم های پردازش داده است که بر سادگی و مقیاس پذیری تمرکز دارد و به طور خاص برای مدیریت حجم بالایی از داده هایی که به شکل سریع تولید میشوند (مانند سیستم های تراکنش های بانکی)، طراحی شده است. در یک سیستم معماری کاپا، تمام داده ها به عنوان یک جریان پردازش می شوند و در یک سیستم ذخیره سازی بادوام و توزیع شده مانند آپاچی کافکا ذخیره می شوند. این سبک از ذخیر سازی امکان پردازش داده ها با  تاخیر بسیار کم را فراهم می کند و نیاز به لایه پردازش دسته ای جداگانه را از بین می برد و برای جایگزینی پردازش دسته ای، داده ها صرفاً از طریق سیستم جریان به سرعت منتقل می شوندجریان داده در معماری کاپا     یکی شدن لایه دسته ای و لایه جریان با استفاده از ترکیبی از نرم افزارها و اجزای مورد نیاز برای ساخت و اجرای سیستم ذخیره سازی و پردازش کلان داده می شود که بزرگترین مزیت معماری کاپا است. این معماری برای پردازش داده های بلادرنگ مانند داشبوردهای بلادرنگ(real time) و یا KPI ها (معیارهایی که برای اندازه گیری عملکرد یک کسب و کار، پروژه یا فرد در برابر اهداف و اهداف خاص استفاده می شود)، نظارت و... بسیار مناسب است.        ایده اصلی پشت معماری کاپا در سیستم‌های کلان داده، ارائه جایگزین ساده‌تر و کارآمدتر برای معماری لامبدا بود و مانند معماری لامبدا، معماری کاپا راه حلی مقیاس پذیر، مقاوم در برابر خطا، و قابلیت پردازش داده های بزرگ ارائه می دهد. همچنین این دو معماری از پشته فناوری (ترکیبی از نرم افزارها و اجزای مختلف فناوری که برای ساخت و اجرای یک برنامه نرم افزاری یا یک سیستم استفاده می شود.) یکسانی برای رسیدگی به پردازش جریان بی‌درنگ و پردازش دسته‌ای تاریخی استفاده می‌کنند.  با این حال، معماری کاپا اغلب به عنوان یک رویکرد ساده تر و کارآمدتر در نظر گرفته می شود، زیرا همان طور که گفته شد نیاز به سیستم های پردازش دسته ای و جریانی جداگانه را از بین میبرد.برخی از انواع برنامه های شبکه های اجتماعی، دستگاه های متصل به سیستم مانیتورینگ مبتنی بر ابر و اینترنت اشیا (IoT) از نسخه بهینه سازی شده معماری لامبدا استفاده می کنند که عمدتاً از خدمات لایه سرعت ترکیب شده با لایه جریان برای پردازش داده ها بر روی دریاچه داده (data lake) استفاده می کنند که به معماری کاپا نزدیک اند.مقایسه دو معماریمعماری لامبدا راه حلی جامع برای پردازش دسته ای و در زمان واقعی برای حجم زیادی از داده ها ارائه می دهد و برای سازمان هایی که نیاز به پردازش داده های تاریخی و فعلی دارند، مناسب است. معماری لامبدا همچنین برای سازمان هایی که به انعطاف پذیری و مقیاس پذیری بالایی در سیستم های پردازش داده خود نیاز دارند نیز میتواند بکار گرفته شود.    از سوی دیگر، معماری کاپا برای ساده سازی پردازش داده های سریع با استفاده از یک خط لوله واحد و یکپارچه در زمان واقعی طراحی شده است. این معماری برای سازمان‌هایی که نیاز به پردازش با تأخیر کم و پردازش رویداد محور داده‌ها دارند، و همچنین برای سازمان‌هایی که سادگی و کارایی را در سیستم‌های پردازش داده‌شان در اولویت قرار می‌دهند، مناسب است.    در نهایت، انتخاب بین معماری کاپا و معماری لامبدا به الزامات و اهداف خاص یک سازمان بستگی دارد. هر دو معماری راه‌حل‌های مقیاس‌پذیر و کارآمدی را برای پردازش داده‌های بزرگ ارائه می‌کنند، اما آنها از دیدگاه‌های متفاوتی به مسئله نزدیک می‌شوند و ممکن است هر کدامبرای موارد استفاده مختلف مناسب‌تر باشند.نتیجه گیریمعماری نرم‌افزاری سیستم‌های کلان داده یک جنبه حیاتی برای مدیریت و پردازش موثر مقادیر زیاد داده است. یک معماری نرم‌افزاری که به خوبی طراحی شده باشد باید مقیاس‌پذیری، عملکرد و قابلیت نگهداری را برای مواجهه با حجم کثیر داده‌ای که تولید و پردازش میشود دارا باشد. همچنین همانطور که گفته شد هزینه هایی این فناوری ها و نرم افزار ها با خود همراه دارند و هزینه هایی که برای گسترش طولی و عرضی سیستم مورد نیاز است را برای ذینفعان پروژه پایین نگه دارد، در نتیجه انتخاب یک معماری نرم افزار مناسب بسیار با توجه با کاربری سیستم حائز اهمیت است.منابع:Avci, C., Tekinerdogan, B. &amp; Athanasiadis, I.N. Software architectures for big data: a systematic literature review. Big Data Anal 5, 5 (2020). https://doi.org/10.1186/s41044-020-00045-1Architecting for Scale: High Availability for Your Growing Applications (Lee Atchison)J. Lin, &quot;The Lambda and the Kappa,&quot; in IEEE Internet Computing, vol. 21, no. 5, pp. 60-66, 2017, doi: 10.1109/MIC.2017.3481351.Hasani, Zirije, Margita Kon-Popovska and Goran Velinov. “Lambda Architecture for Real Time Big Data Analytic.” (2014).Feick, M., Kleer, N. &amp; Kohn, M., (2018). Fundamentals of Real-Time Data Processing Architectures Lambda and Kappa. In: Becker, M. (Hrsg.), SKILL 2018 - Studierendenkonferenz Informatik. Bonn: Gesellschaft für Informatik e.V.. (S. 55-66).Software Architecture for Big Data Systems, Software Engineering Institute | Carnegie Mellon University  discussionhttps://towardsdatascience.com/a-brief-introduction-to-two-data-processing-architectures-lambda-and-kappa-for-big-data-4f35c28005bbhttps://hazelcast.com/glossary/lambda-architecture/این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.</description>
                <category>amirasali1997</category>
                <author>amirasali1997</author>
                <pubDate>Fri, 10 Feb 2023 23:51:45 +0330</pubDate>
            </item>
                    <item>
                <title>بررسی چند مفهوم در معماری نرم افزار</title>
                <link>https://virgool.io/@amirasali1997/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%DA%86%D9%86%D8%AF-%D9%85%D9%81%D9%87%D9%88%D9%85-%D8%AF%D8%B1-%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-oxfs2yjf5d2h</link>
                <description>Domain Driven Design&quot;طراحی دامنه محور” یکی از رویکردهای اصلی در طراحی نرم افزار است. بطور کلی هدف این رویکرد این است که ساختار و زبان کد یک نرم افزار، باید با حوزه کسب و کار آن مطابقت داشته باشد. بعنوان مثال اگر در زبان کسب و کار نرم افزار عبارتی مانند مشتری (customer) داریم در ساختار کد هم چنین کلاسی داشته باشیم. این مسیله باعث به وجود آمدن یک زبان مشترک بین توسعه دهندگان و ذی نفع های پروژه نیز میشود که از یکی از نیاز های مهم یک پروژه نرم افزاری است.    برای درک بهتر نیاز است بدانیم domain به چه معناست. در اینجا دامنه (domain) به معنای حوضهای است که نرم افزار بر پایه آن در حال ساخت است. این معماری به ما کمک میکند تا بتوانیم بخش های مختلف نرم افزار (context) را از هم جدا کنیم (bounded context بسازیم) و بتوانیم این bounded context ها را به هم ارتباط دهیم ؛‌ به همین جهت این معماری بیشتر برای نرم افزار های بزرگ استفاده میشود و استفاده از آن برای نرم افزارهای کوچک توجیهی ندارد.منابع :http://www.atriya.com/Blog/ArticleDetails/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-domain-driven-designhttps://towardsdatascience.com/what-is-domain-driven-design-5ea1e98285e4#:~:text=An%20aggregate%20is%20a%20domain,wheels%2C%20lights%20and%20an%20engine.https://en.wikipedia.org/wiki/Domain-driven_designMVVMیک الگوی معماری (architectural pattern) در معماری نرم افزار است که نرم افزار را به سه بخش model , view و view model تقسیم میکند. در این الگو model مرکز دیتا و نگه داری کننده اطلاعات نرم افزار است.ویو (view) در واقع بخش رابط کابری است و ذخیره اطلاعات و منطق نرم افزار در آن جایی ندارد. ViewModel در واقع رابط بین دو بخش view و model است، ViewModel وظیفه تغییر شکل داده ها و انتقال داده ها به شکلی که در view قابل نشان دادن باشد را دارد و میتواند view را آپدیت کند. همچنین ViewModel میتواند اطلاعات را از view بگیرد و به شکل درست به  model انتقال دهد.ارتباط بین بخش ظاهر برنامه (view)  و منطق برنامه (model)  توسط تکنیکی به اسم Data Binding انجام میشود. با استفاده از این تکنیک دیگر برنامه نویس مجبور نیست هر اطلاعاتی که تغییر میکند را در model تغییر دهد و نیز اطلاعات تغییر یافته در مدل به شکل خودکار در view تغییر میکنند. برای مثال تغییر نام کاربری در بخش view توسط کاربر بطور خودکار در model اعمال میشود.این الگوی معماری به MVC شباهت دارد و تفوت آن با MVC در این است که در MVC مدل و ویو با هم ارتباط دارند ولی در MVVM مدل و ویو از وجود هم آگاه نیستند و ViewModel وظیفه ارتباط بین این دو را دارد.منابع:https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodelhttps://ditty.ir/posts/mvvm-pattern/XpAPJhttps://www.digitalocean.com/community/tutorials/android-mvvm-design-patternEvent Sourcingیک الگوی معماری قدرتمند است که تمام تغییرات ایجاد شده در وضعیت برنامه را به ترتیب رویداد اتفاق افتاده ثبت میکند. در اینگونه سیستم ها به جای اینکه آخرین وضعیت دیتا درون پایگاه داده ذخیره شود در این معماری همه ی رویدادها درون پایگاه داده ذخیره میشوند.به وسیله event sourcing ما میتوانیم بر روی رویداد ها پرس و جو انجام بدهیم و همچنین میتوانیم  با استفاده از این لاگ ها (رویداد های ثب شده)، حالت (state) قبلی برنامه را دوباره بسازیم (برای مواقعی که بعد از تغییرات در برنامه، برنامه به وضعیت نامطلوب و مشکل برخورد کند). نرم افزار هایی با این معماری رویداد ها را در یک مخزن رویداد (نوعی پایگاه داد) ذخیره میکنند پرس و جو ها (queries) در این گونه سیستم ها معمولا براساس زمان هستند. یک مثال رایج از برنامه‌هایی که از Event Sourcing استفاده می‌کنند، سیستم کنترل نسخه است. وضعیت فعلی آخرین کد منبع است و رویدادها کار هایی است که روی سیستم انجام شده است.منابع:https://martinfowler.com/eaaDev/EventSourcing.htmlhttps://virgool.io/@arashrahimi46/event-sourcing-%DA%86%DB%8C%D8%B3%D8%AA-cnnc6vwjqj2ohttps://medium.com/design-microservices-architecture-with-patterns/event-sourcing-pattern-in-microservices-architectures-e72bf0fc9274Micro Frontendمعماری میکروسرویس‌ در سال های اخیز محبوبیت زیادی پیدا کرده‌ است و بسیاری از سازمان‌ها از این سبک معماری استفاده می‌کنند تا از محدودیت‌های بخش backend که جاببت بزرگ  و یکپارچه پیدا میکنند اجتناب کنند.معماری Micro-frontend یک رویکرد طراحی است که در آن یک برنامه front-end به &quot;microapps&quot; منفرد و نیمه مستقل تقسیم می شود که به طور آزاد با هم کار می کنند. ایده پشت Micro Frontends این است که در مورد یک وب سایت یا برنامه وب به عنوان ترکیبی از ویژگی هایی که متعلق به تیم های مستقل است فکر کنید. هر تیم دارای حوزه مشخصی از کسب و کار یا مأموریتی است که به آن اهمیت می دهد و در آن تخصص دارد.معماری‌های Micro-frontend ساده‌تر هستند و بنابراین استدلال و مدیریت آن نیز آسان‌تر است، همچنین تیمهای توسعه مستقل میتوانند در توسعه نرم افزار front-end به آسانی با هم همکاری کنند. اگر چه در سال های اخیر micro frontend بسیار پر استفاده بوده است ولی از مشکلات این معماری میتوان به مشکلات هنگام دیپلوی کردن و تست و همچنین خود اینکه چطور برنامه را به microapp ها تقسیم کنیم اشاره کرد. منابع:https://www.toptal.com/front-end/micro-frontends-strengths-benefitshttps://micro-frontends.org/https://martinfowler.com/articles/micro-frontends.htmlLow code platforms اLow Code development platform محیطی را برای کاربران فراهم میکند که بتوانند با میزان کد کم یا بدون کدنویسی برنامه نرم افزاری را پیاده سازی کنند. این محیط بیشتر گرافیک است و حتی کسانی که میزان کم آشنایی با برنامه نویسی دارند نیز میتوانند از این محیط اسنفاده کنند و در نتیجه افراد بیشتری میتوانند در پروژه را داشته باشند. از دیگر مزایای این محیط میتوان به کاهش زمان معمول در پروسه تولید نرم افزار و کاهش هزینه تولید نرم افزار اشاره کرد.رویکردهای ماژولار کم کد و بدون کد به توسعه دهندگان حرفه ای  نیز اجازه می دهد تا به سرعت برنامه ها را با بی نیازی از نوشتن کد خط به خط، بسازند. همچنین این محیط به تحلیلگران کسب و کار، مدیران اداری، صاحبان بیزینس های کوچک و کسانی که توسعه دهنده نرم افزار نیستند نیز اجازه میدهد که در این محیط کار کنند، برنامه تولید کنند و برنامه ها را آزمایش کنند.از platform های پرطرفدار برای توسعه low-code میتوان به Appian ، Mendix ، OutSystems اشاره کرد.منابعhttps://www.trio.dev/blog/low-code-platformshttps://en.wikipedia.org/wiki/Low-code_development_platformhttps://www.techtarget.com/searchsoftwarequality/definition/low-code-no-code-development-platformESBاEnterprise Service Bus یک مدل ارتباطی و یک middleware است که به برنامه های تجاری اجازه میدهد که با هم ارتباط بر قرار کنند. بستر ESB شامل قوانین تجاری و استاندارد های رایج است. همچنین شامل پروسه و مکانیزمی است که پیام ها را از منبع به مقصد میرساند.مدل Enterprise Servise Bus با بکار گیری قوانین معماری خدمتگرا (SOA) کمک میکند که نرم افزار راحتتر پیاده سازی شود. در این مدل به شکل فرضی یک ارائه کننده خدمت و یک مصرف کننده خدمت وجود دارد که این دو به وسیله پلی به هم متصلاند. در واقع این پل ارتباطی بین مصرف کننده و ارائه دهنده ESB است. هر کدام از این برنامه ها با ESB در تماس هستند و وظایف و کارهایی مانند فراخوانی API و message formatting و ... از این طریق انجام میگیرد.مفهوم enterprise service bus  مشابه مفهوم bus در معماری سخت افزار است.  ESB به عنوان نرم افزار باید بتواند پیام های بین برنامه ها را از طریق bus خود انتقال دهد. برای دستیابی به این ESB باید عملکرد ارائه شده توسط برنامه های کاربردی اجزای خود را به روشی معنی دار محصور کند. وظایف ESB شامل مسیریابی پیام ها بین سرویس ها، نظارت و کنترل مسیریابی سرویس ها و تبادل انها با سرویس ها، مرتب کردن استفاده از سرویس های اضافه شده و ... میباشد.منابع:https://en.wikipedia.org/wiki/Enterprise_service_bushttps://www.integrate.io/glossary/what-is-esb/https://wso2.com/what-is-an-esb/API Gatewayبرای بررسی API gateway ابتدا به مفهوم API میپردازیم. API مخفف عبارت Application programming Interface و به معنی رابط برنامه نویسی اپلیکیشن است. در واقع API ها مکانیسم هایی هستند که دو جزء نرم افزار را قادر می سازند تا با استفاده از مجموعه ای از تعاریف و پروتکل ها با یکدیگر ارتباط برقرار کنند.یک  API gateway برنامه‌ ای است که در مقابل یک API قرار می‌گیرد و نقطه ورود تکی برای API های Back-end و میکروسرویس‌های تعریف شده است. دروازه API بخشی از سیستم مدیریت API است. دروازه API تمام درخواست های دریافتی را رهگیری می کند و آنها را از طریق سیستم مدیریت API ارسال می کند که انواع توابع ضروری را مدیریت می کند. به بیان ساده، دروازه API تمام درخواست‌های API را از یک کلاینت دریافت می‌کند، مشخص می‌کند که کدام خدمات مورد نیاز است، و آنها را در یک حالت یکپارچه برای کاربر محیا می‌کند.این دروازه (gateway) مسئولیت محافظت و برفراری امنیت و همچنین مسئولیت برفراری حداکثر دسترس پذیر را به عهده دارد.  در نتیجه API ها به یک ضرورت استراتژیک برای مشاغل تبدیل شده اند چرا که آنها چابکی، یکپارچگی را تسهیل می کنند و در هنگام بزرگ شدن نرم افزار آنها بسیار کمک کننده هستند.منابع:https://www.redhat.com/en/topics/api/what-does-an-api-gateway-dohttps://blog.axway.com/learning-center/apis/basics/api-gateway-definition#why-do-you-need-an-api-gatewayhttps://microservices.io/patterns/apigateway.htmlhttps://blog.faradars.org/what-is-an-api/BPMSیک سیستم مدیریت فرآیند کسب و کار مدل‌سازی، طراحی، اجرا و نگهداری فعالیت‌های تجاری و کارکنانی که آنها را مدیریت می‌کنند، در بخش‌ها و مکان‌های فیزیکی مختلف را امکان‌پذیر می‌سازد. این راه‌حل‌های نرم‌افزاری برای کمک به کسب‌وکارها طراحی شده‌اند تا فرآیندهای تجاری روزمره خود را برای حداکثر کارایی و بهره‌وری بهینه کنند.Message queueدر علوم کامپیوتر، صف‌های پیام و صندوق‌های پستی اجزای مهندسی نرم‌افزار هستند که معمولاً برای ارتباطات بین فرآیندی (IPC) یا برای ارتباطات بین رشته‌ای (thread)  در همان فرآیند استفاده می‌شوند. صف پیام شکلی از ارتباط سرویس به سرویس ناهمزمان است که در معماری های بدون سرور و میکروسرویس استفاده می شود. پیام ها تا زمانی که پردازش و حذف شوند در صف ذخیره می شوند و هر پیام فقط یک بار توسط یک مصرف کننده پردازش می شود.در معماری نرم افزار مدرن، برنامه‌ها به بلوک‌های ساختمانی کوچک‌تر و مستقل تقسیم می‌شوند که بتوانند راحتتر توسعه، استقرار و نگهداری شوند. صف های پیام ارتباط و هماهنگی را برای این برنامه های توزیع شده فراهم می کنند. صف های پیام می توانند به طور قابل توجهی برنامه نویسی برنامه های جدا شده را ساده کنند، در حالی که عملکرد، قابلیت اطمینان و مقیاس پذیری را بهبود می بخشند.به عنوان مثال نرم افزار RabbitMQ به عنوان یک پلتفرم واسطه کار می کند که تضمین می کند پیام به مقصد مناسب تحویل داده می شود. از این نرم افزار می توان برای کاهش بار و زمان تحویل   web application serverبا واگذاری وظایفی که معمولاً زمان یا منابع زیادی را به شخص ثالثی که کار دیگری ندارد، استفاده کرد.منابع:https://aws.amazon.com/message-queue/https://en.wikipedia.org/wiki/Message_queuehttps://www.cloudamqp.com/blog/part1-rabbitmq-for-beginners-what-is-rabbitmq.htmlhttps://www.rabbitmq.com/</description>
                <category>amirasali1997</category>
                <author>amirasali1997</author>
                <pubDate>Sat, 26 Nov 2022 23:54:37 +0330</pubDate>
            </item>
                    <item>
                <title>بررسی و تحلیل انتشار ویروس کرونا با استفاده از شبکه های پیچیده</title>
                <link>https://virgool.io/@amirasali1997/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D9%88-%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D8%A7%D9%86%D8%AA%D8%B4%D8%A7%D8%B1-%D9%88%DB%8C%D8%B1%D9%88%D8%B3-%DA%A9%D8%B1%D9%88%D9%86%D8%A7-%D8%A8%D8%A7-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-%D8%B4%D8%A8%DA%A9%D9%87-%D9%87%D8%A7%DB%8C-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-yavsl0ech2x6</link>
                <description>نویسندگان ‌: علی کلاته عربی - امیر مهدی عسلیاستاد درس : دکتر صادق علی اکبریمقدمههمه گیری کووید 19 باعث مریضی و مرگ و میر قابل توجهی در سراسر جهان شده است و تنها راه برای کاهش سرعت گسترش آن، اجرای روش های مداخله غیردارویی، به ویژه فاصله گذاری اجتماعی بوده است. مداخلات دارویی دارای اهمیت بالایی ست اما به دلیل قدرت شیوع شدید ویروس و همچنین ناشناخته بودن ابعاد زیادی از آن به منظور درمان کامل، همچنان و حتی بعد از دسترسی عمومی به واکسن نیز روش های مداخلات غیر دارویی اهمیت بالاتری دارد.[1]در تمام کشورهای جهان فاصله گذاری اجتماعی تا حد بالایی در دستور کار دولت ها قرار گرفته است. بعضی کشورها خیلی زود شروع کردند و بعضی دیگر با فاصله زمانی، اما در نهایت تقریبا تمام کشورها متوجه اهمیت ویژه آن شدند و تلاش برای فاصله گذاری و در عین حال پخش به صورت ویژه ماسک و لوازم ضد عفونی را شروع کردند. اما در نحوه اجرای این فاصله گذاری نیز اختلافاتی در میان کشورها و حتی ایالت های کشورها هست. در بعضی خیلی شدید اجرا می شود به صورتی که مردم در هیچ صورتی از خانه بیرون نمی آیند و حتی خریدهای خود را بصورت آنلاین انجام می دهند و در بعضی کشورها مواردی برای راحتی مردم در نظر گرفته می شود.در هر صورت و با تمام حالت های مختلف انجام فاصله گذاری، این روش و دیگر روش های مداخلات غیر دارویی به صورت گسترده برای کنترل شیوع ویروس انجام می شود. این روش ها اما مشکلاتی را نیز به همراه دارد. ملاحظات اقتصادی و همچنین خستگی روانی ناشی از فاصله گذاری اجتماعی در میان جمعیت انسانی، منجر به کاهش مداخلات غیردارویی می شود که دولت ها مجبور به انجام آن می شوند. به این معنا که شما نمی توانید مردم را به طور کامل در خانه ها نگه دارید و توقع داشته باشید که اقتصاد ضربه جدی ای نبیند و یا حتی مردم به راحتی این خانه نشینی را تحمل کنند. اما با کم کردن محدودیت های کرونایی شاهد ایجاد موج های جدید این ویروس نیز خواهیم بود که آثار مخرب آن نه فقط اقتصادی و روانی، بلکه آمار مرگ و میری ست که به طور مستقیم بر جمعیت تاثیرگذار خواهد بود.[2]در کنار تمام این مسائل، این سوال بزرگ نیز هست که این فاصله گذاری اجتماعی با تمام مشکلات اجرایش آیا به اندازه کافی تاثیرگذار است؟ الگوهای متفاوت و جالبی از اثر اعمال محدودیت های کرونایی مشاهده شده است. این الگوها شهر به شهر و کشور به کشور دارای تفاوت های بسیاری ست اما بعضی رفتارها نیز در آنها مشترک است. در برخی شهرها، به دنبال شروع فاصله گذاری اجتماعی شدید، کاهش قابل توجهی از موارد ابتلای روزانه و در برخی شهرها نیز، یک فاز ثابت نسبتا طولانی مدت مشاهده شد، که طی آن به نظر می رسید تعداد موارد روزانه حول یک سطح متوسط ثابت در نوسان است.[1]نکته قابل توجه این است که این امر در مکان‌هایی دیده شده است که اقدامات فاصله‌گذاری اجتماعی را نسبتاً زود اجرا کرده‌اند و موفق شدند شیوع را به طور مؤثر کنترل ‌کنند، مانند کالیفرنیا یا ایالت واشنگتن. اینها فقط دو نمونه از رفتارهای پویا و متغیر ویروس در مقابله با ایجاد محدودیت هاست. این قبیل رفتارها در مسائل مربوط به ویروس بود که باعث شد محققان به دنبال روش هایی بروند که بتوانند این رفتارها را توجیه کنند و با استفاده از آنها بتوانند به کنترل شیوع و انتشار ویروس دست بیابند. استفاده از مدل های ریاضی برای بررسی پویایی بیماری های عفونی سابقه طولانی دارد. مدل های کلاسیک جمعیت به طور گسترده برای مطالعه گسترش همه گیری ها برای نزدیک به یک قرن استفاده شده است. مدل‌ها معمولاً فرض می‌کنند که جمعیت‌ها در بخش‌های مختلف همگن هستند، به این معنا که همه افراد به طور مشابه رفتار می‌کنند و تراکم در یک محل نداریم. این مدل‌ها می‌توانند برای درک پویایی کلی یک بیماری همه‌گیر مفید باشند و پیش‌بینی‌های نسبتاً واقعی را برای یک جمعیت همگن ارائه دهند، اما زمانی که جمعیت از جوامعی با ویژگی‌های اجتماعی-شهری یا جمعیت‌شناختی متفاوت تشکیل شده باشد، دقت کافی ندارد.[3] ما نیاز به مدلی داریم که شیوه های مختلف تعاملات اجتماعی را در نظر بگیرد و همچنین بتواند الگویی برای پخش شدن و نحوه پخش شدن ویروس را ارائه دهد.حالت دیگری از بررسی کرونا بصورت شبکه های پیچیده نیز هست که در اینجا فقط به آن اشاره می شود و در ادامه تحقیقات به سراغ آن نمی رویم. در این حالت توجه و تمرکز شبکه ها بر روی خود ویروس و تشخیص آسیب پذیری راه های نفوذ به آن است.در قدم اول تحلیل موضوعات بیولوژیکی مربوط به کرونا ، واجب است که ساختار ویروس را به خوبی شناخت. ویروس کرونا از 4 پروتئین ساختاری تشکیل شده است.Spike glycoprotein, small envelope glycoprotein , membrane glycoprotein ,nucleocapsid proteinدر این مبحث تمرکز اصلی ما با توجه به تلاش برای تشکیل شبکه و گراف ، بر روی پروتئین spikeاست که از این به بعد با S شناخته می شود.در توضیحات تکمیلی باید گفت که برهمکنش S و گیرنده سلولی (ACE2) موجب اتصال غشا سلولی و غشا ویروس می شود.در حالت کلی تر میتوان گفت که S به نوعی دروازه ورود ویروس به داخل سلول را ایجاد می کند و با اینکار موجب شروع تکثیر ویروس توسط خود سلول می شود.در ادامه برای حفاظت S ها که ضامن بقای ویروس هستند نیاز به glycan دارد که از الان به g شناخته می شود.نقش g در ساختار ویروس به این شکل است که بر روی S تشکیل شده است و مانع از چسبیدن آنتی بادی ها به ویروس هستند.در شکل عملکرد و نحوه قرارگیری glycan ها آورده شده است.در یک تحلیل شبکه که بر روی گلیکان های محافظ بر روی پروتئین S اعمال می شود ؛ منجر به پیدا شدن نقاط قوت و ضعف شبکه محافظ می شود. در این گراف تشکیل شده هر گلیکان در نقش گره ظاهر می شود و ارتباط بین دو گره به این صورت ترسیم می شود که اگر فاصله بین دو گره در شبکه ، کمتر از 50 انگستروم باشد ، یک یال ارتباطی بین آنها کشیده می شود. همچنین باید در نظر داشت یال های ترسیم شده دارای وزنی هستند که مقدار آن برابر با انرژی برهمکنش بین دو گره یا گلیکان است. با اعمال فرضیات گفته شده ، گرافی رسم می شود که میتوان به آن گراف ارتباط شبکه محافظ گفت. به منظور تحلیل این گراف و دستیابی به اطلاعات مورد نیاز، از دو فاکتور مرکزیت استفاده می شود.Betweenness centrality(BC) و Eigenvector centrality(EC)معیار BC برای این منظور است که بفهمیم هر نود در ارتباط بین نودهای دیگر چندبار در کوتاه ترین مسیر ممکن قرار دارد و معیار EC بدین منظور است که قدرت همسایه های هر نود که به آنها وصل است چقدر است و یا به زبان دیگر نودهایی که هر نود به آنها وصل است خود به چند نود دیگر وصل هستند.آنتی بادی های موجود در بدن که کاربرد آنها به منظور خنثی سازی و جلوگیری از تکثیر ویروس می باشد، به دنبال روزنه نفوذی در ساختار محافظتی ویروس هستند. باید توجه داشت که در صورت بالا بودن میزان ارتباط گلیکان ها این امر سخت تر می شود و در نهایت میتوان گفت که بهینگی عملکرد آنتی بادی زیر سوال می رود.حتی مواردی در ساختار ویروس به وجود می آید که نفوذ آنتی بادی به آن در حد صفر است. به همین منظور و با تحلیل گراف موجود به نقاطی ­­دست پیدا میکنیم که چگالی خود گلیکان ها و چگالی ارتباطی آنها از بقیه مناطق کمتر است و این نقاطی ست که با تمرکز بر روی آنها میتوان به ساختار ویروس نفوذ کرد و احتمال خنثی سازی را بالا برد.با توجه به شکل میتوان به نحوه ارتباط گلیکان های با ساختار متفاوت(اسم های متفاوت نشان دهنده ساختار متفاوت می باشد) و وزن یال های آنها پی برد.[4]کارهای گذشتهدر [5]، نویسندگان از مدل‌های فراجمعیت شبکه برای توصیف گسترش سارس و شیوع آنفولانزای معروف به آنفولانزای مرغی، استفاده کردند. ویژگی مشترک این سه بیماری همه گیر، سرعت انتشار آن ها در محدوده جغرافیایی گسترده بود: در سال 2003، SARS-CoV از هنگ کنگ به بیش از 30 کشور در 4 قاره گسترش یافت و در سال 2009 A(H1N1) طی 3 تا 4 ماه به 214 کشور گسترش یافت. مفهوم فراجمعیت، که به عنوان گروهی از جمعیت‌های جدا شده که نوعی تعامل دارند، در ابتدا در مطالعه آفات حشرات معرفی شد و بعداً در ارتباط با شبکه‌ها برای معرفی یک بعد فضایی در مدل‌سازی انتقال بیماری استفاده شد. آنها از این مفهوم استفاده کردند تا به طور دقیق تری انتقال و شیوع بیماری را پیش بینی کنند.در – مقایسه میان رویکردهای مبتنی بر عامل(agent based) و مدل های مبتنی بر جمعیت انجام شده است.[6]تغییرات در الگوی رفت و آمد انسان و اعمال محدودیت هایی بر آن معمولا در زمان شیوع همه گیری انجام می شود تا به کمک آن بتوان ویروس را در محل پخش نگه داشت تا محل های دیگر را آلوده نکند.این ممنوعیت و محدودیت ها میتواند از ممنوعیت سفرهای هوایی باشد تا ممنوعیت های از درب منزل که در زمان کرونا به خوبی شاهد آن بودیم اما جالب است که در مقالاتی اثر این قبیل محدودیت ها نیز مورد سوال قرار گرفته است. به عنوان مثال در 4 اثر محدودیت های سفرهای هوایی اعمال شده توسط سازمان بهداشت جهانی به منظور کنترل آنفولانزا مورد بررسی قرار گرفته و تا حدی نشان از عدم تاثیر مطلوب دارد.در تحقیق دیگری که توسط [1] انجام گرفته است نمونه ای جالب مشاهده شده. آنها با بررسی اطلاعات بدست آمده از تعداد افراد مبتلا، بهبود یافته و فوت شده، متوجه شدند که در برخی ایالت های آمریکا الگویی پیش بینی نشده رخ می دهد. در این ایالت ها که اکثرا از مناطقی هستند که سریع ترین و بیشترین محدویت ها را نیز دارند؛ امار موارد روزانه گزارش شده به یک عدد ثابت می رسد که با توجه به اعمال محدودیت و کاهش اولیه آمار، کمی نگران کننده و شوکه کننده است. آنها علاوه بر نشان دادن power law بودن شیوع ویروس، همچنین نشان دادند که اگر بصورت خیلی سریع و زود هنگام محدودیت ها اعمال شود با احتمال بالا ممکن است یک فاز ثابت در موارد روزانه رخ دهد که بدون هیچ گونه اقدامات بیشتری خود به خود این فاز کنار رفته و کاهش آمار دوباره رخ خواهد داد. همچنین یک بعدی بودن انتقال در زمان اعمال محدودیت ها در مقایسه با دو بعدی بودن آن در قبل از محدودیت ها را عامل این فاز ثابت معرفی کردند. مسئله دیگری که در مطالعات آنها بسیار حائز اهمیت آن است؛ مسئله زمان ایجاد مداخلات غیر دارویی ست که در مطالعات دیگر کمتر به آنها اشاره شده است.در تحقیق دیگری [7] ، به سراغ این مسئله رفته اند که تاثیر سن در ابتلای افراد به چه صورت است و سعی کردند با توجه به داده های دست پیدا کرده از کرونا به مدل ریاضیاتی ای برسند که جواب این سوال را بدهد. آنها مدلی توسعه دادند که نشان داد امکان ابتلای افراد بالای 20 سال تقریبا 2 برابر افراد زیر این سن است و فقط 21 درصد افراد زیر 20 سال ممکن است که علائم داشته باشند. آنها از این مسئله در هوشمند سازی قرنطینه و اعمال سریعتر آن در کشورهایی با میانیگن سنی بالاتر استفاده کردند و نشان دادند که مناطق با سرانه سنی بالاتر اگر دیرتر این محدودیت ها را اعمال کنند میتواند منجر به یک فاجعه بشود.در تحقیق دیگری که به منظور روش های ایجاد قرنطینه هوشمند و رسیدن به نتیجه بهتر انجام شد؛ [8] نشان دادند که با اعمال سیاست های متفاوت از یک قرنطینه ساده و فاقد هوشمندی چقدر بهتر و سریع تر میتوان شیوع بیماری را کنترل کرد. در عکس 1 نتیجه تحقیقات آنها نمایش داده شده است.آنها در این شکل خلاصه از نحوه اعمال محدودیت ها را نشان می دهند و در آخر نشان می دهد که اعمال محدودیت و قطع ارتباط بر اساس مدل repetition بیشترین فایده و بهینه ترین حالت را داشته است. این تحقیق به دلیل مقایسه میان روش های موجود و همچنین ارائه مدلی برای قرنطینه هوشمندتر و بهتر بسیار جالب توجه بود. ما از این روش ها و مطالعات ایده گرفته و مدلی بر اساس تحلیل های خود ارائه دادیم. هدف ما از توسعه این مدل، تلاش برای رسیدن به ایده ای برای قرنطینه هوشمند و همچنین نیازسنجی قرنطینه و سنجش تاثیر اعمال واکسن است.روش مادر این تحقیق ما جامعه نمونه ۱۰۰۰۰ نفری در نظر گرفتیم که ۲۰درصد افراد در این جامعه را گروه های حساس (افراد دارای بیماری زمینه ای، افراد مسن و ...) تشکیل می دهند. شبکه ما یک شبکه رندوم هندسی است که هر نود در آن به نود هایی که در شعاع مشخصی از آن نود قرار دارند متصل میشود و برای رسیدن به یک شبکه شبه واقعی که بتواند شرایط جامعه انسانی را شبیه سازی کند، هر نود به تعدادی نود که خارج از شعاع گفته شده است نیز متصل است. شبیه سازی شرایط جوامع انسانی شاید یکی از بزرگترین چالش ها برای به نتیجه رسیدن تحقیقات در زمینه شبکه های پیچیده باشد. اینکه چه فاکتورهایی در نظر گرفته شود؟ به چه صورت و چه مقداری در نظر گرفته شود؟‌ و آیا نتیجه نهایی با واقعیت منطبق است یا نه؟ ما تلاش کردیم با توجه به درکی کلی از جوامع و با تقریبی از ارتباطات کلی افراد در آن، شبکه ای را بسازیم که وابستگی کمی به تعداد متغیرات داشته باشد و حالتی کلی برای تقریب را به ما بدهد. به همین منظور میانگین درجات هر نود ۱۱ تا ۱۳ است و این عدد را میتوانیم تعداد ارتباطات افراد در طول یک هفته در نظر بگیریم که با توجه به این که این عدد برای شرایط غیر قرنطینه است عدد معقولی به نظر میرسد. در این تحقیق هر مرحله زمانی ۱ هفته در نظر گرفته میشود و هر کس که بیمار میشود دو هفته بیماری را دارد و در این حالت بیماری را سرایت میدهد. پس از این دو هفته شخص یا خوب میشود و دیگر نمی گیرد یا می میرد در نتیجه کسی که بیمار می شود، پس از دو هفته دیگر بیاری را نمی گیرد و انتقال نمی دهد.فرایند گرفتن بیماری به این شکل است که به هر شخص یک ضریب مقاومت به بیماری به شکل تصادفی تعلق میگیرد که میتواند میزان سلامت شخص و ... باشد. این ضریب در افراد حساس بین ۰ تا ۰.۶ است در بقیه افراد این ضریب ۰.۵ تا ۰.۹ است. وقتی فرد با کسی که بیمار است در تماس قرار میگیرد (۲ نود به هم متصل باشند.) یک ضریب انتقال به طور تصادفی تولید میشود (بین ۰ و ۱) که میتواند نشان دهنده میزان تماس دو شخص، نوع تماس و ... باشد. حال اگر ضریب انتقال بزرگتر از ضریب مقاومت شخص باشد، شخص مبتلا میشود.با بررسی و انجام تست های مختلف با شروع از ۵شخص مبتلا، دیده شد که در مراحل زمانی بین ۵۰ - ۶۰هفته حدود ۹۲ درصد جامعه دچار بیماری میشوند فرایند تمام میشود. در این فرایند، تعداد ابتلا های جدید در هر مرحله زمانی و در نهایت تعداد کل کسانی که بیماری را گرفنتد و بهبود یافتند و تعداد کسانی که در نهایت اصلا دچار بیماری نشدند را میتوان بررسی کرد. حال برای بررسی، پس از شروع بیماری در مرحله ای که تعداد بیماران از یک عدد مشخص عبور کرد واکسیناسیون و فاصله گذاری اجتماعی را اعمال می کنیم. فاصله گذاری اجتماعی در میانگین درجات نود ها و واکسیناسیون در ضریب مقاومت افراد موثر است.باید در نظر داشت که مفهوم قرنطینه را نیز در این تحقیق به کار بردیم که تعریف آن به این صورت است که فرد مبتلا در هفته دوم بیماری ۷۰ درصد ارتباطاتش را از دست می دهد که این حالت برای جلوگیری از انتشار در نظر گرفته شده است که به نوعی رفتار طبیعی افرادی ست که مبتلا شده اند و برای جلوگیری از آلوده شدن اطرافیان همچین عملی را انجام می دهند. این فرض به منظور نزدیک تر شدن شبکه به رفتار واقعی در نظر گرفته شده.با اجرای کدهای نوشته شده، به نتایج جالب توجهی در مورد نحوه انتشار و پاسخ شبکه ایجاد شده به مداخلات غیر دارویی رسیدیم. اگر هیچ گونه مداخلات دارویی و غیر دارویی اعمال نشود، در حدود ۱۵ هفته ۹۴ درصد جمعیت شبکه آلوده به ویروس می شوند که این آمار را میتوان آلودگی کل سیستم و تقریبا نابودی آن در نظر گرفت.با اعمال محدودیت های رفت و آمد، واکسن و همچنین فرض قرنطینه افراد مبتلا در هفته دوم ( فرض می شود که علائم در هفته دوم بروز پیدا می کند و فرد متوجه بیمار خود شده و خود را قرنطینه می کند) با توجه به نمودارهای بدست آمده از تعداد مبتلایان نشان داده می شود که زمان ایجاد اعمال محدودیت ها اهمیت بالایی دارد. به طوری که اگر زمانی که ۵ درصد جمعیت آلوده شده است محدودیت های اجتماعی را شروع کنیم، نزدیک به ۱۲۰۰ نفر در بالاترین مرحله انتشار به صورت هفتگی مبتلا می شوند که این آمار اگر در ۱۰ درصد جمعیت محدودیت ها آغاز شود به حدود ۱۹۰۰ نفر می رسد. شاید در نگاه این تفاوت آن چنان به چشم نیاید اما باید در نظر داشت جمعیت آماری فقط ۱۰ هزار نفر است و اگر ابعاد جمعیتی بزرگ تر شود این اختلاف بسیار هولناک خواهد بود اما نکته جالب توجه این است که شیب کاهش آمار موارد ابتلا در حالت دوم که ۱۰ درصد جمعیت آلوده شده و سپس محدودیت ها شروع می شود، تندتر از حالت اول است که این محدودیت ها در ۵ درصد آلودگی آغاز می شود. این پدیده در وهله اول با مطالعات و آمار استخراج شده از مقالات همخوانی دارد و همچنین تاکید بیشتری بر روی زمان اعمال محدودیت ها می کند. در حالت ۵ درصد آلودگی که اعمال محدودیت ها سریعتر از حالت ۱۰ درصد است حالتی از شیب خطی را در قله موارد ابتلا شاهد هستیم که همین مورد کاهش آمار را با تاخیر مواجه می کند.نتیجه جالب توجه دیگر تاثیر ارتباطات دور است. با توجه به تصاویر بدست آمده از نحوه انتشار و همچنین تعداد مراحل زمانی لازم تا به پایان رسیدن شیوع، میتوان نتیجه گرفت که ارتباطات دور تاثیر بسیار بیشتری از ارتباطات نزدیک دارند. آنها میتوانند در حالی که شبکه به حالت درمان و عدم ابتلا نزدیک شده ناگهان از نقطه ای دیگر شیوع را شروع کنند و تمام مداخلات را بی معنا جلوه دهند. اما چطور میتوان این نتیجه را بر اعمال محدودیت های هوشمند تطبیق داد؟‌ میتوان به حالت شهری و یا حتی محله ای به این مسئله نگاه کرد. در حالت محدودیت های سخت، اقتصاد ضربه جدی می خورد و تا خرد ترین کاسب ها و فعالیت های اقتصادی نیز دچار آسیب شدید می شوند و همچنین به دلیل در خانه ماندن افراد و دوری از فضاهای تعاملات انسانی، آسیب های روانی نیز به آن اضافه می شود. اما اگر محدودیت ها را نیز کمی آرام تر کرده و به مردم اجازه رفت و آمد بدهیم شاهد به وقوع پیوستن موج های جدید اپیدمی هستیم. پس آیا باید هرگز سراغ هیچ کم کردن محدودیتی نرویم؟ طبیعتا خیر. این حالت میتواند ضربات جبران ناپذیری دقیقا همانند شیوع بیماری بزند. نتایج تحقیقات ما نشان می دهد که اگر این کاهش محدودیت ها را در سطح انجمن ها انجام بدهیم نتایج قابل قبولی میگیریم. حال این انجمن را میتوان به عنوان مثال یک محله تعریف کرد. با کاهش منطقی محدودیت ها در سطح محله میتوان به نوعی اقتصاد خرد را تا حدی نجات داد و همچنین در مقابل آسیب های روانی اپیدمی نیز ایستادگی کرد. این نتیجه میتواند نوعی از قرنطینه هوشمند را ارائه کند که افراد میتوانند در بازه هایی در سطح های محلی کوچک ارتباط داشته باشند( طبیعتا با دریافت واکسن و رعایت موارد بهداشتی)‌ اما در سطح شهری و یا کشوری همچنان محدودیت ها برقرار بماند. این یعنی جلوگیری از شیوع موج های جدید و همچنین به کمترین حد رساندن آسیب های اقتصادی و روانی اپیدمی.شکل بالا مراحل آلودگی سیستم در حالت بدون اعمال محدودیت های رفت آمد، واکسن و قرنطینه فرد مبتلا را توسط مدل ساخته شده نشان می دهد.عکس بالا نحوه انتشار ویروس در حالتی ست که لینک های دور دست وجود ندارد و به نوعی ارتباط ها محلی می باشد. با دقت در عکس میتوان متوجه نحوه انتشار کند ویروس شد. درست است که اگر مداخلات غیردارویی و دارویی اعمال نشود باز هم سیستم با درصد بالایی آلوده می شود اما نکته حائز اهمیت کندی شیوع می باشد. این خود نمونه ای ست که میتوان برای تاثیر عمیق لینک های دوردست به منظور انتشار ویروس به آن اشاره کرد.نمودار بالا نشان دهنده کاهش موارد ابتلا با اعمال محدودیت کرونایی هوشمند در کنار واکسیناسیون و قرنطینه موارد مبتلا ست.نمودار بالا نشان دهنده حالت بدون اعمال محدودیت های کرونایی ست که نشان از تعداد بسیار بالای مبتلایان دارد. پایین آمدن نمودار فوق نشان از ابتلای بالای ۹۳ درصد جمعیت دارد و به معنای پایان اپیدمی نیست. https://www.dropbox.com/s/d6hkvveevhuyvtw/main_file.ipynb?dl=0 در لینک بالا تمام کدهای نوشته شده به زبان پایتون قابل مشاهده می باشد. تمام فرضیات گفته شده بر روی کد اعمال شده است و تا جای ممکن سعی شده با کامنت گذاری کد خوانایی بیشتری داشته باشدمنابع1) Komarova, Natalia L., Asma Azizi, and Dominik Wodarz. &quot;Network models and the interpretation of prolonged infection plateaus in the COVID19 pandemic.&quot; Epidemics 35 (2021): 100463.2) Block, Per, et al. &quot;Social network-based distancing strategies to flatten the COVID-19 curve in a post-lockdown world.&quot; Nature Human Behaviour 4.6 (2020): 588-596.3) Calvetti, Daniela, et al. &quot;Metapopulation network models for understanding, predicting, and managing the coronavirus disease COVID-19.&quot; Frontiers in Physics 8 (2020): 261.4) Ghorbani, Mahdi, Bernard R. Brooks, and Jeffery B. Klauda. &quot;Exploring dynamics and network analysis of spike glycoprotein of SARS-COV-2.&quot; Biophysical Journal 120.14 (2021): 2902-2913.5) Wang L, Li X. Spatial epidemiology of networked metapopulation: an overview. Chinese Sci Bull. (2014) 59:3511–22. doi: 10.1007/s11434-014-0499-86)Ajelli M, Gonçalves B, Balcan D, Colizza V, Hu H, Ramasco JJ, et al. Comparing large-scale computational approaches to epidemic modeling: agent-based versus structured metapopulation models. BMC Infect Dis. (2010) 10:190. doi: 10.1186/1471-2334-10-1907)Prem, K., Liu, Y., Russell, T.W., Kucharski, A.J., Eggo, R.M., Davies, N., Flasche, S., Clifford, S., Pearson, C.A., Munday, J.D., 2020. The effect of control strategies to reduce social mixing on outcomes of the COVID-19 epidemic in Wuhan, China: a modelling study. Lancet Public Health.8) Block, P., Hoffman, M., Raabe, I.J., Dowd, J.B., Rahal, C., Kashyap, R., Mills, M.C., 2020b. Social Network-based Distancing Strategies to Flatten the COVID 19 Curve in a Post-lockdown World. arXiv preprint arXiv:2004.07052.</description>
                <category>amirasali1997</category>
                <author>amirasali1997</author>
                <pubDate>Mon, 11 Jul 2022 23:42:51 +0430</pubDate>
            </item>
            </channel>
</rss>