38. Аж әзiрлеу кезінде қайтадан пайдалану.

Қайтадан пайдалану-күрделі жүйелерді әзірлеуде еңбек шығындарын қысқырту үшін қолданылатын негізгі методология.

Әрбір программалық өнім (программа тексті, архитектурасы, сценарий немесе документациясы) қайтадан пайдаланылуы мүмкін. Объектіге бағытталған программалау тілдерінде қайта пайдаланудың алғашқы лингвистикалық құралы кластар болып табылады: класс оны бағыттап және толықтырып тұратын ішкі кластардан құралады. Шаблондарды қайта пайдалану индивидуалды кластарды пайдаланумен салыстырғанда абстракцияның жоғарғы деңгейінде орналасады және ұтымды болып табылады.

Қайта пайдалануды сипаттайтын цифрларға сенудің қажеті жоқ. Біз кездестірген табысты проектілерде қайта пайдаланылған элементтер саны 70% - ке дейін жеткен, сонымен қатар нольдік те болған. Қайта пайдалану қандай да міндетті көлемге жету керек деп ойлаудың қажеті жоқ; қайта пайдалану мүмкіндігі пәндік аймаққа және техникалық емес факторларға байланысты, мысалы жұмыс графигінің қысымының деңгейі ретінде, қауіпсіздікті ойластыру.

Қайта пайдаланудың қандай да проценті нулевойге қарағанда жақсырақ, себебі тағы бір рет құртуға кететін ресурстарды экономдайды.

Қайта пайдалануды қалай орындауға болады?

Проект аумағындағы қайта пайдалану немесе бүкіл кәсіпорындағы жағдайға байланысты жүрмеуі керек. Мүмкіндіктерді әдейі іздеп және табыстарды қолдап отыру қажет. Сондықтын да біз макропроцесте қайталанатын шаблондарды іздеуді іске қостық.

Қайта пайдалануды арнайы біреуге тапсырған дұрыс. Архитектураны бақылау кезінде шығатын мүмкін жалпыламаларды іздеп, оларды орындау керек және оған жаңа компоненттерді қосып, ескі компоненттерді орналастыру керек. Қолдаудың келесідей жай формаларының өзі орнықты түрде әсер етеді: алғашқы кодтың авторын мойындау. Одан да басқа қолдауларды ойлап табуға болады, ресторанда тамақтану немесе демалыста екі адамға қыдыруға жолдама , және осы қолдауларды шешімі көбірек пайдаланылған құрастырушыларға береді.

Қайта пайдалану пайда әкелмеуі де мүмкін. Бұл программалық өнімді құрудың кеңауқымды жоспары бар кәсіпорындар үшін маңызды орын алады.

39. Программалық өнiмнің сапасын өлшеу.

Программалық жабдықтаманың сапасы- программалық жабдықтаманың талаптарға сәйкестігінің деңгейі ретінде сипаттамасы.

Сапа факторлары: түсініктілік, толық болуы, келісушілік, тестіленуі, қолдануға ыңғайлылығы, сенімділік, эффектілікі, қауіпсіздік.

Шульмейер мен МакМанус программалық өнімнің сапасын «қолдануға жарамдылығы»деп қарастырады. Программаның сапасы кездейсоқ жұмыс болмауы керек.Сапасы әзірлеу процесімен нақтылануы керек. Негізінде, объектілі- бағытталған технология сапаны автоматты түрде болдырмайды:программалаудың кез келген объектілі- бағытталған тілінде нашар программалар жазуға болады.

Міне сондықтан объектілі- бағытталған әзірлеу процесінде біз программалық жүйенің архитектурасына осындай мағына береміз. Сапасы жай архитектураның арқасында қаланады және қарапайым және тізбектелген тактикалық шешімдермен орындалады.

Программалық өнімнің сапасының басқарылуы бұл-программалық өнімді бүтіндей қолдану жарамдылығын растайтын жүйелі түрдегі әрекеттер.Сапаны басқарудың мақсаты-

бізге программалық жүйе сапасының есептік өлшемдерін беру.Көптеген дәстүрлі есептік өлшемдер объектілі -бағытталған жүйеге де бірегей басылымды.

Сапаның ең басты есептік критериі табылған қателердің саны болуы мүмкін. Жүйенің эволюциясы кезінде біз программалық қателерді олардың салмағына және орналасуына сәйкес ескереміз. Қателерді табу графигі анықталған қателердің санының уақытқа байланысын көрсетеді.

Тағы да бір есептік өлшем-қателердің тығыздығы.Программалық мәтіннің киложолына(KSLOC-Kilo Source Lines Of Code) табылған қателердің саны объектілі -бағытталған жүйелерге қолданылатын дәстүрлі көрсеткіш болып табылады.Дұрыс жобаларда қателердің тығыздығы қарастыру кезінде 10 KSLOC жуық қалыпты мәнге жете алады.Кодты ары қарай қарастыра отырып, біз осы көрсеткіштің көбеюін бақыламауымыз керек.

Объектілі-бағытталған жүйелерде сонымен қатар класстар категориясына немесе класстарға қателер санын өлшеу пайдалы.Осыған орай 80/20 ережесі қабылданбалы деп есептеледі:программада анықталған қателердің 80%-i жүйе класстарының 20%-іне негізделген.

Объектілі-бағытталған өлшемдер

Мүмкін,басқарушы қолдана алатын орындалған жұмысты бағалаудың ең нашар әдісі-программа мәтінінің жазылған жолдар санын санап шығу.Кодтың фрагментіне түскен жолдар саны оның аяқталушылығы және күрделілігімен ешқалай байланысты емес.Күрделіліктің дәстүрлі өлшемдері программалау тілдерінің бірінші сатысына көбірек келеді.Олар объектілі бағытталған жүйе аяқталуы мен күрделілігінінің көрсеткіштері болып табылмайды.

Мысалы, Мак Кэйбтің цикломатикалық метрикасы күрделіліктің пайдалы өлшемі болмайды,егер оны объектілі бағытталған жүйеде бүтіндей қолданбаса,себебі ол жүйе класстарының құрылымына және механизмдерге мәнсіз.Алайда біз цикломатикалық метриканы жеке класстарға қолдану пайдалы деп табамыз – ол күрделілігіне байланысты кейбір көзқарастар береді және де өте көп қателері бар күмән тудыратын класстарды анықтау үшін қолданылуы мүмкін.Біз әзірлеу прогрессін дайын және жұмыс істеп тұрған класстардың (логикалық аспект) санымен немесе жұмыс істейтін модульдердің санымен(физикалық аспект) өлшеуге бейімделгенбіз.

Чидамбер мен Кемерер объектілі бағытталған жүйелерге тікелей қолданылатын бірнеше өлшемдер ұсынады:

• Әдістермен салмағы өлшенген класстың қанықтығы;

• Мұрагерлік ағашының тереңдігі;

• Мұрагерлер саны;

• Объектілер ілінісі;

• Класстарға пікір айту;

• Әдістерде байланыстың жетіспеушілігі.