Se2 9 Metrics

‫مهندسی نرم افزار ‪2‬‬ ‫‪Metrics‬‬ ‫محسن کامیار‬ ‫دانشگاه فردوسی مشهد‬

‫‪Metrics‬‬ ‫‪‬‬

‫‪‬‬

‫در هر فرآیند تولید مهندسی باید معیارهایی‬ ‫(سنجه‪ ،‬محک) برای کیفیت محصول تولید‬ ‫شده وجود داشته باشند که بتوان با‬ ‫استفاده از آن میزان کارایی فرآیند را‬ ‫ارزیابی نمود‪.‬‬ ‫مهمترین مشکل مهندسی نرم افزار را می‬ ‫توان غیر دقیق بودن این معیارها دانست‪.‬‬ ‫چیزی که در بسیاری از رشته های‬ ‫مهندسی کامل به صورت کمی موجود‬

‫‪Metrics‬‬ ‫‪‬‬

‫مهمترین عوامل بروز ناکارایی را می توان‬ ‫در موارد زیر خلصه نمود‪:‬‬ ‫‪‬‬

‫‪‬‬

‫زیربنای سنجش کیفیت را می توان نیازمندی‬ ‫های یک سیستم نرم افزاری دانست‪ .‬عدم‬ ‫انطباق تولید بر نیازمندی ها یکی از منابع‬ ‫ناکارایی خواهد بود‬ ‫استانداردها راه کارهایی برای تولید یک‬ ‫محصول با کیفیت ارائه می نمایند‪ .‬مسلما‬ ‫عدم پیروی از این استانداردها منجر به تولید‬ ‫محصولت بدون کیفیت مناسب خواهد شد‪.‬‬

‫‪Metrics‬‬ ‫‪‬‬

‫همیشه تعدادی نیازمندی های ضمنی هست‬ ‫که مد نظر قرار نمی گیرند (مانند کاربرپسند‬ ‫بودن واسط کاربر)‪ .‬عدم برآورده سازی این‬ ‫نیازمندی ها باعث عدم دست یابی به کارایی‬ ‫مناسب خواهد شد‪.‬‬

‫‪Metrics‬‬ ‫‪‬‬

‫می توان عوامل تأثیر گذار برروی کیفیت‬ ‫نرم افزار را شامل دو دسته زیر دانست‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫عوامل قابل اندازه گیری (مانند تعداد باگ ها‬ ‫به ازای هر تابع و ‪)...‬‬ ‫عوامل غیرقابل اندازه گیری (مانند استفاده‬ ‫مجدد‪ ،‬قدرت نگهداری و ‪)...‬‬

‫در کل می توان عوامل زیر را مهمترین‬ ‫عوامل در کیفیت محصول دانست‪:‬‬

‫‪Metrics‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

‫صحت (‪ :)correctness‬محصول بتواند‬ ‫نیازمندی ها و مشخصات مد نظر و اهداف‬ ‫اصلی مشتری را برآورده سازد‪.‬‬ ‫قابلیت اطمینان (‪ :)Reliability‬محصول بتواند‬ ‫کارکردهای خواسته شده را با دقت کافی‬ ‫برآورده سازد‪.‬‬ ‫کارایی (‪ :)Efficiency‬حجم منابع مورد استفاده‬ ‫برای انجام کارکردها‬ ‫امنیت کافی (‪ :)Integrity‬کنترل دسترسی‬ ‫افراد برای دستیابی به توابع و داده ها‬

‫‪Metrics‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

‫استفاده آسان (‪ :)Usability‬تلش مورد نیاز‬ ‫برای آموزش‪ ،‬تفسیر خروجی ها‪ ،‬آماده سازی‬ ‫وروردی ها و ‪...‬‬ ‫قدرت نگهداری (‪ :)Maintainability‬فعالیت‬ ‫مورد نیاز برای اصلح یک خطا در برنامه‬ ‫انعطاف پذیری (‪ :)Flexibility‬فعالیت مورد نیاز‬ ‫برای تغییر یک کارکرد‬ ‫قابلیت تست (‪ :)Testability‬میزان فعالیت‬ ‫مورد نیاز برای تست یک کارکرد مورد انتظار‬

‫‪Metrics‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫قابلیت انتقال (‪ :)Portability‬میزان فعالیت‬ ‫مورد نیاز برای انتقال نرم افزار از یک بستر‬ ‫سخت افزاری و یا نرم افزاری به یک بستر‬ ‫دیگر‬ ‫استفاده مجدد (‪ :)Reusability‬میزان قابلیت‬ ‫استفاده مجدد از همه یا قسمتی از برنامه‬ ‫تهیه شده‬ ‫قابلیت همکاری (‪ :)Interoperability‬قابلیت‬ ‫همکاری با دیگر نرم افزارها‬

Metrics

‫‪Metrics‬‬ ‫‪‬‬

‫برای اندازه گیری هر یک از جنبه های ذکر‬ ‫شده در بال باید معیارهای قابل اندازه‬ ‫گیری وجود داشته باشد که می توان به‬ ‫موارد زیر اشاره نمود‪ .‬این معیارها عمدتا‬ ‫به نحوی انتخاب شده اند که مستقل‬ ‫باشند‪ .‬هر معیار امتیاز ‪ 0‬تا ‪ 10‬را دریافت‬ ‫می کند و تأثیر هر یک بر عوامل ذکر شده‬ ‫در بال نیز در جدولی آمده است‪.‬‬

‫‪Metrics‬‬ ‫‪‬‬

‫این معیارها شامل موارد زیر هستند‪:‬‬ ‫‪‬‬

‫‪‬‬ ‫‪‬‬

‫‪‬‬ ‫‪‬‬

‫‪ :Auditability‬سادگی بررسی سازگاری با‬ ‫استانداردها‬ ‫‪ :Accuracy‬دقت محاسبات و عملیات کنترلی‬ ‫‪ :Communication commonality‬میزان‬ ‫استفاده از واسطها و پروتکل های استاندارد‬ ‫‪ :Conciseness‬استفاده از حداقل میزان کد‬ ‫‪ :Consistency‬استفاده از روش های طراحی‬ ‫و مستندسازی یکسان در طول تولید‬

‫‪Metrics‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪ :Data commonality‬استفاده از ساختارها و‬ ‫انواع داده استاندارد در تولید‬ ‫‪ :Error tolerance‬میزان تأثیر وجود یک خطا‬ ‫برروی دقت و ‪ ...‬داده ها‬ ‫‪ :Execution Efficiency‬کارایی زمان اجرای‬ ‫برنامه‬ ‫‪ :Expandability‬قابلیت گسترش طراحی‬ ‫ساختار‪ ،‬داده ها و یا توابع‬ ‫‪ :Generality‬آینده نگری در کاربردهای قابل‬ ‫فرض برای اجزاء برنامه‬

‫‪Metrics‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬ ‫‪‬‬

‫‪ :Hardware independence‬میزان استقلل‬ ‫نرم افزار از سخت افزار مورد نیاز‬ ‫‪ :Instrumentation‬امکانات نرم افزار برای‬ ‫کنترل وضعیت داخلی نرم افزار و تشخیص‬ ‫خطاها‬ ‫‪ :Modularity‬میزان استقلل کارکردی اجزاء‬ ‫مختلف سیستم‬ ‫‪ :Operability‬سادگی استفاده از برنامه‬ ‫‪ :Security‬استفاده از مکانیزم های حفظ داده‬ ‫ها و توابع‬

‫‪Metrics‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪ :Software system independence‬میزان‬ ‫استقلل سیستم از عوامل محیطی مانند‬ ‫محدودیت های سیستم عامل و ‪...‬‬ ‫‪ :Traceability‬قابلیت پیگیری رو به عقب از‬ ‫یک جزء خاص از سیستم به سمت طراحی‬ ‫مورد نظر‬ ‫‪ :Training‬میزان کمک های مکانیزه به کاربر‬ ‫برای استفاده از سیستم‬

Metrics ‫دو استاندارد دیگر نیز در مورد عوامل‬ ‫مؤثر در کیفیت وجود دارند که استفاده‬ :‫گسترده ای می شوند‬ ‫ به نام‬HP ‫استاندارد ارائه شده توسط‬ FURPS )Functionality, Usability, )Reliability, Performance, Supportability ISO 9126 )Functionality, ‫استاندارد‬ Usability, Reliability, Efficiency, )Maintainability, Portability







‫‪Metrics‬‬ ‫‪‬‬

‫‪‬‬

‫در ادامه سعی می کنیم تا معیارهای کامل‬ ‫فنی را برای اندازه گیری کیفیت ارائه‬ ‫نماییم‪.‬‬ ‫معیارهای فنی باید‪:‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫در سنجش مدل های تحلیل و طراحی کمک‬ ‫لزم را بنمایند‬ ‫معیاری برای میزان پیچیدگی طراحی و کد‬ ‫ارائه نمایند‬ ‫در طراحی تست های مورد نیاز حداکثر کمک‬ ‫لزم را بنمایند‬

‫‪Metrics‬‬ ‫‪‬‬

‫به همین منظور این معیارها باید از اصول‬ ‫زیر پیروی نمایند‪:‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪ :Formulation‬جمع آوری معیارهایی که برای‬ ‫نرم افزار مورد نظر مناسب تر می باشند‬ ‫‪ :Collection‬تعیین مکانیزم های لزم برای‬ ‫جمع آوری داده های مورد استفاده در‬ ‫معیارهای تعیین شده‬ ‫‪ :Analysis‬استفاده از ابزارهای لزم برای‬ ‫محاسبه معیارها‬ ‫‪ :Interpretation‬بررسی نتایج برای ایجاد تغییر‬

‫‪Metrics‬‬ ‫‪‬‬

‫‪ :Feedback‬انتقال پیشنهادات جمع آوری شده‬ ‫براساس معیارها به تیم تولید نرم افزار‬

‫‪Metrics‬‬ ‫‪‬‬

‫در پایان معیارها باید از خصوصیات زیر‬ ‫پیروی نمایند‪:‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫ساده و قابل محاسبه‪ :‬فهم و محاسبه به‬ ‫سادگی انجام گیرد‬ ‫به صورت تجربی و عینی قابل تفسیر و توجیه‬ ‫باشند (دقیقا مشخص باشد که این معیار قصد‬ ‫دارد تا چه مشخصه ای را اندازه گیری نماید)‬ ‫کامل مستقل و بی طرفانه تهیه شده باشد به‬ ‫صورتی که یک شخص ثالث نیز بتواند به نتیجه‬ ‫مشابه ما با استفاده از داده های یکسان‬

‫‪Metrics‬‬ ‫‪‬‬

‫‪‬‬ ‫‪‬‬

‫در استفاده از واحدها و ابعاد کامل سازگار‬ ‫عمل کند‬ ‫استقلل از زبان برنامه نویسی‬ ‫امکان فراهم نمودن بازخوردهای مناسب به‬ ‫تیم تولید برای دستیابی به نرم افزار با کیفیت‬ ‫بالتر‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬ ‫‪‬‬

‫معیارهای مورد استفاده در مدل تحلیل‪:‬‬ ‫دسته های مختلفی از این معیارها‬ ‫موجودند که در زیر به آنها می پردازیم‬ ‫‪‬‬

‫معیارهای برپایه کارکرد‪ :‬این معیارها‬ ‫(معیارهای نقطه کارکرد) می توانند برای‬ ‫برآورد اندازه سیستم حاصل از تحلیل انجام‬ ‫گرفته استفاده شوند‪ .‬این معیار دارای موارد‬ ‫زیر می باشد‪:‬‬ ‫‪‬‬ ‫‪‬‬

‫تعداد ورودی های کاربر‬ ‫تعداد خروجی های کاربر‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬ ‫‪‬‬ ‫‪‬‬

‫تعداد فایل ها‬ ‫تعداد واسط های خارجی‬

‫سپس از جدول زیر برای محاسبه استفاده می‬ ‫کنیم تا مجموع کل را به دست آوریم‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬ ‫در نهایت عدد به دست آمده را در فرمول زیر‬ ‫قرار می دهیم و عدد ‪ FP‬را به دست می‬ ‫آوریم‪.‬‬ ‫در این فرمول ‪ fi‬ها اعدادی هستند که نتیجه‬ ‫جوابگویی به پرسش های ‪14‬گانه زیر می‬ ‫باشند و به هر پرسش عددی بین ‪ 0‬تا ‪ 5‬نسبت‬ ‫داده می شود‪.‬‬ ‫در نهایت براساس تجاربی مانند اینکه هر واحد‬ ‫‪ FP‬متناظر ‪ 60‬خط کد است و هر ‪ 12‬واحد‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬ ‫‪‬‬

‫‪‬‬

‫معیار ‪ :Bang‬مانند مدل قبل برای به دست‬ ‫آوردن برآوردی از اندازه سیستم مورد‬ ‫استفاده قرار می گیرد‪.‬‬ ‫برای محاسبه این معیار ابتدا باید تعداد اجزاء‬ ‫اولیه را محاسبه نماییم‪ .‬اجزاء اولیه اجزائی از‬ ‫تحلیل هستند که دیگر در مدل تحلیل شکسته‬ ‫نمی شوند‪ .‬این اجزاء اولیه دارای گروه های‬ ‫زیر می باشند‪:‬‬ ‫‪‬‬

‫اجزاء اولیه کارکردی (‪:)Functional Primitives‬‬ ‫تعداد عملیاتی که برروی داده ها انجام می شود‪.‬‬ ‫این تعداد را می توان با استفاده از آخرین سطح‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬ ‫نشان می دهند به دست آورد و یا در زبان ‪ UML‬این‬ ‫معیار را می توان برابر تعداد ‪usecase‬های موجود‬ ‫در آخرین سطح تحلیل دانست‪.‬‬ ‫‪ ‬اجزاء داده ای (‪ :)Data Elements‬تعداد اجزاء داده‬ ‫ای یا به عبارتی داده هایی که نوع داده ترکیبی‬ ‫محسوب نمی شوند‪.‬‬ ‫‪ ‬اشیاء (‪ :)Objects‬تعداد اشیائ تعریف شده در‬ ‫سیستم‪.‬‬ ‫‪ ‬روابط (‪ :)Relationships‬تعداد روابط تعریف شده‬ ‫بین اشیاء مختلف‬ ‫‪ ‬حالت ها (‪ :)States‬تعداد حالت های قابل مشاهده‬ ‫توسط کاربر در سیستم‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬ ‫‪‬‬

‫‪‬‬

‫انتقال ها (‪ :)Transitions‬تعداد انتقال های بین‬ ‫حالت ها در نمودار حالت ها‬

‫علوه بر این باید اعداد زیر نیز به دست آیند‪:‬‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫تعداد کارکردهای دستی اولیه تغییر یافته‬ ‫(‪:)Modified Manual Function Primitives, FuPM‬‬ ‫تعداد کارکردهایی که در حوزه این سیستم نمی‬ ‫گنجند اما باید برای سازگاری با این سیستم تغییر‬ ‫یابند‪.‬‬ ‫اجزاء داده ای ورودی (‪Input Date Elements,‬‬ ‫‪ :)DEI‬تعداد اجزاء داده در ورودی های سیستم‬ ‫اجزاء داده ای خروجی (‪Output Data Elements,‬‬ ‫‪)DEO‬‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

‫اجزاء داده ای نگهداری شده (‪Retained Data‬‬ ‫‪ :)Elements, DER‬تعداد اجزاء داده ای که توسط‬ ‫سیستم ذخیره می شوند‪.‬‬ ‫‪ :Data Tokens – TCi‬تعداد داده هایی که در مرز‬ ‫کارکرد اولیه ٍ‪-i‬ام شکسته نمی شوند‪.‬‬ ‫رابطه ها (‪:)Relationship Connections, REi‬‬ ‫تعداد رابطه هایی که بین داده ‪ i‬ام در مدل داده ها‬ ‫با دیگر داده ها موجود است‪.‬‬

‫بر اساس این موارد می توان کاربردها را به‬ ‫دو دسته کاربردهای مبتنی بر داده و کارکرد‬ ‫تقسیم نمود‪ .‬با استفاده از معیار زیر می توان‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬

‫‪ RE/FuP < 0.7‬کاربردهای مبتنی برکارکرد‬ ‫‪ RE/FuP<1.4<0.8‬کاربردهای ترکیبی‬ ‫‪ RE/FuP<1.5‬کاربردهای مبتنی بر داده‬

‫‪‬‬

‫و یا معیار زیر می تواند نشان دهنده این باشد‬ ‫که آیا تمام توابع دارای درشت دانگی یکسانی‬ ‫هستند‬

‫‪‬‬

‫در نهایت برای محاسبه معیار ‪ Bang‬در‬ ‫کاربردهای مبتنی بر کارکرد از الگوریتم زیر‬ ‫استفاده می شود‪.‬‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬

‫‪‬‬

‫در این الگوریتم تعداد توکن برابر تعداد توکن‬ ‫های مجزایی است که در آن کارکرد اولیه‬ ‫دیده می شوند‪ CFuPI .‬از جدولی که توسط‬ ‫‪ DeMarco‬ارائه شده است به دست می آید‬ ‫که نسخه ساده شده آن در زیر آمده‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬

‫و در نهایت کلس های ذکر شده ‪ 16‬کلس هستند‬ ‫که دارای وزن های ‪ 0.6‬برای کارکردهای‬ ‫شامل انتقال ساده داده ها تا ‪ 2.5‬برای‬ ‫کارکردهای مدیریت داده ها می باشند‪.‬‬ ‫‪ ‬برای محاسبه معیار ‪ Bang‬در کاربردهای‬ ‫مبتنی بر داده نیز به صورت زیر عمل می‬ ‫کنیم‪.‬‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬

‫‪‬‬

‫در این الگوریتم نیز ‪ COBI‬از جدول زیر به‬ ‫دست می آید‪.‬‬

‫‪ – Metrics‬معیارهای مدل تحلیل‬ ‫‪‬‬

‫پیشنهاد عمده در این روش این است که هر‬ ‫مجموعه ای جدول های متناسب با سازمان‬ ‫خود را براساس تجارب موجود در سازمان‬ ‫ایجاد نماید تا انطباق بیشتری با واقعیت‬ ‫داشته باشد‪.‬‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫‪‬‬

‫در این بخش نیز مسلما برای دست یابی‬ ‫به محصولی که کیفیت لزم را داشته باشد‬ ‫باید معیارهای مناسب وجود داشته باشند‬ ‫که در ادامه به توضیح در این مورد می‬ ‫پردازیم‪.‬‬ ‫یکی از اولین دسته معیارها‪ ،‬معیارهای‬ ‫ساختار طراحی (‪Architectural Design‬‬ ‫‪ )Metric‬می باشند‪ .‬این معیارها را می‬ ‫توان معیارهای جعبه سیاه دانست زیرا تنها‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫عملیات در اجزاء سیستم نمی شوند‪.‬‬ ‫‪ ‬سه معیار پیچیدگی طراحی نرم افزار توسط‬ ‫‪ Card‬و ‪ Glass‬ارائه شده است‪ :‬پیچیدگی‬ ‫ساختاری (‪ ،)Structural Complexity‬پیچیدگی‬ ‫داده (‪ )Data Complexity‬و پیچیدگی سیستم‬ ‫(‪.)System Complexity‬‬ ‫‪ ‬این سه معیار بر اساس فرمول های زیر‬ ‫محاسبه می گردند‪.‬‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫در این فرمول ها ‪ fout)i( )fan out‬یک ماژول) برابر‬ ‫است با تعداد ماژول هایی که مستقیما توسط‬ ‫ماژول ‪ i‬ام فراخوانی می شوند‪ )v)i .‬نیز برابر‬ ‫تعداد متغیرهای ورودی و خروجی است‪.‬‬

‫‪‬‬

‫یکی دیگر از معیارها توسط ‪ Henry‬و ‪Kafura‬‬ ‫ارائه شده است و به صورت زیر محاسبه می‬ ‫شود‪.‬‬

‫‪‬‬

‫در این معیار ‪ )length)i‬برابر است با تعداد‬ ‫دستورات زبان برنامه نویسی در ماژول مورد‬ ‫نظر‪ .‬البته در این معیار ‪ fin‬و ‪ fout‬علوه بر‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫‪‬‬

‫هر چه دو معیار ذکر شده در بال بیشتر گردند‬ ‫میزان تلش برای یکپارچه سازی و تست نیز‬ ‫بال می روند‪.‬‬ ‫همچنین معیار زیر نشان دهنده چگالی ارتباط‬ ‫بین اجزاء مختلف سیستم است‪.‬‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫همچنین نیروی هوایی آمریکا معیاری را به نام‬ ‫‪)Design Structure Quality Index )DSQI‬‬ ‫معرفی نموده است که مقداری بین ‪ 0‬و ‪ 1‬را‬ ‫ارائه نموده و باید مقادیر زیر با استفاده از‬ ‫طراحی داده ها و ساختار محاسبه گردند‪:‬‬ ‫‪‬‬

‫‪ : S1‬تعداد ماژول های موجود در سیستم‪.‬‬

‫‪‬‬

‫‪ : S2‬تعداد ماژول هایی که صحت کارکرد آن ها‬ ‫وابسته به داده های ورودی است و یا داده هایی‬ ‫را برای استفاده در دیگر ماژول ها فراهم می‬ ‫آورند‪( .‬ماژول های کنترلی در این دسته قرار نمی‬ ‫گیرند‪).‬‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫‪ : S4‬تعداد اقلم داده ای موجود در پایگاه داده‬

‫‪‬‬

‫‪ : S5‬تعداد اقلم داده ای یکتای موجود در پایگاه‬ ‫داده‬ ‫‪ : S6‬تعداد قسمت های پایگاه داده‬

‫‪‬‬

‫‪ : S7‬تعداد ماژول های با یک ورودی و خروجی‬ ‫(ماژول های کنترل استثنائات چند خروجی‬ ‫محسوب نمی شوند)‬

‫‪‬‬

‫‪‬‬

‫بر این اساس مقادیر زیر نیز محاسبه می‬ ‫گردند‪:‬‬ ‫‪‬‬

‫ساختار برنامه‪ :‬اگر بر اساس روش های مبتنی بر‬ ‫جریان داده و یا شیءگرا طراحی صورت گرفته‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬

‫‪‬‬

‫استقلل ماژول ها‪:‬‬ ‫استقلل ماژول ها از پردازش های قبلی‪:‬‬ ‫اندازه پایگاه داده‪:‬‬ ‫تقسیم پذیری پایگاه داده‪:‬‬ ‫خصوصیات ورود و خروج پایگاه داده‪:‬‬

‫با استفاده از این مقادیر معیار مورد نظر به‬ ‫صورت زیر محاسبه می شود که در آن‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫دسته بعدی از معیارها‪ ،‬معیارهای طراحی‬ ‫در سطح اجزاء (‪Component-level‬‬ ‫‪ )Design Metrics‬می باشند‪ .‬این معیارها‬ ‫بر اساس مشخصات داخلی اجزاء نرم‬ ‫افزار می باشند و از سه ‪ c‬برای اندازه‬ ‫گیری استفاده می نمایند‪.‬‬ ‫‪‬‬ ‫‪‬‬ ‫‪‬‬

‫‪( Cohesion‬چسبیدگی)‬ ‫‪( Coupling‬همکاری)‬ ‫‪( Complexity‬پیچیدگی)‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫در همین سه دسته به بررسی معیارهای‬ ‫موجود می پردازیم‪:‬‬ ‫‪‬‬

‫معیارهای ‪ :cohesion‬این معیار میزان‬ ‫یکپارچگی یک ماژول را مشخص می کند و‬ ‫براساس مفاهیم زیر محاسبه می شود‪:‬‬ ‫‪‬‬

‫‪‬‬

‫‪ :Data slice‬قسمت های داده ای که تعیین کننده‬ ‫محل شروع حرکت یک ماژول در بین حالت های‬ ‫مختلف می باشند‪.‬‬ ‫‪ :Data tokens‬داده هایی که می توانند به عنوان‬ ‫توکن برای ماژول مورد نظر محسوب شوند‪.‬‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪‬‬

‫‪ :Glue Tokens‬این توکن ها برروی یک یا چند‬ ‫‪ data slice‬ساخته شده اند‪.‬‬ ‫‪ :Super Glue Tokens‬این توکن ها در بین تمام‬ ‫‪data slice‬ها مشترک هستند‪.‬‬ ‫‪ :Stickness‬برای یک ‪ glue token‬برابر است با‬ ‫تعداد ‪ data slice‬ها متناظر با آن‪.‬‬

‫و در نهایت معیار زیر برای ‪strong functional‬‬ ‫‪ coherence‬ارائه می گردد‪.‬‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫معیارهای ‪ :coupling‬این معیارها نشان دهنده‬ ‫میزان ارتباط یک ماژول با ماژول های دیگر‬ ‫می باشد و شامل دسته های مختلف ارتباط‬ ‫مانند ارتباط داده ای‪ ،‬ساختارهای کنترل‬ ‫جریان‪ ،‬سراسری و محیطی می باشد‪.‬‬ ‫‪‬‬

‫برای محاسبه باید معیارهای زیر به دست آیند‪:‬‬ ‫‪‬‬

‫ارتباطات داده ای و کنترل اجرا‬

‫‪‬‬

‫ارتباط سراسری‬

‫‪ – Metrics‬معیارهای مدل طراحی‬ ‫‪‬‬

‫ارتباط محیطی‬

‫‪‬‬

‫بر این اساس معیار ارتباط ماژول محاسبه می‬ ‫شود که به صورت زیر محاسبه می شود‪:‬‬ ‫که در آن ‪ k=1‬و ‪ a=b=c=2‬و‬

‫‪‬‬

‫میزان ارتباط با دیگر ماژول ها برابر خواهد بود با‬

‫‪‬‬

‫‪ – Metrics‬معیارهای مدل طراحی‬

‫‪‬‬

‫معیارهای واسط کاربر به عنوان ارائه‬ ‫موضوع بسیار مناسبی می باشد‪.‬‬

‫‪ – Metrics‬معیارهای کد‬ ‫‪‬‬

‫در این دسته از معیارها می توان از‬ ‫مهترین متغیرها به موارد زیر اشاره نمود‪:‬‬

‫‪‬‬

‫با استفاده از این مقادیر می توان‬ ‫‪ Program‬ارائه نمود‬ ‫‪Length‬زیر را‬ ‫معیارهایی مانند‬ ‫‪Program Volume‬‬ ‫‪Program Volume Ratio‬‬

‫‪Metrics‬‬ ‫‪‬‬

‫همچنین معیارهایی برای تست و پشتیبانی‬ ‫وجود دارند که در اینجا بیشتر در این زمینه‬ ‫بحث را ادامه نخواهیم داد‪.‬‬