Назначение: для вывода на экран адресных и банковских реквизитов организации (листинг 3.72).

Примечания: задание свойству Visible форм Подчиненная1 и Подчиненная2 значения False.

4) «Кнопка28» (Счета).

Назначение: для вывода на экран информации по счетам выписанным для текущей организации. (листинг 3.73).

Примечания: заполнение временной таблицы «ИнфоПоСистемамЗаказчика», задание свойству Visible формы Подчиненная1 значения True и Подчиненная2 значения False.

5) «Кнопка27» (Системы).

Назначение: для вывода на экран информации по системам для текущей организации. (листинг 3.74).

Примечания: заполнение временной таблицы «ИнфоПоСистемамЗаказчика», задание свойству Visible формы Подчиненная1 значения False и Подчиненная2 значения True.

6) «Кнопка25» (Выход).

Назначение: для закрытия текущей формы.

Примечания: реализация с помощью мастера.

Форма «ИнфоПоОрганСистемы» - ленточная форма

а) Поля данной формы являются полями для отображения информации временной таблицы источника данных формы и имеют источниками данных соответствующие поля в исходной таблице.

Форма «ИнфоПоОрганSub» - ленточная форма

а) Поля

1) «Поле4»

Назначение: для отображения даты начала сопровождения текущей системы по последнему выписанному и оплаченному счету.

Источник записей: =Format([Поле20];"mmmm yyyy").

2) «ДатаПМС»

Назначение: для отображения даты конца сопровождения текущей системы по последнему выписанному и оплаченному счету.

Источник записей: =Format([Поле2];"mmmm yyyy").

3) Другие поля данной формы являются полями для отображения адресных и банковских реквизитов текущей организации и имеют источниками данных соответствующие поля в исходной таблице.

10. Обмен сообщениями между пользователями (в дальнейшем возможно использование для заказа счетов актов и так далее? ).

Форма «Сообщения»

а) Поля

1) «username» (Кому) - поле со списком

Назначение: для выбора имени пользователя, которому должно быть отправлено сообщение.

Источник строк: SQL - запрос.

Заполнение: по SQL - запросу.

(SELECT DISTINCTROW [usersTable].[Код], [usersTable].[user] FROM
[usersTable];)

Примечания:

2) «messageText» (Текст сообщения)

Назначение: для ввода текста сообщения.

Заполнение: ввод с клавиатуры.

б) Кнопки

1) «Кнопка8» (Послать сообщение).

Назначение: для отсылки сообщения. Процедура обработки событий (листинг
3.75).

Примечания: заполнение временной таблицы «flagsTable».

2) «Кнопка28» (Выход).

Назначение: для закрытия текущей формы.

Примечания: реализация с помощью мастера.

Форма «HiddenFormForCheck»

Данная форма открывается при загрузке базы данных и свойству

Visible для данной формы задается значение False.

Комментарии.

Описанная структура имеет следующие особенности работы

1. Для формы HiddenFormForCheck по событию «Таймер» в процедуре обработки событий происходит проверка содержимого таблицы «flagsTable» на наличие соответствующего имени пользователя для проверки наличия сообщения для него.

(листинг 3.76).

11. Инициализация глобальных переменных НдсДляСчета и ВалДляСчета.

Данные переменные инициализируются при открытии базы данных в модуле
«Сервис» в «Общей области», и используются при выписке счетов, актов , счетов-фактур, накладных.

Форма «ТипСчета» и «ТипСчета1»

а) Группы

1). «Группа0»

Назначение: для задание, по событию «После обновления» в процедуре обработке событий, глобальной переменной НдсДляСчета значения True или
False в зависимости от положения переключателей. (листинг 3.77).

2). «Группа11»

Назначение: для задание, по событию «После обновления» в процедуре обработке событий, глобальной переменной ВалДляСчета значения True или
False в зависимости от положения переключателей. (листинг 3.78).

Заключение. Оценка качества программного обеспечения.

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

Боэм, Браун и Лайпоу занимались проблемой вычисления единой обобщающей меры качества и пришли к выводу, что это невозможно, так как входит в противоречие с частными характеристиками качества. Руководство должно принять решение об относительной важности следующих характеристик:

1) своевременное выполнение;

2) эффективность использования таких ресурсов, как: а) процессоры; б) память; в) периферийные устройства;

3) аспекты обслуживания программы, такие как: а) понимаемость; б) модифицируемость; в) удобство переноса с ЭВМ на ЭВМ.

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

Метрики Боэма, Брауна и Лайпоу.

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

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

2. Насколько просто его обслуживать (разобраться в нем, модифицировать, перепроверить)?

3. Могу ли я пользоваться этим пакетом, если сменю оборудование
(удобство переноса)?

Характеристики самого нижнего уровня представляют собой "примитивы", комбинации которых образуют характеристики среднего уровня. Эти примитивы предлагаются в качестве количественных метрик как самих примитивных характеристик, так и характеристик более высоких уровней.

Боэм, Браун и Лайпоу разработали 51 возможную метрику оценки примитивных характеристик, а затем провели сравнение этих метрик по степени их корреляции с качеством программы. Это подробная и сложная схема, опирающаяся на практический опыт, однако, Боэм, Браун и Лайпоу не предложили четкой демонстрации ее эффективности, надежности или применимости в различных контекстах. Длинный список понятий используется скорее как контрольный лист для рецензирования программы, чем как руководство по ее составлению.

Метрики программного обеспечения Джилба.

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

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

Отношение количества правильных данных ко всем данным приводится
Джилбом в качестве меры точности (свободы от ошибок). Так же, как Боэм,
Браун и Лайпоу, Джилб считает, что точность необходима для надежности программы. Прецизионность определяется как мера того, насколько часты ошибки, обусловленные одинаковыми причинами. Джилб оценивает ее дробью, в числителе которой стоит число фактических ошибок на входе, а в знаменателе
- общее число наблюденных ошибок, причинами которых явились эти ошибки на входе. Так, например, если одна ошибка вызывает в течение определенного периода времени 100 сообщений об ошибках, то прецизионность равна 0.01.

Второй большой категорией, введенной Джилбом, является гибкость, в которую входят:

1) логическая сложность;

2) внутренняя гибкость;

3) открытость (адаптируемость);

4) толерантность (к изменениям входа системы);

5) универсальность;

6) удобство переноса;

7) совместимость.

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

Кроме этих, Джилб приводит еще большое количество иных метрик, но это длинное перечисление скорее будит воображение, чем приносит пользу. Работа
Джилба демонстрирует новые возможности, однако реальное применение этих идей на практике дает обескураживающие результаты. Большинство характеристик очень трудно получить; сбивает с толку и то, что оценки сильно связаны, что затрудняет программисту предсказание влияния изменения программы на некоторую группу характеристик.

Оценка сложности Маккейба.

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

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

Согласно его подходу вычисляется и контролируется число путей в программе. В математические предпосылки входит определение цикломатического числа V(G) для графа с n вершинами, e ребрами и p компонентами связности:

V(G) = e - n + p

Маккейб использует следующую теорему: в сильно связанном графе G цикломатическое число равно максимальному числу линейно-независимых циклов.

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18