Теми рефератів
> Реферати > Курсові роботи > Звіти з практики > Курсові проекти > Питання та відповіді > Ессе > Доклади > Учбові матеріали > Контрольні роботи > Методички > Лекції > Твори > Підручники > Статті Контакти
Реферати, твори, дипломи, практика » Курсовые проекты » Автоматизація ведення обліку замовлень на автомобільні перевезення

Реферат Автоматизація ведення обліку замовлень на автомобільні перевезення





Малюнок 4.3.1 - Список помилок при Першому тестуванні.


Як видно з малюнку среди 118 помилок, аж 115 помилок займають невікорістовуванні методи, но як таке может буті Взагалі? На перший погляд может здать, что много написаного коду у программі Взагалі НЕ вікорістовується, альо ж насправді це не так. Праворуч у тому, что всі Особливостігри мови Java могут впліваті только на процес кодування, но ї на процес тестування. Така особлівість мови Java як відсутність вбудований ЗАСОБІВ для Опису структур змушує розробніків опісуваті структури у виде класів з полями, Які мают рівень доступу public, при цьом в ціх класах НЕ має жодних конструктора, лишь поля. Таке вирішенню проблеми є й достатньо Розповсюдження и по суті правильним, но статичність аналізатор коду помітіть в цьом очевідні помилки: Ми не вікорістовуємо ціх змініх Всередині класу, а отже смороду є непотрібнімі. Насправді ж, як ми знаємо, ЦІ зміні будут використовуват іншімі класами Всередині їх про єктів. Аналогічно до віщеопісаного прикладові подібна ситуация відбувається Із методами класів. Для прикладу розглянемо метод run () діалогового вікна, что збережений на малюнку 4.3.2. Даній метод потрібен для запуску вікна в автоматичності режімі, цею метод по суті потрібен, но віклікатіметься ВІН неявно, того статичність аналізатор відніс его до розряду помилок. Таким чином можна Сказати, что більша частина помилок є результатом неправильного трактування тексту програми статичність аналізатором.


Малюнок 4.3.2 - Приклад НЕ вікорістовуваного методу.


Тім НЕ менше, значний частина підсвіченіх помилок є действительно сігналізатором про невикористаних Деяк методів. На етапі проектування вважаться, что ЦІ методи будуть потрібні, а потім віявілось, что смороду НЕ вікорістовуватімуться.

Кож, як ми бачим з малюнку 4.3.1 є 2 локальних та 1 поле класу, что такоже НЕ є вікорістовуванімі.

Було проведеного виправлення Вищевказаними помилок та повторно тестування, что дало следующие результати:


Малюнок 4.3.3 - Список помилок при іншому тестуванні.

Як видно з малюнку - Кількість НЕ вікорістовуваніх методів булу зменшіть до незначної кількості, а досяжні це Завдяк фільтруванню методів, что Використовують неяно. При третьому тестуванні почти всі попередження Зниклий окрім Деяка. Варто додатково Сказати, что статичність аналізатор НЕ відавав жодних помилок пов язаних з неправильним іменуванням ідентіфікаторів в Програмі.

Таким чином, можна Сказати, что тестування програми Було проведено помощью статичного аналізатора з пакету SciTools Understand та Кількість попередження, что відавалась аналізатором во время Тестування булу звед до мінімальної кількості.


4.4 Результати ОЦІНКИ якості розроблення програмного забезпечення на Основі метричности АНАЛІЗУ


Як известно на Основі метричности АНАЛІЗУ можна Дізнатись про трудомісткість та про єм логіки, что вкладені у програмних систему. Про Дану систему говорять показатели, что вімірюються у кількості рядків програмного коду, кількості функцій, класів, тобто функціонального коду, а такоже коментарів - пояснювально коду. Дані показатели пріведені в табліці 4.1.


Таблиця 4.1 - опису основних метричних показніків розроблення ПЗ.

Значення метричних показниківCountDeclClass141CountDeclFile25CountDeclFunction306CountLine7001CountLineBlank782CountLineCode5456CountLineComment954CountStmtDecl1186CountStmtExe2261RatioCommentToCode0,17 Такоже помощью метричних показніків можна візначіті цікломатічну складність програмного забезпечення. Цікломатічна складність, як всім известно, характерізує Кількість логічніх зв язків, Які наявні в Програмі. Чім вища цікломатічна складність, тім складнішою вважається програма.


Малюнок 4.4.1 - Стовпчата Діаграма про єму коду (кількості стрічок).


Если поглянуті на діаграмі (малюнки 4.4.4, 4.4.5 5.5.5), Які візуалізують метричні показатели представлені в табліці, можна Побачити, что загальна Кількість стрічок перетнула Позначку в 7 тис. рядків и 5.5 тис. рядків з них є функціональнім кодом програми. Весь проект умістівся в 25 ОКРЕМЕ текстових файлів, а максимальна цікломатічна складність програмного забезпечення досяжні Позначки 7.

Всі ЦІ дані говорять достаточно складність проекту, а если розглядаті его у рамках курсового проекту, то можка Сказати, что складність є скроню и Було Виконання велику Кількість роботи.

Малюнок 4.4.2 - Стовпчата Діаграма кількості файлів.


Малюнок 4.4.3 - Діаграма, что відображає цікломатічну складність програми.


<...


Назад | сторінка 10 з 22 | Наступна сторінка





Схожі реферати:

  • Реферат на тему: Метод виловлювання помилок
  • Реферат на тему: Складність методів Вирішення проблеми дискретного логаріфмування в групі то ...
  • Реферат на тему: Приватизація в Росії: аналіз помилок і результати
  • Реферат на тему: Розробка шаблону для web сервісу з обліку помилок програмних продуктів
  • Реферат на тему: Анексія Криму, як можна вірішіті Конфлікт України с Россией чі можна его ві ...