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

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

Генерация базы данных.

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

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

Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ERwin.

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

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

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

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

Режим «определение сущности» служит для презентации диаграммы другим людям.

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

Режим «первичные ключи» - внутри прямоугольников - сущностей показываются только атрибуты/колонки, составляющие первичный ключ.

Режим «пиктограммы». Для презентационных целей каждой таблице может быть поставлена в соответствие пиктограмма (bitmap).

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

Диаграмма может занимать более чем один экран и более чем один лист при печати. Для обзора модели предусмотрены, кроме прокруток экрана, режимы уменьшения/увеличения изображения, отображение всей модели, отображение выделенной части модели.

Все объекты модели ERwin могут редактироваться средствами, принятыми в Windows - группировка, копирование, удаление, перемещение, использование системного буфера. Установка цветов и шрифтов осуществляется в удобных диалогах.

Компоненты модели, представленные текстом (имена сущностей, атрибутов, текстовые элементы) могут редактироваться непосредственно на экране.

В системе поддерживается механизм ссылочной целостности - это обеспечение требования, чтобы значения внешнего ключа экземпляра дочерней сущности соответствовали значениям первичного ключа в родительской сущности. Ссылочная целостность может контролироваться при всех операциях, изменяющих данные (INSERT/UPDATE/DELETE). Средства контроля ссылочной целостности в ERwin включают автоматическую генерацию триггеров и использование механизмов декларативной ссылочной целостности (для тех СУБД, которые поддерживают данные механизмы).

Для каждой связи на логическом уровне могут быть заданы требования по обработке операций INSERT/UPDATE/DELETE для родительской и дочерней сущности. ERwin представляет следующие варианты обработки этих событий:

Отсутствие проверки;

Проверка допустимости;

Запрет операции;

Каскадное выполнение операции (DELETE/UPDATE);

Установка пустого (NULL-значения) или заданного значения по умолчанию.

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

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

Могут быть переопределены триггеры, обеспечивающие правила для всей модели.

Могут быть переопределены триггеры, указанные для конкретной связи.

Могут быть переопределены триггеры, указанные для конкретной таблицы.

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

Обычно модели ERwin сохраняются на диск в виде файла. Имеется возможность хранить модель в целевой СУБД. Для этого с помощью самого ERwin в целевой СУБД создается метабаза ERwin. В этой базе данных сохраняется информация модели. В частном случае базой данных могут быть и dBase-файлы, с которыми ERwin работает через ODBC.

В системе поддерживается обратное проектирование, то есть восстановление информационной модели по существующей базе данных, используется при выборе оптимальной платформы (rightsizing) для существующей настольной (desktop) базы данных или базы данных на mainframe, а также при расширении (или модификации) существующей структуры, которая была построена без необходимой сопроводительной документации. После завершения процесса восстановления модели ERwin автоматически «раскладывает» таблицы на диаграмме. Теперь можно выполнять модификации уже с использованием логической схемы - добавлять сущности, атрибуты, комментарии, связи и т.д. По завершении изменений одна команда - синхронизировать модель с базой данных - актуализирует все проведенные изменения.

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

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

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

ERwin поддерживает прямой интерфейс с основными СУБД: DB2 версии 2 и 3, Informix версий 5.1, 6.0, 7.1, Ingres, NetWare SQL, ORACLE версий 6 и 7, Progress, Rdb версий 4 и 6, SQL/400 версий 2 и 3, SQLBase версий 5 и 6, SQL Server версий 4 и 6, Sybase версии 4.2, Sybase System 10 и 11, Watcom SQL. Отметим, что поддерживаются как самые современные, так и предыдущие версии основных СУБД

ERwin поддерживает также настольные (desktop) СУБД: Microsoft Access, FoxPro, Clipper, dBASE III, dBASE IV и Paradox.

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

Для создания физической структуры БД может быть запрошена генерация DDL-скрипта (data definition language). При этом используется диалект SQL для выбранного типа и версии сервера. Хотя сгенерированный код не нуждается в модификации, имеется возможность его сохранить в файл или распечатать.

ERwin выпускается в нескольких различных редакциях, ориентированных на наиболее распространенные средства разработки 4GL. В числе поддерживаемых средств - PowerBuidler фирмы Powersoft, SQL Windows фирмы Gupta, Visual Basic фирмы Microsoft, Oracle*CASE фирмы Oracle.

Средства двунаправленного взаимодействия ERwin с базой данных обеспечивают управление информацией, ориентированной как на серверную, так и на клиентскую часть. Например, для PowerBuilder можно просматривать/редактировать расширенные атрибуты в редакторах ERwin.

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

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

Функция ERwin по генерации DataWindow позволяет сгенерировать прототипы окон данных будущего приложения уже на стадии создания информационной модели. Для создания Data Windows предлагается Wizard, с помощью которого указывается стиль окна и выбранные колонки таблиц.

ERwin реализует собственный макроязык для подготовки прототипов триггеров и процедур. Схема использования прототипов заключается в подготовке шаблона для различных типов триггеров (например, триггер, реализующий логику каскадного удаления - ON DELETE CASCADE). Базовые шаблоны встроены в ERwin, но пользователь может определить свои собственные шаблоны и использовать их вместо стандартных.

Макроязык шаблонов реализует большое количество макросимволов, ссылающихся на различные объекты базы данных, например:

%Action - расширяется в UPDATE/INSERT/DELETE;

%ForEachAtt(<таблица>,<разделитель>) { <код макрокоманды> } - циклическое выполнение группы операторов над каждым атрибутом таблицы;

%ForEachEntity() { } - циклическое выполнение функций над всеми таблицами;

%If, %else - операторы условного управления.

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

При задании правила или умолчания для клиентской части эти атрибуты переносятся в репозитарий средства 4GL.

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

Для подготовки развитых отчетов может быть использован специальный генератор отчетов фирмы Logic Works - RPTwin, который интегрирован с ERwin.

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

Существенное повышение скорости разработки за счет мощного редактора диаграмм, автоматической генерации базы данных, автоматической подготовки документации;

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

Возможность легко вносить изменения в модель при разработке и расширении системы;

Возможность автоматической подготовки отчетов по базе данных; важно, что эти отчеты всегда в точности соответствуют реальной структуре БД;

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

Тесная интеграция со средствами 4GL позволяет уже на стадии информационного моделирования задавать отображение данных в приложениях;

Обратное проектирование позволяет документировать и вносить изменения в существующие информационные системы;

Поддержка однопользовательских СУБД позволяет использовать для персональных систем современные технологии, что значительно упрощает переход от настольных систем к системам в технологии клиент-сервер (upsizing).

Логическая структура БД ЭИС учета готовой продукции представлена на рис. 2.4.

Рис. 2.4 - Схема логической структуры БД ЭИС учета готовой продукции

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

Старшие смен - содержит информацию об ответственных лицах на производстве каждой партии продукции;

Ассортимент запчастей - содержит наименования и характеристики всех запчастей;

Запчасти - содержит список всех имеющихся на складе запчастей;

Виды технических средств - содержит наименования и характеристики всех производимых технических средств;

Технические средства - содержит список имеющихся технических средств на складе.

Выбрав СУБД можно преобразовывать логическую структуру БД в физическую структуру и сгенерировать SQL-код будущей БД. Схема физической структуры БД приведена на рис. 2.5.

Рис. 2.5 - Схема физической структуры БД ЭИС учета готовой продукции

Для обеспечения согласованности и целостности хранимых данных в приложении БД ЭИС учета готовой продукции созданы триггеры ссылочной целостности на удаление и изменение записи в главной таблице. Такие триггеры созданы в таблица spisok_zapchastei, spisok_ts. При удалении или изменении ключевых атрибутов соответствующие изменения происходят в дочерних таблицах (правило каскадирования). Пример триггера на изменение для таблицы spisok_zapchastei приведен в листинге 2.1.

Листинг 2.1

Триггер ссылочной целостности для таблицы klient на удаление

10 create trigger tU_spisok_zapchastei after UPDATE on spisok_zapchastei 20 referencing old as OldRecord new as NewRecord for each row 30-- ERwin Builtin Wed Apr 29 14:30:47 2009 40-- UPDATE trigger on spisok_zapchastei begin 50 declare numrows INTEGER; 60 declare parent_updrstrct_err EXCEPTION FOR SQLSTATE VALUE 'Parent Update Restrict'; 70 declare child_updrstrct_err EXCEPTION FOR SQLSTATE VALUE 'Child Update Restrict'; 80 -- ERwin Builtin Wed Apr 29 14:30:47 2009 90 -- spisok_zapchastei производятся zapchast ON PARENT UPDATE CASCADE 100 if OldRecord.pasport <> NewRecord.pasport or OldRecord.kod_detali <> NewRecord.kod_detali 110 Then update zapchast 120 set zapchast.kod_detali = NewRecord.kod_detali 130 zapchast.pasport = NewRecord.pasport, 140 zapchast.kod_detali = NewRecord.kod_detali 150 where zapchast.kod_detali = OldRecord.kod_detali 160 zapchast.pasport = OldRecord.pasport and 170 zapchast.kod_detali = OldRecord.kod_detali; 180 end if; 190 -- ERwin Builtin Wed Apr 29 14:30:47 2009 200 -- starshie_smen отвечает за производство spisok_zapchastei ON CHILD UPDATE CASCADE 210 insert into starshie_smen (pasport) 220 select passport from spisok_zapchastei where not exists (select * from starshie_smen where NewRecord.pasport = starshie_smen.pasport NewRecord.pasport = starshie_smen.pasport); 230 end

Выбор среды разработки.

Языки сравниваются между собой более чем 70 параметрам, разделенным на 8 групп (набор операторов, конструктор типов и т.п.), но рассмотрим только основные показатели [2.4].

В основном большинство языков сегодня выглядят похоже на разновидность C или Pascal, например, С++ и Java подобны C, в то время как Ada, Component Pascal и даже Visual Basic и Eiffel подобны Pascal. Lisp, Smalltalk и некоторые другие «экзотические» языки программирования составляют сравнительно небольшое меньшинство.

Языки программирования, которые поддерживают явно формулируемые интерфейсные конструкции, например, типы, объявления, называются «статическими» или «третьего поколения» языками. Примеры таких языков - Pascal, C и C++. Их главное преимущество в том, что они могут быть применены к очень большому числу очень больших задач, и они эффективны. Языки, которые избегают статических конструкций, чтобы получать предельную гибкость с наименьшими усилиями, называются «динамическими» или «четвертого поколения» языками. Динамические языки поддерживают инкрементную загрузку кода, сборку «мусора» и тесно связаны с поддержкой среды разработки. Их превосходство - в быстрой разработке маленьких частей низкотехнологичного кода, например, сценариев для сборки компонентов. Их основное достоинство - что «все проходит», то есть, в них нет жесткой системы типов, лишних секций объявлений или других подобных ограничивающих статических конструкций. Даже с самыми агрессивными технологиями оптимизации они обычно медленнее, чем статические языки. Тесная интеграция со средой означает, что их использование удобно, и что объектная модель может быть вставлена непосредственно в язык, так что взаимодействие между компонентами становится намного более легким, чем при использовании языково-независимой объектной модели.

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

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

Компонентно-ориентированные языки помогают создавать более надежные компонентные программные системы быстрее, поскольку такие языки предоставляют «компонентно-ориентированные» возможности в дополнение к ООП-возможностям (полиморфизм, позднее связывание и сокрытие информации).

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

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

Таблица 2.5

Сравниваются только самые основные языки общего назначения

Аспект	Pascal	Modula-2	C	C++	Smalltalk	Component Pascal	Java
Структурированный синтаксис	+	+	-	-	-	+	-
Простота и регулярность	+	+	-	-	+	+	- (1)
Статические объекты	+	+	+	+	-	+	-
Статические типы	+	+	+	+	-	+	+
Динамические типы	+	-	-	+	+	+	+
Эффективная трансляция	+	+	+	+	-	+	+(2)
Динамич. связывание	+	+ (3)	+(3)	+	+	+	+
Сокрытие информации	-	+ (4)	-	+(5)	+ (5)	+ (4)	+(4)
Полиморфизм	+	-	-	+	+	+	+
Наследование	+	-	-	+	+	+	+
Множ. наследование	+	-	-	+	-	-	+(6)
Полная безопас. типов	- (7)	- (7)	-(7,8)	- (9)	+	+	+
Сборка «мусора» (10)	-	-	-	-	+	+ (11)	+
Динамическая загрузка	-	-	-	-	+	+	+
Разделельный интерф./реализ.	-	-	-	-	-	- (12)	+ (6)
Отсутствие требования к доп. изучению	+	-	-	-	-	-	-
Отсутствие дублирования кода	+	+	+	+	-	-	-
Взаимодействие с традиционным оборудованием	+	+	+	+	+	-	-
Поддерживают пред- и постусловия в интерфейсе	+	+	+	+	+	-	-
Интегральная оценка	14	10	7	12	11	13	12

(1) Определение языка включает 34 класса и сотни методов; существует множество исключений из правил; возможности языка взаимоблокируются так, что невозможно объяснить одно без знания остального;

(2) Отсутствие статических типов и параметров, передаваемых по значению, накладывает ограничения на быстродействие;

(3) Процедурные типы / указатели на процедуры;

(4) Модули / пакеты;

(5) Только в отдельных классах, никакие инварианты между классами не могут гарантироваться;

(6) Интерфейсы для (множественного) наследования интерфейса; классы для (одиночного) наследования реализации;

(7) Небезопасные вариантные записи; явное освобождение памяти;

(8) Небезопасные указатели;

(9) Унаследованные небезопасные возможности C;

(10) Сборка мусора необходима для достижения полной безопасности типов;

(11) Образуется меньше мусора, чем в языках без статических типов, поэтому - более эффективен;

(12) По соглашению, наследование реализации редко используется, поэтому такое разделение не слишком важно.

Интегральная оценка языков программирования производится аддитивной сверткой. При этом «+» имеет вес равный 1, а «-» имеет вес равный 0, все критерии имеют одинаковый вес:

Из таблицы 2.5 видно, что выбранным критериям в полной мере удовлетворяет язык программирования - Pascal.

На данный момент основной визуальной средой разработки ПО, основанной на языке Pascal и имеющей мощные инструменты для работы с БД, является среда разработки Borland Delphi.

2.3 Техническое обеспечение ЭИС

Технические характеристики рабочих станций:

Процессор на базе архитектуры Х86 с тактовой частотой не менее 1000 МГц;

Объем оперативной памяти не менее 256 Мб;

Монитор должен поддерживать разрешение 1024х728;

Объем жесткого диска не менее 10 Гб;

Манипулятор мышь;

Клавиатура;

Принтер.

Программное обеспечение:

Операционная система Windows XP, Window 2000 Professional;

СУБД Sybase SQL Anywhere 5.0.

Рабочие станции должны быть объединены в локальную сеть.

2.4 Требования к безопасности ЭИС

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

Локальная вычислительная сеть, в которой функционирует система должна быть отделена от глобальной сети интернет [2.2]. Сервер БД должен находится в закрытом помещении, во избежание намеренного физического повреждения. Доступ к рабочим станциям должен осуществляться только для сотрудников предприятия. На территории предприятия должны быть предусмотрены организационные меры безопасности - пропускной режим. В связи с этим средства шифрования и помехоустойчивого кодирования в системе не предусмотрено.

Разграничение доступа и политика безопасности реализуется стандартными средствами СУБД. Права на редактирование, добавление и удаление данных из БД предоставляется только определенным сотрудникам ПЭО, остальные сотрудники обладают только правами на просмотр информации. Сотрудники ОСИТП осуществляют резервное копирование БД и ее восстановление в случае неисправности.

2.5 Расчет затрат на разработку ЭИС и определение срока окупаемости

Оценка технической эффективности ИС может проводиться, как путем проведения теоретических расчетов, так и с помощью экспериментальных исследований. Соответственно различают теоретическую и экспериментальную оценки. Так как в ходе теоретического оценивания эффективности принимается ряд упрощений, допущений и соглашений, которые на практике могут и не существовать, то экспериментальная оценка носит более объективный характер. Поэтому для оценки технической эффективности процесса учета готовой продукции на ЗАО «Транс Маш Холдинг» выбрана экспериментальная оценка.

В соответствии с заданием и результатами предпроектных исследований, наиболее значимыми свойствами программного модуля ведения и администрирования БД учета готовой продукции на ЗАО «Транс Маш Холдинг» являются быстродействие, эргономичность и ресурсоемкость.

Для оценки быстродействия в качестве частного показателя эффективности (ЧПЭФ) использовано математическое ожидание времени реализации процедуры ведения БД. Данный ЧПЭФ можно записать в следующем виде: , где tр - время реакции системы на запрос.

Исходя из теоремы Ляпунова (центральная предельная теорема) предполагается, что tр распределено по нормальному закону. Тогда математическое ожидание времени реализации процедуры ведения БД оценивается как среднее арифметическое ti:

; (2.1)

Тогда для оценки быстродействия необходимо определить: ti -- время реакции системы на i запрос, n -- количество реакций системы на запрос.

Оценка ИС по ЧПЭФ произведена по критерию оптимальности.

Для оценки эргономичности в качестве ЧПЭФ использована степень выполнения эргономических требований, рассчитываемая по формуле:

(2.2)

где

n1 - количество выполненных требований;

n2 - количество требований, применимых к рассматриваемому интерфейсу.

На основании задания, результатов предпроектных исследований, сформулированных ЧПЭФ, согласно ГОСТ РВ 29.05.007--96 «Интерфейс человеко-машинный» выработана система оперативно-технических требований (СОТТ) к программному модулю:

{

Расчет значений ЧПЭФ.

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

План проведения эксперимента. Цель: определить среднее время выполнения операции ввода данных , оценить, влияет ли тип операции на время выполнения операции ввода данных.

Выделены два типа операции, следовательно, два уровня фактора, соответствующие типам операций: Операция 1 - ввод всех данных о продукции в БД с помощью встроенной утилиты ActiveSQL, Запрос 2 - ввод всех данных продукции в БД с помощью специализированного интерфейса. Отклик -- время реализации процедуры ведения БД tр..

Допустимые значения вероятности ошибки I и II рода . Мощность эксперимента . С данной вероятностью будем утверждать, что полученное число реплик достаточно.

Определение необходимого числа реплик эксперимента. Использованы оперативные характеристики при a=2, n=20, , . .

(2.3)

Ф=7,следовательно, в ? 0,01, что гарантирует достаточную мощность эксперимента.

Искомое число достаточных реплик равно 20.

Проведено 20 наблюдений. Результаты измерения времени выполнения запросов к БД (таблица 2.6).

Таблица 2.6

Результаты измерения времени выполнения запросов к БД

Уровень фактора	Время реакции системы (сек)
	1	2	3	4	5	6	7	8	9	10
Запрос1	817	815	813	821	825	835	836	830	829	819
Запрос2	327	340	342	352	335	340	348	353	359	362
	11	12	13	14	15	16	17	18	19	20
Запрос1	832	829	819	810	815	830	840	845	838	846
Запрос2	348	340	345	341	345	349	356	329	333	344

Проверка приведенных в таблице величин на аномальность по критерию Диксона: при допустимым значением коэффициента r22 является величина 0,514. Экспериментальный коэффициент Диксона для первого уровня фактора равен 0,15, что меньше допустимого. Экспериментальный коэффициент Диксона для второго уровня фактора равен 0,27, что меньше допустимого. Это позволяет сделать вывод, что аномальные значения отсутствуют.

Проверка влияния типа операции на время выполнения операции ввода данных (по методике однофакторного дисперсионного анализа с использованием статистического критерия Фишера): гипотеза Н0 - дисперсии равны.

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

Проверка соответствия экспериментального распределения предполагаемому теоретическому, т.е. нормальному по правилу трех сигм (таблица 2.7):

Таблица 2.7

Значение для проверки правила 3

Уровень фактора					3
1	810	846	827.2	116.38	349.14	17.2	18.8
2	327	362	344.4	87.94	263.82	17.4	17.6

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

Рассчитаем математическое ожидание и отсортируем полученные результаты (таблица 2.8).

Таблица 2.8

Математическое ожидание уровней фактора

Уровень фактора	1	2
	827.2	344.4
Ранг	2	1

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

Для оценивания эргономичности использована методика, представленная в ГОСТ РВ 29.05.007--96 «Интерфейс человеко-машинный» [2.1], состоящая из трех этапов:

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

на втором этапе оценивается выполнение эргономических требований, выделенных на первом этапе. (Если в разработанном интерфейсе требование выполняется, то в графе «Выполнение» таблица 2.8 ставится буква «В» (выполнено), в противном случае -- буква «Н» (не выполнено). Выполнение проверяется только для требований, отмеченных в графе «Применение» буквой «П»);

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

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

Таблица 2.9

Исследование применимости и контроля выполнения общих эргономических требований к интерфейсу

Номер эргономического требования	Приме-нение	Выпол-нение
1 Панель должна отображаться на экране дисплея в окне и содержать следующие элементы: меню действий, появляющееся меню, инструкцию, поле выбора, поле ввода, область сообщений, область команд, область функциональных клавиш	П	В
2 Панель должна быть разделена на три области: меню действий, основную область, функциональные клавиши и иметь наименование, которое размещается вверху основной области	П	В
3 Появляющееся меню, инструкцию, поля выбора, ввода, область сообщений и область команд располагают в основной области панели	П	В
4 Инструкция должна предписывать необходимые действия с отображаемой панелью и порядок перехода в следующую панель	П	В
5 Меню действий следует располагать в верхней части экрана. Если на панели в появившемся окне отображается вторая панель, то меню действий второй панели располагают непосредственно под наименованием окна	П	В
6 Наименования объектов и функций должны быть представлены существительными, глаголами и состоять из одного или нескольких слов	П	В
7 Объекты меню необходимо располагать слева направо по мере убывания частоты их использования. Допускается группирование объектов меню по смысловому признаку. Последние две позиции меню действий должны быть отведены для объектов «Выход» и «Справка»	П	В
8 Каждому объекту меню должен быть присвоен мнемонический символ	П	В
9 Курсор выбора в меню действий должен целиком покрывать наименование объекта, включая по одному пробелу, справа и слева от объекта	О
10 Переход из основной области панели в меню действий и обратно должен осуществляться с помощью клавиши «Меню» или устройства указания	П	В
11 Появляющееся меню должно располагаться под меню действий так, чтобы первый символ его объекта, находился под первым символом соответствующего объекта меню действий	О
12 Появляющееся меню должно содержать функции «Ввод» и «Отмена», отделенные от других объектов разделительной линией	П	В
13 Появляющееся меню не должно протягиваться. Инструкцию и поля ввода в появляющемся меню не используют	П	В
14 Подтверждение выбора должно индицироваться графическим знаком, располагаемым перед выбранным объектом	О
15 Поле ввода должно располагаться в основной области панели, выделяться визуально и иметь наименование	П	В
16. При необходимости одновременного отображения нескольких полей ввода их группирование должно производиться по столбцам	П	В
17. При первом предъявлении панели поле ввода должно быть заполнено пробелами или значениями по умолчанию	П	В
18. Для информации, превышающей 25 символов, должна быть предусмотрена протяжка поля ввода	О
19. При вводе информации в поле ввода, заполненное данными, должна применяться автоочистка	П	В
20 Область сообщений должна содержать информационные или предупреждающие сообщения прикладной программы, которые не должны перекрываться вторичными или появляющимися окнами	П	В
21 Область команд должна содержать поле ввода с наименованием «Команда» и стрелкой, направленной вправо к полю ввода	О
22 Область функциональных клавиш должна содержать перечень клавиш, за которыми закреплены определенные функции прикладной программы, и наименования этих функций	П	В
23 Окна должны иметь иерархический уровень, соответствующий уровню диалога. Число уровней окон должно быть не более трех	П	В
24 Диалог при решении каждой задачи ИС должен начинаться в собственном первичном окне	П	В
25 Задержка отображения появляющегося окна должна быть не более 500 мс	П	Н
26 Размеры появляющихся окон должны быть меньше размеров экрана	П	В
27 Расположение появляющегося окна определяют двумя способами связи: относительно объекта (ниже, выше, слева, справа) и относительно предыдущего окна	П	В
28. Для выделения появляющихся окон используют цвет, рамку, теневой эффект	П	В
29 Диалог должен включать следующие унифицированные действия, имеющие одинаковый смысл во всех прикладных программах: «Отмена», «Команда», «Ввод», «Выход», «Восстановление», «Обновление», «Идентификаторы», «Клавиши», «Справка»	П	В
30 Действие «Отмена» должно возвращать диалог на один шаг назад	П	В
31 Действие «Команда» должно переводить диалог в область команд для ввода команды с клавиатуры	П	В
32 Действие «Ввод» должно завершать работу по выбору объекта из появляющегося меню или работу с панелью, содержащей поля выбора и поля ввода	П	В
33 Действие «Выход» должно обеспечивать возможность возврата на уровень старшей функции или возможность выхода из прикладной программы	П	В
34 Действие «Клавиши» должно обеспечивать выключение или включение отображения функциональных клавиш	П	Н
35 Вспомогательными функциями могут быть: «Список», «Сообщения», «Подсказка»	О
36 Функция «Сообщения» должна обеспечивать автоматическое предъявление информации от прикладной программы	П	В
37 Информационное сообщение должно указывать, что программа выполняет или завершила выполнение функции	П	В
38 Предупреждающее сообщение следует выдавать при неправильных действиях оператора и удалять после правильного их повторения	П	В
39 Критическое сообщение, информирующее об исключительном состоянии системы, должно выдаваться в появляющемся окне	О
40 При выдаче предупреждающих и критических сообщений должна быть предусмотрена звуковая сигнализация и возможность ее выключения	О
41 Элементы панели должны выделяться одним из следующих способов: цветом, уменьшенной яркостью, рамкой, инверсным цветом	П	В

Для расчета степени выполнения эргономических требований, применимых к рассматриваемому интерфейсу используется формула (2.2).

На основании данных представленных в таблице, произведено исследование применимости и контроля выполнения общих эргономических требований к интерфейсу. Количество выполненных требований - 38, количество требований, применимых к рассматриваемому интерфейсу - 41, следовательно, степень выполнения эргономических требований, применимых к рассматриваемому интерфейсу, составляет 0,93, что удовлетворяет требованиям ГОСТ [2.1], имеющих величину степени выполнения применимых эргономических требований 0,85.

Для экономического обоснования целесообразности разработки и внедрения программного модуля системы учета готовой продукции на ЗАО «Транс Маш Холдинг» необходимо оценить его экономическую эффективность, которая обычно принимается, как соотношение между экономическим эффектом и затратами ресурсов, фактически израсходованных на создание программы [2.4].

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

Проведем расчет показателей экономической эффективности создания и внедрения программного модуля системы учета готовой продукции на ЗАО «Транс Маш Холдинг».

Нормативный коэффициент экономической эффективности капиталовложений (Ен=0,5).

Расчетный коэффициент экономической эффективности капитальных затрат на разработку и внедрение программного модуля Ер представляет собой отношение расчетной годовой экономии (годового прироста прибыли) Эппг к затратам Цпп на разработку программы:

(2.4)

Срок окупаемости Тф представляет собой отношение затрат на разработку и внедрение программы Цпп к годовой экономии (годовому приросту прибыли) Эппг:

Тф= (2.5)

Формулы для расчета единовременных капитальных затрат на создание программы ЦПП приведены в приложении 4.

Формулы для расчета годового экономического эффекта ЭППГ, вызванного мероприятиями по внедрению программного комплекса приложении 2.

Расчет показателей экономической эффективности создания и внедрения программного модуля подсистемы ведения и администрирования БД учета готовой продукции на ЗАО «Транс Маш Холдинг», на основе исходных данных, приведенных в приложениях 3, 4, а также формул, приведенных в приложении 1:

затраты труда на изучение и постановку задачи:

чел/ч.

затраты труда на разработку алгоритмов решения

задачи, комплекса задач:

чел/ч.

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

чел/ч.

затраты труда на отладку программы:

чел/ч.

затраты труда на подготовку документации по программе: чел/ч.

затраты труда на создание программного продукта:

чел/ч.

- расчет часовой тарифной ставки (8-ми часовой рабочий день):

руб/ч

затраты на создание алгоритма и программы:

руб.

- амортизационные затраты:

AАВТ=СВТ*НАВТ*(tОТ+ tК)/FЭФФВТ=19500*25*(120+25)/2016*100= 350.63 руб.

- затраты на электроэнергию:

руб.

Таблица 2.10

Затраты на разработку ПП

№ п/п	Наименование элементов и статей затрат	Затраты, руб.	Удельный вес, %
1	Трудозатраты	57250.9	96
2	Амортизационные затраты	350.63	3
3	Затраты на электроэнергию	142	1
Итого:	57743,53	100

затраты на разработку и внедрение автоматизированной системы:

руб.

Так как программа приводит к уменьшению времени на выполнение процедур учета готовой продукции, то для расчета годового экономического эффекта Эппг от разработки и внедрения программы целесообразно воспользоваться следующей формулой:

, (2.6)

В ходе преддипломной практики в результате проведения эксперимента выявлено, что пользователь тратит ежедневно 8 часа при работе с системой, следовательно, ТМГ=8*21*12=2016.

коэффициент использования мощности информационной системы:

ЗПЭИС= (2.7)

, где r* - заработная плата оператора с учетом выслуги лет, денежных выплат за сложность и напряженность и премий; - численность персонала j - ой категории; n - число операторов работающих с системой каждый день.

руб.

амортизационные отчисления:

руб.

 затраты на электроэнергию:

руб.

затраты на текущий ремонт и обслуживание:

руб.

затраты на технические носители информации:

руб.

накладные расходы по эксплуатации:

руб.

стоимость одного машинного часа:

руб.

годовой экономический эффект:

В подразделе 2.5.2 были получены значения математических ожиданий, времени реализации операции ведения БД с помощью специализированного и с помощью стандартной утилиты ActiveSQL. M(x)и = 344.4 сек (0.095 часа), М(х)у = 827.2 сек (0.230 часа). Рабочих дней в году 231 (из расчета, что рабочих дней в месяце - 21 и отпуск - 30 дней). Так, как в день оператору приходится вводить/изменять информацию в среднем в 4 таблицах, в среднем по 4 раза за час (выявлено в ходе преддипломной практики), то экономию машинного времени по задаче рассчитаем по следующей формуле:

(часа)

руб.

экономическая эффективность разработанной программы:

срок окупаемости:

года

Таким образом, мероприятия по созданию и внедрению программного модуля учета готовой продукции на ЗАО «Транс Маш Холдинг» (Ер = 0.8 > Eн =0.5) окупятся в течение Тф = 1 года 3 месяцев, при этом ежегодный экономический эффект будет составлять Эппг = 229252 руб.

Оценка выполнения требований к программному модулю системы учета готовой продукции на ЗАО «Транс Маш Холдинг» представлена в таблице 2.11.

Таблица 2.11

Оценка выполнения требований к программному модулю системы учета готовой продукции на ЗАО «Транс Маш Холдинг» представлена в таблице

Свойство	Показатель	Критерий	Значение
			Требование	Фактическое
Быстродействие	Математическое ожидание времени реализации операции ведения БД			344.4 c.
Эргономичность	Степень выполнения эргономических требований	N ? 0.85	0.85	0.93
Ресурсоемкость	Годовой экономический эффект (руб.) Расчетный коэффициент эффективности капитальных вложений на разработку и внедрение программного модуля Срок окупаемости капитальных затрат на разработку и внедрение программного модуля (год)	Ер ? Ен	0.5 10 лет	44016.38 р. 0.8 1год 3 месяца

Заключение

Общие выводы по итогам исследования:

дана классификация функций подсистемы администрирования и ведения БД учета готовой продукции на ЗАО «Транс Маш Холдинг», исходя из которой, определен перечень подсистем: информационная и интерфейс пользователя;

система учета готовой продукции на ЗАО «Транс Маш Холдинг» должна выполнять основные задачи: учет информации о продукции, визуализация данных;

для проектирования выбраны CASE - средства BPWin и ERWin;

разработаны проектные решения по обеспечивающим подсистемам: разработана функциональная схема системы учета готовой продукции на ЗАО «Транс Маш Холдинг» (организационное), разработана схема логической структуры БД системы учета готовой продукции на ЗАО «Транс Маш Холдинг» (информационное), разработан перечень требований аппаратным средствам (техническое);

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

Список литературы

Верификация Estelle-спецификаций распределенных систем посредством раскрашенных сетей Петри.// Под ред. Непомнящего В.А., Шилова Н.В. - Новосибирск,1997.

Вишневский В., Ляхов А., Портной С, Шахнович И., Широкополосные сети передачи информации М.: Эко-Трендз, 2005, 592 с

Галатенко В.В., Информационная безопасность, "Открытые системы", N 6 (72), 2005

Герасименко В.А. Защита информации в автоматизированных системах обработки данных: В 2-х кн. - М.: Энергоатомиздат, 1994. - 176 с.

Григорьев В.А, Лагутенко О.И., Распаев ЮА., Сети и системы широкополосной передачи данных М.: Эко-Трендз, 2005, 384 с

Гундарь К.Ю. Защита информации в компьютерных системах - К.:»Корнейчук», 2000. К. Ю. Гундарь, А. Ю. Гундарь, Д. А. Янышевский.

Девянин П.Н. Теоретические основы компьютерной безопасности: Учебное пособие для вузов - М.: Радио и связь, 2000

Зайцев Д.А., Шмелёва Т.Р. Моделирование коммутируемой локальной сети раскрашенными сетями Петри // Зв'язок, № 2(46), 2004, с. 56-60.

Зайцев Д.А., Слепцов А.И. Уравнение состояний и эквивалентные преобразования временных сетей Петри // Кибернетика и системный анализ.- 1997, № 5, с. 59-76.

Кельтон С., Лоу Дж., Имитационное моделирование. Классика Computer Science, CПб. «Питер», 2004

Мендельсон Э., математическая логика. М,, Мир, 1992 360 стр.

Мерит Максим, Дэвид Полино, Аппаратное обеспечение широкополосных сетей передачи данных М.: Компания "АйТи"; ДМК Пресс, 2007, 288 с

Мещеряков В.А. Системы защиты информации от программно- математического воздействия в автоматизированных информационных системах критического применения // Безопасность информационных технологий Выпуск 2, 2003, МИФИ

Панасенко С. Алгоритм шифрования DES и его варианты. // Connect! Мир связи. - 2006 - №№ 3-6.

Семенов Ю.А.Алгоритмы телекоммуникационных сетей. Часть 1. Алгоритмы и протоколы каналов и сетей передачи данных БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2007

Середа С.С., Программно-аппаратные системы защиты программного обеспечения, СПб,BHV, 2002

Черней Г. А., Охрименко С. А., Ляху Ф. С. Безопасность автоматизированных информационных систем, М.: Ruxanda, 1996

1. Размещено на www.allbest.ru

...