Scientific journal
Научное обозрение. Педагогические науки
ISSN 2500-3402
ПИ №ФС77-57475

THE STUDY METRIC CHARACTERISTICS OF THE PHYSICAL SCHEMA OF RELATIONAL DATABASES

Nidzy A.V. 1 Rybanov A.A.  1
1 Volzhsky Polytechnic Institute branch of Volgograd state technical University
Today, software quality is understood as a set of SOFTWARE properties that determine the level of utility of the software product for users in accordance with the selected functional purpose and the requirements set by the consumer of the software product. Under the characteristic of the quality of software can be understood some attribute of SOFTWARE, reflecting the individual factors that affect the quality of programs and amenable to quantitative and qualitative assessment. At the moment, one of the most important parts of the information system is the database. And if the question of assessing the complexity and quality of the development of software modules appealed to many researchers, the problem of working with the database for a long time did not affect. However, despite this, the database is one of the most complex structural elements of the system architecture and changing its structure or technologies may require the entire solution to be rebuilt in contrast to the software module. The database reflects the objects of the real world, so the level and depth of study of objects and make the initial assessment in the design of the database. The study is an analysis of the subject area., basics of building a relational database.
database
metrics
quality criteria
characteristics

Распространение информационных технологий привело к тому, что постоянно происходит расширение круга Развитие информационных технологий очевидно связано с необходимостью постоянного совершенствования не только программных средств, но и методов их разработки. С целью унификации технологий работы с заказчиками и определения уровней достижения целей в процессе разработки программного обеспечения вводились разнообразные стандарты, в том числе и рекомендательные, помогающие привязать разработку к некоторому жизненному циклу ПО, а также регламентировать сам процесс разработки. Описать просто факторы, влияющие на качестве программного продукта, посредством характеристик недостаточно, так как без оценки уровня влияния этого фактора невозможно использовать расчётные показатели. Поэтому необходимо введение понятия критерия качества ПО.

Численные показатели, которые характеризуют уровень отражения данного свойства в рамках конкретного программного продукта, называются критериями качества.

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

• экономичности, отражающее оптимальность используемых ресурсов;

• уровня документированности, выражающего полноту документированного сопровождения;

• гибкости, расширяющей возможности по настройке системы;

• модульности, позволяющей внедрять и разрабатывать всю структуру системы частями;

• надёжности, гарантирующей приемлемый уровень вероятности отказа работы системы;

• обоснованности, предполагающей доказательство необходимости разработки тех или иных компонентов;

• тестируемости, реализующей достаточный уровень возможностей по проверке работы системы до ввода в эксплуатацию;

• модифицируемости, дающей простор для конфигурирования системы;

• эффективности, определяющей уровень снижения издержек и повышения производительности после внедрения системы;

• легкости сопровождения для снижения трудозатрат на поддержку системы [1].

Особенности критерия как характеристики можно выразить следующим образом.

Критерий численно характеризует основную целевую функцию программы

Критерий обеспечивает возможности для определения затрат, необходимых для достижения требуемого уровня качества, а также степени влияния на показатель качества различных внешних факторов.

Критерий должен быть по возможности простым, хорошо измеримым и определяется малым разбросом. Измерение характеристик и критериев качества выполняется с использованием метрик. Систему измерений качества программ называют метрикой качества программ. При этом сами измерения проводятся либо на уровне критериев качества программ, либо на уровне отдельных характеристик качества. Первый вариант позволяет проводить сравнение программных продуктов по категории качества, но с использованием субъективных оценок свойств программных продуктов.

Второй вариант дает возможность выполнить объективно и достоверности измерения метрик. Однако в результате оценка качества программы в целом будет зависеть от субъективной трактовки полученных оценок. Процесс исследования метрик программных продуктов можно вести по следующим направлениям:

• проведение поиска поиск метрик, которые характеризуют наиболее специфические свойства программ (метрики программного продукта);

• применение метрик с целью оценивания технических характеристик и факторов разработки программ (метрики условий разработки программного продукта).

На основании деления по виду получаемой информации метрики оценки качества ПО разбиваются на следующие основные группы [2].

Метрики, которые оценивают отклонение от нормы характеристик исходных проектных материалов. Предназначены для установки полноты заданных технических характеристик исходного кода.

Метрики, которые позволяют формировать прогноз качества разрабатываемого продукта. Задаются на множестве возможных вариантов решений поставленной задачи и их реализации и определяют качество программы, достижимое на итоговом этапе разработки.

Метрики, на базе анализа которых принимается решение о соответствии конечного программного продукта требованиям, определенным в документации заранее. Позволяют проводить оценку соответствия разработки заранее определенным требованиям. Не смотря на отсутствие универсальных подходов к оценке качества и системы метрик, существующие модели довольно широко применяются на практике.

Очевидно, что определение показателя требует и выбора метрической шкалы, структура которой в значительной мере определяет корректность отнесения программного продукта к тому или иному классу и оценку близости программ по качеству. В этом смысле шкалы подразделяются на:

• номинальную;

• порядковую;

• интервальную;

• относительную.

Номинальная шкала предполагает использование метрик, которые классифицируют программные продукты согласно признаку наличия или отсутствия некоторой характеристики без учета ее градаций.

Порядковая шкала предназначена для ранжирования, поэтому основная ее цель, это сравнение определенных характеристик с опорными значениями. По сути, процесс измерения по этой шкале состоит в фактическом определении взаимного положения конкретных программ.

Интервальная шкала включает метрики, показывающие не только относительное положение программного продукта, но и осуществляет оценку условных расстояний между оцениваемыми объектами.

Относительная шкала содержит метрики, которые позволяют произвести оценку не только на уровне интервальной шкалы с учетом взаимного расположения оцениваемых элементов, но проводить сравнение с граничными значениями. Фактически относительная шкала дает ответ на вопрос о близости характеристики к минимальному или максимальному значениям [3].

Выделяют следующие классы метрик для оценки сложности программ:

• размера программ;

• сложности потока управления;

• сложности потока данных;

• стилистики и понятности программ.

Функционал системы предполагает использование как данных, размещенных на сервере баз данных MySQL Server, так и подключение новых баз данных. Таким образом, в качестве входных данных можно рассматривать две структуры.

Первая структура определяется характеристиками базы данных, которая размещена на сервере и данные о ней находятся в системной базе.

Вторая структура связана с новыми базами данных. Наиболее корректный способ переноса базы данных на другой сервер заключается в формировании дампа этой базы. Следовательно, загрузка новых баз должна проводиться с использованием команд по разворачиванию дампа [4].

Сравнительный анализ средств проектирования

Параметры

CA Erwin

Data

Prosses

Modeler

Rational

Data

Architect

Enterprise

Architect

Open

ModelSphere

Работа с нотациями

IDEF 0,

IDEF 3

UML

UML,

IDEF0,

IDEF3

UML,

IDEF0,

IDEF3

Анализ проекта базы данных

Да

-

Да

Да

Удобство представления процессов

Высокое

-

Высокое

Среднее

Генерация кода приложения

-

Java

PHP

Java

Генерация SQL-кода

MSSQL

-

MySQL

MSSQL

MySQL

MSSQL

Генерация ключей в базе данных и наличие концептуальной модели

Да

Да

Да

Да

Проверка корректности построения процессов

Да

-

Частично

Да

В результате основными данными для анализа являются структуры, сформированные в процессе создания резервной копии базы данных. Дамп содержит в зависимости от выбранных параметров настройки в процессе формирования резервной копии:

• структуру базы данных;

• данные, которые расположены в таблицах базы данных [5].

Сравнительный анализ средств проектирования, которые можно использовать для разработки проекта информационной системы проводится согласно основным функциональным характеристикам:

• работа с нотациями;

• возможность проведения анализа проекта базы данных (валидация, целостность);

• удобство представления бизнес процессов;

• отслеживание корректности построения бизнес-процессов (верификация модели);

• генерация кода приложения;

• генерация ключей в базе данных и наличие концептуальной модели;

• генерация SQL-кода.

На основании проведенного анализа проектирования становятся очевидными и введенные метрики для концептуальной и физической моделей данных.