https://virgool.ir/feed/@heidarzade.mhfa2026-11-11 19:10:29https://files.virgool.ir/upload/users/1886851/avatar/k5aw7r.jpghttps://virgool.ir/@heidarzade.mhhttps://virgool.ir/@heidarzade.mh/ارتقای-پوشش-آزمون-نرم-افزار-از-طریق-اولویت-بندی-متغیرهای-علی-با-استفاده-از-graph-autoencoders-f960d7nbmdh9چکیدهتولید خودکار داده‌های آزمون برای سیستم‌های شیءگرا، به دلیل پیچیدگی تعاملات میان اشیاء و الگوی ترکیب (Composition)، با چالش‌های جدی روبرو است. روش‌های سنتی مبتنی بر جستجو اغلب در مواجهه با وابستگی‌های پنهان وضعیت اشیاء، در بهینگی‌های محلی گرفتار شده و از دستیابی به پوشش کد بالا باز می‌مانند. هدف این پژوهش، ارائه روشی نوین مبتنی بر یادگیری عمیق برای کشف گره‌های استراتژیک در گراف نرم‌افزار است که تغییر آن‌ها بیشترین پتانسیل را برای باز کردن مسیرهای اجرایی جدید دارد. در این مطالعه، ابتدا کد منبع Apache Hadoop به یک گراف وابستگی شامل کلاس‌ها، متدها و فیلدها تبدیل شد که منجر به ایجاد گرافی با بیش از ۲۴۰,۰۰۰ گره و ۷۰۰,۰۰۰ یال گردید. سپس، یک مدل Graph Autoencoder – GAE با استفاده از لایه‌های کانولوشن گراف (GCN) پیاده‌سازی شد تا ساختار و وابستگی‌های پنهان سیستم را در یک Embedding Space یاد بگیرد. در نهایت، با تحلیل بردارها در Embedding Space، متغیرهایی که دارای بیشترین امتیاز علیت بودند، استخراج شدند. نتایج نشان داد که مدل پیشنهادی می‌تواند بدون نیاز به اجرای کد، متغیرهای کلیدی سیستم را شناسایی کند. ۱۰ متغیر برتر شناسایی شده شامل Loop Counters، System Status Flags و Configuration Identifiers بودند که نقاط گلوگاه برای کنترل جریان اجرا محسوب می‌شوند. این امر نشان‌دهنده توانایی مدل در درک ساختار معنایی برنامه است. این پژوهش نشان می‌دهد که شبکه‌های عصبی گرافی پتانسیل بالایی برای استخراج روابط علّی در نرم‌افزارهای مقیاس بزرگ دارند. لیست متغیرهای استخراج شده می‌تواند به عنوان یک نقشه راه به الگوریتم‌های تولید آزمون مانند EvoSuite تزریق شود تا با تمرکز بر این موضوع، از دام بهینگی محلی خارج شده و پوشش آزمون را افزایش دهند.واژگان کلیدی: آزمون نرم‌افزار، تولید داده آزمون، شبکه‌های عصبی گرافی(GNN)، تحلیل ایستای کد، Apache Hadoop.ادبیات موضوع: مروری بر روش‌های تولید داده آزمون، چالش‌های شیء‌گرایی و کاربرد هوش مصنوعی و شبکه ارتباطات در نرم‌افزارنرم‌افزارها به جزء جدایی‌ناپذیر زندگی بشر تبدیل شده‌اند و از ساده‌ترین لوازم خانگی تا حیاتی‌ترین زیرساخت‌های صنعتی را مدیریت می‌کنند. این گستردگی باعث شده است که ویژگی‌های کیفی نرم‌افزار نظیر قابلیت اطمینان، نگهداری‌پذیری و امنیت، بیش از پیش اهمیت یابند. کیفیت نرم‌افزار در واقع ستون فقرات موفقیت و پایداری سیستم‌ها محسوب می‌شود و نقص در آن نه تنها به نارضایتی کاربران می‌انجامد، بلکه هزینه‌های مالی و اعتباری سنگینی را به سازمان‌ها تحمیل می‌کند. در این راستا، آزمون نرم‌افزار به عنوان روش اصلی صنعت برای ارزیابی و تضمین کیفیت شناخته می‌شود. با توجه به پیچیدگی روزافزون سیستم‌ها، تولید خودکار مجموعه‌های آزمون (Test Suites) به یک ضرورت تبدیل شده است تا ضمن کاهش تلاش‌های دستی، میزان پوشش آزمون را افزایش دهد. این حوزه همواره یکی از زمینه‌های فعال پژوهشی بوده و روش‌های متنوعی مانند آزمون مبتنی بر جستجو (SBST)، تولید تصادفی هدایت‌شده با بازخورد و اجرای نمادین پویا برای آن توسعه یافته است.آزمون مبتنی بر جستجو (SBST) و محدودیت‌های روش‌های آزمون مبتنی بر جستجو، و به‌ویژه ابزارهایی مانند EvoSuite، در سال‌های اخیر توجه زیادی را به خود جلب کرده‌اند و توانسته‌اند در دستیابی به معیارهای پوشش کد (Code Coverage) عملکرد قابل‌قبولی از خود نشان دهند. اساس کار این روش‌ها، تبدیل مسئله تولید داده آزمون به یک مسئله بهینه‌سازی است که در آن الگوریتم‌های جستجو (مانند الگوریتم ژنتیک) سعی می‌کنند ورودی‌هایی را بیابند که بیشترین بخش‌های کد را اجرا کنند.با این حال، تحقیقات جدید نشان می‌دهد که صرفِ دستیابی به پوشش بالای کد، لزوما به معنای کشف مؤثر خطاها نیست. برای مثال، مطالعات روی مجموعه داده Defects4J نشان داده است که ابزارهای پیشرویی مانند EvoSuite، حتی با رسیدن به پوشش ۱۰۰ درصدی شاخه، تنها قادر به کشف حدود ۲۳ درصد از نقص‌های واقعی بوده‌اند. علت اصلی این ضعف، اتکای این ابزارها به ورودی‌های تصادفی یا مقادیر ثابتی است که با واقعیت‌های معنایی برنامه و مشخصات پروژه همخوانی ندارند. علاوه بر این، این ابزارها در تولید دنباله‌ای از فراخوانی‌های پیچیده که برای ساخت اشیاء در وضعیت‌های خاص لازم هستند، دچار مشکل می‌شوند و نمی‌توانند سناریوهای عمیق را پوشش دهند. این ناتوانی در مدیریت ساختارهای پیچیده، نیاز به استراتژی‌های هوشمندتر برای تولید ورودی‌های باکیفیت را برجسته می‌کند.رویکردهای نوین در تولید داده آزمون برای غلبه بر محدودیت‌های روش‌های سنتی، محققان رویکردهای مختلفی را پیشنهاد کرده‌اند:روش‌های مبتنی بر محدودیت: یکی از این روش‌ها، تغییر فضای جستجو از فضای مقادیر ورودی به فضای محدودیت‌ها است. در این رویکرد، به جای جستجوی کورکورانه مقادیر، الگوریتم ژنتیک بر روی پارامترهای محدودیت‌ساز (Path Constraints) تمرکز می‌کند. سیستم ابتدا محدودیت‌های لازم برای رسیدن به شاخه‌های هدف را یاد می‌گیرد و سپس با حل آن‌ها، داده آزمون دقیق تولید می‌کند.آزمون در زبان‌های پویا: در حالی که ابزارهایی مانند EvoSuite برای زبان‌های با نوع‌دهی ایستا (مانند جاوا) توسعه یافته‌اند، زبان‌های پویا مانند پایتون چالش‌های متفاوتی دارند. فقدان اطلاعات Type در زمان کامپایل باعث می‌شود فضای جستجو بسیار بزرگ شود. ابزار PYNGUIN به عنوان راهکاری برای این زبان‌ها توسعه یافته تا با پیاده‌سازی الگوریتم‌های جستجو، بر این چالش غلبه کند.آزمون جهش(Mutation Testing): این روش به عنوان مکانیزمی قدرتمند برای ارزیابی کیفیت آزمون‌ها مطرح است اما هزینه محاسباتی بالایی دارد. چالش اصلی در اینجا، تولید داده‌هایی است که بتوانند جهش‌یافته‌های سرسخت (Stubborn Mutants) را از بین ببرند. رویکردهای جدیدی مانند چارچوب TDGMSE با معرفی شاخص‌های ترکیبی (قابلیت دسترسی و آلوده‌سازی) و استفاده از تکامل مجموعه، سعی در حل این مشکل دارند. همچنین روش TAMMEA با استفاده از مدل‌های زنجیره مارکوف برای کاهش شاخه و الگوریتم تخمین توزیع (EDA)، تلاش می‌کند با داده آزمون کمتر، جهش‌یافته‌های بیشتری را بکشد. استفاده از شبکه‌های عصبی کانولوشنی (CNN) برای تخمین برازندگی در الگوریتم‌های ژنتیک چند‌جمعیتی نیز از دیگر نوآوری‌های این حوزه است.چالش‌های اختصاصی در آزمون سیستم‌های شیء‌گرا به دلیل ماهیت ساختاری خود، پیچیدگی‌های منحصربه‌فردی را به فرآیند آزمون تحمیل می‌کنند. در این سیستم‌ها، واحد آزمون از «زیربرنامه» به «کلاس» تغییر می‌کند و درستی عملکرد تنها به ورودی وابسته نیست، بلکه به وضعیت داخلی (Internal State) شیء نیز بستگی دارد.State Problem و کپسوله‌سازی: به دلیل اصل کپسوله‌سازی، دسترسی مستقیم به وضعیت اشیاء محدود است و تنها از طریق دنباله‌ای از فراخوانی متدها می‌توان وضعیت را تغییر داد. این مسئله، تولید تست برای سناریوهایی که نیاز به وضعیت خاصی دارند را برای الگوریتم‌های جستجو دشوار می‌کند.وراثت و چندریختی: ویژگی‌هایی مانند وراثت و اتصال پویا (Dynamic Binding) باعث می‌شوند معیارهای پوشش سنتی ناکارآمد باشند. ممکن است یک کلاس والد پوشش داده شود، اما این پوشش توسط شیءای از کلاس فرزند صورت گرفته باشد و رفتار خودِ کلاس والد هرگز آزموده نشود. همچنین، بسیاری از خطاها ناشی از تعامل نادرست بین متدهای کلاس فرزند و وضعیت‌های به ارث رسیده از والد هستند که معیارهای سنتی آن‌ها را نادیده می‌گیرند.پیچیدگی ترکیب (Composition): یکی از چالش‌برانگیزترین الگوها، رابطه ترکیب است. در اینجا، یک کلاس نگهدارنده شامل چندین شیء مؤلفه است. صحت عملکرد سیستم به تعاملات شبکه ای و پیچیده میان این اجزا بستگی دارد. الگوریتم‌های جستجوی فعلی اغلب در درک معنایی این روابط و تولید دنباله فراخوانی‌های صحیح برای مقداردهی به اشیاء داخلی ناتوان هستند و در بهینگی‌های محلی گرفتار می‌شوند.کاربرد هوش مصنوعی و یادگیری عمیق در آزمون نرم‌افزار در سال‌های اخیر، استفاده از یادگیری ماشین (ML) و یادگیری عمیق(DL) برای هوشمندسازی تولید داده آزمون رواج یافته است.مدل‌های زبانی بزرگ (LLMs): مدل‌هایی مانند GPT-3.5 به دلیل توانایی در درک متن، برای استخراج ورودی‌های معنادار از (Bug Reports) استفاده می‌شوند. رویکردهای ترکیبی که از LLM برای پالایش ورودی‌های استخراج‌شده توسط Regex استفاده می‌کنند، توانسته‌اند نرخ کشف نقص ابزارهایی مانند EvoSuite را بهبود بخشند. همچنین تکنیک‌های مهندسی پرامپت مانند Tree-of-Thoughts به این مدل‌ها کمک می‌کند تا با استدلال ساختاریافته، ورودی‌های دقیق‌تری تولید کنند.شبکه‌های مولد تخاصمی (GANs): تحقیقاتی بر روی استفاده از GANها برای یادگیری رفتار نرم‌افزار و تولید داده آزمون متمرکز شده‌اند. برای مثال، مدل WGAN-GP برای بهبود پوشش شاخه در برنامه‌های بزرگ بدون نیاز به تحلیل‌های پیچیده ایستا پیشنهاد شده است.بهینه‌سازی چند وظیفه‌ای و چند هدفه: برخی روش‌ها از یادگیری مشارکتی چند وظیفه‌ای (Multi-task learning) استفاده می‌کنند تا دانش کسب‌شده از آزمون یک تابع را به توابع مشابه منتقل کنند و مشکل انفجار مسیر را کاهش دهند. همچنین در بهینه‌سازی چند هدفه، ترکیب اهداف پوشش کد با اهداف مبتنی بر نقص (مانند تعداد استثناءها) نتایج بهتری نسبت به تمرکز صرف بر پوشش کد داشته است.با وجود تمام پیشرفت‌های ذکر شده، یک شکاف اساسی در ادبیات موضوع وجود دارد و آن عدم درک و مدل‌سازی روابط علّی در ساختارهای پیچیده شیء‌گرا است. اکثر روش‌های موجود (چه سنتی و چه مبتنی بر هوش مصنوعی) بر بهینه‌سازی پارامترها یا استخراج ورودی تمرکز دارند و توجهی به کشف روابط علت و معلولی عمیق در الگوهایی نظیر ترکیب ندارند. همان‌طور که بیان شد، این پیچیدگی‌های تعاملی مانع اصلی دستیابی به پوشش کامل هستند.برای پر کردن این خلاء، می‌توان از پیشرفت‌های حوزه‌های دیگر نظیر زیست‌شناسی الهام گرفت. در زیست‌شناسی محاسباتی، مدل‌های یادگیری عمیق مانند D2CL توانسته‌اند در سیستم‌های بسیار پیچیده با ابعاد بالا (مانند تعاملات ژنی در سلول)، روابط علی را کشف کنند. این مدل‌ها بر اساس فرضیه متا-ژنراتور عمل می‌کنند که می‌گوید روابط علی، امضاهای ساختاری و آماری مشخصی در داده‌ها بر جای می‌گذارند. مدل D2CL با استفاده از معماری دو شاخه (شامل شبکه عصبی کانولوشنی برای تحلیل توزیع داده و شبکه عصبی گرافی برای تحلیل ساختار)، این امضاها را یاد می‌گیرد و می‌تواند روابط ناشناخته را پیش‌بینی کند.این پژوهش با فرض اینکه سیستم‌های نرم‌افزاری شیء‌گرا نیز از پیچیدگی ساختاری مشابهی پیروی می‌کنند، پیشنهاد می‌دهد که می‌توان از منطق مشابهی (تحلیل همزمان گراف نرم‌افزار و توزیع داده‌های اجرا) برای کشف متغیرهای تاثیرگذار بر پوشش آزمون استفاده کرد. این رویکرد می‌تواند با شناسایی گلوگاه‌های علّی در گراف ترکیب اشیاء، فرآیند جستجوی داده آزمون را هوشمندانه هدایت کرده و از گرفتاری در بهینگی‌های محلی جلوگیری کند.رویکرد این پژوهشپژوهش حاضر با الهام از مدل‌های کشف روابط علّی در زیست‌شناسی نظیر مدل D2CL که برای تحلیل ژن‌ها استفاده می‌شود، یک رویکرد نوین را پیشنهاد می‌دهد. فرضیه اصلی ما این است که همان‌طور که در شبکه‌های زیستی، برخی ژن‌ها نقش تنظیم‌کننده اصلی (Master Regulator) را دارند، در گراف نرم‌افزار نیز متغیرها و فیلد‌هایی وجود دارند که نقش گلوگاه‌های اطلاعاتی را بازی می‌کنند. شناسایی و تغییر این متغیرها، موثرترین راه برای تغییر وضعیت شیء و در نتیجه افزایش پوشش آزمون است.مراحل پیاده‌سازی این ایده بر روی چارچوب عظیم Apache Hadoop تشریح می‌شود. ما با استخراج یک گراف وابستگی غول‌پیکر و آموزش یک مدل Graph Autoencoder - GAE، موفق به استخراج سیگنال‌های علَی از دل میلیون‌ها خط کد شدیم.گام نخست، تبدیل کد منبع ایستا به یک ساختار قابل فهم برای ماشین بود. ما نیاز به گرافی داشتیم که نه تنها کلاس‌ها، بلکه ریزترین جزئیات اجرایی را نیز مدل کند. برای این منظور، چارچوب Apache Hadoop به عنوان مورد مطالعاتی انتخاب شد. دلیل این انتخاب، استفاده گسترده از الگوهای شیءگرا، حجم عظیم کد (بیش از ۱.۵ میلیون خط) و پیچیدگی تعاملات توزیع‌شده بود.با استفاده از Parserها، ما یک گراف Call and Data Usage Graph استخراج کردیم که شامل سه نوع گره بود:کلاس‌ها (Classes): به عنوان ظروف اصلی منطق برنامه.متدها (Methods): به عنوان واحدهای اجرایی.فیلدها/متغیرها (Fields): به عنوان حافظه‌های وضعیت سیستم.یال‌های گراف نیز نشان‌دهنده روابط معنایی بودند:رابطه HAS_METHOD و HAS_FIELD ساختار کلاسرابطه CALLS جریان کنترل.رابطه ACCESSES جریان داده.خروجی این مرحله، گرافی عظیم با مشخصات زیر بود:تعداد گره‌ها: ۲۴۴,۷۸۹ گرهتعداد یال‌ها: ۷۳۹,۸۶۰ یالبرای اینکه شبکه عصبی بتواند گراف را پردازش کند، هر گره نیاز به یک بردار ویژگی (Feature Vector) داشت. در ابتدا، از روش One-Hot Encoding برای نوع گره (کلاس، متد، فیلد) استفاده شد. اما در آزمایش‌های اولیه با Symmetry Problem مواجه شدیم.از آنجا که هزاران متغیر در سیستم وجود داشتند که از نظر نوع یکسان بودند، مدل GNN قادر به تمایز قائل شدن بین آن‌ها نبود و به همه امتیاز یکسانی می‌داد. برای شکستن این تقارن و دادن هویت منحصر‌به‌فرد به هر گره، ما استراتژی تزریق نویز تصادفی Random Noise Injection را پیاده‌سازی کردیم و بردار ویژگی نهایی برای هر گره به صورت زیر تعریف شد:که در آن Type یک بردار ۳ بعدی و Noise یک بردار ۱۶ بعدی از اعداد تصادفی نرمال بود. این کار باعث شد ورودی شبکه ۱۹ بعدی شود و مدل بتواند هر گره را به صورت مجزا ردیابی کند.مدل اصلی استفاده شده، یک خودرمزنگار گرافی (GAE) است که از دو بخش تشکیل شده است:رمزنگار(Encoder): یک شبکه عصبی کانولوشنی گراف (GCN) دو لایه که اطلاعات ساختاری و ویژگی‌های گره‌ها را دریافت کرده و آن‌ها را به یک Latent Space با ابعاد کمتر فشرده می‌کند.Z = GCN(X, A)در اینجا Z ماتریس Embedding نهایی است که حاوی امضای ساختاری هر گره می‌باشد.رمزگشا (Decoder): این بخش تلاش می‌کند تا ماتریس مجاورت گراف (A) را از روی فضای نهان (Z) بازسازی کند. هدف این است که مدل یاد بگیرد کدام گره‌ها باید به هم متصل باشند.Loss Function مدل، میزان خطای بازسازی گراف را می‌سنجد. کاهش این خطا به این معناست که مدل توانسته است منطق ارتباطی موجود در نرم‌افزار Hadoop را یاد بگیرد.پیاده‌سازی با استفاده از کتابخانه PyTorch Geometric انجام شد. آموزش مدل بر روی گراف ۲۴۴ هزار گره‌ای Hadoop طی ۲۰۰ epoch صورت گرفت.خطا از مقدار اولیه حدود ۱.۷۰ شروع شد و به سرعت کاهش یافت تا در نهایت در مقدار ۱.۰۲ تثبیت شد. این همگرایی نشان می‌دهد که مدل توانسته است الگوهای تکرار شونده در کد مانند الگوهای Getter/Setter، الگوهای Factory، و زنجیره‌های فراخوانی را درک کند و آن‌ها را در فضای برداری (Z) فشرده نماید.پس از آموزش، ما ماتریس Z را استخراج کردیم. طبق تئوری مدل‌های علّی، گره‌هایی که دارای مرکزیت و نفوذ بیشتری در شبکه هستند، در فضای نهان دارای بردار بزرگتری خواهند بود. ده متغیر برتری که مدل به عنوان تاثیرگذارترین نقاط سیستم شناسایی کرد عبارتند از:1.      org.apache.hadoop.metrics2.impl.PurgableSource.nextKey2.      org.apache.hadoop.mapred.TestJobClientGetJob.runningJob3.      org.apache.hadoop.hdfs.tools.offlineImageViewer.TestOfflineImageViewer.FILE_NODE_ID_14.      org.apache.hadoop.mapred.TestJobClientGetJob.getJobRetriesCounter5.      org.apache.hadoop.hdfs.tools.offlineImageViewer.TestOfflineImageViewer.LOG6.      org.apache.hadoop.mapred.TestJobClientGetJob.lastGetJobRetriesCounter7.      org.apache.hadoop.hdfs.tools.offlineImageViewer.TestOfflineImageViewer.FILE_NODE_ID_28.      org.apache.hadoop.hdfs.tools.offlineImageViewer.TestOfflineImageViewer.TEST_RENEWER9.      org.apache.hadoop.yarn.server.globalpolicygenerator.webapp.GPGPoliciesBlock.gpg10.  org.apache.hadoop.mapred.TestJobClientGetJob.TEST_ROOT_DIRحضور متغیرهایی مانند runningJob و getJobRetriesCounter و lastGetJobRetriesCounter در صدر لیست، بسیار معنادار است. در برنامه‌نویسی همروند و توزیع‌شده مانند Hadoop MapReduce،  Retries و Running flags دقیقا همان نقاطی هستند که جریان کد را تعیین می‌کنند. یک ابزار تست تصادفی ممکن است هزاران بار متغیرهای رشته‌ای بی‌اهمیت (مثل نام کاربر) را تغییر دهد و هیچ اتفاقی نیفتد. اما تغییر RetryCounter از 0 به 1، بلافاصله کد را وارد بلوک‌های catch و مکانیزم‌های Error Recovery می‌کند. مدل GNN ما بدون اینکه بداند Retry  چیست، تنها از روی ساختار گراف فهمیده است که این متغیر به شاخه‌های حیاتی کد متصل است.متغیرهایی مثل FILE_NODE_ID و TEST_ROOT_DIR و gpg  نیز شناسایی شدند. این‌ها پارامترهای پیکربندی هستند. تغییر FILE_NODE_ID در ماژول HDFS (سیستم فایل توزیع شده) باعث می‌شود الگوریتم‌های پردازش تصویر روی داده‌های متفاوتی کار کنند. این متغیرها اغلب در ابتدای زنجیره اجرا قرار دارند و تغییر آن‌ها Butterfly Effect در کل سیستم دارد. شناسایی خودکار این پارامترها تاییدی بر فرضیه متا-ژنراتور است؛ یعنی روابط علّی در سیستم‌های نرم‌افزاری، امضای ساختاری مشخصی دارند که مدل آن را آموخته است.ارزیابیبرای ارزیابی کارایی روش پیشنهادی،  نتیجه  از دو منظر کیفی و کمی مورد بررسی قرار گرفت. در روش‌های سنتی نظیر Fuzzing، انتخاب متغیرها برای Mutation اغلب تصادفی است. اگر از بین ۵۰,۰۰۰ متغیر Hadoop به صورت تصادفی انتخاب کنیم، احتمال بالایی وجود دارد که متغیرهایی نظیر DEBUG_STRING یا tempVar انتخاب شوند که تغییر آن‌ها هیچ تاثیری بر منطق برنامه ندارد. متغیرهای انتخاب شده ما همگی دارای بار معنایی بالا هستند. این انتخاب‌ها، فضای جستجو را برای ابزار آزمون به شدت کاهش می‌دهد.زیرگراف مربوط به متغیر PurgableSource.nextKey بررسی شد. این متغیر در مرکز یک ستاره قرار دارد که به متدهای متعددی در سیستم Metrics متصل است. این تایید می‌کند که بردار Z که مدل یاد گرفته است، همبستگی مستقیمی با Graph Centrality و پیچیدگی اتصالات دارد. مدل به درستی یاد گرفته است که گره‌هایی که پل ارتباطی بین ماژول‌های مختلف هستند، کاندیداهای بهتری برای روابط علّی می‌باشند.جمع‌بندی و نتیجه‌گیریاین پژوهش با هدف حل مشکل تولید داده آزمون در سیستم‌های پیچیده شیءگرا، یک رویکرد نوین مبتنی بر تلفیق تحلیل ایستا و یادگیری عمیق را ارائه کرد. ما نشان دادیم که:می‌توان کد منبع عظیم و پیچیده را به یک گراف یکپارچه تبدیل کرد که تمام جزئیات تعاملات (وراثت، ترکیب، جریان داده) را حفظ کند.مدل‌های GNN به‌ویژه Autoencoderها قادرند ساختار پنهان و روابط علّی موجود در نرم‌افزار را بدون نیاز به اجرای کد یاد بگیرند.متغیرهای استخراج شده  برای تست به خوبی انتخاب شدند.منابع:[1] M. Ghoreshi و H. Haghighi، "Object Coverage Criteria for Supporting Object-oriented Testing،" Research Square، 2022.[2] P. Amman و j. Offutt، Introduction to software testing، United States of America: Cambridge University Press، 2008.[3] W. C، Ouédraogo، L. Plein، K. Kaboré، A. Habib، J. Klein، D. Lo، T. F و Bissyandé، " Enriching automatic test case generation by extracting relevant test inputs from bug reports،" 2025.[4] A. Fontes، G. Gay و R. Feldt، "Exploring the Interaction of Code Coverage and Non- Coverage Objectives in Search- Based Test Generation،" 2025.[5] F. Tamagnan، A. Vernotte، F. Bouquet و B. Legeard، "Generation of Regression Tests From Logs With Clustering Guided by Usage Patterns،" 2023.[6] S. Lukasczyk، FlorianKroiß و GordonFraser، "An empirical study of automated unit test generation for Python،" 2023.[7] L. Taoa، X. Dang، J. Hu، D. Gong، G. Hao، X. Yao و B. Huang، "Optimizing test data generation using SI_CNNpro-enhanced MGA for mutation testing،" 2024.[8] C. Weia، X. Yaoa، D. Gongb، H. Liuc و X. Dangd، "Set evolution basedtest datageneration for killing stubborn mutants،" 2024.[9] C. Wei، X. Yao، D. Gong و H. Liu، "Test Data Generation for Mutation Testing Based on Markov Chain Usage Model and Estimation of Distribution Algorithm،" 2024.[10] M. Ghoreshi و H. Haghighi، "An incremental method for extracting tests from object-oriented specification،" 2016.[11] X. GUO، H. OKAMURA و T. DOHI، "Automated Software Test Data Generation With Generative Adversarial Networks،" 2022.[12] AfonsoFontes و GregoryGay، "The integration of machine learning into automated test generation: A systematic mapping study،" 2022.[13] J. Cao، H. Huang، F. Liu، Q. Zhang و Z. Hao، " Multi-task collaborative method based on manifold optimization for automated test case generation based on path coverage،" 2024.[14] K. Lagemann، C. Lagemann، B. Taschler و S. Mukherjee، "Deep Learning of causal Structures in high dimensions under data limitations،" nature machine intelligence، 2023.[15] L. B. a. M. Miraz، "TestFul: Automatic Unit-Test Generation for Java Classes،" 2010. محمدحسین حیدرزادهمحمدحسین حیدرزادهWed, 11 Feb 2026 09:22:49 +0330https://virgool.ir/@heidarzade.mh/software-architecture-njywepybeawr1- Infrastructure as Code (IaC)بارها شده به مشکلات مربوط به راه‌اندازی زیرساخت برای توسعه نرم‌افزار برخورده باشیم و در ادامه این مشکلات، زمان و هزینه‌ای را از دست دادیم که می‌توانستیم آن را صرف توسعه نرم‌افزار و یا کارهای مفید دیگری کنیم. مشکل زمانی شدیدتر می‌شود که این امر تکرار پذیر شود که در اغلب موارد سراغ نوشتن اسکریپت‌هایی می‌رویم که این فرآیند را هموارتر کنند. ایده‌ی "کد" به جای "نصب زیرساخت به صورت دستی" از همین مشکلات سرچشمه می‌گیرد. مفهوم Infrastructure as Code (IaC) بیان می‌کند برای راه‌اندازی زیرساخت از کدها استفاده شود. مزایای زیادی برای اینکار شمرده می‌شود که به چندی از آنها اشاره می‌کنیم:خودکارسازی فرآیند نصب بدون دخالت انسان و کاهش خطاهای انسانی در نصب زیرساختقابلیت تکرار مجدد برای یک زیرساخت یکسان برای محیط‌های توسعه، تست و عملیاتقابلیت نسخه‌بندی زیرساخت و ایجاد Branch برای توسعه زیرساخت بدون آنکه نسخه اصلی متاثر تغییرات شود.تست زیرساخت ارائه شده قبل از اجرای آن در محیط‌های عملیاتیاستفاده از best-practiceها. در واقع می‌توان از زیرساخت‌های توسعه داده شده توسط دیگران که جواب خود را پس داده استفاده کرد.ابزارهای مختلفی برای تسهیل اجرایی کردن ایده‌ی IaC وجود دارند که از معروف‌ترین آنها می‌توان به Ansible و Terraform اشاره کرد.2- API Gateway & Service Meshدو مفهوم API Gateway و Service Mesh در کنار هم عمده‌ی تعاملات بین سرویسی و کلاینت-سرویسی را در نرم‌افزار شکل می‌دهند. API Gateway نقطه‌ی ورود درخواست‌ها به نرم‌افزارهای میکروسرویسی و یکپارچه (Monolithic) می‌باشد که به صورت خاص در معماری میکروسرویس نقش مهمی را ایفا می‌کند. API Gateway جلوی درخواست‌های کلاینت قرار می‌گیرد. کلاینت‌ها (موبایل اپلکیشن‌ها و یا وب‌اپلیکیشن‌ها) به جای آنکه مستقیما با سرویس‌ها صحبت کنند، درخواست خود را به API Gateway می‌دهند. API Gateway در قدم اول درخواست‌ها را به سرویس مورد نظر Route می‌کند و در این بین می‌تواند بار روی سیستم را مدیریت کرده و با استفاده از الگوریتم‌های Load Balancing، بار درخواست‌ها را بین سرویس‌ها پخش کند. همچنین API Gateway می‌تواند لایه‌ای برای احراز هویت (Authentication و Authorization) درخواست‌ها باشد تا درخواست‌‌های غیر مجاز، لایه‌ی سرویس‌های نرم‌افزار را تحت تاثیر قرار ندهند. همچنین API Gateway می‌تواند با مدیریت تعداد درخواست‌ها و اعمال Rate Limit و یا ایجاد صف برای درخواست‌ها، حجم درخواست‌هایی که به سرویس‌ها می‌رسد را مدیریت کند. در ادامه‌ی مدیریت حجم درخواست‌ها می‌توان با تعریف درخواست‌های پر تکرار که عموما جواب یکسانی دارند، لایه‌هایی از کش تعریف کرد تا بتوان پردازش‌های تکراری در سطح سرویس را تا حد خوبی کاهش داد.در کنار ارتباط بین کلاینت و سرویس، ارتباط بین سرویسی را داریم. جایی که لازم است سرویس‌ها همدیگر را پیدا کنند و در ارتباطی پایدار و امن اطلاعات را منتقل کنند. Service Meshدر اصل یک لایه‌ی زیربنایی می‌باشد که ارتباط بین سرویسی را تسهیل می‌کند. از فواید استفاده از Service Mesh می‌توان به موارد زیر اشاره کرد:امکان مشاهده‌پذیری بیشتر بین سرویس‌ها با اضافه کردن Logهای سیستمیرمزنگاری ارتباطات بین سیستمیمدیریت حجم ترافیک و اضافه کردن Load Balancing بین سرویسیمدیریت ترافیک درخواست‌ها برای Canary Deploymentمانیتورینگ وضعیت درخواست‌هاابزارهای مختلفی برای API Gateway و Service Mesh وجود دارند که می‌توان به nginx و Consul اشاره کرد.3- CQRS (Command Query Responsibility Segregation)عمده درخواست‌هایی که در نرم‌افزار به سمت سرویس‌ها ارسال می‌شوند در دو دسته مجزا تقسیم می‌شوند:کامند: تغییر وضعیت سیستم که منجر به تغییر در دیتایس‌ها می‌شود. (درخواست ساخت کاربر)کوئری: گرفتن اطلاعات از وضعیت فعلی سیستم. (درخواست گرفتن لیست کابران)بعضی وقت‌ها پیش می‌آید که ساختاری برای دیتابیس طراحی شده است که نوشتن بر روی دیتابیس آسان است اما خواندن از دیتابیس به همان میزان پیچیدگی دارد. ممکن است با کمی افزایش پیچیدگی در نوشتن، پیچیدگی خواندن را کاهش دهیم و همواره درحال trade-off برای این موضوع باشیم. حال آنکه CQRS الگویی را معرفی می‌کند که بتوان پیچیدگی این مسئله را کمی تقلیل داد. در CQRS عنوان می‌شود که دیتابیس مربوط به خواندن اطلاعات از دیتابیس مربوط به ذخیره اطلاعات جدا باشد و این دو دیتابیس با الگوریتم‌های مشخصی با هم سینک شوند. 4- Event-Driven Architecture (EDA)در معماری مبتنی بر رخداد سیستم‌ها از طریق واکنش‌ها (Events) با یکدیگر تعامل می‌کنند. به عبارت بهتر سیستم‌ها به جای آنکه با یکدیگر به صورت مستقیم ارتباط برقرار کنند از واسط‌هایی استفاده می‌کنند. این ارتباط بیشتر برای اعلام اتفاقی در سامانه استفاده می‌شود. برای مثال: کاربری ساخته شد. گروهی حذف شد. احراز هویت شخصی با موفقیت انجام شد. کالایی به سمت مشتری ارسال شد.رخدادها ویژگی‌ها منحصر به فردی دارند. اول آنکه مقصد آنها توسط فرستنده مشخص نیست. چرا که فرستنده پیامی را مخابره می‌کند و این گیرندگان هستند که مطابق نیاز به دنبال آن درخواست می‌روند. دوم آنکه ممکن از چند گیرنده آن پیام را دریافت کنند و سوم آنکه فرستنده به جواب مخابره پیام خود از طریق گیرندگان نیازی ندارد.استفاده از معماری مبتنی بر رخداد سرعت توسعه را افزایش و وابستگی (coupling) بین سرویس‌ها را کاهش می‌دهد.برای پیاده‌سازی Event-Driven Architecture ابزارهای متعددی وجود دارد که از معروف‌ترین آنها می‌توان به Kafka و RabbitMQ اشاره کرد.5- Serverless Architectureدر معماری Serverless پیچدگی‌های مربوط به استقرار نرم‌افزار بر روی سرور از چشم توسعه‌دهندگان پنهان می‌ماند. این موضوع به این معنی نیست که هیچ سروری وجود دارد. زیرساخت‌های وجود دارد که توسعه تنها با نوشتن کد (یا حتی چند کلیک) می‌تواند زیرساخت لازم برای توسعه خود را فراهم کند. در این حالت توسعه دهندگان صرفا بر توسعه تمرکز می‌کنند.در بعضی موارد ارائه خدمات به صورت رخداد محور می‌باشد به این صورت که پس از ایجاد یک رخداد، نرم‌افزاری اجرا می‌شود، کاری را انجام می‌دهد و در نهایت خاموش می‌شود که در اینجا Serverless Architectureها می‌توانند مفید باشند چرا که منابع را می‌توانند مدیریت کنند، تخصیص دهند و آزاد کنند.از مزیت‌های معماری Serverless می‌توان به خودکارسازی فرآیند‌ها، کمک به مقیاس‌پذیری بهتر سامانه و افزایش کارایی توسعه اشاره کرد چرا که حجم کاری با حذف دغدغه‌های مربوط به سرور کاهش می‌یابد و تمرکز بر روی توسعه می‌رود.6- API-first Approachرویکرد API-First به فرآیندی اشاره دارد که در آن توسعه‌ی APIها در اولویت قرار می‌گیرد. این رویکرد در سازمان‌هایی استفاده می‌شود که تعداد سرویس‌های زیادی از طریق API با هم ارتباط برقرار می‌کنند. زمانی این رویکرد اتخاذ می‌شود که ساختار ارتباطی بین سرویس‌ها اهمیت زیادی دارد و قرار است چند تیم به طور موازی با یکدیگر ویژگی خاصی را توسعه دهند. اگر ساختار داده‌ی ارتباطی مشخص نباشد ممکن است توسعه‌ها ناهمگون پیش روند و سیستم متحمل هزینه‌های زیادی شود.در این رویکرد، مقیاس‌پذیری سامانه به دلیل آنکه کانال‌های ارتباطی مستند و دقیق هستند افزایش پیدا می‌کند و توسعه به راحتی انجام می‌شود و سرعت توسعه افزایش پیدا می‌کند. یکی از دلایل این امر ایجاد بستری است که باعث می‌شود تیم‌ها به صورت مستقل و موازی با هم توسعه دهند.7- Domain Driven Designمدل طراحی DDD توسط Eric Evans برای توسعه نرم‌افزارها مبتنی بر دامنه کسب و کار معرفی شد. تمرکز اصلی این مدل، طراحی برای کسب و کاری است که قرار است برای آن نرم‌افزار تولید شود و در ادامه بتوان دامنه‌های موجود در کسب و کار را بر روی نرم‌افزار نگاشت کرد. مفاهیم مختلفی در مدل طراحی DDD مطرح می‌شود که می‌توان به آنها اشاره کرد:مدل دامنه: مدلی که مفهومی از مسائل کسب و کار را نشان می‌دهد و فرآیند‌های آن را شرح می‌دهد.زبان مشترک: ایجاد یک زبان مشترک بین توسعه‌دهندگان و افراد کسب و کار برای شرح بهتر مسئلهمرز‌ها (Bounded Context): تقسیم بندی دامنه به بخش‌های مختلف و ایجاد مرزهایی برای جداسازی آنها برای آنکه مشخص باشد هر دامن به صورت مجزا چطور کار می‌کند.اشتراکات (Shared Kernel): لازم است دامنه‌ها بتوانند با یکدیگر ارتباط برقرار کنند و ممکن است اشتراکاتی با یکدیگر داشته باشند. این اشتراکات که به نوعی دامنه‌ای جدید را شکل می‌دهند را Shared Kernel می‌گویند.8- Hexagonal architectureمعماری Hexagonal به جداسازی منطق برنامه از ماژول‌های جانبی مانند Databaseها اشاره دارد. این معماری را Ports and Adapters Architecture نیز می‌نامند. Portها interfaceهای استاندارد و پایداری هستند که راه ارتباطی منطق برنامه با دنیای بیرون هستند و Adapterها پیاده‌سازی مربوط به این portها. از مزیت‌های این مدل معماری می‌توان به انعطاف‌پذیری سیستم اشاره کرد چرا که به راحتی می‌توان ماژول‌های خارجی را جابجا کرد بدون آنکه معماری داخلی منطق نرم‌افزار تغییری کند. همچنین امکان تست نوشتن بهتری برای نرم‌افزار فراهم می‌شود زیر می‌توان بدون هیچ‌گونه وابستگی به ماژول‌های خارجی منطق برنامه را تست کرد و عملکرد آن را ارزیابی کرد. همچنین در فرآیند استقرار محصولاتی با معماری Hexagonal تسهیل می‌شود. چرا که به راحتی می‌توان بدون آنکه interfaceهای قبلی تغییر کند interfaceهای جدیدی را به سامانه اضافه کرد. تا ماژول‌های جدید بتوانند با آن ارتباط برقرار کنند. و اگر interfaceای deprecate شود به راحتی و به مرور زمان می‌توان آن را حذف کرد.9- Event Sourcingدر اکثر نرم‌افزارهایی که توسعه داده می‌شود آخرین وضعیت هر شی درون دیتابیس ذخیره می‌شود و این مدل ذخیره‌سازی با CRUD مدیریت می‌شود که علاوه بر insert ما عملیات update و delete را برای ایجاد تغییر در دیتابیس داریم. اما در Event Sourcing مفهومی معرفی می‌شود که برای ایجاد تغییر در دیتابیس فقط عملیاتی insert را خواهیم داشت و تنها تغیرات مربوط به اشیاء ذخیره می‌شود و برای دریافت اطلاعات اشیاء لازم است تمامی تغییرات مربوط به اشیاء را که در دیتابیس ذخیره شده را ادغام کرد تا به شی اصلی برسیم. از محدودیت‌های این روش می‌توان به عملیات Read اشاره کرد که با ترکیب Event Sourcing و CQRS تا حد خوبی این مشکل بر طرف می‌شود. از مزایای این روش می‌توان به Auditability اشاره کرد که تمامی تغییرات در طول زمان قابل دستیابی می‌باشد.10- Low-code/No-code platformsپلتفرم‌های زیادی تحت عنوان Low-code/No-code platforms مطرح شدند که فرآیند تولید نرم‌افزار را به راحتی drag-and-drop کامپوننت‌ها کردند. با استفاده از این نرم‌افزارهای می‌توان هزینه‌ها را کاهش داد، نرم‌افزارها را با سرعت بیشتری تغییر داد و به راحتی تستشون کرد. این پلتفرم‌ها به صاحبان کسب و کار‌های کوچک که توسعه‌دهنده ندارند کمک می‌کند که بتواند به راحتی نرم‌افزار خود را با دانش ابتدایی توسعه دهند.این پلتفرم‌ها عمدتا برای افرادی مناسب است که دانش پیچیده‌ای از توسعه نرم‌افزار ندارند ولی برای کارهای خاص منظوره می‌خواهند نرم‌افزاری را توسعه دهند و سریع به خروجی برسند.از پلتفرم‌های Low-code می‌توان به OutSystems، Mendix و Appian اشاره کرد.از پلتفرم‌های No-code نیز می‌توان به Wix، Bubble و Airtable اشاره کرد.11- Business Process Management Systems (BPMS)فرآیندهای مختلفی در سازمان‌ها اجرا می‌شود که هرکدام نیازهای خاص منظوره خود را دارند. BPMSها کمک می‌کنند که بتوانیم فرآیندهای سازمان را تعریف و یا مدل کنیم به این منظور که بتوانیم آنها را پایش کنیم و گلوگاه‌ها را شناسایی کنیم و بهبودشان بدهیم. همچنین BPMSها امکان خودکارسازی فرآیندهای سازمانی را تسهیل می‌کنند و جریانات کاری به صورت خودکار و بدون دخالت انسان کار خود را انجام می‌دهد. استفاده از BPMSها باعث کاهش هزینه و افزایش شفافیت و نظارت بهتر بر روی فرآیندها توسط مدیران می‌شود. BPMSها به نوعی زیرساختی برای اتصال ابزارها و یونیت‌های کاری مختلف در سازمان‌ها می‌باشند و با تعریف فرآیندهای کاری بهینه می‌توانند پیچیدگی‌های ارتباطی در سازمان‌ها را به طور موثر کاهش دهند.12- Message Queue (such as Kafka and RabbitMQ)صف‌ها کمک به ارتباطات آسنکرون بین سرویس‌ها می‌کنند. زمانی حجم درخواست‌های بالایی برای پردازش وجود دارد،‌ لازم است آنها جایی ذخیره شوند و به ترتیب اولویت اجرا شوند بدون آنکه اختلالی در عملکرد سیستم به وجود بیاید. از مزیت تکنولوژی‌هایی مثل Kafka و RabbitMQ می‌توان به تضمین Delivery اشاره کرد. به این صورت که پیامی که تحویل این تکنولوژی‌های می‌شود تا زمانی که به موفقیت در سامانه مقصد اجرا نشود از صف پاک نمی‌شود و بارها برای اجرای آن تلاش می‌شود. مثلا اگر سرویسی خاموش باشد، صف تا زمانی که آن سیستم روشن شود پیام را در خود نگه می‌دارد. صف‌ها در معماری رخداد محور (EDA) که پیشتر به آن اشاره کردیم استفاده می‌شوند و می‌توانند رخداد‌ها را به سرویس‌های دیگر منتقل کنند.13- Container orchestration (such as Kubernetes)کانتینر‌ها با ایزوله‌سازی محتوای اجرای استقرار را راحت‌تر از قبل کردند. اما بعضا افزایش تعداد کانتینر‌ها، مدیریت آنها را پیچیده می‌کند. ابزارهایی مانند Kubernetes با ارائه‌ی امکاناتی مدیریت این کانتیرها را راحت‌تر می‌کنند. از مزیتی‌های آن میتوان به مدیریت تعداد کانتینرها بر اساس میزان حجم درخواست‌ها اشاره کرد که با افزایش تعداد درخواست‌ها، تعداد کانتینر‌های مربوطه به صورت خودکار افزایش می‌یابد. از دیگر مزایای Kubernetes می‌توان به مدیریت منابع اشاره کرد به این صورت که می‌تواند کانتینر‌ها را بر اساس میزان منبعی که مصرف می‌کنند در سرورهایی که ظرفیت باز دارند اجرا کند. همچنین این ابزارها می‌توانند وضعیت سیستم را پایش کنند و در صورت ایجاد خطا رفتار مناسبی که برایشان تعریف شده را اجرا کنند.14- Multi-Tenancy Architectureبعضا پیش آمده که میخواهیم یک محصول را به چند مشتری ارائه دهیم. در اینجا لازم است که به ازای هر مشتری یک نسخه از نرم‌افزار را نصب شود که ممکن از هزینه‌های مربوط به سخت‌افزار افزایش پیدا کند و صرف اقتصادی نداشته باشیم. Multi-Tenancy Architecture مفهومی را معرفی می‌کند که در آن با استفاده یک نسخه از نرم‌افزار می‌توان به چند مشتری خدمت ارائه دهیم. فواید و مضراتی برای این مدل معماری گفته میشه که از فواید آن می‌توان به کاهش هزینه زیرساخت و سهولت استقرار اشاره کرد و از مضرات آن می‌توان به خطرات امنیتی اشاره کرد. چرا که اگر نرم‌افزار به درستی پیاده‌سازی نشود ممکن است اطلاعات مشتری‌های مختلف به یکدیگر نمایش داده شود که مطلوب نیست.15- Enterprise Integration Patternsتعدد سیستم‌ها و سامانه‌ها در سازمان‌ها منجر به الزام ایجاد یکپارچگی در برخی لایه‌ها برای مدیریت بهتر آن‌ها می‌شود. الگو‌های مختلفی برای یکپارچه‌سازی سامانه‌ها مطرح می‌شود که به چند نمونه از آنها اشاره می‌شود:الگوی Hub-and-Spoke: در این الگو یک هاب مرکزی به عنوان واسط بین سیستم‌های مختلف عمل می‌کند.الگوی Publish-Subscribe: این الگو زمانی مفید که بعد از ایجاد یک رخداد در سامانه لازم است چند سرویس بروزرسانی شوندالگوی Message-Oriented Middleware: این الگو زمانی استفاده می‌شود که به ارسال اطلاعات به صورت آسنکرون نیاز داریم با تضمین Delivery پیام به سامانه مقصد و امکان ذخیره‌سازی پیام تا زمانی که پردازش نشده است.منابعhttps://aws.amazon.com/what-is/iac/#:~:text=Infrastructure%20as%20code%20(IaC)%20is%20used%20for%20infrastructure%20automation%20to,to%20set%20up%20infrastructure%20environments.https://aws.amazon.com/what-is/service-mesh/#:~:text=A%20service%20mesh%20is%20a,is%20composed%20of%20containerized%20microservices.https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrshttps://aws.amazon.com/what-is/eda/https://cloud.google.com/discover/what-is-serverless-architecturehttps://swagger.io/resources/articles/adopting-an-api-first-approach/https://www.contentful.com/blog/what-is-api-first/https://deviq.com/domain-driven-design/shared-kernelhttps://www.geeksforgeeks.org/hexagonal-architecture-system-design/https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcinghttps://www.microsoft.com/en-us/power-platform/products/power-apps/topics/low-code-no-code/low-code-no-code-development-platformshttps://www.processmaker.com/blog/what-is-a-bpms-a-guide-to-business-process-management-systems/https://www.gooddata.com/blog/multi-tenant-architecture/https://www.oneio.cloud/blog/what-are-enterprise-integration-patternsمحمدحسین حیدرزادهمحمدحسین حیدرزادهSun, 11 May 2025 08:52:54 +0330https://virgool.ir/@heidarzade.mh/oraclestructure-l0tzohplhmrtاوراکل یکی از بزرگ‌ترین پایگاه‌های داده در صنعت است. آن را Oracle RDBMS و یا به اختصار Oracle می‌نامند. Oracle یک پایگاه‌داده‌ی رابطه‌ای است و توسعه آن توسط شرکت Oracle انجام می‌شود. در این نوشته قصد داریم با معماری Oracle آشنا شویم و آن را به صورت جزئی بررسی کنیم.اوراکل از database و حداقل یک database instance تشکیل شده است. هر database instance یا به اختصار instance، مجموع memory و process و هر database مجموعه‌ای از فایل‌ها است.تصویر زیر معماری Oracle Database Server را به خوبی نشان می‌دهد:oracle database server architectureهر instance تنها می‌تواند به یک database دسترسی داشته باشد. همچنین می‌توانیم چند instance تعریف کرده که همه آن‌ها به یک database دسترسی داشته باشند. در ادامه هر یک از بخش‌های Database و Database Instance را بررسی می‌کنیم.معماری Databaseهر Database مجموعه‌ای از فایل‌ها را شامل می‌شود. Oracle برای مدیریت فایل‌ها ساختاری ارائه کرده است که می‌توانیم Database خود را به صورت ریزدانه مدیریت کنیم. واحدهای مختلفی برای مدیریت حافظه وجود دارد که عبارتند از:Data blocksExtentsSegmentsTablespacesبزرگ‌ترین واحد ذخیره‌سازی در Oracle را Tablespaceمی‌نامند. شکل زیر قسمت‌های مختلف یک Tablespace را به خوبی نمایش می‌دهد.Tablespace structureمعماری Database Instanceبه طور کلی هر Database Instance رابطی بین کاربر و Database می‌باشد. هر Database Instance شامل ۳ بخش می‌باشد.System Global Area (SGA)Program Global Area (PGA)Background Processesهنگام شروع Database Instance یک SGA ایجاد می‌شود. این بخش یک Shared Memory است که زمان خاموش شدن Database Instance از حافظه آزاد می‌شود.در طرف دیگر PGA را داریم که در دسترس همه Process ها می‌باشد و به ازای هر Session ایجاد شده و در پایان از حافظه آزاد می‌شود.شکل زیر معماری کلی Database Instance را به خوبی نمایش می‌دهد.Database Instance Structureنحوه عملکرد Listenerپل ارتباطی کاربر و Database Instance در معماری ارائه شده، Listener است. در ابتدا دستورات از طرف کاربر به Listener می‌رسد و در ادامه Listener آن را به Database Instance می‌فرستد. اگر Listener در دسترس نباشد، نمی‌توانیم با Database Instance ارتباط برقرار کنیم.Database Server Listenerتمریندر این بخش قصد داریم قسمتی از مفاهیمی که ارائه شد را به صورت عملیاتی مشاهده کنیم. در ابتدا instance را خاموش می‌کنیم که مطمئن شویم SGA و PGA از حافظه آزاد شده‌اند.SQL> shutdown Database closed. Database dismounted. ORACLE instance shut down.حال instance را با دستور ارائه شده روشن می‌کنیم.SQL> startup ORACLE instance started. Total System Global Area 1.0234E+10 bytes Fixed Size 14585696 bytes Variable Size 1711276032 bytes Database Buffers 8489271296 bytes Redo Buffers 18968576 bytes Database mounted. Database opened.برای روشن کردن instance سه مرحله داریم که عکس زیر این سه مرحله را به خوبی نمایش می‌دهد.database startup stagesپس از انجام هر مرحله، background Process هایی شروع می‌شوند و حافظه‌های مورد نیاز allocate می‌شود. همانطور که قبلا درباره آن صحبت کردیم، SGA یک حافظه مشترک برای هر Instance می‌باشد. این قسمت از حافظه در مرحله‌ی اول پس از شروع Instance ایجاد می‌شود.جداولی در اوراکل وجود دارد که به راحتی می‌توانید اطلاعات مربوط به Database را در آن جستجو کنید. برای مثال در جدول DBA_DATA_Files می‌توانید اطلاعات مربوط به data files را مشاهده کنید. در این جدول همچنین tablespace مربوط به هر data file مشخص است.SQL> describe DBA_DATA_FILES; Name Null? Type ----------------------------------------- -------- ---------------------------- FILE_NAME VARCHAR2(513) FILE_ID NUMBER TABLESPACE_NAME VARCHAR2(30) BYTES NUMBER BLOCKS NUMBER STATUS VARCHAR2(9) RELATIVE_FNO NUMBER AUTOEXTENSIBLE VARCHAR2(3) MAXBYTES NUMBER MAXBLOCKS NUMBER INCREMENT_BY NUMBER USER_BYTES NUMBER USER_BLOCKS NUMBER ONLINE_STATUS VARCHAR2(7) LOST_WRITE_PROTECT VARCHAR2(7)برگرفته شده از سایت oracletutorialمحمدحسین حیدرزادهمحمدحسین حیدرزادهFri, 11 Nov 2022 13:00:29 +0330