چکیده
ارزیابی معماری نرم افزار تکنیکی است که ویژگی ها، کاستی ها و کیفیت سبک معماری نرم افزار یا طرح چارچوب را ارزیابی می کند. همچنین به سازندگان اطمینان میدهد که معماری انتخابی پاسخگوی نیازمندی های کیفیت عملکردی و غیرعملکردی است. چنین ارزیابی، درک و مستندسازی گسترده ساختار، تصدیق مسائل مربوط به معماری موجود را تضمین می‌کند و یادگیری سلسله مراتبی مختلف را افزایش میدهد. در این تحقیق قصد داریم مقایسه جامعی از تکنیکهاي ارزیابی معماري نرم افزار را ارائه کنیم. سپس مدل ArchCaMo را برای دسترسی به سطح بلوغ معماری با استفاده از ISO/IEC/IEEE 42010 توصیف خواهیم کرد و در نهایت، SQME را به عنوان چارچوبی برای ارزیابی معماری نرم افزار با توجه به ویژگی های کیفی مختلف معرفی می کنیم.
کلمات کلیدی: ارزیابی معماری نرم افزار، مدلهای بلوغ، معماری فنی نرم افزار
۱. مقدمه
هدف از ارزیابی معماری نرم افزار، مطالعه توانایی های معماری انتخاب شده در برآوردن نیازهای کیفی مورد نیاز و شناسایی هرگونه ریسک بالقوه است. علاوه بر این، تشخیص و حل و فصل اشتباهات طرح کلی در دوره‌های اولیه توسعه نرم‌افزار کم هزینه تر و کم ریسکتر است. این تنها دلیلی است که یک روش ارزیابی معماری نرم افزار موثر برای تجزیه و تحلیل معماری های بالقوه از اهمیت تجاری فوق العاده ای برخوردار است.
پیش نیازهای کیفیتی از اهمیت زیادی برخوردارند. طبقه‌بندی تکنیک‌های ارزیابی با استفاده از روش‌های مبتنی بر سناریو یک رویکرد توسعه‌یافته در نظر گرفته می‌شود [4، 5]. از سوی دیگر، مدلهای کمی و مدلهای ویژگی نیز به همان اندازه مهم هستند. با ظهور تکنیک های جدید و اشغال جایگاه تکنیک های قدیمی، تکنیک های موجود در حال از بین رفتن هستند. به این ترتیب، یافتن شباهت ها و تضادها در میان تکنیک های مختلف دشوار می شود. مقایسه روش‌های ارزیابی معماری نرم‌افزار می‌تواند درک روش‌های موجود را افزایش دهد که جهت‌های پژوهشی بالقوه را به محققان ارائه میدهد [6، 7]
نرم افزار پیچیده معماری پیچیده ای دارد [8] و گاهی اوقات اجرای نکات محصور شده در معماری دشوار است. بنابراین، معماری نرم افزار باید قبل از تخصیص منابع به آن، ارزیابی شود. تکنیک‌هایی برای ارزیابی معماری نرم‌افزار با متدولوژی‌های مختلف توسعه یافته‌اند. استراتژی‌های ارزیابی معماری بر ویژگی‌های کیفی مختلفی مانند قابلیت استفاده مجدد، قابلیت تغییر، دسترسی، عملی بودن، امنیت و آزمایش‌پذیری تمرکز می‌کنند، [9، 10]
علاوه بر این، با وجود اهمیت فرآیند معماری نرم افزار، فرآیند، ارزیابی و حتی تأثیر اجتماعی بر معماری نرم افزار در یک سازمان هنوز در توسعه نرم افزار نادیده گرفته می شود. ایجاد یک معماری نرم افزار قابل اعتماد و قوی نیازمند تلاش است که در صورتی که معماری به خوبی توسط ذینفعان فنی توصیف و درک نشود تقریباً بی فایده خواهد بود. معماران نرم افزار باید آن را در سطح لازم از جزئیات توصیف کنند، سعی کنند مسائل مبهم را حل کنند و معماری را به گونه ای سازماندهی کنند که قابل درک و با اطلاعاتی باشد که به راحتی بازیابی شود. مستندات معماری ناکافی، ناقص یا قدیمی یکی از موارد بدهی فنی است.
از راه حل‌های ممکن برای توصیف معماری نرم‌افزار، تکیه بر مدل‌ها و استانداردهایی مانند مدل 4+1 یا ISO/IEC/IEEE 42010 است. البته مسئله این است که در عمل درک چنین استانداردهایی دشوار است، زیرا آنها بسیار سطح بالا برای استفاده در عمل هستند یا انقدر پیچیده اند که به راحتی توسط تیم توسعه نرم افزار قابل درک نیستند.
۲. گام های قبلی
۱.۲. گام یک
در فاز یک به تکنیک های ارزیابی معماری نرم افزار پرداختیم و در نهایت به این جدول رسیدیم که مقایسه ای از روش های ارزیابی متفاوت را با استفاده از فاکتورهای ارزیابی معماری ارائه میدهد.
۲.۲. گام دو
در فاز دو، مدل ArchCaMo را برای دسترسی به سطح بلوغ معماری با استفاده از ISO/IEC/IEEE 42010 توصیف کردیم. هدفArchCaMo دوگانه است. مدلArchCaMo می تواند برای ارزیابی معماری های فعلی مورد استفاده قرار گیرد و به تیم توسعه نشان دهد که معماری آنها در چه سطحی از بلوغ قرارر دارد. علاوه بر این، برای آن دسته از سازمان‌هایی که با سازماندهی، توصیف و برقراری ارتباط معماری نرم‌افزار برای ذینفعان متعدد درگیر هستند، مفید است. با استفاده از این مدل، سازمان برای هر سطح از بلوغ معماری می داند که دقیقاً چه فعالیت ها و محصولاتی انتظار دارد.
تقریباً تمام 5 سطح ArchCaMO بر اساس قوانین استانداردISO/IEC/IEEE 42010:2011 هستند. سطح اولیه یا سطح 1، به تمام سازمان هایی اشاره دارد که روشی رسمی برای تعریف معماری نرم افزار ندارند. سطوح 2 و 3 از بیشتر جنبه های مرتبطی تشکیل شده اند که برای توصیف معماری نرم افزار ضروری هستند. سطوح 4 و 5 مربوط به جنبه هایی است که برای بهبود وضعیت معماری نرم افزار در چرخه حیاتی که قبلاً ساختار یافته، مورد نیاز است.
پس از توضیحات سطوح، نحوه عملکرد سطوح در طول فرآیند توضیح داده شد.
متوجه شدیم که مدل بلوغ ArchCaMO معماری‌های نرم‌افزار را ارزیابی می‌کند و تیم معماری نرم‌افزار را راهنمایی می‌کند که چگونه توصیفی از معماری‌های نرم‌افزار را از سیستم‌های جدید و موروثی مدیریت کند.
۳. کارهای گذشته
تعدادی از کارهای گذشته در زمینه ارزیابی معماری نرم افزار در جدول زیر أورده شده است.
۱.۳. نقص کارهای گذشته
هیچ اثری مدل بلوغ معماری نرم افزار را بر اساس ISO/IEC/IEEE 42010 که استانداردی برای توصیف نرم افزار و معماری سیستم است، توصیف نکرده است.
۴. چارچوبSQME
در این مرحله SQME را به عنوان چارچوبی برای ارزیابی معماری نرم افزار با توجه به ویژگی های کیفی مختلف معرفی می کنیم. از ویژگی های متمایز این چارچوب می توان به موارد زیر اشاره کرد:
• پشتیبانی از استانداردهای شناخته شده برای مدل سازی نرم افزار و توصیف کیفی: SQME برای مدل سازی معماری نرم افزار، از UMLپشتیبانی می کند. UML به عنوان یک زبان استاندارد برای مدل‌سازی نرم‌افزار شناخته می‌شود و مکانیسم پروفایل آن به ما اجازه میدهد اطلاعات با کیفیت را به مدلهای معماری اضافه کنیم. SQME از پروفایل[13] MARTE و مشتقات آن برای توصیفهای کیفی پشتیبانی می کند. MARTE یک نمایه استاندارد است که افزودن اطلاعات زمان و عملکرد به مدلهای UML را تسهیل می‌کند. از این اطلاعات می توان برای ارزیابی عملکرد معماری نرم افزار استفاده کرد. DAM [14] مشتق MARTE برای حوزه قابلیت اطمینان وSecAM [14] مشتقMARTE برای حوزه امنیت هستند.
• بهینه سازی تکاملی مدل های معماری نرم افزار: با استفاده از الگوریتم های تکاملی چند معیاره موجود، فرآیند ارزیابی پیشنهاد شده توسط SQME مدل معماری اولیه را تا زمانی که مدل های بهینه پرتو پیدا شود، به طور مکرر اصلاح و ارزیابی می کند.
• مدیریت عدم قطعیت پارامتر با استفاده از نظریه شواهد: در SQME، عدم قطعیت در پارامترهای مدل از طریق فواصل مقادیر ممکن بیان می شود. اثرات این عدم قطعیت بر معیارهای کیفیت و تصمیمات معماری با استفاده از معیارهای باور و معقول بودن نظریه شواهد تجزیه و تحلیل می شود [15].
• تجزیه و تحلیل trade offکیفیت با استفاده از:EV/TOPSIS برای انتخاب بهترین مدل از مجموعه پرتو، یک روش مبتنی برEV/TOPSIS پیشنهاد شده که در ادامه بیان خواهد شد. مطمئناً بهترین مدل مدلی است که بهترینtrade off را در بین ترجیحات کیفی ذینفعان نشان دهد.
• فرآیند ارزیابی خودکار: یک ابزار نرم افزاری توسعه یافته که تمام مراحل فرآیند ارزیابی پیشنهادی توسط چارچوب SQME را خودکار می کند. این ابزار از تولید مدلهای رسمی از مدلهای معماری نرم‌افزار، و بهینه‌سازی تکاملی و تجزیه و تحلیل trade off کیفیت آنها نیز پشتیبانی می‌کند.
شکل زیر یک نمای کلی از چارچوب پیشنهادی را نشان می دهد. در این شکل،SQME توسط یک مستطیل نشان داده شده که توسط ذینفعان، ورودی ها و خروجی های چارچوب احاطه شده است. این موارد به طور خلاصه در ادامه توضیح داده شده است:
• ذینفعان: کسانی که در موفقیت سیستم سهیم هستند، از جمله معماران، طراحان، مهندسین نیازمندی ها و ...
• ورودی ها: نهادهای مورد استفاده در فرآیند ارزیابی، از جمله مدل معماری اولیه، ترجیحات کیفی ذینفعان، و درجات آزادی برای اصلاح معماری.
• خروجی ها: موجودیت های تولید شده توسط فرآیند ارزیابی، از جمله مدل معماری بهینه، و نتایج تحلیل آن.
مدل معماری اولیه با مجموعه ای از نمودارهای UML نشان داده می شود. به عنوان مثال، مدل UML در شکل زیر شامل سه نمودار مورد کاربری (UCD)، فعالیت (AD)، و استقرار (DD)است.
۱.۴. عناصر چارچوب
چارچوب SQME از عناصر زیر تشکیل شده است:
– مدل معماری اولیه: مدل اولیه UML معماری که بر اساس الزامات عملکردی توسعه یافته است.
– مدل آگاه از کیفیت: یک مدل UML حاشیه نویسی شده با پارامترهای کیفیت (مانند یک مدل UML/MARTE )
– مدل رسمی: یک مدل رسمی ( مانند زنجیره مارکوف) که برای ارزیابی معیارهای کمی در مدل آگاه از کیفیت استفاده می شود.
– روش تحلیل رسمی: روشی که برای تجزیه و تحلیل مدل رسمی استفاده می شود (به عنوان مثال، تحلیل عددی)
– روش تحلیل عدم قطعیت: معیارهای باور/معقول بودن که بر اساس نتایج تحلیل ارزیابی می شوند.
– عملگر انتخاب: عملگری که برای مقایسه و رتبه بندی نامزدهای معماری استفاده می شود. این رتبه بندی مبنای انتخاب نامزدهای والد برای نامزدهای نسل بعدی است.
– عملگرهای نسل: اپراتورهایی که برای تولید نامزدهای جدید از نسل فعلی استفاده می‌شوند (به عنوان مثال، جهش، متقاطع، تاکتیک‌های معماری و ...).
– روش تجزیه و تحلیل مبادله: گسترش روش EV/TOPSIS که برای انتخاب بهترین نامزد از مجموعه نهایی پرتو استفاده می شود. منظور از بهترین، نامزدی است که بیشترین تطابق را با اولویت های کیفی ذینفعان دارد.
۲.۴. فرآیند ارزیابی
فرآیند ارائه شده توسط چارچوب SQME برای ارزیابی مدل های معماری نرم افزار در شکل زیر ارائه شده است. این فرآیند شامل هشت مرحله است که در بخش‌های بعدی توضیح داده شده است.
۱.۲.۴. گسترش مدل UML با حاشیه نویسی کیفی
اطلاعات موجود در مدل اولیه UML فقط جنبه های عملکردی سیستم را پوشش می دهد. این اطلاعات برای تجزیه و تحلیل ویژگی های کیفی کافی نیست. در این مرحله از نمایه MARTE و پسوندهای آن برای جاسازی اطلاعات کیفی در مدل UMLاستفاده می شود.
۲.۲.۴. برآورد پارامترهای نامشخص
ممکن است مقدار دقیق برخی از پارامترها در طول طراحی معماری ناشناخته باشد. در این مرحله، تحلیلگر باید اطلاعاتی را از منابع موجود جمع آوری کند تا مقادیر احتمالی پارامترهای نامشخص را تخمین بزند. به عنوان مثال، او می‌تواند داده‌های تاریخی را در مورد سیستم‌های مشابه جمع‌آوری کند و مجموعه‌ای از فواصل زمانی را به متخصصان حوزه پیشنهاد دهد و درجات باور آنها را برای هر بازه بپرسد. پس از مشورت با کارشناسان، او باید فواصل تخمینی را جمع آوری کرده و به مدل UML اضافه کند.
۳.۲.۴. تبدیل به مدل های رسمی
در این مرحله، مدل UML حاشیه نویسی شده به مدلهای رسمی و ریاضی برای تجزیه و تحلیل معیارهای کیفیت تبدیل می‌شود. الگوریتم‌هایی در [11،12] ارائه شده است که مدلهای UML/DAM و UML/SecAM را به ترتیب به درخت‌های خطا و درخت‌های حمله تبدیل می کنند. در این بخش، مجموعه‌ای از قوانین را برای تبدیل مدلهای UML/MARTE به شبکه‌های پتری زمانی (TPNs) تعریف می‌کنیم [16،17]. در ابتدا، نحوه مدل‌سازی سه مفهوم عملکرد اصلی، یعنی حجم کار، سناریو و منبع را با TPN توضیح می‌دهیم. سپس مدلهای TPN ساخته‌شده بر روی انتقال‌های برچسب رایج خود ترکیب می‌شوند تا یک مدل TPN قابل تجزیه و تحلیل به دست آید.
۴.۲.۴. تجزیه و تحلیل مدل های رسمی
مدلهای رسمی تولید شده باید با استفاده از تکنیک‌های راه‌حل و ابزارهای موجود برای آنها تحلیل شوند. خروجی این تحلیل‌ها شامل مجموعه‌ای از فواصل و احتمالات مرتبط با آنها برای معیارهای کیفیت است. بر این اساس، ما به راحتی می توانیم مرزهای توان عملیاتی را برای هر ترکیبی از بازه های ورودی تخمین بزنیم. بسته به تعداد پارامترهای نامشخص و فواصل مرتبط با آنها، این تجزیه و تحلیل ممکن است چندین بار تکرار شود.
۵.۲.۴. تجزیه و تحلیل عدم قطعیت
خروجی مرحله قبل شامل مجموعه ای از فواصل و احتمالات مربوط به آنها برای هر معیار کیفیت است. به جای خود فواصل، تحلیلگر علاقه مند است که احتمال این که معیارهای ارزیابی شده بالاتر یا کمتر از مقادیر آستانه مشخص شده به عنوان الزامات کیفیت برای سیستم هستند را بداند.
در این مرحله از معیارهای باور و معقولیت برای برآورد احتمال تحقق نیاز استفاده می شود.
۶.۲.۴. انتخاب مدل های والد
در الگوریتم‌های تکاملی، نسل‌های جدیدی از راه‌حل‌های کاندید به طور مکرر تولید می‌شوند تا زمانی که نامزدهای بهینه پیدا شوند. در SQME، فرآیند ارزیابی از مدل معماری اولیه شروع می شود. از این رو، نسل اول شامل یک مدل است. با این حال، مدل های بیشتری در تکرارهای بعدی تولید خواهند شد.
در این مرحله، مدلهای معماری موجود بر اساس انطباق آنها با الزامات کیفی مقایسه می‌شوند. سپس مدلهای پرتو بهینه [18] به‌عنوان والدین برای مدلهای نسل بعدی انتخاب می‌شوند. تعریف اصلی رابطه تسلط پارتو مبتنی بر مقایسه مقادیر واضح است. با توجه به عدم قطعیت در نتایج ارزیابی، ما باید یک تعریف جدید ارائه دهیم که امکان مقایسه مقادیر فاصله را فراهم می کند.
اکنون می‌توانیم به راحتی مدلهای معماری را با هم مقایسه کنیم و مشخص کنیم که کدام مدل‌ها متعلق به مجموعه پارتو هستند.
۷.۲.۴. ایجاد نامزدهای جدید
در این مرحله با اصلاح مدل های انتخاب شده در مرحله قبل، مدل های جدید تولید می شوند. تغییرات بر اساس درجات آزادی تعریف شده برای سیستم انجام می شود.
عملگرهایی که برای اصلاح استفاده می‌شوند ممکن است شامل عملگرهای متقاطع و جهش الگوریتم ژنتیک یا هر عملگر خاص ویژگی باشند. در این مقاله فقط عملگرهای جهش و متقاطع در نظر گرفته شده است. متقاطع فرآیندی است که در آن دو نامزد طراحی برای ایجاد یک راه حل جدید ادغام می شوند. جهش یک یا چند گزینه طراحی را در یک نامزد تغییر می دهد تا یک گزینه جدید ایجاد کند.
۸.۲.۴. انتخاب بهترین مدل
مراحل 1 تا 7 فرآیند ارزیابی ممکن است چندین بار تکرار شود تا زمانی که مجموعه پارتو دیگر تغییر نکند. در این لحظه، مدلهای معماری در مجموعه پارتو باید با هم مقایسه شوند، به طوری که مدلی که حداکثر مطابقت را با ترجیحات ذینفعان دارد به عنوان مدل خروجی انتخاب شود.
بدیهی است که مشکل انتخاب بهترین مدل یک مسئله MCDM با ویژگی های کیفی Q A j , j = 1, . . . n به عنوان معیارهای تصمیم گیری، مدل های معماری Mi , i = 1, . . . , n به عنوان گزینه های موجود و سهامداران S Hk , k = 1, . . . , p ، به عنوان تصمیم گیرندگان هر عنصر Belij, Plij از این ماتریس نشان دهنده نتیجه ارزیابی Q A j بر روی Mi است. به هر Q A j یک وزن Wk j اختصاص داده می شود که نشان دهنده اهمیت این ویژگی کیفیت برای ذینفع S Hk است.
۵. پشتیبانی از ابزار
چارچوب SQME توسط SQMETool [19] پشتیبانی می شود. این ابزار نرم افزاری با استفاده از زبان برنامه نویسی جاوا برای ارائه حداکثر قابلیت حمل و استقلال پلت فرم توسعه یافته است و به عنوان یک پلاگین برای Eclipse IDE قابل استفاده است. Eclipse یک محیط توسعه نرم افزار شناخته شده است و در حال حاضر از توسعه مدل UML و حاشیه نویسی MARTE پشتیبانی می کند. این پشتیبانی توسط پلاگین پاپیروس [20] ارائه می شود. اخیراً پشتیبانی از پروفیل DAM به این افزونه اضافه شده است [21]. SQMETool قادر به ارزیابی نمایش XMI از مدل های UML/MARTE یا UML/DAM است که با استفاده از پلاگین پاپیروس بر اساس فرآیند ارزیابی SQME توسعه یافته اند. معماری این ابزار در شکل زیر ارائه شده است. بر این اساس، این ابزار شامل ماژول های زیر است:
- رابط کاربری گرافیکی: این ماژول کاربر را قادر می سازد تا با ابزار تعامل داشته باشد، به عنوان مثال، مدل های UML را وارد کند، آنها را تجزیه و تحلیل کند، و گزارش های تجزیه و تحلیل تولید کند.
- ماژول تبدیل مدل: این ماژول مدل های رسمی را از مدل های ورودی UML تولید می کند.
- ماژول تجزیه و تحلیل TPN: این ماژول با تجزیه و تحلیل مدل TPN تولید شده توسط ماژول تبدیل مدل، معیارهای باور و معقول بودن عملکرد سیستم را ارزیابی می کند.
- کنترلر: این ماژول تعاملات بین رابط کاربری گرافیکی و سایر ماژول ها را مدیریت می کند.
- ماژول تجزیه و تحلیل FT:این ماژول معیارهای باور و قابل قبول بودن قابلیت اطمینان سیستم را با تجزیه و تحلیل مدل FT تولید شده توسط ماژول تبدیل مدل ارزیابی می کند.
- ماژول I-MOEA : این ماژول چارچوب MOEA را گسترش می دهد [22]. MOEA یک کتابخانه معروف جاوا برای الگوریتم های تکاملی چند هدفه است.
- ماژول I-EV/TOPSIS: این ماژول روشی را برای انتخاب بهترین مدل معماری پیاده سازی می کند.
۶. نتیجه گیری و کار آینده
در این تحقیق، SQME را به عنوان چارچوبی برای ارزیابی کمی ویژگی‌های کیفیت مدلهای معماری نرم‌افزار معرفی کردیم. هدف از این چارچوب حمایت از معماران نرم افزار در یافتن راه حل های معماری بهینه در موقعیت های طراحی پیچیده با بسیاری از ویژگی های کیفیت بالقوه متناقض است. این چارچوب از الگوریتم‌های تکاملی چند هدفه برای اکتشاف فضای طراحی، EV/TOPSIS برای تجزیه و تحلیل معاوضه با کیفیت و نظریه شواهد برای مدیریت عدم قطعیت پارامتر در طول فرآیند ارزیابی استفاده می‌کند.
مطمئناً، خودکار کردن فرآیند ارزیابی، تلاش انسان را کاهش میدهد، که ممکن است زمان ورود به بازار و هزینه‌های توسعه را کاهش دهد. آزمایش‌های اولیه و اجرای نمونه اولیه نشان داده‌اند که فرآیند ارزیابی SQME برای سیستم‌های واقعی قابل اجرا است.
«این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.»
منابع
[1] Ahmed, F., Capretz, L.F.: An Architecture Process Maturity Model of Software Product Line Engineering. Innov. Syst. Softw. Eng. 7(3), 191–207 (Sep 2011)
[2] Ostadzadeh, S.S., Shams, F.: Towards a Software Architecture Maturity Model for Improving Ultra-Large-Scale Systems Interoperability. CoRR abs/1401.5752 (2014)
[3] Meyer, M., Helfert, M., O’Brien, C.: An Analysis of Enterprise Architecture Maturity Frameworks. In: Grabis, J., Kirikova, M. (eds.) Perspectives in Business Informatics Research. pp. 167–177. Springer Berlin Heidelberg, Berlin, Heidelberg (2011)
[4] S. Mahmood, A. Ullah, and A. K. Kayani, "Fog Computing Trust based Architecture for Internet of Things Devices," International Journal of Computing Communication Networks, vol. 1, no. 1, pp. 18-25, 2019.
[5] K. N. Qureshi, A. H. Abdullah, F. Ullah, and Informatics, "Beaconless Packet Forwarding Approach for Vehicular Urban Environment," Bulletin of Electrical Engineering Informatics, vol. 5, no. 2, pp. 253-262, 2016.
[6] H. Nafea, K. Kifayat, Q. Shi, K. N. Qureshi, and B. Askwith, "Efficient Non-Linear Covert Channel Detection in TCP Data Streams," IEEE Access, 2019.
[7] S. Iqbal, A. H. Abdullah, and K. N. Qureshi, "An adaptive interference‐aware and traffic‐aware channel assignment strategy for backhaul networks," Concurrency Computation: Practice Experience, p. e5650, 2019.
[8] E. Anjos and M. Zenha-Rela, "A framework for classifying and comparing software architecture tools for quality evaluation," in International Conference on Computational Science and Its Applications, 2011, pp. 270-282: Springer.
[9] M. S. Aliero, I. Ghani, K. N. Qureshi, and M. F. a. Rohani, "An algorithm for detecting SQL injection vulnerability using black-box testing," Journal of Ambient Intelligence Humanized Computing, pp. 1-18, 2019.
[10] K. N. Qureshi, F. Bashir, and A. H. Abdullah, "Provision of Security in Vehicular Ad hoc Networks through An Intelligent Secure Routing Scheme," in 2017 International Conference on Frontiers of Information Technology (FIT), 2017, pp. 200-205: IEEE.
[11] Sedaghatbaf, A., Azgomi, M.A.: Quantitative evaluation of soft- ware security: an approach based on UML/SecAM and evidence theory. ISC. Int. J. Inf. Secur. 8(2), 137–149 (2016)
[12] Sedaghatbaf, A., Azgomi, M.A.: Reliability evaluation of UML- DAM models under unertainty. IET Softw. (2018). https://doi.org/ 10.1049/iet-sen.2017.0077
[13] Group, O.M.: UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems v.1.0 (2009)
[14] Bernardi, S., Merseguer, J., Petriu, D.C.: A dependability profile within MARTE. Softw. Syst. Model. 10(3), 313–336 (2011)
[15] Shafer, G.: A Mathematical Theory of Evidence. Princeton University Press, Princeton (1976)
[16] Merlin, P.M., Farber, D.J.: Recoverability of communication pro- tocols: implications of a theoretical study. IEEE Trans. Commun. 24(9), 1036–1043 (1976)
[17] Bernardi, S., Campos, J.: Computation of performance bounds for real-time systems using time Petri nets. IEEE Trans. Ind. Informat- ics 5(2), 168–180 (2009)
[18] Coello Coello, C.A., Dhaenens, C., Jourdan, L.: Multi-objective combinatorial optimization: problematic and context. Stud. Com- put. Intell. 272, 1–21 (2010)
[19] Sedaghatbaf, A.: SQME Tool Web Page (2018). [Online]. Avail- able: http://webpages.iust.ac.ir/azgomi/TwCL/sqme.htm
[20] Gérard, S., Dumoulin, C., Tessier, P., Selic, B.: 19 Papyrus: a UML2 tool for domain-specific language modeling. In: Model- Based Engineering of Embedded Real-Time Systems, pp. 361–368. Springer, Berlin Heidelberg (2010)
[21] DICE Profiles 2016. [Online]. Available: http://dice-project. github.io/DICE-Profiles/
[22] MOEA Framework. [Online]. Available: http://moeaframework.org/
