Статистические данные, корректность программного обеспечения

Уникальным идентификатором типа сущности  ЭЛЕМЕНТ РАСПИСАНИЯ является пара атрибутов  <номер рейса, дата-время  вылета>. Если вернуться к терминам функциональных зависимостей, то между  атрибутами этой сущности имеются следующие FD:

• {номер рейса, дата-время вылета}->бортовой номер самолета;
• номер рейса -> аэропорт вылета;
• номер рейса -> аэропорт назначения;
• бортовой номер самолета -> тип самолета.

Кроме того, очевидно, что каждый экземпляр  связи с сущностью  ГОРОД также  определяется значением атрибута  номер рейса. Налицо нарушение требования второй нормальной формы. Мы получаем не только избыточное хранение значений атрибутов  аэропорт вылета и аэропорт назначения в каждом экземпляре типа сущности  ЭЛЕМЕНТ РАСПИСАНИЯ с  одним и тем же значением номера рейса. Искажается и затемняется  смысл связи с сущностью  ГОРОД. Можно подумать, что в разные дни  один и тот же рейс прибывает в  разные города. На рисунке показан нормализованный вариант диаграммы, в котором все сущности находятся во второй нормальной форме. Теперь имеются три типа сущности: РЕЙС с атрибутами  номер рейса, аэропорт вылета, аэропорт назначения, ЭЛЕМЕНТ РАСПИСАНИЯ с атрибутами  дата-время вылета, бортовой номер самолета, тип самолета и ГОРОД. Уникальным идентификатором сущности РЕЙС является атрибут номер рейса, уникальный идентификатор ЭЛЕМЕНТ РАСПИСАНИЯ состоит из атрибута  дата вылета и конца связи КОГДА, НА ЧЕМ. Мы видим, что ни в одном типе сущности больше нет атрибутов, определяемых частью уникального идентификатора. Свойства второй нормальной формы удовлетворяются, и мы имеем более качественную диаграмму.

 

1.9 Третья нормальная форма ER-диаграммы

В третьей нормальной форме устраняются  атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.  Взглянем еще раз на тип сущности  ЭЛЕМЕНТ РАСПИСАНИЯ на рисунке. Конечно, каждый день каждый рейс выполняется только одним самолетом, поэтому бортовой номер самолета полностью зависит от уникального идентификатора. Но бортовой номер является уникальной характеристикой каждого самолета, и от этой характеристики зависят все остальные характеристики, в частности тип самолета. Другими словами, между уникальным идентификатором и другими атрибутами  типа сущности  ЭЛЕМЕНТ РАСПИСАНИЯ имеются следующие функциональные зависимости:

• {КОГДА, НА ЧЕМ, дата-время вылета}->бортовой номер самолета
• {КОГДА, НА ЧЕМ, дата-время вылета}->тип самолета
• бортовой номер самолета -> тип самолета

Как видно, имеется транзитивная FD {КОГДА, НА ЧЕМ, дата вылета}  тип самолета, и наличие этой FD вызывает нарушение  требования третьей нормальной формы. На самом деле, тип сущности  ЭЛЕМЕНТ  РАСПИСАНИЯ на рисунке включает в себя (по крайней мере, частично) тип сущности  САМОЛЕТ. Это вызывает избыточность хранения и затуманивает смысл диаграммы. На рисунке показан нормализованный вариант диаграммы, в котором все сущности находятся в третьей нормальной форме.

 

2 Конструирование программного  обеспечения

Процесс программирования включает четыре шага (рис. 1):

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

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

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

2.1 Постановка задачи

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

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

Характеристики Хорошей Постановки Задачи:

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

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

Ясность, т.е. она должна быть понятной и пользователю и системному аналитику, поскольку постановка задачи – это единственный контракт между ними.

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

Стандартная форма постановки задачи.

Рассмотрим следующую постановку задачи: «Ввести три числа и  вывести числа в порядке».

Такая постановка не удовлетворяет  приведенным выше требованиям: она  не является ни точной, ни полной, ни понятной. Действительно, должны ли числа вводиться  по одному на строке или все числа  на одной строке? Означает ли выражение  «в порядке» упорядочение от большего к меньшему, от меньшего к большему или тот же порядок, в каком  они были введены.

Очевидно, что подобная постановка не отвечает на множество вопросов. Если же учесть ответы на все вопросы, то постановка задачи станет многословной и трудной для восприятия. Поэтому  Д. Райли предлагает для постановки задачи пользоваться стандартной формой, которая обеспечивает максимальную точность, полноту, ясность и включает:

• Наименование задачи (схематическое определение);
• Общее описание (краткое изложение задачи);
• Ввод;
• Вывод;
• Ошибки (явно перечислены необычные варианты ввода, чтобы показать пользователям и программистам те действия, которые предпримет машина в подобных ситуациях);
• Пример (хороший пример может передать сущность задачи, а также проиллюстрировать различные случаи).

Пример. Постановка задачи в стандартной  форме.

НАЗВАНИЕ 

 Сортировка трех целых чисел.

ОПИСАНИЕ

• Ввод и вывод трех целых чисел, отсортированных от меньшего числа к большему.

ВВОД

• Вводятся три целых числа по одному числу на строке. При этом целым числом является одна или несколько последовательных десятичных цифр, которым может предшествовать знак плюс «+» или знак минус «–».

ВЫВОД

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

ОШИБКИ

1) Если введено менее трех  чисел, программа ждет дополнительного  ввода.

2) Строки ввода, кроме первых  трех, игнорируются.

3) Если какая-либо из первых  трех строк содержит более  одного целого числа, то программа  завершает работу и выдает  сообщение.

ОШИБКА ВВОДА – допускается  только одно целое число на строке.

ПРИМЕР:

ввод ® – 3

2

+ 17

вывод ® – 3 2 + 17

2.2 Проектирование решения

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

Существуют две основные модели вывода:

Первая модель известна как дедуктивный вывод. Эту форму логического мышления обессмертил знаменитый сыщик Шерлок Холмс. Дедуктивная логика применяет общие правила к конкретным случаям. Например, Холмс мог вывести конкретное утверждение «Дворецкий является убийцей» из более общих сведений «Убийца-блондин», а «Дворецкий является единственным блондином, которого можно подозревать».

Вторая модель – это индуктивный вывод, который является противоположностью дедуктивному выводу. Индуктивная логика извлекает общие заключения из отдельных случаев. Например, индуктивный вывод может быть использован, чтобы обосновать общее заключение «солнце поднимается на востоке» на основании многих отдельных наблюдений того, что солнце всегда поднималось на востоке.

Эти два процесса вывода умозаключений  – дедукция (от общего к частному) и индукция (от частного к общему) – тесно связаны с двумя наиболее широко распространенными методами проектирования: «сверху вниз» и «снизу вверх». Подобно дедукции, проектирование «сверху вниз» начинается с большой задачи, которая разбивается на подзадачи. Например, проектировщик нового холодильника-морозильника на основании исходного множества спецификаций агрегата (т.е. постановки задачи) должен дать детальные схемы и спецификации окончательного продукта (т.е. проект).

Если при этом он использует метод  проектирования «сверху вниз», то единственная задача проектирования может быть разбита  на две меньшие подзадачи: (1) проектирование холодильного агрегата и (2) проектирование морозильника.

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

Задача проектировщика – создание алгоритма, выполняющего функции связующего звена между постановкой задачи и готовой для исполнения программой. Проверку созданного алгоритма, т. е. насколько  последний отражает постановку задачи, осуществляет системный аналитик. В  силу этого и системный аналитик, и проектировщик должны уметь  читать и понимать алгоритм. Каждый алгоритм записывается на некотором  псевдоязыке. Алгоритмы, называемые также псевдокодами, не могут быть выполнены ни на каком компьютере.

2.3 Кодирование алгоритма

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

2.4 Сопровождение программы

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