https://virgool.io/feed/@mahyarpanahi81256 fa 2026-06-18 10:30:45 https://files.virgool.io/upload/users/4012375/avatar/avatar.png?height=120&width=120 https://virgool.io/@mahyarpanahi81256 https://virgool.io/@mahyarpanahi81256/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%A7-%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D9%88-%D9%BE%DB%8C%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%DB%8C%DA%A9-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-multi-agent-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%D9%88%D9%84%DB%8C%D8%AF-%D8%B3%D9%86%D8%AF-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-kr0jm89ujplm این روز ها کمتر جایی هست که در مورد هوش مصنوعی و استفاده از LLM ها صحبت نشود . LLM ها نه تنها مورد استفاده ی دانشجویان و افراد متخصص قرار میگیرد بلکه مردم عادی هم از این مدل ها استفاده میکنند . در بحث سرمایه گذاری هم اکثر شرکت های بزرگ سعی دارند مدل های زبانی بزرگ خودشان را اموزش و عرضه کنند . این موضوع به قدری داغ است که مدیر عامل شرکت بزرگ اینتل وارد نشدن در این عرصه را دلیل شکست اینتل میداند .امروزه LLM ها در تولید محتوا ، آموزش و یادگیری ، خودکار سازی فرایند ها و خیلی حوزه های دیگر به کار میرود . در مهندسی نرم افزار و خصوصا نوشتن کد تلاش های زیادی توسط شرکت های آموزش دهنده ی مدل ها و همینطور محققان انجام شده است . یکی از عامل های اصلی برای ارزیابی مدل های زبانی بزرگ قدرت آنها برای درک و نوشتن کد و باقی موضوعات زیر مجموعه ی مهندسی کامپیوتر است .تحقیقاتی که در زمینه ی معماری نرم افزار انجام شده است میگویند LLM ها نه یک ابزار مهندسی است و نه یک متودولوژی . بلکه یک عامل الهام بخش است که گاهی اوقات میتواند پیشنهاداتی بدهد که شما دیدگاه جدیدی به دست بیاورید .مشکلات بزرگی که تحقیقات و استفاده های شخصی از LLM ها در معماری نرم افزار میگویند این است که اگر مدل ها نمیتوانند خروجی قابل استفاده برای معماران بسازند و اتوماتیک شدن در این زمینه شدنی نیست . هر چند میتوانند یک ابزار کمکی باشند اما حتما نیاز به برسی یک معمار متخصص را دارند . معمار باید مرحله به مرحله ایرادات را به مدل بازگو کند و با برسی فراوان و یک پرامپت دقیق مدل را یک مرحله جلو تر ببرد تا تغیرات مد نظر او اعمال شود.مشکل دیگر که حتی باعث پدید امدن مشکل قبلی هم میشود و یکی از ایرادات اصلی مدل ها است مشکل توهم یا Hallucination است . به این معنی که مدل با اعتماد به نفس کامل کار اشتباهی انجام میدهد و اگر کسی در ان زمینه اطلاعاتی نداشته باشد متوجه اشتباه مدل نمیشود .سیستم چند عاملیاگر چک کردن پاسخ های مدل را به یک مدل قدرتمند دیگر بسپاریم تا حد بسیار زیادی این مشکل حل خواهد شد . یک مدل قدرتمند دیگر که در ان زمینه هم آموزش دیده است میتواند اگر ایراداتی ناشی از توهم در خروجی مدل اول وجود داشت ان را کشف کنند . طبق تجربه ی شخصی و مقالاتی که در این زمینه وجود دارد عامل ها در برسی و اشکال زدایی میتوانند عملکرد بهتری از تولید داشته باشند .این موضوع باعث شد که یک سیستم چند عاملی پیاده سازی شود که در این زمینه تلاش کند تا بتوان خروجی بهتر و قابل اعتماد تری به دست آورد . این سیستم چند عاملی یک سند معماری مینویسد و چون سند معماری بخش ها مختلفی دارد که تمامی آن بخش ها از ارتباط نسبی برخوردار هستن و متن و تصاویر زیادی دارند برای ارزیابی این سیستم میتوانند مناسب باشند .روش انجام به این صورت است که یکبار خروجی توسط سیستم چند عاملی تولید میشود و یکبار هم توسط یک مدل بسیار قوی تر و سپس خروجی آنها با هم مقایسه میشود تا نتیجه بگیریم که سیستم چند عاملی با مدل ضعیف تر بهتر است یا مدل تک عامله با مدل قوی تر.میتوانید فایل کد و خروجی سیستم چند عامل و خروجی سیستم تک عامله و همینطور گزارش پروژه را در لینک زیر دانلود و استفاده کنید:https://github.com/mahhyar/multiagentهمانطور که در کد ارائه شده قابل مشاهده است در این قسمت که متغیر PROJECT_BRIEF تعریف شده است در واقع پرامپت ورودی است که ما به سیستم میدهیم . میتوانیم با تغییر دادن مقدار این متغیر پروژه را عوض کنیم .در این سیتم از چند عامل زیر استفاده شده است :DraftAgent (عامل پیش‌نویس): اولین متن خام سند معماری را تولید می‌کند.ReviewerAgent (عامل بازبین): متن خام را بازبینی و از نظر فنی و کیفی آن را تکمیل می‌کند.DiagramAgent (عامل طراح نمودار): متن معماری را دریافت و چهار نمودار اصلی UML را بر اساس آن می‌سازد.SyntaxCorrectionAgent (عامل اصلاح کد): کدهای PlantUML را بررسی می‌کند تا اگر خطای نوشتاری دارند آن‌ها را اصلاح کند.ConsistencyAgent (عامل بررسی سازگاری): مهم‌ترین وظیفه را بر عهده دارد یعنی بررسی اینکه آیا بین متن سند و نمودارها تناقض منطقی وجود دارد یا خیر.RefinementAgent (عامل اصلاح نهایی): گزارش عامل سازگاری را دریافت و بر اساس آن، کل سند را برای رفع مشکلات بازنویسی می‌کند.طبق تصویر بالا عامل ها با یکدیگر در تولید این سند همکاری میکردند. حلقه ای که در تصویر هم مشاهده میکنید سه بار اجرا میشد تا نقص هایی که دارد بر طرف شود .خروجی سیستم چندعاملی شامل یک سند Word و چهار نمودار UML بود. سند بخش‌های اصلی معماری (مقدمه، اهداف، میکروسرویس‌ها، فناوری‌ها، امنیت و استقرار) را پوشش داد اما در بعضی قسمت‌ها محتوای آن سطحی و کلی باقی ماند (مثل CI/CD و مستندات API). نمودارهای UML تولیدشده در سطح مفهومی مفید بودند، ولی جزئیات و انطباق کامل با متن را نداشتند مثلا برخی کلاس‌ها یا سناریوهای مهم غایب بودند. با این حال، وجود خودکار هر چهار نمودار یک دستاورد مثبت محسوب می‌شود.و در مقابل برای تست مدل تک عاملی از مدل قدرتمند GROK استفاده شده است که پرامپت زیر به آن داده شده است:لطفا برای من یک سند معماری برای یک فروشگاه آنلاین بنویس.این فروشگاه باید قابلیت‌هایی مانند مدیریت کاربران، سبد خرید، پرداخت آنلاین و جست‌ و جوی محصولات داشته باشد.لطفا سند شامل بخش‌های مهم معماری باشد و به زبان فارسی نوشته شود.خروجی که به ما داد یک فایل word نبود و فقط متنی بود که داخل سایت رسمی گراک برایم ارسال شد . برای نمایش بهتر من ان را داخل ورد کپی پیست کردم که در لینک فایل ها هم قابل مشاهده است. این خروجی نشان داد که متن آن گرچه روان و رسمی است اما فاقد نمودار و بازبینی چندمرحله‌ای است.این پروژه نشان داد با وجود اینکه مدل چند عامله از مدل بسیار ضعیف تر gemini 1.5 استفاده کرد اما خروجی بهتری نسبت به مدل تک عامله ی قوی تر ساخت که این ارزشمند است . اما همانگونه که مشاهده کردید هنوز نمیشود این خروجی را به عنوان خروجی که هیچ ایراد فنی و مفهومی ندارد حساب کرد . اما اگر از مدل های قوی تر مثل جمنای 2.5 یا gpt 5 به صورت چند عامله استفاده کنیم خروجی خیلی بهتری به ما میدهد . همچنین به دلیل کمبود اعتبار api key سعی بر این شد که مراحل کمتری را در سیستم داشته باشیم . اگر تعداد اجرای حلقه ی بازخورد را اضافه کنیم و همچنین از دو مدل مختلف قدرتمند تر استفاده کنیم خروجی بسیار بهتری میگیریم. باز با این حال خروجی که گرفتیم بسیار بهتر از خروجی سیستم تک عامله هست."این مطلب ، بخشی از تمرینات درس معماری نرم افزار دانشگاه شهید بهشتی است"منابع:Will Generative AI Fill the Automation Gap in Software Architecting?State of practice: LLMs in software engineering and software architectureTransforming Software Architecture Design With Intelligent Assistants-A Comparative Analysis mahyar panahi mahyar panahi Sun, 24 Aug 2025 15:32:38 +0330 https://virgool.io/@mahyarpanahi81256/%DA%86%D9%86%D8%AF-%D8%A7%D8%B5%D8%B7%D9%84%D8%A7%D8%AD-%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-tnaffikaefrt سلام در این پست میخواهیم چند اصطلاح در معماری نرم افزار را یاد بگیریم.موضوع اول Infrastructure as Code (IaC) است برای راه اندازی محیط میشود مولفه ها را به صورت دستی تنظیم کرد . وقتی که تعداد این راه اندازی ها زیاد میشود برای مثال وقتی میخواهیم چندین سرور را راه اندازی کنیم این روش سخت میشود . با Infrastructure as Code یک فایل متنی که شامل کد های برنامه نویسی است مثل jason درست میکنیم و این فایل را به برنامه های Infrastructure as Code میدهیم تا برای ما تنظیم و راه اندازی کند . این موضوعات برای تیم devops بسیار کاربردی است چون قسمت ci/cd را با Infrastructure as Code انجام میدهیم و این روش باعث میشود که سریع تر بتوانیم فاز استقرا را انجام دهیم . و اینکه اشتباه انسانی را هم کم میکند چون به صورت اتوماتیک انجام میشود . موضوع دیگری که وجود دارد افزایش امکان کار تیمی است و میشود فایل ها را در اختیار باقی گروه ها قرار داد و هم اینکه میشود از فایل های اماده ی قبلی استفاده کرد یا فایل های خودمان را برای استفاده دیگران آپلود کنیم . terraform یکی از این ابزار ها است که Infrastructure as Code را برای ما انجام میدهد.موضوع دوم API Gateway & Service Mesh است . در معماری میکروسرویس کاربر درخواست خود را به یک دروازه یا api gateway میدهد و این gateway مشخص میکند که باید با کدام میکروسرویس خدمات بگیرد باعث میشود که جلوی حمله ها گرفته بشود و تشخیص میدهد درخواست معتبر است یا خیر .وقتی که تعداد میکروسرویس های یک سیستم زیاد میشود نیاز به این است که این میکروسرویس ها با هم در ارتباط باشن و از همدیگر خدماتی را بگیرن . مثلا میکروسرویس سفارش از پرداخت استفاده میکند . اینجا service mesh میاید که وظیفه ی مدیریت ارتباط بین میکروسرویس ها را دارد . موضوع سوم CQRS (Command Query Responsibility Segregation) است .  سبکی از معماری است به این صورت که فرایند هایی که تغییری در سیستم ایجاد میکنند را از فرایند هایی ک فقط استخراج اطلاعات هستن و میخوانیم جدا کنیم . برای مثال ما داده هایی که تغییر میکنن را در sql و داده هایی که فقط مثل گزارش می مانند را در پایگاه داده های nosql ذخیره کیم . این سبک معماری باعث میشود که کارایی سیستم افزایش پیدا کند چون که ما برای بخش هایی که نیاز به نوشتن است از یک فناوری و بخش هایی که فقط نیاز به خواندن دارن را از یک فناوری دیگر میتوانیم استفاده کنیم و این باعث میشود که بهینه سازی انجام شود . همچنین باعث میشود طراحی ساده تر شود البته یکی از معایب این سبک این است که باعث میشود که پیاده سازی سخت تر شود . این موضوع با ساده شدن طراحی متفاوت است .موضوع چهارم Event-Driven Architecture (EDA) است . وقتی که یک رویدادی اتفاق میفته بخش های مختلف سیستم که به این قسمت مربوط هستن خودشون تصمیم میگیرند که چه واکنشی به این رویداد نشون دهند . برای مثال وقتی کاربر روی خرید کلیک میکند بخش های مختلف مثل پرداخت و سریس انبارداری و سرویس ارسال و حمل و نقل به این رویداد واکنش نشان میدهند . بخش های مختلف با هم دیگر متصل نیستند و این عدم اتصال باعث میشود که راحت تر تغییر کند و همینطور این معماری برای سرویس های real time مناسب هستند . اصلی ترین بخش این معماری evant broker است که این بخش مثل یک واسط عمل میکند و وظیفه دارد که انتقال رویداد بین سیستم ها را انجام دهد .موضوع پنجم Serverless Architecture است . رایانش بدون سرور یعنی انکه توسعه دهندگان بدون توجه به سرور بتوانند برنامه های خود را توسعه دهند . البته به این معنا نیست که سروری وجود ندارد . بلکه به این معنی است که توسعه دهنده نیاز به ارتباط با سرور نداردند و ارائخ دهندگان سرویس ابری از چندین تا سرور برای اجرای برنامه ی توسعه دهنده استفاده میکنند . پس توسعه دهنده فقط وظیفه ی نوشتن کد و منطق برنامه را دارد.معماری بدون سرور رویکردی جدید برای ساخت وب‌ اپلیکیشن‌ها به شمار می رود. برخلاف معماری‌های سنتی، معماری serverless به توسعه‌ دهندگان این امکان را می‌دهد تا بدون نگرانی در مورد زیرساخت‌، برنامه‌های کاربردی را طراحی و پیاده‌سازی نمایند .موضوع ششم API-first Approach است . رویکردی است که برای طراحی سیستم ها از این استفاده میشود و در این رویکرد قبل از اینکه به رابط کاربری و backend بپردازیم api ها را طراحی میکنیم . در این رویکرد api ها در مرکز و نقطه شروع پروژه قرار دارند . این رویکرد باعث میشود که استفاده ی مجدد در برنامه ی ما بالا برود و اینکه هماهنگی بیشتر بین تیم های front و back وجود دارد چون که رابط های ساده ای باعث ایجاد هماهنگی بین اجزای مختلف سیستم میشوند .موضوع هفتم Domain Driven Design است .این رویکرد برای توسعه نرم‌افزارهای پیچیده کاربرد دارد و از مرحله تحلیل تا کدنویسی همراه تیم توسعه است. DDD در دو بخش استراتژیک و تکنیکی فعالیت می‌کند، اما تمرکز اصلی آن روی درک عمیق دامنه کسب‌وکار (Domain) است؛ یعنی همان محدوده‌ای که نرم‌افزار قرار است در آن کار کند.DDD معمولاً زمانی مفید است که پروژه دارای منطق تجاری پیچیده باشد. اما در پروژه‌های کوچک یا ساده، استفاده از آن ممکن است باعث افزایش زمان و هزینه بدون فایده خاصی شود.موضوع هشتم Hexagonal architecture است . این معماری با هدف ایجاد سیستم‌هایی انعطاف‌پذیر، قابل آزمایش و مستقل از زیرساخت طراحی شده است.در این مدل منطق اصلی برنامه (Domain Logic) در مرکز قرار دارد و از طریق پورت‌ها (رابط‌های ارتباطی) با اجزای خارجی تعامل می‌کند. آداپتورها نیز مسئول تبدیل ورودی‌ها و خروجی‌ها به شکلی قابل فهم برای منطق کسب‌وکار هستند.این معماری را می‌توان به قلعه‌ای شش‌ضلعی تشبیه کرد که تالار مرکزی آن نمایانگر منطق برنامه و هر ضلع آن، درگاهی برای برقراری ارتباط با دنیای بیرون است.موضوع نهم Event Sourcing است .  به این معناست به جای اینکه فقط مقدار اخر را ذخیره کنیم مجموعه ی تغییراتی که در ان دیتا صورت گرفته است را ذخیره کنیم. این کار باعث میشود که حجم دیتابیس اضافه شود اما موضوعی که وجود دارد این است که باعث میشود که اطلاعات دیگری هم از ان فرایند داشته باشیم و اگر به هر دلیلی مقدار اخر دیتا از دست رفت بتوانیم بازیابی کنیم. مثلا در سیستم موجودی به جای اینکه فقط موجودی را ذخیره کنیم تراکنش های پیشین را هم ذخیره میکنیم .موضوع دهم Low-code/No-code platforms است .  پلتفرم هایی هستند که میشود بدون نوشتن کد یا با نوشتن کد های کم نرم افزار های مختلف را توسعه داد. یعنی مثلا ما میخواهیم قسمت محصولات  نرم افزار خودمان را توسعه بدهیم . به جای اینکه کد بزنیم با کشیدن و رها کردن که با ماوس انجام میدهیم این کار را انجام میدهیم .موضوع یازدهم Business Process Management Systems است .یک سیستم نرم افزاری است که به مدیریت برنامه های سازمان ها کمک میکند .نقش هر فرد را مشخص میکند و وظایفی که هر کس دارد را مشخص میکند . بعنی فرایند کاری را میشود با این سیستم مشخص کرد .موضوع دوازدهم Message Queue (such as Kafka and RabbitMQ) است .یک ابزار نرم افزاری است که کاری میکند که اجزای مختلف سیستم با هم ارتباط برقرار کنند بدون اینکه به همدیگر وابستگی زیادی داشته باشند .موضوع سیزدهم Container orchestration است . کانتینر ها بسته های سبکی هستند که هر چیزی که برنامه نیاز دارد تا به صورت مستقل کار کند را داخلش دارد . وقتی برنامه‌ها رو با فناوری کانتینر اجرا می‌کنیم  Container Orchestration به ما کمک می‌کنه این جعبه‌ها رو به صورت خودکار و هوشمندانه اجرا، متوقف، جابه‌جا، یا هماهنگ کنیم.موضوع چهاردهم Multi-Tenancy Architecture است .  یک نرم‌افزار واحد به چند مشتری یا سازمان مختلف به‌صورت هم‌زمان سرویس بده، بدون اینکه اون‌ها از وجود هم باخبر باشن یا به داده‌های هم دسترسی داشته باشن. برای مثال خانه هایی که در یک اپارتمان قرار دارند و اپارتمان هایی که در ان ساختمان قرار دارند . ساختمان نرم افزار است و هر خانواده که در یک اپارتمان زندگی میکند یک سازمان.موضوع پانزدهمEnterprise Integration Patterns است . مجموعه‌ای از الگوهای طراحی که کمک می‌کنن سیستم‌های مختلف یک سازمان که جداگانه ساخته شدن، بتونن با هم ارتباط برقرار کنن و اطلاعات رد و بدل کنن.برای مثال ممکن است بخش های مختلف یک سیستم مثل سفارش و پرداخت جداگانه از هم ساخته شده باشند اما وقتی کاربری خریدی را انجام میدهد باید پرداخت انجام شود و سفارش ثبت شود و موجودی تغیر کند . این الگوی طراحی باعث میشود بین اجزای مختلف سیستم پیام رد و بدل شود و با هم در ارتباط باشند .https://www.irandnn.irfaragostar.nethttps://www.systemgroup.nethttps://quera.orghttps://mihanwebhost.comhttps://blog.faradars.orghttps://virgool.io mahyar panahi mahyar panahi Thu, 15 May 2025 00:27:11 +0330