Содержание

ВВЕДЕНИЕ

1 Техническое задание

1.1 Описание предметной области

1.1.1 Особенности бизнес-процессов в организации

1.1.2 Основное назначение проектируемой системы

1.1.3 Основные пользователи системы и их обязанности

1.1.4 Виды запросов в информационной системе

1.1.5 Примеры шаблонов документов, использующихся в бизнес-процессе

1.2 Описание технологии обработки информации

1.2.1 Контекстная диаграмма

1.2.2 Диаграмма потоков данных: DFD

1.3 Информационно-логическая модель системы

1.3.1 ER-диаграмма

1.3.2 Описание параметров входной и выходной информации. Правила целостности данных

1.4 Требования к техническому и программному обеспечению

1.5 Требования к интерфейсам разрабатываемой информационной системы

2 Рабочий проект

2.1 Даталогическая модель системы

2.2 Физическое проектирование

2.2.1 Скрипты для создания базы данных и реализации запросов к данным на языке SQL

2.2.2. Общий алгоритм работы программного продукта

2.3 Описание разработанного приложения

2.3.1 Руководство пользователя

2.3.1.1 Форма N:структура меню, взаимодействие интерфейсов

2.3.1.2 …

2.3.2 Сообщения системы

2.4 Инсталляция и выполнение программного продукта

2.5 Программа и демонстрация испытания приложения

ЗАКЛЮЧЕНИЕ

ЛИТЕРАТУРА

ПРИЛОЖЕНИЕ A. Контекстная диаграмма

ПРИЛОЖЕНИЕ B. Диаграмма потоков данных

ПРИЛОЖЕНИЕ C. Макеты входных документов

ПРИЛОЖЕНИЕ D. ER-диаграмма

1. Введение должно занимать не более 1-2 страниц, соответствующей машинописному тексту. В нем кратко характеризуется объект изучения, обосновывается актуальность темы. Постулируются цель и задачи проектируемой системы, ее назначение. Рассмотрим это на примере:

ПРИМЕР:

Разрабатываемая система создается с целью:

- автоматизации процесса отчетности по показателям деятельности предприятия;

- повышения качества информации в ходе ее обработки: полноты, точности, достоверности, своевременности, согласованности;

- реализации политики информационной безопасности данных в организации.

Назначение системы:

- уменьшение временных затрат на составление отчетных документов;

- уменьшение вероятности ввода ошибочных данных;

- обеспечение защиты данных при обработке и хранении.

2. Основная теоретическая часть курсового проекта должна содержать несколько разделов. Рассмотрим содержание пояснительной записки на примере курсового проекта по дисциплине «Проектирование защищенных баз данных».

В подразделе «Описание предметной области» определяются системы и объекты автоматизации, информационные связи между структурными единицами, границы разрабатываемой системы, выделяются внешние сущности, взаимодействующие с системой.

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

Сбор и анализ требований является предварительным этапом концептуального проектирования базы данных, в ходе которого спецификации требований пользователей анализируются с целью выяснения всех необходимых сведений. Объем собранных данных зависит от сути проблемы и действующих бизнес-правил предприятия. Слишком тщательный анализ легко может привести к параличу сверханализа (paralysis by analysis), а слишком поверхностный — к пустой трате времени и денежных средств на проведение работ по реализации решения, которое окажется ошибочным в результате неправильной формулировки проблемы. Обычно разработчик базы данных во время проектирования одной базы данных использует несколько методик сбора фактов. Ниже перечислены пять чаще всего используемых методик сбора фактов:

• Изучение документации;

• Проведение собеседований;

• Наблюдение за работой предприятия;

• Проведение исследований;

• Проведение анкетирования.

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

• "Каковы ваши должностные обязанности?"

• "Какого вида задачи вы повседневно выполняете?"

• "С данными какого рода вы обычно работаете?"

• "Какого типа отчеты вы обычно используете?"

• "Дела какого типа вам необходимо отслеживать?"

• "Какие услуги предоставляет ваша компания своим заказчикам?"

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

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

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

• "Какие транзакции в базе данных выполняются чаще?"

• "Какие транзакции важны для работы организации?"

• "Когда выполняются наиболее важные транзакции?"

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

• "Какого типа защиту необходимо обеспечить для приложения базы данных?"

• "Имеются ли конфиденциальные данные, к которым должны иметь доступ только определенные сотрудники?"

• " За какой прошедший период необходимо хранить данные?"

• "Какие требования к работе в сети и совместному доступу предъявляются к системе базы данных?"

• "Какого типа защиту от аварийных ситуаций или потерь данных необходимо обеспечить для приложения базы данных?"

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

• начальный размер базы данных;

• темп роста базы данных;

• типы информационного поиска и их распределение по частоте использования;

• требования к работе в сети и совместному доступу;

• производительность;

• защита;

• резервное копирование и восстановление;

• юридические вопросы.

ПРИМЕР: ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ ПРИ РАЗРАБОТКЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ «ВУЗ».

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

Виды запросов в информационной системе:

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

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

3. Получить перечень и общее число тем кандидатских и докторских диссертаций, защищенных сотрудниками указанной кафедры, либо указанного факультета.

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

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

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

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

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

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

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

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

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

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

Собранная на этом этапе информация может быть плохо структурирована и включать некоторые неформальные заявления пользователей, которые впоследствии потребуется преобразовать и представить в виде более четко сформулированных требований. Описание предметной области, бизнес-процессов, логической модели данных проектируемой системы предполагает использование различных графических нотаций: IDEF0, IDEF1x, IDEF3, DFD, ERD и использование их на следующих этапах при описании бизнес-процессов, информационно-логической модели системы, технологии обработки информации.

Диаграммы IDEF0. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Модель может содержать четыре типа диаграмм:

• контекстную (в каждой модели может быть только одна контекстная диаграмма);

• декомпозиции;

• дерева узлов;

• только для экспозиции.

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

Рисунок 1 - Общая схема контекстной диаграммы

• Вход – это потребляемая или изменяемая работой информация или материал;

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

• Управление – процедуры, правила, стратегии или стандарты, которыми руководствуется работа. В отличие от входной информации управление не подлежит изменению;

• Исполнители, механизмы – ресурсы, которые выполняют работу. Например, сотрудники, оборудование, устройства и т.д.

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

Туннель у границы показывает, что этой стрелки нет на диаграмме-родителе (т.е. на контекстной), т. е. на верхнем уровне декомпозиции эта стрелка неважна. Туннель у блока говорит о том, что эта стрелка не важна на диаграмме-потомке, и там она не отобразится.

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

Рисунок 2 - Контекстная диаграмма и диаграмма декомпозиции

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

Основными компонентами диаграмм потоков данных являются:

• внешние сущности

• накопители данных или хранилищ

• процессы

• потоки данных.

Пример диаграммы DFD приведен на рисунке 3.

Рисунок 3 – Пример диаграммы DFD

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

Рисунок 4 – IDEF3-модель разработки базы данных

Диаграммы IDEF1X. Методология IDEF1X – один из подходов к семантическому моделированию данных, основанный на концепции Сущность-связи (Entity-Relationship). ER-диаграммы позволяют строить модели логической структуры данных предметной области, а так же производить моделирование физической структуры систем хранения данных. Сущность на ER-диаграмме представляется прямоугольником с именем в верхней части. В прямоугольнике перечисляются атрибуты сущности, при этом атрибуты, составляющие уникальный идентификатор сущности, подчеркиваются или помечаются знаками: # или PK (primary key). На стадиях разработки логической и физической моделей реляционной базы данных домены уточняются в сущностях на ER-диаграмме.

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

В подразделе «Информационно-логическая модель системы» описывается логика обработки информации:

- определяются сущности предметной области и строится диаграмма "сущность-связь" (ERD);

- описываются структура и информационное содержание входных документов, определяются правила целостности данных;

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

- описывается спецификация обработки информации — обобщенные алгоритмы работы функциональных блоков, представленные в понятиях языка пользователя;

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

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

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

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

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

Критериями оценки должны выступать:

1. Содержательное название

2. Ясные и понятные инструкции

3. Логически обоснованные группировки и последовательности полей

4. Привлекательный вид окна формы или поля отчета

5. Легко узнаваемые названия полей

6. Согласованная терминология и сокращения

7. Согласованное использование цветов

8. Визуальное выделение пространства и границ полей ввода данных

9. Удобные средства перемещения курсора

10. Средства исправления отдельных ошибочных символов и целых полей

11. Средства вывода сообщений об ошибках при вводе недопустимых значений

12. Особое выделение необязательных для ввода полей

13. Средства вывода пояснительных сообщений с описанием полей

14. Средства вывода сообщения об окончании заполнения формы.

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

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

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

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

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

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

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

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

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

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

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

3. В основной практической части должны содержаться следующие сведения:

• общие сведения о работе системы;

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

• общий алгоритм программного продукта;

• разработанные меню и интерфейсы;

• сообщения системы;

Физическое проектирование включает выбор СУБД и средств разработки программного обеспечения, используемых технических средств, разработку программного обеспечения, необходимого для функционирования системы, создание скриптов для создания БД, запросов к БД на языке SQL, процедур, функций, триггеров.

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

В подразделе «Описание разработанного приложения» указываются:

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

• состав и общая схема взаимодействия и взаимосвязи модулей (классов);

• функциональное назначение каждого модуля, класса, объекта, метода, процедуры;

• описание (функциональное назначение) важнейших переменных программы;

• реакция системы на события, происходящие во время диалога.

В подразделе «Инсталляция и выполнение программного продукта» указываются способы инсталляции с описанием диалога установки. Описываются параметры настройки, способы запуска программы на выполнение.

приводится структура разработанного программного обеспечения:

В подразделе «Программа и демонстрация испытания приложения» необходимо указать объект тестирования, порядок и методику тестирования. Здесь приводится полный набор тестов для проверки системы, а также примеры выполнения тестов с результатами работы.

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

Общий объем курсовой работы — 22-30 листов машинописного текста вместе с приложениями.