Ярошевская Е.Ю. Анализ и проектирование информационных систем. Учебное пособие
Подождите немного. Документ загружается.
30
предметной области Вашей системы. Очень полезно пообщаться с
таким специалистом.
3. Экономия времени на этом этапе, вызванная желанием ускорить
начало реализации, может привести к обратному результату -
временным затратам на дополнительное изучение предметной области.
3.2. Проектирование ИС
Проектирование – это не рисование диаграмм;
диаграммы просто отражают
результаты проектирования.
Г. Буч
Собранную на предыдущем этапе информацию о входных и
выходных данных необходимо систематизировать. Существует
достаточно разветвленная теория о том, как производится
систематизация данных. Подробно с теорией объектно-
ориентированного анализа можно ознакомиться в книге Гради Буча. [2].
В главе 1 настоящего пособия отмечены наиболее существенные
моменты этой теории. Напомним, что наиболее эффективным
принципом организации таблиц (основных структурных единиц MS
Access) является объединение в них данных, полностью
характеризующих конкретный объект. Соответственно, количество
таблиц определяется количеством объектов в предметной области.
Связи объектов в предметной области определяют связи между
таблицами. При задании связей (ассоциаций) учитывайте тот факт, что
СУБД MS Access реализует напрямую только два типа отношений:
«один-к-одному» и «один-ко-многим». При необходимости реализовать
отношение «многие-ко-многим» вам придется создавать так
называемую буферную промежуточную таблицу. Подобная схема
изображена на рис.7:
M N
1 1
Рис.7. Реализация отношения «многие-ко-многим»
Таблица Б Таблица А
Буферная
таблица
31
В соответствии с постановкой задачи, Вы разделяете входные
данные на информацию об экскурсиях, клиентах, экскурсоводах и
проданных путевках. СУБД MS Access предусматривает объединение
данных, относящихся к одному объекту, в таблицы. Итого, для
работы ИС создаются 4 таблицы («Экскурсии», «Клиенты»,
«Экскурсоводы», «Проданные путевки»), связанные между собой,
которые и представляют собой информационную модель Вашей
системы. В терминах MS Access информационная модель называется
схемой данных (Рис.8).
1
Рис. 8 . Фрагмент схемы данных
Таблицы «Экскурсоводы» и «Экскурсии» связаны по полю «ИНН
экскурсовода». Тип связи «один ко многим» (1 - ) означает, что 1
экскурсовод может вести несколько типов экскурсий.
По завершении проектирования информационной модели ИС
следует перейти к разработке функциональной модели ИС, то есть,
после систематизации информации можно приступить к ее обработке.
Составление функциональной модели подразумевает использование
принципа декомпозиции, или выделение в составе будущей системы
функциональных модулей, поэтапно решающих задачи
алгоритмической обработки структурированной информации. При
проведении декомпозиции необходимо обеспечивать одинаковую
степень детализации функций создаваемых модулей. Так, разделяя
функции системы, не следует выносить на один уровень модуль
обработки всей информации и модуль получения конкретного отчета.
Таблица «Экскурсии»
К
од экск
у
рсии
Н
азвание
П
родолжительность
Дата и время начала
Стоимость
И
НН Экскурсовода
Особые условия
Таблица «Экскурсоводы»
И
НН Экск
у
рсовода
Фамилия
И
мя
Отчество
Дата рождения
Дата последнего отпуска
...
32
Начинаем анализировать функции ИС в туристической фирме. На
рис. 9 представлен первый уровень декомпозиции.
Рис. 9. Функциональная модель: первый уровень декомпозиции
Продолжаем декомпозицию. В модуль «Работа с клиентом»
входят следующие функциональные блоки: «Регистрация нового
клиента», «Поиск клиента в базе», «Выбор экскурсии», «Выдача
квитанции». Это второй уровень декомпозиции, и т.д.
Аналогично проводится необходимая декомпозиция любого уровня
для любого модуля. Критерием завершения декомпозиции системы
является получение набора модулей (дерева модулей), каждый из
которых может быть реализован с помощью элементарной функции MS
Access [3]. Обращаем Ваше внимание, что для различных модулей
одной системы может потребоваться различное количество уровней
декомпозиции.
Возможные ошибки и способы их устранения
1. Собрано недостаточно информации, что не позволяет в полном
объеме описать функции системы. Для устранения подобной ошибки
вернитесь к шагу «Постановка задачи» и проверьте полноту
собранных данных.
2. Избыточность представления информации. Например, при
фиксированном расписании экскурсий на неделю, создается 52
отдельных графика расписаний на каждую неделю года. Проверьте,
что для каждого информационного объекта данные не дублируются в
разных таблицах.
3. Неэффективная декомпозиция системы, не дающая возможности
адекватной реализации каждого модуля с помощью элементарных
функций MS Access. Перед тем, как завершить декомпозицию
модуля проверьте критерий окончания декомпозиции.
ИС турфирмы
Работа с
клиентом
Составление
графика работы
экскурсоводов
Получение
статистики
Обновление
экскурсионных
данных
33
3.3. Реализация ИС
Большие системы подобны спагетти на
тарелке: тянешь с одной стороны –
что-то движется с другой.
Д. Ван Тассел
Завершение проектирования ИС означает долгожданную
возможность реализации Вашего проекта в среде MS Access в
соответствии с информационной моделью. То есть, всю схему данных,
уютно расположенную в Вашей голове и на подручных материалах,
следует перенести в компьютер, в соответствии с предназначенными
для этой цели средствами MS Access [4].
Примечание.
При создании таблиц существенно объявление поля –
структурной единицы таблицы – индексированным или
неиндексированным. Если по конкретному полю предполагается
производить выборку, целесообразно описать это поле как
индексированное, для более эффективного доступа к искомой записи в
таблице.
Далее следует последовательно реализовать каждый модуль
функциональной модели, создавая соответствующие формы, запросы и
отчеты MS Access [2].
При реализации системы особое внимание следует уделить
пользовательскому интерфейсу, который не прорабатывался подробно
на предыдущих этапах.
Интерфейсы пользователя должны быть реализованы так, чтобы
работа с ИС была интуитивно ясной, обращения конечного
пользователя к документации сводились к минимуму. Для этого
рекомендуется следующее:
• Соблюдайте единство стиля при реализации форм и отчетов.
• Создавайте системы пользовательского меню.
• Пользуйтесь едиными обозначениями. (Пользователю трудно
разобраться, когда одно поле в разных формах называется по-разному,
или разные поля имеют одинаковые названия. Так, если в одной форме
под временем экскурсии подразумевается время начала экскурсии, а в
другой форме – продолжительность экскурсии, могут возникнуть
конфликтные ситуации, связанные с опозданием клиентов на
экскурсии.)
• Реализуйте ограничения на ввод.
Установите «возраст экскурсовода» > 14, в соответствии с КЗОТ.
• Используйте всплывающие подсказки.
• Минимизируйте необходимый ввод данных с клавиатуры. При
контакте пользователя с клавиатурой вероятность ошибки возрастает.
Создавайте самораскрывающиеся списки на основе данных таблиц. При
34
выборе экскурсии надежнее выбрать название из списка предлагаемых
на ближайшее время экскурсий, нежели набивать это название,
пропуская буквы.
• Работайте в терминологии конечного пользователя. Например,
вместо абстрактного имени пункта меню «Открыть запрос на
выборку», назовите его «Вывести список постоянных клиентов».
Примечание.
В процессе документирования этапа реализации
желательно руководствоваться принципами «живучести» Вашей ИС –
система в реальной жизни должна развиваться, чтобы соответствовать
меняющимся реальным условиям. Поэтому создаваемая Вами
документация должна содержать достаточно информации о системе для
ее модификации. Модификация ИС может производиться по
прошествии времени, достаточного, чтобы забыть весь процесс ее
разработки. Не исключено, что модифицировать систему придется не
Вам, или Вам будет поручена модификация чужой ИС. Документируйте
каждый шаг!
Возможные ошибки и способы их устранения
На этапе реализации возникает самое большое количество
ошибок, так как, в отличие от предыдущих этапов, выполнявшихся в
условиях отсутствия внешних ограничений, здесь необходимо
соблюдение правил работы, установленных в среде MS Access. Поэтому
основные виды ошибок на этом этапе связаны с работой в MS Access.
Большинство приведенных ниже ошибок (если отсутствуют
специальные оговорки) устраняются путем проверки корректности
использования функций MS Access.
1. Синтаксические ошибки. Возникают из-за небрежности при задании
объектов БД. Например, #15.03.01
при задании условий для поля типа «дата» не поставлен знак # в конце
даты. В результате условие для выборки не определено.
2. Ошибки внутренних несоответствий. Например, попытка связать
таблицы через поля разного типа. Неправильное использование поля -
попытка присвоить числовому полю символьное значение. Основная
причина - плохое знание языка СУБД.
3. Логические ошибки
• Вызывают выполнение недопустимых операций: деление на 0,
обращение к несуществующему объекту (форме, запросу, макросу),
открытие формы без указания ее названия и т.п.
• Не вызывают прекращение работы системы, но приводят к
несоответствию между предполагаемым и реальным результатом.
Например, открыта другая форма (не та, с которой предполагается
35
работать в соответствии с функциональной моделью). Для
устранения такого рода ошибок вернитесь на этап проектирования и
проверьте конкретный модуль функциональной модели.
4. Внешние ошибки (в техническом обеспечении): несоответствие версий
(если Вы работаете над системой параллельно на разных компьютерах),
сбои оборудования, нехватка памяти.
Эти проблемы легче предупредить, чем потом решать по мере
возникновения. Узнайте, совместимы ли версии MS Access на тех
компьютерах, на которых Вы собираетесь работать, до начала этапа
реализации. На этапе постановки задачи выясните, какое количество
записей должна поддерживать Ваша система в условиях реальной
работы.
3.4. Тестирование ИС
Тестирование призвано указывать на
наличие, а не на отсутствие ошибок.
Дейкстра
На этом этапе Вы должны убедиться, что Ваша ИС работает в
соответствии со спецификациями и решает поставленную задачу.
В идеале процесс тестирования выглядит так: система
проверяется для всех возможных комбинаций входных данных, а
выходные данные сравниваются с предварительно рассчитанными
правильными результатами.
НО! Почти для всех систем существует бесконечное множество
входных комбинаций - вручную их проверить невозможно.
Поэтому:
1. Необходимо проведение автономного тестирования модулей
(фрагментов) системы
2. Возможна замена диапазона данных, соответствующих некоторому
условию, одним данным из этого диапазона.
ВЫВОД: Если небольшой фрагмент правильно работает с
набором входных данных, соответствующим определенным
условиям, он будет правильно работать и для всех остальных
наборов данных, соответствующих этим условиям [5].
Главное - определить, достаточно ли прост выбранный фрагмент
системы, чтобы его проверять таким способом. Каждый фрагмент
проверяется отдельно, после чего проверенные фрагменты
объединяются в более крупный фрагмент и т.д., до тех пор, пока
объединенные проверенные фрагменты не образуют систему в целом.
Этот метод хорошо согласуется с принципами структурного
проектирования, требующего разбиения на логические и
функциональные модули.
36
Рис. 10 . Разбиение системы на модули
Если система тестируется как единое целое:
число тестов = 5 х 6 х 4 = 120
Если разбить систему на модули (рис. 10):
число тестов = 5 + 6 + 4 = 15
• Тестирование модульной системы можно начинать с головного
модуля, а потом проверять подчиненные ему, а можно двигаться в
обратном порядке.
• Необходимо продумать данные для тестирования, обеспечивающие
проверку модуля по всем его ветвям.
• Процесс тестирования можно разделить на три этапа, выполняемые
один за другим:
1. Проверка в нормальных условиях – на основе данных, которые
характерны для реальных условий функционирования ИС.
2. Проверка в экстремальных условиях – в наборе входных данных
должны быть значения, проверяющие граничные условия. Следует
брать начальное и конечное значения допустимой области изменения
данного. Особый интерес представляют нулевые примеры. Для
цифровых данных – это нулевые значения, для символьных данных –
пробелы или отсутствие ввода.
3. Проверка в исключительных ситуациях – использование данных,
значения которых лежат за пределами допустимой области изменения.
Необходимо знать, как ИС обрабатывает неверные входные данные,
которые могут возникать в результате неизбежных опечаток или
неправильного понимания пользователем правил ввода данных.
Наихудшая ситуация складывается тогда, когда ИС воспринимает
неверные данные как правильные и выдает неверный, но
правдоподобный результат.
Например, если по условию задания количество человек в группе не
может быть больше 10, нужно проверить, как работает модуль при
Монолитная система
Модуль 3
4 ветви
Модуль 2
6 ветвей
Модуль 1
5 ветвей
37
количестве равном 0, 1, 6(любое число более 1 и менее 10), ровно 10 и
более 10 человек.
• Возможности разработчика по тестированию ограничены его опытом
и воображением. Если Вы плохо изучили предметную область и не
представляете, какие условия могут встретиться при эксплуатации - Вы
не учтете их при тестировании.
• Процесс тестирования удостоверяет качество системы - он должен
быть задокументирован! Пользователю необходимо дать нечто
большее, чем голословное заявление, что система работает правильно.
В документ, подтверждающий успешное тестирование, входят описание
тестовых процедур, входные данные и результаты.
Возможные ошибки и способы их устранения
Беспорядочное тестирование может привести к неправильной
диагностике и увеличению количества ошибок!
• Попросите коллегу поработать «конечным пользователем» с Вашей
системой. «Свежий» взгляд может выявить несоответствия, Вам не
заметные.
• Ответьте на 4 вопроса:
1) все ли модули функциональной модели реализованы, нет ли лишних
объектов;
2) можно ли, не выходя из ИС перейти от любой точки в любую другую;
3) правильно ли используются данные извне;
4) не выходят ли данные за пределы допустимых значений.
38
Автор надеется, что последовательное выполнение вышеизложенных
этапов работы обеспечит Вам достижения, отличные от результатов,
изображенных на рис. 11 [6].
Рис. 11. Этапы разработки ИС
Как было описано в
техническом задании
Как было реализовано
программистами
Чего хотел пользовательКак было внедрено
Как было спроектировано ведущим
системным специалистом
Как было предложено
организатором разработки
39
4. Документирование курсовой работы
Курсовая работа документируется в виде отчета.
Отчет по курсовой работе должен содержать следующие разделы:
1. Титульный лист.
2. Оглавление.
3. Формулировка задачи.
4. Логическая схема решения задачи. Сравнение ручного и машинного
варианта.
а) Описание метода решения задачи с выделением отдельных
функциональных действий.
б) Описание входных данных.
в) Описание выходных данных.
г) Блок-схема алгоритма решения задачи.
5. Программная схема решения задачи.
а) Входные документы (таблицы, формы, схемы данных) с полным
описанием формы, реквизитов, порядка заполнения и содержания
каждого типа документа.
б) Промежуточные (внутренние) документы (например, книги
учета) с полным описанием формы, реквизитов, порядка заполнения и
содержания каждого типа документа.
в) Выходные документы (отчеты) с полным описанием формы,
реквизитов, порядка заполнения и содержания каждого типа документа.
г) Запросы на получение промежуточных и выходных документов
с полным описанием реквизитов.
д) Тесты, на которых проверялось решение задачи – конкретные
значения входных, промежуточных и выходных документов.
6. Руководство по установке и обслуживанию ИС, в том числе
требования к аппаратно-программному обеспечению для эксплуатации
системы.
7. Руководство пользователя ИС.
8. Оценка результатов (эффективность решения, допущенные ошибки,
эффективность применения, пути оптимизации).
9. Список литературы.
10. Приложение: Распечатки тестовых значений входных и выходных
документов.