Заключительный этап

Рекомендации по разработке технологического раздела

Рекомендации по разработке специального раздела

Рекомендации по разработке аналитического раздела

Основной этап практики

Основной этаппредусматривает разработку программного продукта, написание и оформление аналитического, проектного и технологического разделов ВКР:

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

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

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

- выбор и обоснование методического аппарата аналитического приложения (компоненты);

- постановка задачи на разработку автоматизированной системы.

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

- разработка архитектуры автоматизированной системы;

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

- разработка структуры данных (базы данных);

- разработка алгоритмов компонентов автоматизированной системы;

- тестирование разработанных компонентов.

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

- требования к аппаратному обеспечению;

- руководство программиста;

- руководство оператора.

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

Объект исследований должен соответствовать образовательной программе подготовки бакалавра и профилю: «Программное обеспечение средств вычислительной техники и автоматизированных систем».

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

По результатам анализа информационных процессов предметной области строятся модели: диаграмма потоков данных по методологии DFD и функциональная модель по методологии SADT в стандарте IDEF0 нулевого и первого уровня детализации. Требуемый уровень детализации определяется возможным решением проблем практики предметной области исследований.

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

Указанный подраздел ВКР выполняется в рамках расчетно-графического задания по дисциплине «Основы теории принятия решений».

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

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

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

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

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

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

Техническое задание (учебный вариант) на разработку программной системы включает:

Введение

1 Основание для разработки

2 Назначение

3 Требования к программе или программному изделию

3.1 Требования к функциональным характеристикам

3.2 Требования к надежности

3.3 Требования к составу и параметрам технических средств

3.4 Требования к информационной и программной совместимости

4. Требования к программной документации

5. Этапы разработки.

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

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

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

Если проект АС реализуется на основе средств автоматизации разработки в среде Rational Rose, для представления функционала автоматизированной системы может использоваться диаграмма вариантов использования.

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

Функциональная схема автоматизированной системы отражает схему работы системы, необходимые для реализации функций компоненты (архитектура) и выполняется в соответствии с требованиями ГОСТ19.701-90 – схемы алгоритмов, программ, данных и систем единой системы программной документации (ЕСПД).

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

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

Инструментальные средства разработки АС включают системы управления базами данных (СУБД), а также высокоуровневые средства программирования приложений. Выбор инструментальных средств является составной часть курсовой работы по дисциплине «Основы проектирования информационных систем» и осуществляется на основе сравнения их характеристик.

Проектирование структуры данных. Автоматизированная система разрабатывается, как правило, на основе баз данных (БД). БД является отражением информационной модели предметной области и представляет собой совокупность связанных данных, организованных по определенным правилам. СУБД обеспечивает поддержку создания объектов баз данных, централизованного управления и организации доступа к ним различных пользователей. Эта часть ВКР выполняется в рамках курсовой работы по дисциплине «Основы проектирования информационных систем».

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

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

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

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

При разработке модели данных необходимо учитывать:

1) исключение или сведение к минимуму повторяющихся данных путем задания нормализованных структур;

2) обеспечение всем пользователям быстрого доступа к данным;

3) возможность расширения структуры модели данных;

4) обеспечение целостности данных;

5) предотвращение несанкционированного доступа к данным;

6) предоставление делегированного доступа к данным отдельному пользователю или группе пользователей;

7) снижение сложности создания приложений, предназначенных для ввода, редактирования, обработки данных, а так же анализа скрытых закономерностей в структурах данных.

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

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

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

- физические – тип, длина;

- логические ограничения – диапазон, список, значения по умолчанию;

- опциональность – признак того, что значение может быть или должно быть определено;

- процессы – генерация, ввод, обновление, просмотр значения.

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

В результате анализа предметной области выявляются роли пользователей АС (таблица - Уровни доступа пользователей).

Концептуальный уровень архитектуры базы данных. Информационно-логическая модель (ИЛМ) предметной области является проблемно-ориентированной и системно-независимой, она не зависит от конкретной СУБД, операционной системы и аппаратного обеспечения АС. Назначение ИЛМ предметной области – адекватное, единое, интегрированное и непротиворечивое отображение реального мира в рамках решаемой задачи автоматизации; отражение потребностей всех пользователей разрабатываемой АС.

ИЛМ предметной области представляет классы объектов предметной области и связи (отношения) между ними. Связи относятся к одному из следующих типов: «один к одному» (1:1) и «один ко многим» (1:М).

Графическое представление ИЛМ предметной области осуществляется в виде ER-модели. Основными элементами ER-модели в нотации Ричарда Баркера являются: класс объектов; свойство класса объектов; уникальный идентификатор; опциональность свойства, связь; опциональность и переносимость связи; уникальность объекта из связи; супертипы, подтипы, арки и др. На диаграмме используются следующие соглашения:

- КО отображается в виде четырехугольника с закругленными углами. Имя КО указывается внутри четырехугольника, это имя существительное в единственном числе, отображенное заглавными буквами;

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

- четырехугольники, отображающие КО, могут иметь разные размеры;

- опциональность свойства помечается: обязательное свойство – звездочкой (*), необязательное – кружочком (о);

- уникальный идентификатор КО помечается #, если уникальных идентификаторов в КО выявлено несколько, тогда каждый помечается номером, указанным в скобках, например, #(1), #(2);

- обязательная связь помечается сплошной линией, необязательная – пунктирной;

- тип связи «один» помечается линией, «много» – «вороньей лапой».

После построения ИЛМ предметной области необходима проверка полученной модели на соответствие выполнения заданных функций АС (таблица - Перекрестная проверка иерархии функций АС и ИМЛ).

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

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

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

Полученная схема логической структуры РБД должна соответствовать, как минимум, третьей нормальной форме (3НФ) для избегания избыточности данных, ведущей к аномалиям при добавлении, обновлении и удалении данных. Схема РБД находится в 3НФ, если все входящие в неё схемы отношений соответствуют 3НФ.

Схема РО находится в 1НФ, если все атрибуты имеют атомарные (неделимые) значения. Схема отношения находится в 2НФ, если она находится в 1НФ и все неключевые атрибуты функционально полно зависят от составного первичного ключа. Если в схеме отношения имеется простой первичный ключ (состоит из одного атрибута), то схема по определению находится в 2НФ. Схема отношения находится в 3НФ, если она находится в 2НФ и в ней отсутствуют транзитивные зависимости между неключевыми атрибутами и ПК.

Физическая модель базы данных описывается на языке определения данных (ЯОД) выбранной СУБД. Для разрабатываемых в рамках ВКР баз данных рекомендуется использовать ЯОД системы управления базами данных MS SQL 2008 R2, т.к. Оренбургский государственный университет имеет лицензию АА MSDN на этот инструмент.

СУБД MS SQL 2008 поддерживает ряд объектов реляционной БД:

1) Таблица – базовая структура РБД;

2) Представление – поименованная, динамическая выборка из одной или нескольких таблиц базы данных;

3) Хранимая процедура – хранимый в базе данных программный модуль, написанный на процедурном языке СУБД и реализующий правила предметной области;

4) Триггер – хранимая процедура, автоматически выполняемая СУБД при внесении изменений в указанной таблице (вставка, обновление, удаление данных);

5) Индекс – хранимая последовательность упорядочивания данных в столбце (столбцах) указанной таблицы по возрастанию или убыванию;

6) Домен – альтернатива типу данных для столбца (столбцов) таблицы (таблиц); определяет тип данных и может также задавать некоторые другие ограничения атрибута, значения по умолчанию;

7) Роль – именованный набор прав или привилегий на объекты базы данных;

8) Генератор – позволяет формировать последовательность уникальных чисел (номеров).

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

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

Поддержка целостности РБД рассматривается в 3-х аспектах.

1) Целостность таблицы. Обязательно должны поддерживаться:

- уникальность строк таблицы. Должен быть определен первичный ключ таблицы, и значение его должно быть определено;

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

Эти ограничения реализуются в командах создания и модификации таблиц. Например, в языке SQL это команды Create Table, Alter Table. В этих командах для описания полей - первичных ключей используется конструкция «primary key», для описания полей – уникальных ключей конструкция «unique», обязательность значений полей задается конструкцией «not null».

2) Декларативные ограничения данных. Так называют ограничения РБД, объявленные предметной областью и выявленные в ходе её анализа. Это ограничения на свойства объекта предметной области, далее атрибута реляционного отношения или поля таблицы: обязательность значения поля; тип, длина, диапазон значения поля (например, значение должно быть целым и положительным), вхождение значения в заданный список и др.

Такие ограничения рекомендуется задавать на уровне домена в командах Create Domain, Alter Domain. Кроме того, ограничения могут быть заданы в командах создания и модификации таблиц - Create Table, Alter Table при описании поля таблицы.

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

Физическое проектирование базы данных включает в себя также определение уровней доступа пользователей. Привилегии доступа устанавливает АБД или другой пользователь (прикладной программист), которому АБД предоставил такое право. Для реализации привилегии доступа к таблице используется SQL-команда «Grant», при этом необходимо указать как минимум следующие параметры: ключевое слово, обозначающее вид привилегии доступа; имя таблицы; имя пользователя.

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

Для отображения взаимодействия модулей прикладной программы АС разрабатывается обобщенная (укрупненная) схема алгоритма.

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

Разработанные спецификации алгоритмов позволяют перейти к этапу реализации (кодированию) компонентов автоматизированной системы.

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

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

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

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

В технологическом разделе ВКР излагаются руководства персонала, эксплуатирующего разработанную автоматизированную систему. Руководства разрабатываются на основе ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению, ГОСТ 19.504-79 ЕСПД. Руководство программиста. Требования к содержанию и оформлению, ГОСТ 19.505-79 ЕСПД. Руководство оператора. Требования к содержанию и оформлению.

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

Заключительный этап связан с оформлением отчета (приложение В) по преддипломной практике в виде пояснительной записки согласно требованиям ЕСПД и стандарта предприятия. Отчет должен содержать следующие разделы.

Титульный лист (приложение В).

Индивидуальное задание на разработку программного продукта.

Дневник практики (приложение Г).

Содержание.

Введение.

1 Аналитический раздел.

2 Проектный раздел.

3 Технологический раздел.

Заключение.

Список использованных источников.

Отзыв руководителя преддипломной практики от предприятия.

Приложения.

Дата добавления: 2017-02-01; Просмотров: 85; Нарушение авторских прав?; Мы поможем в написании вашей работы!