Architectural tactics identification in source code based on a semantic approach
Subject Areas :Ehsan Sharifi 1 , Ahmad عبداله زاده بارفروش 2
1 - Amir Kabir University
2 - Amirkabir
Keywords: Architectural tactic, Microtactic, ontology, semantic model,
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 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 |
|
شناسایی تاکتیکهای معماری در کد منبع بر اساس یک رویکرد معنایی
احسان شریفی* احمد عبدالله زاده بارفروش**
* دانشجوی دکتری، دانشکده مهندسی کامپیوتر، دانشگاه صنعتی امیرکبیر، تهران، ایران
** استاد، دانشکده مهندسی کامپیوتر، دانشگاه صنعتی امیرکبیر، تهران، ایران
تاریخ دریافت: 17/03/1400 تاریخ پذیرش: 06/06/1400
نوع مقاله: پژوهشی
چكیده
سامانههای نرمافزاری تا زمانی که قابلیت اعمال تغییرات را داشته باشند زنده هستند و امکان استفاده از آنها وجود دارد. اعمال تغییرات در کد منبع بدون توجه به تأثیرات آن میتواند باعث فرسایش معماری سامانهی نرمافزاری شود. فرسایش معماری بهمرور، امکان انجام تغییرات را غیرممکن مینماید و سامانه روبهزوال میرود. تصمیمات معماری در کد منبع معمولاً توسط تاکتیکهای معماری محقق میشوند. تاکتیکها تصمیمهای ریزدانهای هستند که برای تحقق یک ویژگی کیفیتی خاص اتخاذ میشوند. شناسایی تاکتیکها در کد منبع این امکان را برای تولیدکنندگان فراهم میکند که اعمال تغییرات در کد منبع را با آگاهی از مکان پیادهسازی این تصمیمها انجام دهند. لذا فرآیند فرسایش معماری کندتر شده و سامانهی نرمافزاری دیرتر به سمت زوال حرکت مینماید. بدین منظور، در این مقاله یک رویکرد معنایی بهمنظور شناسایی تاکتیکهای معماری در کد منبع معرفی میشود. بر اساس این رویکرد، مفهوم جدیدی به نام ریزتاکتیک معرفی میشود که امکان شناسایی تاکتیکهای معماری را با استفاده از یک رویکرد معنایی مبتنی بر وب معنایی و آنتولوژی ارتقاء میبخشد. نتایج حاصل از ارزیابی رویکرد پیشنهادی نشان میدهد که امکان شناسایی تاکتیکها در این روش با دقت و کیفیت بهتری نسبت به روشهای مشابه انجام میشود.
واژگان کلیدی: تاکتیک معماری، ریزتاکتیک، آنتولوژی، مدل معنایی
1. مقدمه
سامانههای نرمافزاری مانند یک موجود زنده بهطور مستمر در حال تغییر هستند. بخش عمدهی فعالیت یک تیم توسعه، اعمال تغییر و ایجاد تکامل در محصولی است که بر اساس نیازمندیهای جدید مشتری در حال رشد است. تا زمانی که امکان اعمال تغییرات در نویسنده مسئول: احمد عبدالله زاده بارفروش Ahmad@aut.ac.ir
محصول نرمافزاری وجود دارد چرخه حیات محصول در جریان بوده و محصول زنده است.
هر زمان که امکان تکامل و تغییر فراهم نباشد یا بهسختی انجام شود چرخه حیات محصول به اتمام رسیده است و محصول جدید جایگزین قبلی میشود. فرسایش معماری زمانی اتفاق میافتد که تیم توسعه بدون توجه به معماری کلی و بهمرور، تغییراتی محلی را در سطح کد اعمال میکند و به دلیل ناآگاهی از تصمیمات معماری در سطح کلان باعث فرسایش معماری میگردد. مهمترین تأثیر این فرسایش پایین آمدن قابلیت نگهداری نرمافزار است[1].
فرسایش معماری1 زمانی اتفاق میافتد که تیم توسعه بدون توجه به معماری کلی و بهمرور، تغییراتی محلی را در سطح کد اعمال میکند و به دلیل ناآگاهی از تصمیمهای معماری در سطح کلان باعث فرسایش معماری میشود. مهمترین تأثیر این فرسایش پایین آمدن قابلیت نگهداری نرمافزار است[1].
الگوها و تاکتیکهای معماری دو نمونه از تصمیمهای معماری هستند که برای تحقق ویژگیهای کیفیتی اتخاذ میشوند. الگوهای معماری راهحلهای درشتدانهای هستند که از مجموعهای از تاکتیکهای معماری و الگوهای طراحی تشکیلشدهاند و طیف وسیعی از ویژگیهای کیفیتی را تحت تأثیر قرار میدهند. در مقابل، تاکتیکهای معماری تصمیمهای طراحی ریزدانهای هستند که هدف آنها تحقق یک ویژگی کیفیتی مشخص است[2]. بهعنوانمثال، یکی از دغدغههای طراحی مرتبط با ویژگی کیفیتی امنیت، «نحوه جلوگیری از حمله2 به یک سیستم» است و یک تصمیم طراحی یا به عبارت صحیحتر تاکتیک معماری متناظر با آن «تائید اعتبار»3 کاربر است.
تاکتیکهای معماری به دلیل ماهیت ریزدانگی که دارند مهمترین اجزاء معماری هستند که امکان شناسایی در کد منبع نرمافزار رادارند. لذا شناسایی و مراقبت از تاکتیکهای معماری در خلال فرآیند توسعهی نرمافزار میتواند فرآیند فرسایش معماری را کند نماید. متأسفانه ماهیت تاکتیکهای معماری با الگوهای طراحی تفاوت دارد. الگوهای طراحی با روشهای تحلیل ساختاری قابلشناسایی هستند؛ اما تاکتیکهای معماری بهصورت نقشها و تعاملات بین آنها توصیف میشوند و ساختار استانداردی برای پیادهسازی ندارند[3].
در این مقاله با معرفی مفهوم جدیدی به نام ریزتاکتیک4، یک رویکرد معنایی بر پایهی آنتولوژی و وب معنایی ارائه میشود که امکان شناسایی تاکتیکهای معماری در کد منبع را فراهم مینماید. بر اساس این رویکرد، تاکتیکهای معماری با استفاده از اجزاء ریزدانهتری به نام ریزتاکتیک مدل میشوند. این اجزاء با استفاده از آنتولوژی توصیفشده و از طریق پرسوجوهای وبمعنایی و استفاده از یک رویکرد مبتنی بر مشابهت معنایی امکان شناسایی تاکتیکهای معماری را فراهم میکنند.
اولین نوآوری این مقاله معرفی مفهوم ریزتاکتیک است که امکان شناسایی تاکتیکهای معماری را در سطح کد تسهیل مینماید. دومین نوآوری ارائه یک راهکار معنایی مبتنی بر وب معنایی و آنتولوژی برای شناسایی تاکتیکهای معماری است که تاکنون توسط سایر پژوهشگران موردتوجه قرار نگرفته است. بهکارگیری رویکرد معنایی در این حوزه این امکان را فراهم میکند که شناسایی تاکتیکهای معماری به ساختار نحوی پیادهسازی آنها وابسته نبوده و نتایج بهدستآمده دارای صحت و اعتبار بیشتری باشد.
ساختار مقاله در ادامه بدینصورت است. در بخش دوم پیشینه تحقیق بهصورت اجمالی بررسی میشود. سپس در بخش سوم رویکرد پیشنهادی معرفی میشود. در بخش چهارم با انجام یک مطالعه موردی نتایج حاصل از رویکرد پیشنهادی مورد آزمایش قرار میگیرد. در بخش پنجم نتایج حاصل موردبحث و بررسی قرارگرفته و در بخش ششم نتیجهگیری انجامشده و فعالیتهای آتی معرفی میشوند.
2. پیشینه تحقیق
در حوزهی تشخیص الگوهای طراحی پژوهشهای متنوعی انجامشده است؛ اما در حوزهی شناسایی تاکتیکهای معماری پژوهشهای انجامشده اندک است. در ادامه به معرفی چند پژوهش شاخص در این حوزه میپردازیم.
رویکرد برخی از پژوهشهای این حوزه، استخراج تاکتیکهای معماری از الگوهای طراحی یا معماری است. یکی از پژوهشهای مطرح در این حوزه یک رویکرد جدید برای استخراج تاکتیکهای معماری مربوط به ویژگی کیفیتی امنیت از الگوهای شناختهشده معرفی نموده است[4]. هستهی اصلی این رویکرد، آزمودن الگوهای معماری شناختهشده در حوزهی امنیت است. این آزمون بهمنظور بررسی مجموعهای از شرایط است که در صورت احراز، الگوی موردنظر بهعنوان یک تاکتیک معماری شناخته خواهد شد. ضعف این دیدگاه عدم توجیه نحوه تعیین شرایط مذکور است.
در پژوهش دیگر از تکنیکهای دادهکاوی برای یافتن نمونههای الگوهای طراحی در تاکتیکهای معماری استفادهشده است[5]. هدف از این پژوهش ایجاد «نقاط تغییری»5 است که امکان پیادهسازی یا شناسایی تاکتیکهای معماری را بر اساس الگوهای طراحی مختلف فراهم نماید.
یکی دیگر از پژوهشهای مطرح در این حوزه با استفاده از تکنیکهای بازیابی اطلاعات و یادگیری ماشین تاکتیکهای معماری را شناسایی نموده است. دیدگاه اصلی این پژوهش مبتنی بر یادگیری واژگانی است که در پیادهسازیهای مختلف تاکتیکهای معماری مورداستفاده قرار میگیرند[6]. نقطهضعف اصلی این رویکرد وابسته بودن به واژگانی است که قبلاً در پیادهسازیهای مختلف تاکتیکها مورداستفاده قرارگرفتهاند. تغییر این واژگان یا استفاده از واژگان هممعنی میتواند دقت شناسایی این روش را بهشدت کاهش دهد.
تحقیق دیگری در این حوزه ایدهی ایجاد یک موتور جستجو برای تاکتیکهای معماری را مطرح نموده است[7]. ایده اصلی این دیدگاه معرفی مفهوم «کلونهای تاکتیک»6 بهعنوان المان اصلی این موتور جستجو است. یک رویکرد مشابه نیز برای یافتن کدهای مهم ازنظر معماری پیشنهاد شده است[8]. در این رویکرد از تکنیکهای بازیابی اطلاعات و «تحلیل برنامه»7 برای شناسایی کدهای موردنظر استفاده میکند.
پژوهش دیگر در این حوزه مسئلهی شناسایی تاکتیک را به مسئلهی دستهبندی8 کردن متن نگاشت نموده و با استفاده از مدلهای زبانی نظیر برت9 سعی نموده است که این مسئله را در حوزه پردازش زبان طبیعی حل نماید[9].
در یک رویکرد دیگر برای ارزیابی معماری سامانههای نرمافزاری، از شناسایی الگوها و تاکتیکهای پیادهسازی شده در آنها استفاده شده است[10]. این روش با استفاده از ابزاری به نام آرچی10 تاکتیکها و الگوهای معماری را از کد منبع استخراج نموده و پس از توصیف آنها در قالب مدلهای معماری، میزان تأثیر آنها بر ویژگیهای کیفیتی را با استفاده از یکزبان توصیف نیازمندی هدفگرا11 بررسی مینماید.
3. رویکرد پیشنهادی
در این بخش رویکرد ردیابی پیشنهادی معرفی میشود. در ابتدا برخی مفاهیم نظری12 مرتبط با این رویکرد تشریح میشوند. سپس فعالیتهای مربوط به روش پیشنهادی با جزئیات تشریح میشوند.
1.3 مفاهیم نظری
در این بخش در ابتدا مفهوم ریزتاکتیک معرفیشده و در ادامه یک متامدل و آنتولوژی برای توصیف آن ارائه میشود. سپس یک آنتولوژی برای توصیف کدهای شیءگرا معرفیشده و در انتها نیز چارچوبی برای توصیف معنایی کد شیءگرا به نام کدآنتولوژی پلاس معرفی میشود.
1.1.3 معرفی مفهوم ریزتاکتیک
شناسایی المانهایی در کد منبع که بهطور بالقوه محقق کننده تاکتیکها باشند میتواند فرآیند شناسایی تاکتیکهای معماری در کد منبع را تسهیل نمایند. لذا میبایست به ازای هر تاکتیک معماری، ریزساختارهایی13 را که محقق کننده آن تاکتیک در کد منبع هستند شناسایی نمود. ریزساختارها، المانهایی از کد منبع هستند که یک موجودیت یکتا یا ارتباط بین دو یا چند موجودیت را در کد منبع تعریف مینمایند. مهمترین ویژگی ریزساختارها، قابلشناسایی بودن آنها بهطور خودکار است و به دلیل برخورداری از این ویژگی استخراج آنها از کد منبع با دقت و یادآوری بالا قابل انجام است[11].
در این تحقیق مفهوم ریزتاکتیک برای اشاره به ریزساختارهایی انتخابشده است که در محقق نمودن اهداف یک تاکتیک معماری نقش دارند. ایده اولیه ریزتاکتیک برگرفته از دو مفهوم در حوزه الگوهای طراحی است. اولین مفهوم «ریز الگو14» است که برای الگوهای طراحی معرفیشده است [12]. مفهوم بعدی «اثرهای الگوی طراحی15» است [13].
هر دو مفهوم فوق بهعنوان یک ریزساختار قصد دارند که فرآیند شناسایی الگوهای طراحی در کد منبع را تسهیل نمایند. از این جنبه این دو ریزساختار شباهت معنایی به مفهوم ریزتاکتیک دارند. اما تفاوت اصلی ریزتاکتیک نسبت به دو مفهوم فوق در گستردگی و مقیاسپذیری آن است. درواقع میتوان اینگونه بیان کرد که ریزتاکتیکها خود شامل ریز الگوها و اثرهای الگوی طراحی هستند، اما محدود به آنها نبوده و المانهای بیشتری را میتوانند در برگیرند.
تاکتیکهای معماری زمان اجرا شامل نقشها و تعاملات بین این نقشها میباشند. لذا در وهلهی اول نقشهای موجود در یک تاکتیک انتخاب مناسبی هستند که بهعنوان ریزتاکتیک انتخاب شوند.
2.1.3 معرفی متامدل ریزتاکتیک
بهمنظور تشریح دقیق ریزتاکتیکها نیاز به ارائه یک متامدل داریم. یکی از معدود پژوهشهای موجود تاکتیکهای معماری را در قالب نقشها و تعاملات بین آنها و بر پایهی زبان آربیامال16 توصیف نموده است [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
شکل 1. متامدل پیشنهادی ریزتاکتیک
شکل 2. مدل ریزتاکتیک مربوط به تاکتیک پینگ/اکو
جدول 1: ریزتاکتیکهای مربوط به تاکتیک پینگ/اکو
نوع ریزتاکتیک | عنوان ریزتاکتیک | ردیف |
دستهبند | PingSender | 1 |
دستهبند | FaultMonitor | 2 |
دستهبند | PingReceiver | 3 |
ویژگی ساختاری | maxWaitingTime | 4 |
ویژگی ساختاری | timeInterval | 5 |
ویژگی ساختاری | elapsedTime | 6 |
ویژگی رفتاری | Ping | 7 |
ویژگی ساختاری | echo | 8 |
رابطه | notifies | 9 |
رابطه | checks | 10 |
بر اساس این متامدل، ریزتاکتیک میتواند یک دستهبند1، ویژگی، پارامتر یا رابطه باشد. شکل 2 مدل مربوط به تاکتیک پینگ/اکو2 را که بر اساس متامدل شکل 1 ایجادشده است نمایش میدهد. تاکتیک پینگ/اکو یکی از تاکتیکهای «شناسایی خرابی»3 است که ذیل تاکتیکهای مرتبط با ویژگی کیفیتی دسترسپذیری4 قرار دارد[15]. اجزای این مدل نیز در جدول 1 تشریح شده است.
3.1.3 آنتولوژی ریزتاکتیک
تعاریف مرتبط با آنتولوژی در حوزه علوم کامپیوتر بسیار متفاوت و متنوع است. مشهورترین تعریف متعلق به استادر5 است که آنتولوژی را بدینصورت تعریف میکند: «آنتولوژی یک توصیف صوری6 و صریح7 از یک مفهومسازی8 اشتراکی است»[16].
در حوزهی تاکتیکهای معماری نیازمند چنین ساختاری هستیم تا از طریق توصیف معنایی دانش این حوزه، فرآیند شناسایی تاکتیکها در کد منبع تسهیل شود. این آنتولوژی در وهلهی نخست میبایست ساختار ریزتاکتیکها را بر اساس متامدل ریزتاکتیک توصیف نماید. در وهلهی دوم نیز امکان توصیف مفاهیم و روابط موجود در حوزهی تاکتیکهای معماری را فراهم نماید. آنتولوژی در این مقاله، یک پنجتایی مرتب شامل مفاهیم (C)، روابط ردهبندی (RT)، روابط غیر ردهبندی (RN)، اصول (A) و دامنه (D) است که بدین شکل تعریف میشود[17]:
(1)
فرآیند ایجاد آنتولوژی ریزتاکتیک طی سه مرحله انجام میشود. در اولین مرحله یک «آنتولوژی پایه»9 ایجاد میشود که مفاهیم اصلی ریزتاکتیک را توصیف مینماید. در مرحلهی دوم یک «آنتولوژی حوزه»10 بر اساس مفاهیم و ردهبندیهای موجود در این حوزه ایجاد میشود. در مرحلهی سوم نیز یک آنتولوژی حوزه بر اساس منابع مرتبط با این حوزه ایجاد میشود.
در اولین مرحله و بر اساس ساختار متامدل ریزتاکتیک معرفیشده در شکل1، آنتولوژی پایه ایجاد میشود. بدین منظور، قواعد زیر را تعریف میکنیم:
- قاعده 1: هر دستهبند در متامدل به یک مفهوم در آنتولوژی نگاشت میشود.
- قاعده 2: هر رابطه ارثبری در متامدل به یک رابطه سلسله مراتبی در آنتولوژی نگاشت میشود.
- قاعده 3: هر رابطه تناظر11 در متامدل به یک رابطه غیر ردهبندی یا دودویی در آنتولوژی نگاشت میشود.
شکل 3 بخشی از آنتولوژی پایه را ذیل مفهوم «MicroTactic» نمایش میدهد. همانگونه که در متامدل شکل 1 مشاهده میشود، «Classifier Microtactic» بهعنوان یک دستهبند بر اساس قاعدهی 1 به مفهوم «Classifier_Microtactic» در آنتولوژی پایه نگاشت شده است. از طرف دیگر بر اساس قاعدهی 2 و با توجه به رابطهی ارثبری آن با کلاس «MicroTactic»، یک رابطهی سلسله مراتبی بین مفهوم «Classifier_Microtactic» و مفهوم «MicroTactic» در آنتولوژی ایجادشده است.
در مرحلهی دوم، آنتولوژی حوزه مربوط به تاکتیکهای معماری ایجاد میشود. آنتولوژی حوزه، معانی واژگان موجود در یک حوزه را تشریح نموده و امکان توصیف بهتر مفاهیم و روابط بین آنها در یک فیلد خاص را فراهم میکند[18]. در این مرحله، از ردهبندی ارائهشده توسط بَس و همکاران برای ایجاد اولین بخش از آنتولوژی حوزهی تاکتیک استفاده میشود[15]. این ردهبندی، تاکتیکهای معماری مطرح در حوزهی نرمافزار را بر اساس ویژگیهای کیفیتی مرتبط با آنها دستهبندی نموده است. شکل 3 بخشی از آنتولوژی حوزهی تولیدشده بر اساس ردهبندی فوق را ذیل مفهوم «Tactic» نمایش میدهد. این بخش از آنتولوژی بهصورت دستی و توسط نویسنده اول مقاله ایجادشده است. اما ایجاد آنتولوژی حوزه به روش دستی یک فرآیند پرهزینه، زمانبر و مستعد خطاست. خودکارسازی عملیات ساخت آنتولوژی که از آن با عنوان یادگیری آنتولوژی12 یاد میشود، هزینهی ساخت و میزان خطا را کاهش میدهد.
در بخش سوم و بهمنظور تکمیل آنتولوژی حوزه، از رویکردی که توسط نویسنده اول این مقاله استفاده میکنیم[19]. هدف اصلی این پژوهش جمعآوری «تودهی متون»13 جامع برای تولید یک آنتولوژی فازی14 است[20]. توده متون شامل کلیهی منابعی است که بهطور مستقیم یا غیرمستقیم به حوزهی موردنظر مرتبط بوده و مفاهیم و روابط موجود در حوزه با دقت قابل قبولی از این توده متون قابلاستخراج است. لذا جامعیت تودهی متون تأثیر مستقیم بر کیفیت آنتولوژی حوزهی نهایی دارد. با استفاده از این رویکرد، امکان جمعآوری خودکار توده متون جامع در حوزهی تاکتیکهای معماری فراهم میشود.
بخش سوم از آنتولوژی حوزهی تاکتیک با استفاده از این توده متون و بر اساس رویکرد [19] ایجاد میشود.
شکل 3. بخشی از آنتولوژی ریزتاکتیک
|
آنتولوژی نهایی از درونبرد15 سه آنتولوژی تولیدشده ایجاد میشود. شکل 3 بخشی از این آنتولوژی نهایی را نمایش میدهد. این آنتولوژی بهصورت آنلاین در دسترس است16.
4.1.3 آنتولوژی کد شیءگرا
بهمنظور ایجاد مدل معنایی از کد منبع نیازمند وجود یک آنتولوژی در حوزهی زبانهای شیءگرا هستیم.
در این پژوهش از یک آنتولوژی که برای برای مدلسازی معنایی زبانهای برنامهنویسی شیءگرا معرفیشده است استفاده میکنیم[21]. این آنتولوژی به زبان اُوِل217 و با ابزار پروتج18 ایجادشده است و شامل 65 کلاس، 86 ویژگی شیء19 و 11 ویژگی داده20 است. در این آنتولوژی موجودیتهای ساختاری مرتبط با تمامی زبانهای برنامهنویسی شیءگرا نظیر کلاسها، متدها، متغیرها، جملات21 و عبارتها22 را در قالب کلاسهای مجزا23 بازنمایی میشوند. طراحی این آنتولوژی بر اساس «الگوهای طراحی آنتولوژی»24 انجامشده است. این آنتولوژی بهصورت آنلاین در دسترس است25. شکل 4 بخشی از این آنتولوژی را نمایش میدهد.
شکل 4. بخشی از آنتولوژی کد شیءگرا
|
5.1.3 چارچوب کدآنتولوژی پلاس26
افزایش روزافزون حجم پروژههای نرمافزاری نیازمند راهکاری است که امکان مدیریت تغییر، بازنگری27 و بازآرایی28 کد را فراهم نماید. لذا امکان انجام پرسوجو بر روی کد منبع یکی از چالشهای مهم در حوزهی مهندسی نرمافزار است.
پشتهی فناوری وب معنایی یک مجموعه استاندارد برای بازنمایی و پرسوجوی اطلاعات ساختیافته ارائه مینماید. کدآنتولوژی چارچوبی بر مبنای وب معنایی است که امکان تبدیل کد منبع پروژه به یک مدل معنایی را فراهم میکند[21]. این ساختار معنایی امکان انجام پرسوجوهای متنوع بر روی کد منبع پروژه را با استفاده از زبان قدرتمند اسپارکل29 فراهم میکند. ورودی این چارچوب، کد منبع پروژه به زبان جاوا است و خروجی آنیک ساختار معنایی به فرمت آردیاف30 است. این چارچوب فرآیند تولید مدل آردیاف از کد منبع را طی سه مرحله انجام میدهد. در مرحلهی اول پروژه بهمنظور دانلود وابستگیهایش مورد تحلیل قرار میگیرد. سپس در مرحلهی دوم یک «درخت نحوی انتزاعی»31 از کد منبع ایجاد میشود. سپس در مرحلهی سوم این درخت مورد پردازش قرارگرفته و با استفاده از آنتولوژی کد که در بخش ۳.۱.۴ معرفی شد سهگانههای آردیاف ایجاد میشوند.
بهمنظور بهکارگیری چارچوب کدآنتولوژی در این مقاله، تغییراتی در این چارچوب ایجادشده است و ازاینپس با عنوان کدآنتولوژی پلاس به آن رجوع مینماییم. شکل ۵ چارچوب کدآنتولوژی پلاس را نمایش میدهد. بدین منظور در حین پردازش درخت نحوی انتزاعی مربوط به کد منبع، بین «موجودیتهای نامدار»32 موجود در کد منبع و مفاهیم موجود در آنتولوژی ریزتاکتیک که در بخش 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
شکل 6. مدل ریزتاکتیک ضربان قلب
2.3 تشریح رویکرد پیشنهادی
با توجه به مفاهیم و پیشنیازهای معرفیشده در بخش 3.1 فعالیتهای رویکرد پیشنهادی در این بخش تشریح میشوند. این فعالیتها شامل مدلسازی معنایی کد منبع، ایجاد مخزن معنایی ریزتاکتیک، پیشنهاد تاکتیک و شناسایی تاکتیک است.
1.2.3 مدلسازی معنایی کد
اولین فعالیت در رویکرد پیشنهادی، تبدیل کد منبع پروژه به مدل معنایی است که امکان تحلیل و استنتاج کد منبع را فراهم نموده و دستیابی به اجزاء کد را تسهیل نماید. برای این منظور از چارچوب کدآنتولوژیپلاس که در بخش 3.1.5 معرفی شد استفاده میکنیم.
نحوهی ایجاد مدل معنایی وابسته به رویکرد موردنظر است.
اگر هدف شناسایی تاکتیکهای معماری در بخش مشخصی از کد منبع نظیر یک کلاس، مؤلفه یا زیرسیستم است، میتوان فقط همان بخش از کد را به مدل معنایی تبدیل نمود. در این صورت فرآیند شناسایی تاکتیکهای معماری با سرعت و کارایی بیشتری انجام خواهد شد. در غیر این صورت میبایست تمامی کد منبع به ساختار معنایی تبدیل شود که نیازمند زمان و هزینه بیشتری است.
مدیریت تغییرات نیز بدینصورت انجام میشود که با تغییر هر بخش از کد بهطور خودکار یک «رویداد تغییر»1 ایجادشده و مدل معنایی جدیدی از کد ارسالشده2 در مخزن کد ایجاد میشود.
2.2.3 ایجاد مخزن معنایی ریزتاکتیک
گام دوم رویکرد پیشنهادی ایجاد مخزن معنایی ریزتاکتیک است. در این مخزن مدلهای ریزتاکتیک مربوط به هر تاکتیک معماری در قالب دادههای معنایی ذخیره میشوند. آردیاف، مدل دادهی معنایی مورداستفاده در این مقاله است. شمای داده نیز با استفاده از آنتولوژی ریزتاکتیک که در بخش 3.1.3 معرفی شد توصیف میشود. هر مدل ریزتاکتیک موجود در مخزن، اجزاء یک تاکتیک و روابط بین آنها را توصیف میکند.
توصیف مدلهای ریزتاکتیک نیازمند شناسایی ریزتاکتیکهای موجود در هر تاکتیک معماری است. در این بخش با استفاده از رویکرد معرفیشده توسط کیم و همکاران بهمنظور توصیف تاکتیکهای معماری، مدلهای معنایی ریزتاکتیک ایجاد و در مخزن معنایی ذخیره میشوند[14].
شکل 6 مدل ریزتاکتیک مرتبط با تاکتیک «ضربان قلب»3 را بر اساس متامدل پیشنهادی ریزتاکتیک نمایش میدهد. تاکتیک ضربان قلب یکی از تاکتیکهای مرتبط با ویژگی کیفیتی دسترسپذیری است. جدول 2 نیز بخشی از سهگانههای آردیاف مربوط به مدل معنایی تاکتیک ضربان قلب را نمایش میدهد.
نکته قابلتوجه در خصوص مخزن معنایی ریزتاکتیک امکان تکامل آن توسط آکسیومها4 و قوانین5 است. با افزودن آکسیومها و قوانین جدید به مخزن معنایی ریزتاکتیک، امکان استنتاج بر روی دادههای موجود و بهتبع آن تولید سهگانههای جدید آردیاف وجود دارد. این سهگانههای جدید امکان غنیتر شدن مخزن معنایی تاکتیک را در طول زمان فراهم میکنند.
مخزن معنایی ریزتاکتیک علاوه بر دادههای معنایی در قالب آردیاف شامل پرسوجوهای معنایی در قالب اسپارکل است. این پرسوجوها بر اساس متامدل ریزتاکتیک و با استفاده از آنتولوژی ریزتاکتیک بهمنظور شناسایی اجزایی از کد منبع که مشابهت ساختاری به یک تاکتیک معماری دارند تعریف میشوند.
جدول 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، کلاسهایی از کد منبع که احتمال پیادهسازی بخشی از تاکتیکهای معماری توسط آنها وجود دارد شناسایی میشوند. متأسفانه برخی از کلاسهای شناساییشده در این مرحله دارای «مثبت کاذب»6 هستند و ممکن است بیانگر یک پیادهسازی از تاکتیک یا ریزتاکتیک معماری نباشند. لذا خروجی این مرحله بهعنوان نامزدهایی7 برای پیادهسازی بخشی از تاکتیکهای معماری مطرح است. در این مرحله یک الگوریتم برای پیشنهاد تاکتیکهای معماری معرفی میشود. بر اساس این الگوریتم، هر یک از پرسوجوهای توصیفشده در بخش 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 یا هر آنتولوژی از واژگان نظیر ویکیپدیا است.
شکل 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)
سنجهی یادآوری9 بیانگر نسبت تعداد کلاسهای مرتبط با تاکتیکهای معماری در کلاسهای شناساییشده به تعداد کل کلاسهای مرتبط است. سنجهی دقت10 بیانگر تعداد کلاسهای مرتبط با تاکتیکهای معماری در کلاسهای شناساییشده به تعداد کل کلاسهای بازیابی شده است. سنجهی-اف11 نیز یک «میانگین همساز»12 از دقت و یادآوری است.
2.1.4 انتخاب کد منبع
در این مرحله یک پروژه نرمافزاری متنباز که قرار است رویکرد پیشنهادی برای شناسایی تاکتیکهای معماری بر روی آن آزمایش شود انتخاب میشود. در این مقاله چارچوب متنباز «آپاچی هدوپ»13 برای این منظور انتخابشده است. آپاچی هدوپ مجموعهای متشکل از ابزارهای متنباز است که برای غلبه بر مشکلات مرتبط با «کلان دادهها»14 از آن استفاده میشود. هدوپ یک پروژه سطح بالای آپاچی است که توسط گستره وسیعی از مشارکتکنندگان پشتیبانی و استفاده میشود و از زبان برنامهسازی جاوا استفاده میکند. این پروژه بهصورت متنباز و در گیتهاب در دسترس است15.
3.1.4 انتخاب تاکتیکهای معماری
مرحله بعدی در انجام این مطالعه موردی انتخاب تاکتیکهایی است که قرار است شناسایی آنها توسط رویکرد پیشنهادی مورد ارزیابی قرار گیرد. تاکتیکهای ضربان قلب، نقطهی چک16، آربَک17 و زمانبندی18 تاکتیکهای انتخابشده در این مقاله هستند.
جدول 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