Файл: Методические рекомендации по написанию магистерской диссертации для направления Прикладная информатика.doc

Пример фрагмента дерева функций

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

Диалог в ИС не всегда можно формализовать в структурной форме. Как правило, диалог в явном виде реализован в тех ИС, которые жестко привязаны к исполнению предметной технологии. В некоторых сложных ИС (например, в экспертных системах) диалог не формализуется в структурной форме и тогда данный пункт может не содержать описанных схем.

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

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



Пример фрагмента сценария диалога
2.4.2. Характеристика базы данных

ER модель предполагает определение состава и взаимосвязей таблиц, отражающих содержание информационной модели в терминах конкретной СУБД, выбранной в п.1.4.

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

Пример фрагмента описания структуры записей таблицы «Контрагенты»

Наименование поля	Идентификатор поля	Тип поля	Длина поля	Прочее
Код контрагента	Kod_kontr	строка	5	ключевое поле
Наименование	Name_kontr	строка	20
Юридический адрес	Address	строка	50
Расчетный счет	R_sch	строка	20
Банк	Bank	строка	50
Корреспондирующий счет	K_sch	строка	20
БИК	BIK	число	8
Телефон	Tel	строка	15
Контактное лицо	Kontakt	строка	30

---

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

Если информационная база организована в форме корпоративной базы данных, то приводится описание и других её элементов: распределение прав доступа, бизнес-правил, триггеров и др.



Пример фрагмента ER модели
2.4.3 Структурная схема пакета (дерево вызова процедур и программ)

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

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

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

Пример фрагмента таблицы описания функций модулей

№ п/п	Наименование модуля	Функции модуля
1.	Глобальный модуль	Содержит глобальные процедуры и функции, предопределенные процедуры, процедуры и функции, которые необходимо выполнить при запуске системы «1С:Предприятие 7.7».
2.	Модуль справочника «Виды пакетов»	Содержит предопределенные процедуры формы списка и элемента справочника
3.	Модуль справочника «Расход сырья»	Содержит предопределенные процедуры формы списка и элемента справочника

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

---

4. 
   Описание программных модулей
   

Описание программных модулей должно включать блок-схемы (возможно привести блок-схему одного из расчётных модулей) и описание блок-схем алгоритмов основных расчетных модулей (объемом не менее 500 операторов) или настройки программных модулей (при внедрении типовых информационных систем).
2.5 Апробация результатов исследования

Контрольный пример включает описание:

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

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

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

Например, для задачи «автоматизация расчета себестоимости изделий» алгоритм может быть следующим:

1. 
   экранная форма входа в систему;
   
2. 
   экранная форма входа в меню расчета;
   
3. 
   экранные формы ввода нормативно-справочной информации (номеклатура изделий, ставки оплаты труда, учетные цены на материалы, перечень производственных работ, нормы накладных расходов и так далее);
   
4. 
   формы документов, необходимые для расчета (технологическая карта изделия, технологическая комплектация изделия);
   
5. 
   экранные формы ввода данных из вышеуказанных форм;
   
6. 
   экранная форма введенных данных для расчета себестоимости (трудоемкость изготовления и нормы расхода материалов);
   
7. 
   экранная форма запуска расчета себестоимости;
   
8. 
   экранная форма с результатами расчета;
   
9. 
   форма документа «Себестоимость изделия»
   

---

5. 1   2   3   4   5   6   7   8

---

---