کد مقاله : 1400062227290 بازدید : 5708 صفحه: 195 - 208

نوع مقاله: پژوهشی

شناسایی تاکتیک‏های معماری در کد منبع بر اساس یک رویکرد معنایی

محورهای موضوعی :

احسان شریفی ¹ , احمد عبداله زاده بارفروش ²

1 - دانشجوی دکتری، دانشکده مهندسی کامپیوتر، دانشگاه صنعتی امیرکبیر، تهران، ایران
2 - استاد، دانشکده مهندسی کامپیوتر، دانشگاه صنعتی امیرکبیر، تهران، ایران

تاریخ دریافت : 1400/03/17 تاریخ پذیرش : 1400/06/06 تاریخ انتشار : 1401/06/23

کلید واژه: تاکتیک معماری, ریزتاکتیک, آنتولوژی, مدل معنایی,

چکیده مقاله :

سامانه‏ های نرم ‏افزاری تا زمانی که قابلیت اعمال تغییرات را داشته باشند زنده هستند و امکان استفاده از آن‌ها وجود دارد. اعمال تغییرات در کد منبع بدون توجه به تأثیرات آن می‏ تواند باعث فرسایش معماری سامانه‏ ی نرم ‏افزاری شود. فرسایش معماری به‌مرور، امکان انجام تغییرات را غیرممکن می‏ نماید و سامانه‏ روبه‌زوال می‏ رود. تصمیمات معماری در کد منبع معمولاً توسط تاکتیک ‏های معماری محقق می‏ شوند. تاکتیک‏ ها تصمیمات ریزدانه‏ ای هستند که برای تحقق یک ویژگی کیفیتی خاص اتخاذ می‏ شوند. شناسایی تاکتیک‏ ها در کد منبع این امکان را برای توسعه ‏دهندگان فراهم می‏ کند که اعمال تغییرات در کد را با آگاهی از مکان پیاده‏ سازی این تصمیمات انجام دهند. لذا فرآیند فرسایش معماری کندتر شده و سامانه ‏ی نرم ‏افزاری دیرتر به سمت زوال حرکت می ‏نماید. بدین منظور، در این مقاله یک رویکرد بر مبنای وب معنایی به‌منظور شناسایی تاکتیک‏ های معماری در کد منبع معرفی می‏ شود. بر اساس این رویکرد، مفهوم جدیدی به نام ریز تاکتیک معرفی می‎‏ شود که امکان شناسایی تاکتیک ‏های معماری را با استفاده از یک رویکرد معنایی مبتنی بر وب معنایی و آنتولوژی ارتقاء می‏ بخشد. نتایج حاصل از ارزیابی رویکرد پیشنهادی نشان می‏ دهد که امکان شناسایی تاکتیک‏ها در این روش با دقت و کیفیت بهتری نسبت به روش ‏های مشابه انجام می ‏شود.

چکیده انگلیسی:

Software systems are alive as long as they can be changed and used. Changing the source code without considering the consequences can lead to the architectural erosion of software systems. Architectural erosion gradually makes the system unchangeable and moves it towards deterioration. Architectural decisions in the source code are usually made using architectural tactics. These tactics are fine-grained decisions that are made to achieve a certain quality attribute. Recognizing these tactics in the source code, allows developers to change the code while knowing the implementation location of these decisions. This slows the architectural erosion process and delays the system's movement towards deterioration. Thus, this paper introduces a method based on semantic web for recognizing the architectural tactics presented in the source code. Based on this approach, the new concept of microtactic is introduced that increases the possibility of recognizing architectural tactics using a semantic web and ontological approach. The evaluation results show that this method in comparison with other similar methods recognizes the tactics with higher precision and quality.

منابع و مأخذ:

M. Mirakhorli, “Preventing erosion of architectural tactics through their strategic implementation, preservation, and visualization,” in 2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE), Nov. 2013, pp. 762–765. doi: 10.1109/ASE.2013.6693152.
N. B. Harrison and P. Avgeriou, “How do architecture patterns and tactics interact? A model and annotation,” Journal of Systems and Software, vol. 83, no. 10, pp. 1735–1758, Oct. 2010, doi: 10.1016/j.jss.2010.04.067.
M. Mirakhorli, A. Fakhry, A. Grechko, M. Wieloch, and J. Cleland-Huang, “Archie: A Tool for Detecting, Monitoring, and Preserving Architecturally Significant Code,” in Proceedings of the 22Nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, New York, NY, USA, 2014, pp. 739–742. doi: 10.1145/2635868.2661671.
J. Ryoo, P. Laplante, and R. Kazman, “A Methodology for Mining Security Tactics from Security Patterns,” in 2010 43rd Hawaii International Conference on System Sciences, Jan. 2010, pp. 1–5. doi: 10.1109/HICSS.2010.18.
M. Mirakhorli, P. Mäder, and J. Cleland-Huang, “Variability points and design pattern usage in architectural tactics,” in Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering, New York, NY, USA, Nov. 2012, pp. 1–11. doi: 10.1145/2393596.2393657.
M. Mirakhorli and J. Cleland-Huang, “Detecting, Tracing, and Monitoring Architectural Tactics in Code,” IEEE Transactions on Software Engineering, vol. 42, no. 3, pp. 205–220, Mar. 2016, doi: 10.1109/TSE.2015.2479217.
D. E. Krutz and M. Mirakhorl, “Architectural clones: toward tactical code reuse,” in Proceedings of the 31st Annual ACM Symposium on Applied Computing, New York, NY, USA, Apr. 2016, pp. 1480–1485. doi: 10.1145/2851613.2851787.
I. J. Mujhid, J. C. S. Santos, R. Gopalakrishnan, and M. Mirakhorli, “A search engine for finding and reusing architecturally significant code,” Journal of Systems and Software, vol. 130, pp. 81–93, Aug. 2017, doi: 10.1016/j.jss.2016.11.034.
J. Keim, A. Kaplan, A. Koziolek, and M. Mirakhorli, “Does BERT Understand Code? – An Exploratory Study on the Detection of Architectural Tactics in Code,” in Software Architecture, Cham, 2020, pp. 220–228. doi: 10.1007/978-3-030-58923-3_15.
B. Milhem and H. A. Ismail, “Evaluating Software Architecture Based on Their Implemented Patterns and Tactics,” Thesis, Université d’Ottawa / University of Ottawa, 2020. doi: 10.20381/ruor-25057.
M. Zanoni, F. Arcelli Fontana, and F. Stella, “On applying machine learning techniques for design pattern detection,” Journal of Systems and Software, vol. 103, no. Supplement C, pp. 102–117, May 2015, doi: 10.1016/j.jss.2015.01.037.
J. (Yossi) Gil and I. Maman, “Micro Patterns in Java Code,” in Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-oriented Programming, Systems, Languages, and Applications, New York, NY, USA, 2005, pp. 97–116. doi: 10.1145/1094811.1094819.
S. Maggioni, “Design pattern detection and software architecture reconstruction: an integrated approach based on software micro-structures,” Università degli Studi di Milano-Bicocca, 2010.
R. Studer, V. R. Benjamins, and D. Fensel, “Knowledge engineering: Principles and methods,” Data & Knowledge Engineering, vol. 25, no. 1, pp. 161–197, Mar. 1998, doi: 10.1016/S0169-023X(97)00056-6.
A. Barforoush and A. Rahnama, “Ontology Learning: Revisited,” Journal of Web Engineering (JWE), vol. 11, pp. 269–289, Dec. 2012.
N. Noy and D. Mcguinness, “Ontology Development 101: A Guide to Creating Your First Ontology,” Knowledge Systems Laboratory, vol. 32, Jan. 2001.
S. Ehsan and D. Mahmood, “AN APPLICABLE METHOD FOR COMPREHENSIVE CORPUS GATHERING NEEDS FOR FUZZY DOMAIN ONTOLOGY GENERATION,” ELECTRONIC INDUSTRIES, vol. 7, no. 1, pp. 89–103, Jan. 2016.
R. Y. K. Lau, D. Song, Y. Li, T. C. H. Cheung, and J.-X. Hao, “Toward a Fuzzy Domain Ontology Extraction Method for Adaptive e-Learning,” IEEE Transactions on Knowledge and Data Engineering, vol. 21, no. 6, pp. 800–813, Jun. 2009, doi: 10.1109/TKDE.2008.137.
M. Atzeni and M. Atzori, “CodeOntology: RDF-ization of Source Code,” in The Semantic Web – ISWC 2017, Cham, 2017, pp. 20–28. doi: 10.1007/978-3-319-68204-4_2.
S. Kim, D.-K. Kim, L. Lu, and S. Park, “Quality-driven architecture development using architectural tactics,” Journal of Systems and Software, vol. 82, no. 8, pp. 1211–1231, Aug. 2009, doi: 10.1016/j.jss.2009.03.102.
S. Paydar and M. Kahani, “A semantic web enabled approach to reuse functional requirements models in web engineering,” Autom Softw Eng, vol. 22, no. 2, pp. 241–288, Jun. 2015, doi: 10.1007/s10515-014-0144-4.

متن کامل:

دو فصلنامه علمي

فناوري اطلاعات و ارتباطات ایران

سال چهاردهم، شمارههای ‌51 و 52 ، بهار و تابستان 1401

صص: 195_208

$E:\E Drive\logo\iicta Logo0.JPG$

شناسایی تاکتیک‏های معماری در کد منبع بر اساس یک رویکرد معنایی

احسان شریفی* احمد عبدالله زاده بارفروش**

* دانشجوی دکتری، دانشکده مهندسی کامپیوتر، دانشگاه صنعتی امیرکبیر، تهران، ایران

** استاد، دانشکده مهندسی کامپیوتر، دانشگاه صنعتی امیرکبیر، تهران، ایران

تاریخ دریافت: 17/03/1400 تاریخ پذیرش: 06/06/1400

نوع مقاله: پژوهشی

چكیده

سامانه‏های نرم‏افزاری تا زمانی که قابلیت اعمال تغییرات را داشته باشند زنده هستند و امکان استفاده از آن‌ها وجود دارد. اعمال تغییرات در کد منبع بدون توجه به تأثیرات آن می‏تواند باعث فرسایش معماری سامانه‏ی نرم‏افزاری شود. فرسایش معماری به‌مرور، امکان انجام تغییرات را غیرممکن می‏نماید و سامانه‏ روبه‌زوال می‏رود. تصمیمات معماری در کد منبع معمولاً توسط تاکتیک‏های معماری محقق می‏شوند. تاکتیک‏ها تصمیم‏های ریزدانه‏ای هستند که برای تحقق یک ویژگی کیفیتی خاص اتخاذ می‏شوند. شناسایی تاکتیک‏ها در کد منبع این امکان را برای تولیدکنندگان فراهم می‏کند که اعمال تغییرات در کد منبع را با آگاهی از مکان پیاده‏سازی این تصمیم‏ها انجام دهند. لذا فرآیند فرسایش معماری کندتر شده و سامانه‏ی نرم‏افزاری دیرتر به سمت زوال حرکت می‏نماید. بدین منظور، در این مقاله یک رویکرد معنایی به‌منظور شناسایی تاکتیک‏های معماری در کد منبع معرفی می‏شود. بر اساس این رویکرد، مفهوم جدیدی به نام ریزتاکتیک معرفی می‎‏شود که امکان شناسایی تاکتیک‏های معماری را با استفاده از یک رویکرد معنایی مبتنی بر وب معنایی و آنتولوژی ارتقاء می‏بخشد. نتایج حاصل از ارزیابی رویکرد پیشنهادی نشان می‏دهد که امکان شناسایی تاکتیک‏ها در این روش با دقت و کیفیت بهتری نسبت به روش‏های مشابه انجام می‏شود.

واژگان کلیدی: تاکتیک معماری، ریزتاکتیک، آنتولوژی، مدل معنایی

1. مقدمه

سامانه‏های نرم‏افزاری مانند یک موجود زنده به‌طور مستمر در حال تغییر هستند. بخش عمده‏ی فعالیت یک تیم توسعه‏، اعمال تغییر و ایجاد تکامل در محصولی است که بر اساس نیازمندی‏های جدید مشتری در حال رشد است. تا زمانی که امکان اعمال تغییرات در نویسنده مسئول: احمد عبدالله زاده بارفروش Ahmad@aut.ac.ir

محصول نرم‏افزاری وجود دارد چرخه حیات محصول در جریان بوده و محصول زنده است.

هر زمان که امکان تکامل و تغییر فراهم نباشد یا به‌سختی انجام شود چرخه حیات محصول به اتمام رسیده است و محصول جدید جایگزین قبلی می‏شود. فرسایش معماری زمانی اتفاق می‏افتد که تیم توسعه بدون توجه به معماری کلی و به‌مرور، تغییراتی محلی را در سطح کد اعمال می‏کند و به دلیل ناآگاهی از تصمیمات معماری در سطح کلان باعث فرسایش معماری می‏گردد. مهم‌ترین تأثیر این فرسایش پایین آمدن قابلیت نگهداری نرم‌افزار است[1].

فرسایش معماری ¹ زمانی اتفاق می‏افتد که تیم توسعه بدون توجه به معماری کلی و به‌مرور، تغییراتی محلی را در سطح کد اعمال می‏کند و به دلیل ناآگاهی از تصمیم‏های معماری در سطح کلان باعث فرسایش معماری می‏شود. مهم‌ترین تأثیر این فرسایش پایین آمدن قابلیت نگهداری نرم‌افزار است[1].

الگوها و تاکتیک‏های معماری دو نمونه از تصمیم‏های معماری هستند که برای تحقق ویژگی‏‏های کیفیتی اتخاذ می‏شوند. الگوهای معماری راه‏حل‏های درشت‏دانه‏ای هستند که از مجموعه‏ای از تاکتیک‏های معماری و الگوهای طراحی تشکیل‌شده‌اند و طیف وسیعی از ویژگی‏های کیفیتی را تحت تأثیر قرار می‏دهند. در مقابل، تاکتیک‏های معماری تصمیم‏های طراحی ریزدانه‌ای هستند که هدف آن‌ها تحقق یک ویژگی کیفیتی مشخص است[2]. به‌عنوان‌مثال، یکی از دغدغه‏های طراحی مرتبط با ویژگی کیفیتی امنیت، «نحوه جلوگیری از حمله² به یک سیستم» است و یک تصمیم طراحی یا به عبارت صحیح‏تر تاکتیک معماری متناظر با آن «تائید اعتبار»³ کاربر است.

تاکتیک‏های معماری به دلیل ماهیت ریزدانگی که دارند مهم‌ترین اجزاء معماری هستند که امکان شناسایی در کد منبع نرم‏افزار رادارند. لذا شناسایی و مراقبت از تاکتیک‏های معماری در خلال فرآیند توسعه‏ی نرم‏افزار می‏تواند فرآیند فرسایش معماری را کند نماید. متأسفانه ماهیت تاکتیک‏های معماری با الگوهای طراحی تفاوت دارد. الگوهای طراحی با روش‏های تحلیل ساختاری قابل‌شناسایی هستند؛ اما تاکتیک‏های معماری به‌صورت نقش‏ها و تعاملات بین آن‌ها توصیف‌ می‏شوند و ساختار استانداردی برای پیاده‏سازی ندارند[3].

در این مقاله با معرفی مفهوم جدیدی به نام ریزتاکتیک⁴، یک رویکرد معنایی بر پایه‏ی آنتولوژی و وب معنایی ارائه می‏شود که امکان شناسایی تاکتیک‏های معماری در کد منبع را فراهم می‏نماید. بر اساس این رویکرد، تاکتیک‏های معماری با استفاده از اجزاء ریز‏دانه‏تری به نام ریزتاکتیک مدل می‏شوند. این اجزاء با استفاده از آنتولوژی توصیف‌شده و از طریق پرس‏وجوهای وب‏معنایی و استفاده از یک رویکرد مبتنی بر مشابهت معنایی امکان شناسایی تاکتیک‏های معماری را فراهم می‏کنند.

اولین نوآوری این مقاله معرفی مفهوم ریزتاکتیک است که امکان شناسایی تاکتیک‏های معماری را در سطح کد تسهیل می‏نماید. دومین نوآوری ارائه یک راهکار معنایی مبتنی بر وب معنایی و آنتولوژی برای شناسایی تاکتیک‏های معماری است که تاکنون توسط سایر پژوهشگران موردتوجه قرار نگرفته است. به‌کارگیری رویکرد معنایی در این حوزه این امکان را فراهم می‏کند که شناسایی تاکتیک‏های معماری به ساختار نحوی پیاده‏سازی آن‌ها وابسته نبوده و نتایج به‌دست‌آمده دارای صحت و اعتبار بیشتری باشد.

ساختار مقاله در ادامه بدین‌صورت است. در بخش دوم پیشینه تحقیق به‌صورت اجمالی بررسی می‏شود. سپس در بخش سوم رویکرد پیشنهادی معرفی می‏شود. در بخش چهارم با انجام یک مطالعه موردی نتایج حاصل از رویکرد پیشنهادی مورد آزمایش قرار می‏گیرد. در بخش پنجم نتایج حاصل موردبحث و بررسی قرارگرفته و در بخش ششم نتیجه‏گیری انجام‌شده و فعالیت‏های آتی معرفی می‏شوند.

2. پیشینه تحقیق

در حوزه‏ی تشخیص الگوهای طراحی پژوهش‏های متنوعی انجام‌شده است؛ اما در حوزه‏ی شناسایی تاکتیک‏های معماری پژوهش‏های انجام‌شده اندک است. در ادامه به معرفی چند پژوهش شاخص در این حوزه می‏پردازیم.

رویکرد برخی از پژوهش‏های این حوزه، استخراج تاکتیک‏های معماری از الگوهای طراحی یا معماری است. یکی از پژوهش‏های مطرح در این حوزه یک رویکرد جدید برای استخراج تاکتیک‏های معماری مربوط به ویژگی کیفیتی امنیت از الگوهای شناخته‌شده معرفی نموده است[4]. هسته‏ی اصلی این رویکرد، آزمودن الگوهای معماری شناخته‌شده در حوزه‏ی امنیت است. این آزمون به‌منظور بررسی مجموعه‏ای از شرایط است که در صورت احراز، الگوی موردنظر به‌عنوان یک تاکتیک معماری شناخته خواهد شد. ضعف این دیدگاه عدم توجیه نحوه تعیین شرایط مذکور است.

در پژوهش دیگر از تکنیک‏های داده‏کاوی برای یافتن نمونه‏های الگوهای طراحی در تاکتیک‌های معماری استفاده‌شده است[5]. هدف از این پژوهش ایجاد «نقاط تغییری»⁵ است که امکان پیاده‎سازی یا شناسایی تاکتیک‏های معماری را بر اساس الگوهای طراحی مختلف فراهم نماید.

یکی دیگر از پژوهش‏های مطرح در این حوزه با استفاده از تکنیک‏های بازیابی اطلاعات و یادگیری ماشین تاکتیک‏های معماری را شناسایی نموده است. دیدگاه اصلی این پژوهش مبتنی بر یادگیری واژگانی است که در پیاده‏سازی‏های مختلف تاکتیک‏های معماری مورداستفاده قرار می‏گیرند[6]. نقطه‌ضعف اصلی این رویکرد وابسته بودن به واژگانی است که قبلاً در پیاده‏سازی‏های مختلف تاکتیک‏ها مورداستفاده قرارگرفته‌اند. تغییر این واژگان یا استفاده از واژگان هم‌معنی می‏تواند دقت شناسایی این روش را به‌شدت کاهش دهد.

تحقیق دیگری در این حوزه ایده‏ی ایجاد یک موتور جستجو برای تاکتیک‏های معماری را مطرح نموده است[7]. ایده اصلی این دیدگاه معرفی مفهوم «کلون‏های تاکتیک»⁶ به‌عنوان المان اصلی این موتور جستجو است. یک رویکرد مشابه نیز برای یافتن کدهای مهم ازنظر معماری پیشنهاد شده است[8]. در این رویکرد از تکنیک‏های بازیابی اطلاعات و «تحلیل برنامه»⁷ برای شناسایی کدهای موردنظر استفاده می‏کند.

پژوهش دیگر در این حوزه مسئله‏ی شناسایی تاکتیک را به مسئله‏ی دسته‏بندی⁸ کردن متن نگاشت نموده و با استفاده از مدل‏های زبانی نظیر برت⁹ سعی نموده است که این مسئله را در حوزه پردازش زبان طبیعی حل نماید[9].

در یک رویکرد دیگر برای ارزیابی معماری سامانه‏های نرم‏افزاری، از شناسایی الگوها و تاکتیک‏های پیاده‏سازی شده در آن‌ها استفاده شده است[10]. این روش با استفاده از ابزاری به نام آرچی¹⁰ تاکتیک‏ها و الگوهای معماری را از کد منبع استخراج نموده و پس از توصیف آن‌ها در قالب مدل‏های معماری، میزان تأثیر آن‌ها بر ویژگی‏های کیفیتی را با استفاده از یک‌زبان توصیف نیازمندی هدف‏گرا¹¹ بررسی می‏نماید.

3. رویکرد پیشنهادی

در این بخش رویکرد ردیابی پیشنهادی معرفی می‏شود. در ابتدا برخی مفاهیم نظری¹² مرتبط با این رویکرد تشریح می‏شوند. سپس فعالیت‏های مربوط به روش پیشنهادی با جزئیات تشریح می‏شوند.

1.3 مفاهیم نظری

در این بخش در ابتدا مفهوم ریزتاکتیک معرفی‌شده و در ادامه یک متامدل و آنتولوژی برای توصیف آن ارائه می‏شود. سپس یک آنتولوژی برای توصیف کدهای شی‌ءگرا معرفی‌شده و در انتها نیز چارچوبی برای توصیف معنایی کد شی‌ءگرا به نام کدآنتولوژی‏ پلاس معرفی می‏شود.

1.1.3 معرفی مفهوم ریزتاکتیک

شناسایی المان‏هایی در کد منبع که به‌طور بالقوه محقق کننده تاکتیک‏ها باشند می‏تواند فرآیند شناسایی تاکتیک‏های معماری در کد منبع را تسهیل نمایند. لذا می‏بایست به ازای هر تاکتیک معماری، ریزساختارهایی¹³ را که محقق کننده آن تاکتیک در کد منبع هستند شناسایی نمود. ریزساختارها، المان‏هایی از کد منبع هستند که یک موجودیت یکتا یا ارتباط بین دو یا چند موجودیت را در کد منبع تعریف می‏نمایند. مهم‌ترین ویژگی ریزساختارها، قابل‌شناسایی بودن آن‌ها به‌طور خودکار است و به دلیل برخورداری از این ویژگی استخراج آن‌ها از کد منبع با دقت و یادآوری بالا قابل انجام است[11].

در این تحقیق مفهوم ریزتاکتیک برای اشاره به ریزساختار‏هایی انتخاب‌شده است که در محقق نمودن اهداف یک تاکتیک معماری نقش دارند. ایده اولیه ریزتاکتیک برگرفته از دو مفهوم در حوزه الگوهای طراحی است. اولین مفهوم «ریز الگو¹⁴» است که برای الگوهای طراحی معرفی‌شده است [12]. مفهوم بعدی «اثر‏های الگوی طراحی¹⁵» است [13].

هر دو مفهوم فوق به‌عنوان یک ریزساختار قصد دارند که فرآیند شناسایی الگوهای طراحی در کد منبع را تسهیل نمایند. از این جنبه این دو ریزساختار شباهت معنایی به مفهوم ریزتاکتیک دارند. اما تفاوت اصلی ریزتاکتیک نسبت به دو مفهوم فوق در گستردگی و مقیاس‏پذیری آن است. درواقع می‏توان این‌گونه بیان کرد که ریزتاکتیک‏ها خود شامل ریز الگوها و اثر‏های الگوی طراحی هستند، اما محدود به آن‌ها نبوده و المان‏های بیشتری را می‏توانند در برگیرند.

تاکتیک‏های معماری زمان اجرا شامل نقش‏ها و تعاملات بین این نقش‏ها می‏باشند. لذا در وهله‏ی اول نقش‏های موجود در یک تاکتیک انتخاب مناسبی هستند که به‌عنوان ریزتاکتیک انتخاب شوند.

2.1.3 معرفی متامدل ریزتاکتیک

به‌منظور تشریح دقیق ریزتاکتیک‏ها نیاز به ارائه یک متامدل داریم. یکی از معدود پژوهش‏های موجود تاکتیک‏های معماری را در قالب نقش‏ها و تعاملات بین آن‌ها و بر پایه‏ی زبان آربی‏ام‏ال¹⁶ توصیف نموده است [14].

متامدل پیشنهادی ریزتاکتیک در این مقاله بر اساس متامدل زبان آربی‏ام‏ال ایجادشده است. در این متامدل اجزائی از کد منبع که می‏توانند در نقش ریزتاکتیک ظاهر شوند ارائه‌شده است.

شکل 1 متامدل پیشنهادی ریزتاکتیک را نمایش می‏دهد. اجزای این متامدل، ریزتاکتیک‏های مرتبط با یک تاکتیک معماری را نمایش می‏دهند که امکان ‌شناسایی خودکار آن‌ها در کد منبع یک پروژه ‏وجود دارد.

[1] Architectural erosion

[2] Attack

[3] Authentication

[4] Micro Tactic

[5] Variability Points

[6] Tactical-clones

[7] Program analysis

[8] Classify

[9] BERT

[10] Archie

[11] Goal-oriented

[12] Theory

[13] Microstructure

[14] Micro Pattern

[15] Design Pattern Clues

[16] RBML

Diagram

Description automatically generated

شکل 1. متامدل پیشنهادی ریزتاکتیک

Diagram

Description automatically generated

شکل 2. مدل ریزتاکتیک مربوط به تاکتیک پینگ/اکو

جدول 1: ریزتاکتیک‏های مربوط به تاکتیک پینگ/اکو

نوع ریزتاکتیک	عنوان ریزتاکتیک	ردیف
دسته‏بند	PingSender	1
دسته‏بند	FaultMonitor	2
دسته‏بند	PingReceiver	3
ویژگی ساختاری	maxWaitingTime	4
ویژگی ساختاری	timeInterval	5
ویژگی ساختاری	elapsedTime	6
ویژگی رفتاری	Ping	7
ویژگی ساختاری	echo	8
رابطه	notifies	9
رابطه	checks	10

بر اساس این متامدل، ریزتاکتیک می‏تواند یک دسته‏بند¹، ویژگی، پارامتر یا رابطه باشد. شکل 2 مدل مربوط به تاکتیک پینگ/اکو² را که بر اساس متامدل شکل 1 ایجادشده است نمایش می‏دهد. تاکتیک پینگ/اکو یکی از تاکتیک‏های «شناسایی خرابی»³ است که ذیل تاکتیک‏های مرتبط با ویژگی کیفیتی دسترس‏پذیری⁴ قرار دارد[15]. اجزای این مدل نیز در جدول 1 تشریح شده‏ است.

3.1.3 آنتولوژی ریزتاکتیک

تعاریف مرتبط با آنتولوژی در حوزه علوم کامپیوتر بسیار متفاوت و متنوع است. مشهورترین تعریف متعلق به استادر⁵ است که آنتولوژی را بدین‌صورت تعریف می‏کند: «آنتولوژی یک توصیف صوری⁶ و صریح⁷ از یک مفهوم‏سازی⁸ اشتراکی است»[16].

در حوزه‏ی تاکتیک‏های معماری نیازمند چنین ساختاری هستیم تا از طریق توصیف معنایی دانش این حوزه، فرآیند شناسایی تاکتیک‏ها در کد منبع تسهیل شود. این آنتولوژی در وهله‏ی نخست می‏بایست ساختار ریزتاکتیک‏ها را بر اساس متامدل ریزتاکتیک توصیف نماید. در وهله‏ی دوم نیز امکان توصیف مفاهیم و روابط موجود در حوزه‏ی تاکتیک‏های معماری را فراهم نماید. آنتولوژی در این مقاله، یک پنج‏تایی مرتب شامل مفاهیم (C)، روابط رده‏بندی (RT)، روابط غیر رده‌بندی (RN)، اصول (A) و دامنه (D) است که بدین شکل تعریف می‏شود[17]:

(1)

فرآیند ایجاد آنتولوژی ریزتاکتیک طی سه مرحله انجام می‏شود. در اولین مرحله یک «آنتولوژی پایه»⁹ ایجاد می‏شود که مفاهیم اصلی ریزتاکتیک را توصیف می‏نماید. در مرحله‏ی دوم یک «آنتولوژی حوزه»¹⁰ بر اساس مفاهیم و رده‏بندی‏های موجود در این حوزه ایجاد می‏شود. در مرحله‏ی سوم نیز یک آنتولوژی حوزه بر اساس منابع مرتبط با این حوزه ایجاد می‏شود.

در اولین مرحله و بر اساس ساختار متامدل ریزتاکتیک معرفی‌شده در شکل1، آنتولوژی پایه ایجاد می‏شود. بدین منظور، قواعد زیر را تعریف می‏کنیم:

- قاعده 1: هر دسته‏بند در متامدل به یک مفهوم در آنتولوژی نگاشت می‏شود.

- قاعده 2: هر رابطه ارث‏بری در متامدل به یک رابطه سلسله مراتبی در آنتولوژی نگاشت می‏شود.

- قاعده 3: هر رابطه تناظر¹¹ در متامدل به یک رابطه غیر رده‌بندی یا دودویی در آنتولوژی نگاشت می‏شود.

شکل 3 بخشی از آنتولوژی پایه را ذیل مفهوم «MicroTactic» نمایش می‏دهد. همان‌گونه که در متامدل شکل 1 مشاهده می‏شود، «Classifier Microtactic» به‌عنوان یک دسته‏بند بر اساس قاعده‏ی 1 به مفهوم «Classifier_Microtactic» در آنتولوژی پایه نگاشت شده است. از طرف دیگر بر اساس قاعده‏ی 2 و با توجه به رابطه‏ی ارث‏بری آن با کلاس «MicroTactic»، یک رابطه‏ی سلسله مراتبی بین مفهوم «Classifier_Microtactic» و مفهوم «MicroTactic» در آنتولوژی ایجادشده است.

در مرحله‏‏ی دوم، آنتولوژی حوزه مربوط به تاکتیک‏های معماری ایجاد می‏شود. آنتولوژی حوزه، معانی واژگان موجود در یک حوزه را تشریح نموده و امکان توصیف بهتر مفاهیم و روابط بین آن‌ها در یک فیلد خاص را فراهم می‏کند[18]. در این مرحله، از رده‏بندی ارائه‌شده توسط بَس و همکاران برای ایجاد اولین بخش از آنتولوژی حوزه‏ی تاکتیک استفاده می‏شود[15]. این رده‏بندی، تاکتیک‏های معماری مطرح در حوزه‏ی نرم‏افزار را بر اساس ویژگی‏های کیفیتی مرتبط با آن‌ها دسته‏بندی نموده است. شکل 3 بخشی از آنتولوژی حوزه‏ی تولیدشده بر اساس رده‏بندی فوق را ذیل مفهوم «Tactic» نمایش می‏دهد. این بخش از آنتولوژی به‌صورت دستی و توسط نویسنده اول مقاله ایجادشده است. اما ایجاد آنتولوژی حوزه به روش دستی یک فرآیند پرهزینه، زمان‏بر و مستعد خطاست. خودکارسازی عملیات ساخت آنتولوژی که از آن با عنوان یادگیری آنتولوژی¹² یاد می‏شود، هزینه‏ی ساخت و میزان خطا را کاهش می‏دهد.

در بخش سوم و به‌منظور تکمیل آنتولوژی حوزه‏، از رویکردی که توسط نویسنده اول این مقاله استفاده می‏کنیم[19]. هدف اصلی این پژوهش جمع‏آوری «توده‏ی متون»¹³ جامع برای تولید یک آنتولوژی فازی¹⁴ است[20]. توده متون شامل کلیه‏ی منابعی است که به‌طور مستقیم یا غیرمستقیم به حوزه‏ی موردنظر مرتبط بوده و مفاهیم و روابط موجود در حوزه‏ با دقت قابل قبولی از این توده متون قابل‌استخراج است. لذا جامعیت توده‏ی متون تأثیر مستقیم بر کیفیت آنتولوژی حوزه‏ی نهایی دارد. با استفاده از این رویکرد، امکان جمع‏آوری خودکار توده متون جامع در حوزه‏ی تاکتیک‏های معماری فراهم می‏شود.

بخش سوم از آنتولوژی حوزه‏ی تاکتیک با استفاده از این توده متون و بر اساس رویکرد [19] ایجاد می‏شود.

شکل 3. بخشی از آنتولوژی ریزتاکتیک

آنتولوژی نهایی از درون‏برد¹⁵ سه آنتولوژی تولیدشده ایجاد می‏شود. شکل 3 بخشی از این آنتولوژی نهایی را نمایش می‏دهد. این آنتولوژی به‌صورت آنلاین در دسترس است¹⁶.

4.1.3 آنتولوژی کد شیءگرا

به‌منظور ایجاد مدل معنایی از کد منبع نیازمند وجود یک آنتولوژی در حوزه‏ی زبان‏‏های شی‌ءگرا هستیم.

در این پژوهش از یک آنتولوژی که برای برای مدل‏سازی معنایی زبان‏های برنامه‏نویسی شی‌ءگرا معرفی‌شده است استفاده می‏کنیم[21]. این آنتولوژی به زبان اُوِل2¹⁷ و با ابزار پروتج¹⁸ ایجادشده است و شامل 65 کلاس، 86 ویژگی شیء¹⁹ و 11 ویژگی داده²⁰ است. در این آنتولوژی موجودیت‏های ساختاری مرتبط با تمامی زبان‎های برنامه‏نویسی شی‌ءگرا نظیر کلاس‏ها، متدها، متغیرها، جملات²¹ و عبارت‏ها²² را در قالب کلاس‏های مجزا²³ بازنمایی می‏شوند. طراحی این آنتولوژی بر اساس «الگوهای طراحی آنتولوژی»²⁴ انجام‌شده است. این آنتولوژی به‌صورت آنلاین در دسترس است²⁵. شکل 4 بخشی از این آنتولوژی را نمایش می‏دهد.

شکل 4. بخشی از آنتولوژی کد شیءگرا

5.1.3 چارچوب کدآنتولوژی پلاس²⁶

افزایش روزافزون حجم پروژه‏های نرم‏افزاری نیازمند راهکاری است که امکان مدیریت تغییر، بازنگری²⁷ و بازآرایی²⁸ کد را فراهم نماید. لذا امکان انجام پرس‏و‏جو بر روی کد منبع یکی از چالش‏های مهم در حوزه‏ی مهندسی نرم‏افزار است.

پشته‏ی فناوری وب معنایی یک مجموعه استاندارد‏ برای بازنمایی و پرس‏و‏جوی اطلاعات ساخت‏یافته ارائه می‏نماید. کدآنتولوژی چارچوبی بر مبنای وب معنایی است که امکان تبدیل کد منبع پروژه به یک مدل معنایی را فراهم می‏کند[21]. این ساختار معنایی امکان انجام پرس‌وجوهای متنوع بر روی کد منبع پروژه را با استفاده از زبان قدرتمند اسپارکل²⁹ فراهم می‏کند. ورودی این چارچوب، کد منبع پروژه به زبان جاوا است و خروجی آن‌یک ساختار معنایی به فرمت آردی‏اف³⁰ است. این چارچوب فرآیند تولید مدل آردی‏اف از کد منبع را طی سه مرحله انجام می‏دهد. در مرحله‏ی اول پروژه به‌منظور دانلود وابستگی‏هایش مورد تحلیل قرار می‏گیرد. سپس در مرحله‏ی دوم یک «درخت نحوی انتزاعی»³¹ از کد منبع ایجاد می‏شود. سپس در مرحله‏ی سوم این درخت مورد پردازش قرارگرفته و با استفاده از آنتولوژی کد که در بخش ۳.۱.۴ معرفی شد سه‏گانه‏های آردی‏اف ایجاد می‏شوند.

به‌منظور به‌کارگیری چارچوب کدآنتولوژی در این مقاله، تغییراتی در این چارچوب ایجادشده است و ازاین‌پس با عنوان کدآنتولوژی پلاس به آن رجوع می‏نماییم. شکل ۵ چارچوب کدآنتولوژی پلاس را نمایش می‏دهد. بدین منظور در حین پردازش درخت نحوی انتزاعی مربوط به کد منبع، بین «موجودیت‏های نامدار»³² موجود در کد منبع و مفاهیم موجود در آنتولوژی ریزتاکتیک که در بخش 3.1.3 معرفی‌شده است پیوندهایی برقرار می‏شود. ایجاد این پیوندها امکان شناسایی معنایی ریزتاکتیک‏ها را در کد منبع فراهم می‏کند.

شکل 5. معماری کدآنتولوژی پلاس

[1] Classifier

[2] Ping/Echo

[3] Fault Detection

[4] Availability

[5] Studer

[6] Formal

[7] Explicit

[8] Conceptualization

[9] Base ontology

[10] Domain ontology

[11] Association

[12] Ontology Learning

[13] Corpus

[14] Fuzzy

[15] Import

[16] http://islab.ceit.aut.ac.ir/mt

[17] OWL2

[18] Protégé

[19] Object property

[20] Data property

[21] Statement

[22] Expression

[23] Disjoint

[24] Ontology Design Patterns

[25] http://doi.org/10.5281/zenodo.577939

[26] Codeontology+

[27] Review

[28] Refactor

[29] SPARQL

[30] RDF

[31] Abstract Syntax Tree (AST)

[32] Named Entity

Diagram

Description automatically generated

شکل 6. مدل ریزتاکتیک ضربان قلب

2.3 تشریح رویکرد پیشنهادی

با توجه به مفاهیم و پیش‏نیازهای معرفی‌شده در بخش 3.1 فعالیت‏های رویکرد پیشنهادی در این بخش تشریح می‏شوند. این فعالیت‏ها شامل مدل‏سازی معنایی کد منبع، ایجاد مخزن معنایی ریزتاکتیک، پیشنهاد تاکتیک و شناسایی تاکتیک است.

1.2.3 مدل‎سازی معنایی کد

اولین فعالیت در رویکرد پیشنهادی، تبدیل کد منبع پروژه به مدل معنایی است که امکان تحلیل و استنتاج کد منبع را فراهم نموده و دستیابی به اجزاء کد را تسهیل ‏نماید. برای این منظور از چارچوب کدآنتولوژی‏پلاس که در بخش 3.1.5 معرفی شد استفاده می‏کنیم.

نحوه‏ی ایجاد مدل معنایی وابسته به رویکرد موردنظر است.

اگر هدف شناسایی تاکتیک‏های معماری در بخش مشخصی از کد منبع نظیر یک کلاس، مؤلفه یا زیرسیستم است، می‏توان فقط همان بخش از کد را به مدل معنایی تبدیل نمود. در این صورت فرآیند شناسایی تاکتیک‏های معماری با سرعت و کارایی بیشتری انجام خواهد شد. در غیر این صورت می‏بایست تمامی کد منبع به ساختار معنایی تبدیل شود که نیازمند زمان و هزینه بیشتری است.

مدیریت تغییرات نیز بدین‌صورت انجام می‏شود که با تغییر هر بخش از کد به‌طور خودکار یک «رویداد تغییر»¹ ایجادشده و مدل معنایی جدیدی از کد ارسال‌شده² در مخزن کد ایجاد می‏شود.

2.2.3 ایجاد مخزن معنایی ریزتاکتیک

گام دوم رویکرد پیشنهادی ایجاد مخزن معنایی ریزتاکتیک است. در این مخزن مدل‏های ریزتاکتیک مربوط به هر تاکتیک معماری در قالب داده‏های معنایی ذخیره می‏شوند. آردی‏اف، مدل داده‏ی معنایی مورداستفاده در این مقاله است. شمای داده‏ نیز با استفاده از آنتولوژی ریزتاکتیک که در بخش 3.1.3 معرفی شد توصیف می‏شود. هر مدل ریزتاکتیک موجود در مخزن، ‏اجزاء یک تاکتیک و روابط بین آن‏ها را توصیف می‏کند.

توصیف مدل‏های ریزتاکتیک نیازمند شناسایی ریزتاکتیک‏های موجود در هر تاکتیک‏ معماری است. در این بخش با استفاده از رویکرد معرفی‌شده توسط کیم و همکاران به‌منظور توصیف تاکتیک‏های معماری، مدل‏های معنایی ریزتاکتیک ایجاد و در مخزن معنایی ذخیره می‏شوند[14].

شکل‏ 6 مدل‏ ریزتاکتیک مرتبط با تاکتیک «ضربان قلب»³ را بر اساس متامدل پیشنهادی ریزتاکتیک نمایش می‏دهد. تاکتیک ضربان قلب یکی از تاکتیک‏های مرتبط با ویژگی کیفیتی دسترس‏پذیری است. جدول 2 نیز بخشی از سه‏گانه‏های آردی‏اف مربوط به مدل معنایی تاکتیک ضربان قلب را نمایش می‏دهد.

نکته قابل‌توجه در خصوص مخزن معنایی ریزتاکتیک امکان تکامل آن توسط آکسیوم‏ها⁴ و قوانین⁵ است. با افزودن آکسیوم‏ها و قوانین جدید به مخزن معنایی ریزتاکتیک، امکان استنتاج بر روی داده‏های موجود و به‌تبع آن تولید سه‏گانه‏های جدید آردی‏اف وجود دارد. این سه‏گانه‏های جدید امکان غنی‏تر شدن مخزن معنایی تاکتیک را در طول زمان فراهم می‏کنند.

مخزن معنایی ریزتاکتیک علاوه بر داده‏های معنایی در قالب آردی‏اف شامل پرس‏وجوهای معنایی در قالب اسپارکل است. این پرس‏وجو‏ها بر اساس متامدل ریزتاکتیک و با استفاده از آنتولوژی ریزتاکتیک به‌منظور شناسایی اجزایی از کد منبع که مشابهت ساختاری به یک تاکتیک معماری دارند تعریف می‏شوند.

جدول 2. بخشی از مدل معنایی مربوط به تاکتیک ضربان قلب

مدل آردی‏اف ضربان قلب
Object	Predicate	Subject
Structural_Feature_MicroTactic	type	Last_Updated_Time
Sending_Interval	Has_Structural_Feature	Emitter
Classifier_MicroTactic	type	Emitter
Behaviroal_Feature_MicroTactic	type	Update_Time
Last_Updated_Time	Has_Structural_Feature	Receiver
Checking_Time	Has_Structural_Feature	Receiver
Update_Time	Has_Beahvioral_Feature	Receiver
Check_Alive	Has_Beahvioral_Feature	Receiver
Classifier_MicroTactic	type	Receiver

3.2.3 پیشنهاد تاکتیک

در این بخش با استفاده از پرس‏وجو‏های معنایی ایجادشده در بخش 2.2.3، کلاس‏هایی از کد منبع که احتمال پیاده‏سازی بخشی از تاکتیک‏های معماری توسط آن‌ها وجود دارد شناسایی می‏شوند. متأسفانه برخی از کلاس‏های شناسایی‌شده در این مرحله دارای «مثبت کاذب»⁶ هستند و ممکن است بیانگر یک پیاده‏سازی از تاکتیک یا ریزتاکتیک معماری نباشند. لذا خروجی این مرحله به‌عنوان نامزدهایی⁷ برای پیاده‏سازی بخشی از تاکتیک‏های معماری مطرح است. در این مرحله یک الگوریتم برای پیشنهاد تاکتیک‏های معماری معرفی می‏شود. بر اساس این الگوریتم، هر یک از پرس‏وجوهای توصیف‌شده در بخش 2.2.3 بر روی مدل معنایی کد منبع اجراشده و نتایج به‌دست‌آمده مجموعه‏ای از تاکتیک‏های نامزد را ارائه می‏نماید.

1. semSrc = Semantic Source Code;

2. tSRepo = Repository of SPARQL queries;

3. tCandidList = Tactic Candidate List = {};

4. foreach query tS in repository tSRepo {

5. c = execSparql(tS , semSrc);

6. if (c != Null)

7. {

8. add c to tCandidList;

9. }

10. }

11. return tCandidList;

شکل 7. شبه کد الگوریتم پیشنهاد تاکتیک

شکل 7 شبه کد الگوریتم پیشنهاد تاکتیک را نمایش می‏دهد. بر اساس این الگوریتم، پرس‏وجوهای مرتبط با هر تاکتیک معماری بر روی مخزن معنایی کد منبع اجراشده و نتایج در قالب مجموعه تاکتیک‏های نامزد به بخش بعدی که شناسایی تاکتیک است ارسال می‏شود.

4.2.3 شناسایی تاکتیک

در این مرحله از بین موارد پیشنهادشده در مرحله قبل تاکتیک یا تاکتیک‏های نهایی شناسایی می‏شوند. رویکرد این بخش استفاده از تکنیک‏های مشابهت معنایی به‌منظور مقایسه‏ی تاکتیک‏های نامزد شناسایی‌شده در بخش 3.2.3 با سه‏گانه‏های آر‏دی‏اف موجود در مخزن تاکتیک است.

در یک کد شی‌ءگرا، کلاس کوچک‌ترین کپسول ماژولاری است که امکان پیاده‏سازی بخشی از یک تاکتیک معماری را دارد. ما در این بخش کلاس را در قالب یک چهارگانه به شکل زیر تعریف می‏کنیم:

(2)

در این چهارگانه Ni بیانگر نام کلاس i، Ai مجموعه ویژگی‏های کلاس i، Mi مجموعه متدهای کلاس i و Pi مجموعه پارامترهای مربوط به متدهای کلاس i است. همچنین هر تاکتیک معماری را در قالب یک چندگانه به شکل زیر تعریف می‏کنیم:

(3)

در این چندگانه TNi نام تاکتیک i، TCi مجموعه کلاس‏های تاکتیک i، TSFi مجموعه خصیصه‏های ساختاری تاکتیک i، TBFi مجموعه خصیصه‏های رفتاری تاکتیک i، TPi مجموعه پارامترهای مربوط به خصیصه‏های رفتاری تاکتیک i و TRi مجموعه روابط بین کلاس‏های تاکتیک i را نمایش می‏دهد.

ایده اصلی الگوریتم شناسایی تاکتیک بر اساس محاسبه‏ی میزان شباهت معنایی هر کلاس‏ Ci از کد منبع با تاکتیک‏های Ti موجود در مخزن تاکتیک است. بدین منظور، شباهت معنایی المان‏های متناظر موجود در چندگانه‏های معرفی‌شده در روابط (2) و (3) با یکدیگر محاسبه می‏شود.

الگوریتم‏های متنوعی برای محاسبه‏ی میزان شباهت دو کلمه یا جمله معرفی‌شده است. مشابهت معنایی در این مقاله بر اساس رابطه‏ی (4) محاسبه می‏شود[22].

(4)

در رابطه (4) میزان مشابهت یک کلاس با یک تاکتیک بر اساس سه مؤلفه‌ی مشابهت ساختاری، رفتاری و کلاسی محاسبه می‏شود. این سه مؤلفه مشابهت در روابط (5) تا (7) تعریف‌شده است.

(5)

(6)

(7)

در رابطه (8) نیز نحوه محاسبه‏ی semSim مشاهده می‏شود.

(8)

در رابطه‏ی (8) semSimT بیانگر شباهت معنایی بر اساس وردنت⁸ یا هر آنتولوژی از واژگان نظیر ویکی‌پدیا است.

شکل 8 شبه کد مربوط به الگوریتم انتخاب تاکتیک برای کلاس c را نمایش می‏دهد.

1. c = A Class of Source Code;

2. tCandidList = Candidate List of Tactics;

3. tFinalList = Final List of Tactics = {};

4. foreach tactic t in tCandidList {

5. s = semSim(c, t);

6. if (s >= threshold)

7. {

8. add t to tFinalList;

9. }

10. }

11.

12. if (tFinalList.length >0)

13. return tFinalList;

14. else

15. return tCandidList;

شکل 8. شبه کد الگوریتم انتخاب تاکتیک

تعیین حد آستانه و وزن‏های α در الگوریتم فوق می‏تواند بر میزان دقت و یادآوری رویکرد پیشنهادی تأثیرگذار باشد. انتخاب این حد آستانه به‌صورت تجربی انجام می‏شود.

4. مطالعه موردی

در این بخش با انجام یک مطالعه موردی نحوه عملکرد راهکار پیشنهادی موردبررسی و ارزیابی قرار می‏گیرد. در ادامه و در ابتدا مقدمات مطالعه موردی تشریح می‏شود. سپس مطالعه موردی انجام می‏شود.

1.4 تشریح مقدمات انجام مطالعه موردی

در این بخش مقدمات انجام مطالعه‏ی موردی شامل معرفی سنجه‏های ارزیابی، کد منبع انتخاب‌شده، تاکتیک‏های معماری موردنظر و دیتاست مورداستفاده معرفی می‏شوند.

1.1.4 معرفی سنجه‏های ارزیابی

نتایج این مطالعه موردی بر اساس سه سنجه‏ی استاندارد حوزه‏ی بازیابی اطلاعات مورد ارزیابی قرار می‏گیرد.

(9)

(10)

(11)

سنجه‏ی یادآوری⁹ بیانگر نسبت تعداد کلاس‏های مرتبط با تاکتیک‏های معماری در کلاس‏های شناسایی‌شده به تعداد کل کلاس‏های مرتبط است. سنجه‏ی دقت¹⁰ بیانگر تعداد کلاس‏های مرتبط با تاکتیک‏های معماری در کلاس‏های شناسایی‌شده به تعداد کل کلاس‏های بازیابی شده است. سنجه‏ی-اف¹¹ نیز یک «میانگین همساز»¹² از دقت و یادآوری است.

2.1.4 انتخاب کد منبع

در این مرحله یک پروژه نرم‏افزاری متن‌باز که قرار است رویکرد پیشنهادی برای شناسایی تاکتیک‏های معماری بر روی آن آزمایش شود انتخاب می‏شود. در این مقاله چارچوب متن‌باز «آپاچی هدوپ»¹³ برای این منظور انتخاب‌شده است. آپاچی هدوپ مجموعه‌ای متشکل از ابزارهای متن‌باز است که برای غلبه بر مشکلات مرتبط با «کلان داده‌ها»¹⁴ از آن استفاده می‌شود. هدوپ یک پروژه سطح بالای آپاچی است که توسط گستره وسیعی از مشارکت‌کنندگان پشتیبانی و استفاده می‌شود و از زبان برنامه‌سازی جاوا استفاده می‌کند. این پروژه به‌صورت متن‌باز و در گیت‏هاب در دسترس است¹⁵.

3.1.4 انتخاب تاکتیک‏های معماری

مرحله بعدی در انجام این مطالعه موردی انتخاب تاکتیک‏هایی است که قرار است شناسایی آن‌ها توسط رویکرد پیشنهادی مورد ارزیابی قرار گیرد. تاکتیک‏های ضربان قلب، نقطه‏ی چک¹⁶، آربَک¹⁷ و زمان‌بندی¹⁸ تاکتیک‏های انتخاب‌شده در این مقاله هستند.

جدول 3. لیست تاکتیک‏های معماری انتخاب‌شده

ردیف	نام تاکتیک	نام ویژگی کیفیتی مرتبط
1	ضربان قلب	دسترس‏پذیری
2	نقطه‏ی چک	دسترس‏پذیری
3	آربَک	امنیت
4	زمان‌بندی	کارایی

دو تاکتیک معماری ضربان قلب و نقطه‏ی چک مرتبط با ویژگی کیفیتی دسترس‏پذیری هستند. آربَک نیز تاکتیک‏ معماری مرتبط با ویژگی کیفیتی امنیت و زمان‌بندی مرتبط با ویژگی کیفیتی کارایی هستند. جدول 3 تاکتیک‏های انتخاب‌شده را نمایش می‏دهد.

4.1.4 دیتاست

در این بخش کدهای چارچوب هدوپ به‌منظور شناسایی تاکتیک‏های موردنظر موردبررسی دستی قرار می‏گیرد. این شناسایی با مراجعه به مقالات مرتبط با این چارچوب و بررسی کد منبع توسط نویسنده اول مقاله انجام‌شده است. جدول 4 نتایج این بررسی را نمایش می‏دهد.

جدول 4. نمونه‏های تاکتیک‏های معماری در آپاچی هدوپ

نام تاکتیک	نام پکیج در هدوپ	تعداد کلاس
ضربان قلب	HDFS	27
نقطه‏ی چک	MapReduce, HDFS	32
آربَک	HDFS, MapReduce, Security	39
زمان‌بندی	Common & MapReduce	88

2.4 انجام مطالعه موردی

در این بخش مطالعه‏ی موردی بر اساس موارد تعیین‌شده در بخش 4-1 انجام می‏شود. بدین منظور و در ابتدا مدل معنایی مربوط به پروژه آپاچی هدوپ ایجاد می‏شود. سپس بر اساس پرس‏وجو‏های اسپارکل مربوط به تاکتیک‏های معرفی‌شده در جدول 4، لیست کلاس‏های شناسایی به‌عنوان تاکتیک‏های نامزد بر اساس الگوریتم پیشنهاد تاکتیک محاسبه می‏شود.‏ در انتها نیز بر اساس الگوریتم شناسایی تاکتیک لیست تاکتیک‏های شناسایی‌شده نهایی استخراج می‏شود.

5. بحث

جدول‏ 5 نتایج حاصل از محاسبه‏ی سنجه‏های معرفی‌شده در بخش 4.1.1 را بر روی نتایج به‌دست‌آمده از رویکرد پیشنهادی نمایش می‏دهد. جدول‏ 6 نیز نتایج حاصل از محاسبه‏ی این سنجه‏ها را بر روی نتایج به‌دست‌آمده از رویکرد تِد نمایش می‏دهد[6].

در شکل 9 نیز میزان سنجه‏ی-اف در این دو رویکرد در قالب یک نمودار نمایش داده‌شده است. مقایسه نتایج حاصل از رویکرد پیشنهادی با نتایج حاصل از تِد به‌عنوان مهم‌ترین رویکرد موجود در این حوزه بیانگر این واقعیت است که رویکرد معنایی پیشنهادشده در این مقاله نتایج قابل قبولی را ارائه نموده است.

جدول 5. نتایج به‌دست‌آمده از رویکرد تِد

نام تاکتیک	دیدگاه تِد
نام تاکتیک	دقت	یادآوری	سنجه‏ی‏اف
ضربان قلب	0.66	1	0.79
نقطه‏ی چک	1	1	1
آربَک	0.31	0.97	0.48
زمان‏بندی	0.65	0.94	0.77

جدول 6. نتایج به‌دست‌آمده از رویکرد پیشنهادی

نام تاکتیک	دیدگاه پیشنهادی
	دقت	یادآوری	سنجه‏ی‏اف
ضربان قلب	0.93	0.71	0.81
نقطه‏ی چک	0.88	1	0.93
آربَک	0.77	0.97	0.86
زمان‏بندی	0.83	0.73	0.78

شکل 9. مقایسه سنجه‏ی اف در رویکرد پیشنهادی و تِد

همان‌گونه که در شکل 9 مشاهده می‏شود در خصوص تاکتیک‏های ضربان قلب، آربَک و زمان‌بندی، رویکرد پیشنهادی در این مقاله نتایج بهتری ارائه نموده است؛ اما در خصوص تاکتیک نقطه‏ی چک رویکرد تِد وضعیت بهتری دارد. نکته قابل‌توجه در خصوص روش تِد در این نمودار، مشاهده تغییرات شدید بین میزان سنجه‏ی-اف برای تاکتیک‏های نقطه‏ی چک و آربَک است. همان‌گونه که مشاهده می‏شود تغییر شدید در مقدار این سنجه در رویکرد پیشنهادی وجود ندارد.

درروش تِد تمرکز اصلی بر روی یادگیری واژگان استفاده‌شده در پیاده‏سازی‏های مختلف از یک تاکتیک است. لذا میزان سنجه‏ی‏-اف به الگوریتم یادگیری و دیتاست مربوطه وابسته است. همچنین پیاده‏سازی‏های جدید از یک تاکتیک نیازمند فرآیند یادگیری مجدد است که وجود این نقص از کارایی این روش می‏کاهد.

6. نتیجه‏گیری

در این مقاله یک رویکرد معنایی به‌منظور شناسایی خودکار تاکتیک‏های معماری از کد منبع معرفی‌شده است. بدین منظور در ابتدا یک متامدل برای تاکتیک‏های معماری معرفی‌شده و به‌عنوان متامدل برای مدل‏های تاکتیک مورداستفاده قرارگرفته است. همچنین بر اساس این متامدل یک آنتولوژی ایجادشده که به‌عنوان شمای مدل‏های معنایی تاکتیک مورداستفاده قرارگرفته است. سپس هر تاکتیک توسط یک مدل معنایی با ساختار آردی‏اف توصیف و در مخزن ذخیره می‏شود. از طرف دیگر، کد منبع پروژه نیز به ساختار آردی‏اف تبدیل می‏شود. سپس فرآیند شناسایی تاکتیک طی دو مرحله و بر اساس شباهت معنایی و ساختاری انجام می‏شود.

نتایج حاصل از ارزیابی رویکرد پیشنهادی بیانگر کارایی قابل‌قبول این روش است. رویکرد معنایی پیشنهادی از دو جنبه‏ی مهم دارای تأثیرات مثبت است. اولین جنبه قابل‌گسترش بودن آن است. در این رویکرد امکان افزودن مدل‏های معنایی مرتبط با تاکتیک‏های معماری با یافتن پیاده‏سازی‏های جدید از هر تاکتیک به‌سادگی امکان‏پذیر است. هر پیاده‏سازی جدید از یک تاکتیک با افزودن آکسیوم‏های مربوطه به مدل معنایی قابل‌استفاده خواهند بود. جنبه مثبت دیگر رویکرد پیشنهادی عدم نیاز به فرآیند یادگیری است که یک فرآیند زمان‏بر است و نیازمند دیتاست‏های مربوط به خود است. همچنین به‌کارگیری رویکرد معنایی این امکان را فراهم می‏کند که فرآیند شناسایی یک تاکتیک به واژگان خاصی حساس نباشد.

پژوهش‏های آتی در این حوزه شامل افزودن سایر تاکتیک‏های معماری به مخزن معنایی خواهد بود. همچنین با افزودن امکان شناسایی روابط بین تاکتیک‏ها الگوریتم‏های شناسایی و انتخاب تاکتیک بهبود خواهد یافت.

7. مراجع

[1] M. Mirakhorli, “Preventing erosion of architectural tactics through their strategic implementation, preservation, and visualization,” in 2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE), Nov. 2013, pp. 762–765. doi: 10.1109/ASE.2013.6693152.

[2] N. B. Harrison and P. Avgeriou, “How do architecture patterns and tactics interact? A model and annotation,” Journal of Systems and Software, vol. 83, no. 10, pp. 1735–1758, Oct. 2010, doi: 10.1016/j.jss.2010.04.067.

[3] M. Mirakhorli, A. Fakhry, A. Grechko, M. Wieloch, and J. Cleland-Huang, “Archie: A Tool for Detecting, Monitoring, and Preserving Architecturally Significant Code,” in Proceedings of the 22Nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, New York, NY, USA, 2014, pp. 739–742. doi: 10.1145/2635868.2661671.

[4] J. Ryoo, P. Laplante, and R. Kazman, “A Methodology for Mining Security Tactics from Security Patterns,” in 2010 43rd Hawaii International Conference on System Sciences, Jan. 2010, pp. 1–5. doi: 10.1109/HICSS.2010.18.

[5] M. Mirakhorli, P. Mäder, and J. Cleland-Huang, “Variability points and design pattern usage in architectural tactics,” in Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering, New York, NY, USA, Nov. 2012, pp. 1–11. doi: 10.1145/2393596.2393657.

[6] M. Mirakhorli and J. Cleland-Huang, “Detecting, Tracing, and Monitoring Architectural Tactics in Code,” IEEE Transactions on Software Engineering, vol. 42, no. 3, pp. 205–220, Mar. 2016, doi: 10.1109/TSE.2015.2479217.

[7] D. E. Krutz and M. Mirakhorl, “Architectural clones: toward tactical code reuse,” in Proceedings of the 31st Annual ACM Symposium on Applied Computing, New York, NY, USA, Apr. 2016, pp. 1480–1485. doi: 10.1145/2851613.2851787.

[8] I. J. Mujhid, J. C. S. Santos, R. Gopalakrishnan, and M. Mirakhorli, “A search engine for finding and reusing architecturally significant code,” Journal of Systems and Software, vol. 130, pp. 81–93, Aug. 2017, doi: 10.1016/j.jss.2016.11.034.

[9] J. Keim, A. Kaplan, A. Koziolek, and M. Mirakhorli, “Does BERT Understand Code? – An Exploratory Study on the Detection of Architectural Tactics in Code,” in Software Architecture, Cham, 2020, pp. 220–228. doi: 10.1007/978-3-030-58923-3_15.

[10] B. Milhem and H. A. Ismail, “Evaluating Software Architecture Based on Their Implemented Patterns and Tactics,” Thesis, Université d’Ottawa / University of Ottawa, 2020. doi: 10.20381/ruor-25057.

[11] M. Zanoni, F. Arcelli Fontana, and F. Stella, “On applying machine learning techniques for design pattern detection,” Journal of Systems and Software, vol. 103, no. Supplement C, pp. 102–117, May 2015, doi: 10.1016/j.jss.2015.01.037.

[12] J. (Yossi) Gil and I. Maman, “Micro Patterns in Java Code,” in Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-oriented Programming, Systems, Languages, and Applications, New York, NY, USA, 2005, pp. 97–116. doi: 10.1145/1094811.1094819.

[13] S. Maggioni, “Design pattern detection and software architecture reconstruction: an integrated approach based on software micro-structures,” Università degli Studi di Milano-Bicocca, 2010.

[14] S. Kim, D.-K. Kim, L. Lu, and S. Park, “Quality-driven architecture development using architectural tactics,” Journal of Systems and Software, vol. 82, no. 8, pp. 1211–1231, Aug. 2009, doi: 10.1016/j.jss.2009.03.102.

[15] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 3rd edition. Upper Saddle River, NJ: Addison-Wesley Professional, 2012.

[16] R. Studer, V. R. Benjamins, and D. Fensel, “Knowledge engineering: Principles and methods,” Data & Knowledge Engineering, vol. 25, no. 1, pp. 161–197, Mar. 1998, doi: 10.1016/S0169-023X(97)00056-6.

[17] A. Barforoush and A. Rahnama, “Ontology Learning: Revisited,” Journal of Web Engineering (JWE), vol. 11, pp. 269–289, Dec. 2012.

[18] N. Noy and D. Mcguinness, “Ontology Development 101: A Guide to Creating Your First Ontology,” Knowledge Systems Laboratory, vol. 32, Jan. 2001.

[19] S. Ehsan and D. Mahmood, “AN APPLICABLE METHOD FOR COMPREHENSIVE CORPUS GATHERING NEEDS FOR FUZZY DOMAIN ONTOLOGY GENERATION,” ELECTRONIC INDUSTRIES, vol. 7, no. 1, pp. 89–103, Jan. 2016.

[20] R. Y. K. Lau, D. Song, Y. Li, T. C. H. Cheung, and J.-X. Hao, “Toward a Fuzzy Domain Ontology Extraction Method for Adaptive e-Learning,” IEEE Transactions on Knowledge and Data Engineering, vol. 21, no. 6, pp. 800–813, Jun. 2009, doi: 10.1109/TKDE.2008.137.

[21] M. Atzeni and M. Atzori, “CodeOntology: RDF-ization of Source Code,” in The Semantic Web – ISWC 2017, Cham, 2017, pp. 20–28. doi: 10.1007/978-3-319-68204-4_2.

[22] S. Paydar and M. Kahani, “A semantic web enabled approach to reuse functional requirements models in web engineering,” Autom Softw Eng, vol. 22, no. 2, pp. 241–288, Jun. 2015, doi: 10.1007/s10515-014-0144-4.

[1] Change Event

[2] Commit

[3] Heartbeat

[4] Axioms

[5] Rules

[6] False Positive

[7] Candidate

[8] WordNet

[9] Recall

[10] Precision

[11] F-measure

[12] Harmonic mean

[13] Apache Hadoop

[14] Big Data

[15] https://github.com/apache/Hadoop

[16] Checkpoint

[17] RBAC

[18] Scheduling

Architectural Tactics identification in Source Code based on a

Semantic Approach

Abstract:

Software systems are alive as long as they can be changed and used. Changing the source code without considering the consequences can lead to the architectural erosion of software systems. Architectural erosion gradually makes the system unchangeable and moves it towards deterioration. Architectural decisions in the source code are usually made using architectural tactics. These tactics are fine-grained decisions that are made to achieve a certain quality attribute. Recognizing these tactics in the source code, allows developers to change the code while knowing the implementation location of these decisions. This slows the architectural erosion process and delays the system's movement towards deterioration. Thus, this paper introduces a semantic method for recognizing the architectural tactics presented in the source code. Based on this approach, the new concept of microtactic is introduced that increases the possibility of recognizing architectural tactics using a semantic web and ontological approach. The evaluation results show that this method in comparison with other similar methods recognizes the tactics with higher precision and quality.

Keywords: Architectural tactic, Microtactic, An ontology, semantic model

اشتراک گذاری

آدرس مقاله

شناسایی تاکتیک‏های معماری در کد منبع بر اساس یک رویکرد معنایی

رایمگ

پیوندهای سایت

مراکز مرتبط

پشتیبانی

صفحات رسمی