‫مهندسی نرم افزار ‪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‬‬

‫همچنین معیارهایی برای تست و پشتیبانی‬ ‫‪‬‬

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