РЕФЕРАТ
Дипломный проект.
Пояснительная записка: 25
стр., 31 рис.
БАЗА ДАННЫХ,
КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ, ЛОГИЧЕСКАЯ МОДЕЛЬ, ФИЗИЧЕСКАЯ МОДЕЛЬ, МЕТОДОЛОГИЯ, SADT, ДИАГРАММА.
В представленном дипломном проекте в соответствии с техническим заданием
разработана и реализована автоматизированное рабочее место МУП редакция газеты
«Новости»
В процессе выполнения дипломного проекта была проанализирована предметная
область, выделены основные функции.
Разработана модель функционирования системы по методологии SADT, логическая модель базы данных
системы в пакете ERWin.
В соответствие с моделью функционирования системы было реализовано программное
обеспечение АИС средствами MS Access и Borland Delphi 7.0 на основе модульной
архитектуры. Модули системы условно делятся на модуль реализации (глобальный
модуль), модули отчетов и модули форм. Интерфейс системы снабжен удобной
системой просмотра информации.
Система формирует различные виды отчетов: «Реестр оплаты объявлений»,
«Реестр по размещению объявлений», «Подсчет количества строк», «Подсчет
количества символов», «Аналитика соотношения объявлений».
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1. СИСТЕМО-ТЕХНИЧЕСКАЯ ЧАСТЬ
1.1. Общие принципы и особенности работы редакции
газеты
1.2. Постановка задачи разработки автоматизации учета
объявлений редакцией газеты
1.3. Анализ аналогичных существующих систем по учету
объявлений
1.4. Построение логической модели функционирования
системы
1.4.1. Методологии описания логики
функционирования автоматизированных систем
1.4.2. Описание логического проекта
АИС
2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ
2.1. Проектирование базы данных системы
2.1.1. Описание модели логического уровня представления данных
2.1.2. Построение отношений и их нормализация
2.2. Выбор средств реализации АИС
2.2.1. Выбор операционной системы
2.2.2. Выбор СУБД
2.2.3. Выбор среды программирования
2.3. Разработка физической модели БД
2.4. Выбор комплекса технических средств
2.4.1. Расчет необходимого объема ВЗУ
2.4.2. Расчет необходимого объема ОЗУ
2.4.3. Расчет времени реакции системы
2.5 Описание реализации программного обеспечения
2.5.1. Структура программного обеспечения АИС учета объявлений
2.5.2. Разработка интерфейса
2.6. Защита информации и обеспечение целостности
2.7. Разработка руководства пользователя и системного
администратора
2.8. Программа и методика испытаний. Контрольный пример
3. БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ
4. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ СОЗДАНИЯ АИС УЧЕТА ОБЪЯВЛЕНИЙ
РЕДАКЦИЕЙ ГАЗЕТЫ
ЗАКЛЮЧЕНИЕ
Список использованных источников
Приложение А. Диаграммы, разработанные по методологии SADT
Приложение Б. Руководство пользователя
Приложение В. Руководство системного
администратора
Приложение Г. Листинг программы
ВВЕДЕНИЕ
Современные
предприятия и фирмы представляют собой сложные организационные системы,
отдельные составляющие которых основные и оборотные фонды, трудовые и материальные
ресурсы и другие- постоянно изменяются и находятся в сложном взаимодействии
друг с другом. Функционирование предприятий и организаций различного типа в
условиях рыночной экономики поставило новые задачи по совершенствованию управленческой
деятельности на основе комплексной автоматизации управления всеми производственными
и технологическими процессами, а также трудовыми ресурсами.
Редакция
газеты «Новости» оказывает населению и организациям услуги по публикации
объявлений и изготовлении печатной продукции. Наличие системы, автоматизирующей
сбор, подготовку и обработку информации, является одним из необходимых условий,
определяющих конечный успех деятельности предприятия. В настоящее время на
предприятии используется АИС - это 1С:Предприятие «Бухгалтерский учет». Но она
затрагивает автоматизацию только бухгалтерского учёта и кадровый учёт
персонала. Было принято решение о разработки автоматизированного рабочего места
для автоматизации профессиональной деятельности предприятия. Актуальность
обусловлена широким внедрением АИС во все без исключения сферы деятельности,
как организаций, так и физических лиц.
Анализ
существующих программ показал, что они в основном нацелены на большие
редакционные издания и позволяют организовывать работу и через Интернет. Так же
они достаточно дорогостоящи. А для небольшой редакции многие функции являются
излишними. Исходя из анализа было решено разрабатывать АИС
для автоматизации учёта объявлений на предприятии, используя в качестве среды
программирования Delphi,
а базы Access.
Таким
образом целью данного дипломного проекта является разработка АРМа для
автоматизации учёта объявлений на предприятии.
1. СИСТЕМОТЕХНИЧЕСКАЯ
ЧАСТЬ
1.1 Общие принципы и особенности работы МУП редакция газеты
«Новости»
Основным
видом деятельности МУП редакция газеты «Новости» является выпуск периодического
издания средств массовой информации с размещением объявлений юридических и
физических лиц.
Одной из особенностей производственного процесса при издании газеты
объявлений является учет прохождения заявок. Расчет стоимости объявления
выполняется на основании набора базирующихся на рыночной стоимости
полиграфических услуг прайс-листов, позволяющих в зависимости от тиража,
формата, красочности и других параметров определить стоимость.
В
связи с этим, ведётся оплата услуг и учёт размещения объявлений. В настоящее
время работа с объявлениями ведётся только на бумажных носителях, отсутствуют
точные данные размещения объявлений, затруднён поиск по архиву.
Рисунок 1.1 Технологическая схема обработки документов.
1.2. Постановка задачи разработки АИС МУП редакция газеты «Новости»
для ведения оперативного учета размещения объявлений
АИС
МУП редакция газеты «Новости» для ведения оперативного учета размещения
объявлений предназначено для решения следующих задач:
·
ведение
информационных справочников:
·
ведение
оперативной информации (документы);
·
формирование
и печать отчетов.
Ведение
информационных справочников:
-
контрагенты;
-
договора;
-
номенклатура.
Ведение
оперативной информации (документы):
-
прием
объявления;
-
оплата
объявления.
Формирование
и печать следующих отчетов
-
реестр
по оплате;
-
реестр
по размещению объявлений;
-
подсчёт
количества символов;
-
подсчет
количества строк;
-
аналитика
соотношения объявлений между физическими и юридическими лицами.
1.3 Анализ аналогичных существующих систем учета объявлений
Говоря об автоматизации издания газеты, следует
остановиться на использовании современных издательских технологий (настольные
издательские системы, системы малого тиражирования, цифровой офсет, широкоформатная
печать и др.), повышающих производительность издательского процесса. Имеющиеся
средства автоматизации решают многие специфические издательские задачи.
Сотрудники редакции получают возможность больше времени уделять решению
творческих задач, а не выполнению однообразных операций, связанных с
подготовкой документов.
Одной из особенностей производственного процесса при издании газеты
объявлений является учет прохождения заявок. Расчет стоимости объявления выполняется
на основании набора базирующихся на рыночной стоимости полиграфических услуг
прайс-листов, позволяющих в зависимости от тиража, формата, красочности и
других параметров определить стоимость.
И прежде чем приступить к автоматизации системы был проведен анализ существующих
на рынке систем:
Таблица 1 – Сравнение существующих систем и системы, предлагаемой
к разработке
|
Название, фирма-разработчик, стоимость
|
Платформа,
технические средства
|
Основные функции
|
|
Advertising
Layout System (ALS) от MEI
|
Приложение
среды Windows. Она может эксплуатироваться на любых компьютерах, работающих
под управлением этой среды, начиная с версии MS Windows 2000 и выше. Возможна
работа на одном компьютере или в локальной сети.
|
Функционал
системы позволяет создать план издания с заданием различных секций, отличающихся
друг от друга физическими или производственными характеристиками; можно задать
в системе список планируемых рекламных модулей с описанием их статуса и
различных характеристик — от размера этих модулей до пожеланий заказчика
в отношении правил их размещения на полосе; могут учитываться тематика
рекламы, заполнение рекламой конкретной страницы, размещение на странице или
развороте редакционной информации и т.д.
|
|
DALiM
DiALOGUE
|
Является клиент-серверным
решением; файлы изображений хранятся на общем сервере, там же сохраняются
пользовательские данные. Система передает через Интернет минимально
необходимый объем информации, поэтому не предъявляет особенно высоких требований
к каналу связи. DiALOGUE использует уникальную технологию постоянного отображения
данных, которая гарантирует, что пользователи одновременно работают с одним и
тем же файлом в его полном разрешении.
|
Позволяет в режиме реального времени воспроизводить
через стандартный веббраузер файл изображения и сопроводительную информацию
к нему, включающую свободные примечания и пометки. Главной особенностью
DiALOGUE является возможность проводить с помощью простого интерфейса согласование
файла изображения между несколькими участниками процесса
|
Модуль «Частные
объявления»
adCAM_Advertisements
v01.0
|
Программный
комплекс выполнен на базе СУБД Microsoft SQL Server с использованием
клиент-серверной технологии, что позволяет работать в системе одновременно нескольким
пользователям с различных рабочих станций.
|
Модуль частных объявлений позволяет осуществлять прием, проверку,
учет и хранение частных объявлении, графических объявлений, фото-объявлений
автоматическую их верстку и доступ к ним через Internet
|
Как видно,
предложенные программы в основном нацелены на большие редакционные издания,
позволяют организовывать работу и через Интернет. Так же они достаточно
дорогостоящи. А для небольшой редакции многие функции являются излишними. Основываясь
на этом было решено самостоятельно разрабатывать АИС по учету объявлений.
1.4 Построение диаграмм логического моделирования
1.4.1 Методологии
описания логики функционирования автоматизированных систем
Наиболее
распространенными методологиями для построения логических моделей системы в
настоящее время являются следующие:
-
Гейна-Сарсона
(DFD);
-
Росса
(SADT);
-
Буча
(UML).
Методология
SADT представляет собой совокупность методов, правил и процедур,
предназначенных для построения функциональной модели объекта какой-либо
предметной области. Функциональная модель SADT отображает функциональную
структуру объекта, т.е. производимые им действия и связи между этими
действиями. Основные элементы этой методологии основываются на следующих
концепциях:
·
графическое
представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает
функцию в виде блока, а интерфейсы входа/выхода представляются дугами,
соответственно входящими в блок и выходящими из него. Взаимодействие блоков
друг с другом описываются посредством интерфейсных дуг, выражающих
"ограничения", которые в свою очередь определяют, когда и каким
образом функции выполняются и управляются;
·
строгость
и точность. Выполнение правил SADT требует достаточной строгости и точности, не
накладывая в то же время чрезмерных ограничений на действия аналитика. Правила
SADT включают:
·
ограничение
количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
·
связность
диаграмм (номера блоков);
·
уникальность
меток и наименований (отсутствие повторяющихся имен);
·
синтаксические
правила для графики (блоков и дуг);
·
разделение
входов и управлений (правило определения роли данных).
·
отделение
организации от функции, т.е. исключение влияния организационной структуры на
функциональную модель.
Методология
SADT может использоваться для моделирования широкого круга систем и определения
требований и функций, а затем для разработки системы, которая удовлетворяет
этим требованиям и реализует эти функции. Для уже существующих систем SADT
может быть использована для анализа функций, выполняемых системой, а также для
указания механизмов, посредством которых они осуществляются.
SADT
является простым и мощным средством моделирования, который может быть
эффективно использован для построения концептуальных, логических и графических
систем.
В
настоящем проекте использована методология SADT.
1.4.2 Описание
логического проекта АИС
Цель: автоматизация учета объявлений редакцией газеты
Уровень детализации: до уровня запроса
Точка зрения: главный редактор
А-0 «АИС учета объявлений редакцией газеты «Новости»
Это диаграмма верхнего уровня, она представляет систему в целом. Здесь
отображены все входные и выходные информационные потоки системы, а так же
потоки управления и механизмы. Блок, представляющий собой систему,
детализируется диаграммой А0.
·
Входные данные: Сведения
по справочной информации, Сведения об объявлениях, Сведения об оплате
·
Выходные данные:
Отчеты, Системные сообщения, Представление хранимых данных,
·
Управление:
Справочник пользователей, Информационные запросы
·
Механизмы:
Пользователи, Технический комплекс.
А0 «АИС учета объявлений редакцией газеты «Новости»
На данной диаграмме система разбивается на три подсистемы: «Инициализация
системы», «Ведение БД», «Формирование отчетов».
Блок «Инициализация системы» отвечает за вход в систему, разграничение
прав доступа к системе, идентификация пользователя, настройка интерфейса. Блок
детализируется диаграммой А1.
·
Управление:
Справочник пользователей, Информационные запросы
·
Механизмы:
Пользователи, Технический комплекс.
·
Выходные данные:
Разрешение работы, Системные сообщения, Представление хранимых данных о
пользователях.
2
Конструкторско-технологическая часть
2.1 Проектирование базы данных системы
2.1.1 Описание модели логического уровня представления данных
Наиболее известными моделями представления данных являются:
-
иерархическая;
-
сетевая;
-
реляционная;
-
многомерная;
-
объектно-ориентированная.
Иерархическая модель данных представляет собой иерархию в виде дерева,
предметная область которой разбивается на отдельные части, находящиеся в отношении
предшествования. Древовидная структура обязательно включает в себя корень
дерева, узлы-предки и узлы-потомки. В узлах
дерева могут находиться сущности, экземпляры сущностей, атрибуты и значения
атрибутов. Подобная иерархическая структура данных обуславливает последовательный порядок доступа к данным. К недостаткам данной
модели можно отнести следующие:
· сложность реализации связи «многие ко многим», которая
сопровождается избыточностью данных на физическом уровне, что приводит к
нежелательному и неоправданному увеличению БД.
· требование повышенной корректности
при операции удаления, поскольку удаление узла ведет к одновременному удалению всех его
узлов-потомков;
· доступ к любому узлу возможен
только через исходный, что увеличивает время отклика на запрос к БД;
· механизм поддержания целостности связей между записями
отсутствует. Недостатки иерархической модели были устранены в сетевой модели данных.
Сетевая модель данных - более общая структура данных по сравнению с
иерархической. В данной модели узлы представляют собой отдельные экземпляры
записи, являющиеся единицей доступа к БД. В данной модели узел может иметь как
несколько узлов-потомков, так и несколько узлов-предков. Основной конструкцией
сетевой модели данных является набор. Для каждого типа набора определятся
сущность-владелец и произвольное число сущностей-записей. Каждый экземпляр
набора состоит из одного экземпляра сущности-владельца
и одного или более экземпляров сущностей-записей. Ограничением является
то, что ни одна сущность-запись не может принадлежать более чем одному экземпляру
набора.
С целью преодоления указанных выше недостатков была разработана
реляционная модель данных, являющаяся наиболее распространенной в настоящее
время.
В основе реляционной модели лежит понятие «отношение», которое удобно
представить в виде двумерной таблицы. Имена столбцов таблицы представляют собой атрибуты отношения, строки -
кортежи. В отношении выделяются несколько атрибутов, которые однозначно
идентифицируют кортежи и называются
ключами. Отличительной особенностью реляционной модели от иерархической и
сетевой, является единообразное представление в базе данных - в виде
нормализованных отношений. К недостаткам данной модели можно отнести следующие:
· сложность сортировки по нескольким таблицам;
· не учитывается сложная
упорядоченность;
· не учитывается группировка по значению
индексов. Достоинства реляционной модели данных:
· удобное представление данных в виде таблиц;
· реляционная модель дает четкое представление
взаимосвязей атрибутов различных отношений;
· направленные связи в реляционной базе данных
отсутствуют.
· операции проекции и объединения позволяют получать
данные в нужной форме;
· возможность разграничения прав доступа для каждой
таблицы;
· реляционная база данных
допускает возможность расширения отношений;
· простое размещение однородных данных по сравнению с
иерархическими и сетевыми структурами.
Предметная область разрабатываемой
автоматизированной информационной системы
не имеет ярко выраженной древовидной или сетевой структуры, поэтому использование
иерархической или сетевой моделей данных не целесообразно. Постреляционная и
объектно-ориентированная модели отличаются сложностью разработки и
сопровождения. Многомерная модель представления данных рассчитана на
относительно редкое изменение данных и ориентирована на частое создание
отчетов. Реляционная модель данных имеет хорошо развитую алгебру отношений,
проста при сопровождении, легко модифицируема. Поэтому в качестве модели
представления данных на логическом уровне для разрабатываемой
автоматизированной информационной системы была выбрана реляционная модель
данных.
2.1.2 Построение отношений и их нормализация
Построение
логической модели данных предполагает определение сущности и атрибутов, а так
же, какая информация будет храниться в той или иной сущности. Между сущностями
устанавливаются связи, которые задают отношения между ними. Связи делятся на
идентифицирующие и идентифицирующие, а так же на «один к одному», «один ко многим»
и «многие ко многим». В каждой сущности выделяется один или несколько атрибутов,
однозначно идентифицирующих экземпляры сущности, которые называются первичным
ключом.
Переход к
схемам предварительных отношений осуществляется по следующим правилам:
1
Если степень бинарной связи равна 1:1 и класс принадлежности
обеих сущностей является обязательным, то требуется только одно отношение.
Первичным ключом этого отношения может быть ключ любой из двух сущностей.
2
Если степень бинарной связи равна 1:1 и класс принадлежности
одной сущности является обязательным, а другой - необязательным, то необходимо
построение двух отношений по одному на каждую сущность, при этом ключи
сущностей должны служить первичными ключами для данных отношений. Кроме того,
ключ сущности, для которого класс принадлежности является необязательным,
добавляется в качестве атрибута в отношение, выделенное для сущности с
обязательным классом принадлежности.
3
Если степень бинарной связи равна 1:1 и класс принадлежности
ни одной сущности не является обязательным, то необходимо использовать три
отношения: по одному для каждой сущности, ключи которых служат в качестве
первичных в соответствующих отношениях, и одно для связи. Среди своих атрибутов
отношение, выделяемое на связь, будет иметь по одному ключу от каждой сущности.
4
Если степень бинарной связи равна 1:n и класс
принадлежности n-связной
сущности является обязательным, то достаточным является использование двух
отношений, по одному на каждую сущность, при условии, что ключ каждой сущности
используется в качестве первичного ключа для соответствующего отношения.
Дополнительно, ключ 1-связной сущности должен быть добавлен как атрибут в отношение,
отводимое n-связной
сущности.
5
Если степень бинарной связи 1:n и класс
принадлежности n-связной сущности
является необязательным, то необходимо формирование трех отношений: по одному
для каждой сущности, причем ключ каждой сущности служит первичным ключом
соответствующего отношения, и одного отношения для связи. Связь должна иметь
среди своих атрибутов ключи от каждой сущности.
6
Если степень бинарной связи равна m:n, то для
хранения данных требуется три отношения вне зависимости от класса
принадлежности как первой, так и второй сущности.
7
Если степень связи m:n, то для
хранения данных необходимо три отношения: по одному для каждой сущности, причем
ключ каждой сущности используется в качестве первичного ключа соответствующего
отношения, и одно отношение для связи. Последнее отношение должно иметь в числе
своих атрибутов ключ сущности каждой сущности.
Учитывая
правила перехода к схеме предварительных отношений, получим:
R1(код контрагента,
наименование, полное наименование)
R2(код контрагента,
код договора, наименование, дата, срок действия)
RЗ(код рубрики,
наименование)
R4(код подрубрики,
наименование)
R5(код номенклатуры,
наименование, цена)
R6(код пользователя,
имя, пароль)
R7(номер,
дата, код контрагента, код договора, сумма)
R8(номер,
дата, код контрагента, код договора, код номенклатуры, код рубрики, код рубрики,
текст объявления, количество, сумма, дата начала выхода, дата окончания выхода)
Для
обеспечения целостности хранимых данных, отсутствия избыточности информации и
аномалий добавления, удаления и изменения необходимо провести нормализацию
полученных отношений. Нормализация - это процесс разбиения исходного отношения
на несколько отношений с целью удаления нежелательных функциональных
зависимостей между атрибутами.
Отношение
находится в первой нормальной форме (1НФ), если в нем отсутствуют повторяющиеся
записи, и каждое значение атрибута не является списком или повторяющейся
группой.
Отношение
находится во второй нормальной форме (2НФ), если оно находится в 1 НФ, и
отсутствуют частичные функциональные зависимости атрибутов, не входящих в ключ,
от ключа. В том случае, если такая зависимость существует, производится
разбиение исходного отношения на два: в первое отношение включаются часть ключа
и все зависящие от нее атрибуты, не входящие в ключ, во второе входят ключ и
оставшиеся атрибуты, не вошедшие в первое отношение.
Отношение
находится в третьей нормальной форме (ЗНФ), если оно находится во 2НФ, и
отсутствуют транзитивные зависимости атрибутов, не входящих в ключ, от ключа.
Следует
отметить, что обязательным является соответствие отношений 1НФ и 2НФ. ЗНФ
является необязательной, так как в некоторых случаях строгое соответствие
приводит к увеличению числа таблиц, времени обработки запросов и суммарного
объема места, занимаемого таблицами на диске.
Все отношения
находятся в 1НФ, так как ни одно значение атрибута не является множеством или
повторяющейся группой.
Все отношения
находятся во 2НФ, поскольку они находятся в 1НФ и в них нет атрибутов,
зависящих от части ключа.
Диаграмма
модели БД логического уровня системы представлена в приложении.
2.2
Выбор средств реализации АИС
2.2.1 Выбор
операционной системы
Наиболее известными операционными системами являются:
-
MS DOS;
-
MS Windows
95/98/Me/NT/2000/XP;
-
Unix/Linux;
-
OS/2.
Использование ОС MS DOS при создании АИС нецелесообразно по причине отсутствия
в ней развитых средств разработки интерфейса, работы с виртуальной памятью,
межпрограммного взаимодействия и т.д.
ОС Unix/Linux отличаются надежностью, защищены и имеют бесплатные версии.
С другой стороны, эти системы относительно сложны в эксплуатации и
администрировании, что и определило их сравнительно малую распространенность.
ОС OS/2 используется для работы с большими БД в таких областях, где
стабильность операционной системы важнее совместимости с существующими
прикладными программами.
ОС Windows являются наиболее распространенными среди пользователей персональных
компьютеров. Удобный, хорошо продуманный и стандартизированный пользовательский
интерфейс простой при освоении. Система управления памятью использует все
возможности современных процессоров, также имеются развитые интерфейсы межпрограммного
обмена (OLE, COM, ActiveX, ODBC и т.п.). Важным достоинством является также
совместимость версий от более ранних к более поздним. Поэтому из перечисленных
выше операционных систем в качестве платформы для разработки АИС была выбрана
ОС MS Windows ХР.
2.2.2 Выбор
СУБД
Из распространенных реляционных СУБД были рассмотрены следующие:
-
Microsoft Access
2000;
-
Microsoft Visual
FoxPro 8.0;
-
Oracle 9.0;
-
Microsoft SQL
Server 2000.
MS Access и MS Visual FoxPro реализуют файл-серверную архитектуру. Файлы
БД при этом хранятся на так называемом файл-сервере, к которому СУБД с рабочих
мест посылают запросы. Подобная архитектура отличается простотой установки и
администрирования для небольших рабочих групп. К недостаткам данного метода
организации доступа к данным относится повышенная нагрузка на сеть,
сопровождаемая замедлением работы сети в целом, при обращении к базе данных
более чем пяти пользователей.
СУБД Oracle и MS SQL Server 2000 имеют все необходимые для разрабатываемой
АИС функции и широко распространены в качестве промышленных СУБД. Но стоимость
Oracle значительно превышает стоимость MS SQL Server 2000. Следует также
отметить, что СУБД Oracle требует значительно больше ресурсов и высокую
квалификацию администратора системы.
В силу того, что рассматриваемое предприятие относится к категории «Малые
предприятия», и число пользователей системы не превысит 5 пользователей, то
была выбрана СУБД MS Access.
2.2.3 Выбор среды
программирования
В качестве возможных сред программирования были рассмотрены следующие:
-
Borland Delphi
7.0;
-
JBuilder6.0;
-
MS Visual C++6.0.
JBuilder 6.0 использует язык программирования Java, особенностью которого
является кросс-платформенность. В силу аппаратной независимости языка он не
может использовать все возможности конкретной операционной системы, что
приводит к заметному падению производительности. Поскольку
разрабатываемая АИС создавалась для работы по ОС MS Windows, то снижение
производительности ради возможности запуска системы на других платформах не
оправдано.
MS Visual C++ 6.0 является компилятором C++. Он получил широкое
распространение благодаря широким возможностям использования библиотек Windows
при создании приложений. Но в MS Visual C++ затруднено создание сложных
пользовательских интерфейсов.
Borland Delphi 7.0 предоставляет возможность разработки программ с
высокой скоростью, создания сложного пользовательского интерфейса. Программные
продукты, созданные с помощью Borland Delphi, также отличаются высокой степенью
надежности, так как в этой среде разработки присутствует система отладки,
поэтому эта среда была выбрана для разработки АИС.
Основываясь на выше изложенном, было выбрано MS Access как СУБД и Borland
Delphi 7.0, как среда программирования.
2.3 Разработка физической модели БД
При разработке физической модели базы
данных был осуществлен переход от логической схемы отношений к физической.
Результирующая модель представлена базы данных представлена в виде набора схем
данных, которые приведены в приложении. (Access)
2.4 Выбор комплекса технических средств
2.4.1 Расчет
необходимого объема ВЗУ
Расчет необходимого объема ВЗУ для клиента:
Va = Voc + Vnporp;
Vос = Vxp + Vswap + Vсвоб=160+60+60=340M6;
Vпрогр=5 Мб;
Уд=340+5=345;
Расчет необходимого объема ВЗУ для сервера:
Vд=Voc+Vsql+VБД;
Voc=Vwin2003+Vswap+Vсвоб=210+80+120=410 Мб;
Vsql=200 Мб;
VБД=N1•Vl+N2•V2+Nз•V3+... + N34•V34,
где Ni - максимальное число записей в z-той таблице, а Vi - средний
размер записи. Большой объем занимают таблицы «Контрагент». Максимальное число
записей – 20000. Среднее число записей в остальных таблицах -1000. На основании
этих данных получаем:
УБД= 20000•1024+ 1000•34•100 =23880000 Байт =24 Мб;
Уд=410+200+24=634 Мб.
2.4.2
Расчет
необходимого объема ОЗУ
Расчет необходимого ОЗУ для клиента:
Vд = Vос + Vданных
V0C=16M6;
Vпрог=N•V,
Где N - максимальное число обрабатываемых записей, а V - средний размер
одной записи. Для обработки полного списка контрагентов имеем:
V данных=20000•512 = 10Мб;
V03y= 16+6+10=32 Мб.
VO3y=16+6+10=32M6.
Расчет необходимого ОЗУ для сервера:
Vд = Vос + VSQL + Vданных
Voc=48 Мб;
VSQL=32 Мб;
VБД=N•V,
Где N - максимальное число обрабатываемых записей, а V - средний размер
одной записи. Для обработки полного списка контрагентов и их связей имеем:
V данных=20000•512 + 30000 •100= 13Мб;
V03y=48+32+13=93 Мб.
2.4.3 Расчет времени
реакции системы
Расчет времени реакции системы произведем согласно следующим формулам:
tреакции = tсчитывания + tзаполнения + tвыводов,
tзаполнения = tсоздания + tстр•Nстр + tобщ,
tсчитывания = Nобл•(tпоз + tсч. бл.) + Nопер•K/f,
Где tсоздания _ время на создание заготовки отчета в памяти компьютера,
с;
tстр - время на заполнение одной строки отчета, с;
tобщ - время на внесение в отчет общей информации, с;
tпоз - время позиционирования головок винчестера, с;
tсч. бл - время считывания блока на винчестере, с;
Nопер - количество операций, необходимых для выполнения задачи;
К - среднее количество машинных команд на одну операцию;
f - тактовая частота процессора, Гц;
Vтабл - средний объем таблицы, б;
Nтабл - объем блока физического носителя, б.
Произведем расчеты:
tсчитывания = 410•(0,006 + 0,001) + ,
tзаполнения = 0,4 + 0,001•50 + 0,03 = 0,35с,
tреакции = 12,9 + 0,35 + 0,15 = 13,4с,
Таким образом, время реакции системы не превышает 13,5 секунд.
Приложение АИС предназначено для работы на IBM-совместимых персональных компьютерах.
-
Компьютер,
используемый для разработки конфигураций:
-
Операционную
систему MS Windows 98/2000/XP/Server 2003;
-
Процессор Intel Pentium III 866 МГц и выше
-
Оперативную
память – 128 Мб (рекомендуется 512 Мб);
-
Жесткий диск (при
установке используется около 2 Мб);
-
Устройство чтения
компакт-дисков;
-
USB-порт;
-
SVGA-дисплей
2.5 Описание программного обеспечения
2.5.1 Структура
программного обеспечения АИС учета объявлений
АИС учета объявлений включает в себя средства обработки данных по
контрагентам, реализации услуг и оплате.
Программное обеспечение АИС реализовано в соответствии с моделью функционирования
системы на основе модульной архитектуры. Модули системы можно условно разделить
на модули настройки, модули отчетов, модули форм. Основным является модуль
реализации (или глобальный модуль). Через него осуществляется связь с другими
модулями системы (рисунок 2.1)
АИС построено на клиент-серверной архитектуре. Подобная структура
обеспечивает легкую масштабируемость системы, снижает требования к аппаратной
части клиентских мест и уменьшает нагрузку локальной сети. В качестве сервера
выступает MS Ассеss. Работа с пользовательским интерфейсом ведется на клиентских
местах.
2.5.2 Разработка
интерфейса
Интерфейс АИС учета объявлений разрабатывался средствами Borland Delphi
7.0. Инструменты представляемые данной средой, позволяют создать интерфейс
любой сложности за минимум времени.
Особенностью интерфейса системы является удобное представление
информации, доступ к которой организован с учетом важности и частоты использования.
Выводимая информация представляется в табличном виде. Такой подход к выводу
информации обусловлен тем, что в табличном представлении наиболее удобной
является навигация и поиск данных. Удобная навигация без особого труда
позволяет перемещаться по таблице, а так же легко переключаться между таблицами
для доступа к другой информации. Простота модификации информации в диалоговом
режиме с использованием справочных данных позволяет избавить пользователя от
ошибок и сократить время, затрачиваемое на ввод часто повторяющейся информации.
При неккоректных действиях, производимых в системе, пользователь будет оповещен
соответствующим сообщением об ошибке.
Приложение реализовано по модальному принципу. Главная форма содержит элементы
управления и отображения данных. Основа управления – главное меню программы (вверху).
Из главной формы доступны все основные, представляющие визуальные средства для
работы с данными.
Меню главной формы изображено на рисунке 2.1.
Посредством главного меню программы можно выполнить все основные
действия, предусмотренные в АИС. Каждый пункт организован в соответствии с
важностью и частотой использования данных. Для ускорения доступа к документам,
некоторые из них вынесены на отдельную панель.
Рисунок 2.1. Меню главной
формы.
Пункт главного меню «Справочники» предоставляет доступ ко всем справочным
данным для просмотра и модификации информации.
Рисунок 2.2 Пункт главного меню «Справочники».
Пункт меню «Документы» позволяет осуществить ввод нового документа.
Рисунок 2.3 Пункт главного меню «Документы»
Для получения итоговой, а так же другой сводной или детальной информации
используются отчеты. Меню «Отчёты» представлено списком отчётов.
Рисунок 2.4 Пункт меню «Отчеты»
Форма авторизации появляется при загрузке АИС. Посредством этой формы осуществляются
авторизация и смена пользователя.
Рисунок 2.5 Авторизация пользователя.
Система способна формировать различные виды отчетов: «Реестр оплаты объявлений», «Реестр
по размещению объявлений», «Подсчет количества строк», «Подсчет количества
символов», «Аналитика соотношения объявлений».
2.5 Защита информации и обеспечение целостности
Обеспечение целостности БД - необходимое условие успешного функционирования БД. Целостность БД - свойство
БД, означающее, что база данных содержит полную и непротиворечивую
информацию, необходимую для корректного функционирования приложений. Для
обеспечения целостности БД накладывают
ограничения целостности в виде некоторых условий, которым должны
удовлетворять хранимые в базе данные. Примером таких условий может служить
ограничение диапазонов возможных значений
атрибутов объектов, сведения о которых хранятся в БД, контроль уникальности
ключей.
Большинство ограничений задано MS Access при разработки БД. Его встроенные средства позволяют
накладывать правила проверки на поля таблиц. Контроль уникальности ключей и индексов производится
системой автоматически.
Безопасность БД - это возможность БД обеспечивать защиту данных от
преднамеренного доступа.
Основными методами обеспечения безопасности БД являются разграничение
прав доступа и аутентификация пользователей при входе в систему. Эти методы
реализованы средствами Borland Delphi 7.0.
Назначение прав усложняется при большом количестве пользователей.
Подобная задача разрешается путем возможности объединения пользователей в
группы, для которых назначаются общие права.
Безопасность БД - это также и возможность сохранения данных от непредвиденных
ситуаций. Уменьшение риска связанного с потерей данных достигается регулярным резервным
копированием на другой носитель ( другой
логический диск, флэш-карта, оптический диск и т.п.). Архивирование базы данных
производится в каталог с программой.
2.6 Разработка руководства пользователя
Предполагается, что специалист должен быть знаком с операционной системой
компьютера, на котором работает АИС (Microsoft Windows
98, MS Windows NT, MS Windows 2000, MS Windows XP) и владеет базовыми навыками работы в ней
Руководство разработано в соответствии с ГОСТом.
Руководство пользователя представлено в приложении Б, а руководство
системного администратора в приложении В.
4 ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ СОЗДАНИЯ АИС УЧЕТА ОБЪЯВЛЕНИЙ
4.1 Краткое описание разрабатываемой подсистемы
АИС предназначена для автоматизации работы по учетприема и полаты
населению. Основными функциями АИС являются хранение информации о контрагентах,
договорах и номенклатуре, автоматизации приема объявлений.
АИС разрабатывается по техническому заданию главного редактора МУП
редакция газеты «Новости».
Для расчета целесообразности разработки подсистемы требуется найти
значение следующих величин:
·
затраты на
разработку;
·
минимальная цена
разработки.
4.2 Оценка трудоемкости и длительности разработки
Для определения трудоемкости и продолжительности разработки подсистемы используем
метод эксперсс-оценки, за единицу нормирования которого принято число исходных
команд программного продукта.
Трудоемкость разработки
(t) определяется по формуле, чел.-мес.:
t = 3,6 (nт.и.к.)1,2
, где nт.и.к. — число тысяч исходных команд.
Продолжительность разработки
программного продукта (T) рассчитывается по формуле,
мес.:
T = 2,5 · t 0,32
По предварительным оценкам исходный
текст разрабатываемой подсистемы должен содержать 1,5 тысячи машинных команд.
Исходя из этого получаем:
t = 3,6*1,5 1,2 = 5,9
T = 2,5 · t 0,32 = 4,4
Среднее число
исполнителей (чи) рассчитывается исходя из определенных или
заданных характеристик трудоемкости и длительности разработки
программного изделия по формуле, чел.:
чи = t / T
Подставив полученные значения,
получим:
чи = 5,9 / 4,4 = 1
Для определения времени,
затрачиваемого непосредственно на программирование, воспользуемся формулой:
, где tк — трудоемкость написания одной
команды (примерно 0,2 человеко-часа).
Таким образом, для написания
программы требуется около пяти месяцев, из них непосредственно на
программирование отводится 2 месяца.
4.3 Планирование процесса разработки
Анализируя исходные данные, приходим к выводу, что для планирования процесса
создания подсистемы можно ограничиться построением линейного графика работ, так
как перечень работ включает менее 10 наименований. План разработки подсистемы
представлен в таблице 4.1
Таблица 4.1 – Сводная таблица планирования работ.
|
Наименование работ
|
Трудоемкость (чел.-дн.)
|
Продолжительность (дней)
|
|
Разработка
проекта АИС
|
50
|
25
|
|
Разработка
модели БД
|
30
|
15
|
|
Разработка
алгоритмов функционирования подсистемы
|
30
|
15
|
|
Реализация
|
30
|
15
|
|
Тестирование
и отладка
|
30
|
15
|
|
Оформление
документации
|
40
|
20
|
|
Внедрение
|
40
|
20
|
4.4 Расчет затрат на разработку
Был произведен укрупненный
расчет затрат на разработку АС по формуле:
Кп
= Фз/п [(1+bд)(1+bс)+bн+bпр]+tЭВМ См-ч ,
где Фз/п —
фонд основной заработной платы разработчиков и других исполнителей работ,
р.;
bд=0,10— коэффициент дополнительной зарплаты, можно
принимать;
bс — коэффициент отчислений на социальные нужды от
основной и дополнительной заработной платы, равен 0,26;
bн=0,6 — коэффициент накладных расходов организации, разрабатывающей
проект, можно принимать;
bпр=0,1 — коэффициент прочих
расходов, принимать;
tЭВМ —
машинное время, затраченное для отладки программного обеспечения АС,
ч.;
См-ч —
стоимость машино-часа работы ЭВМ, р.
Укрупненный расчет
фонда основной заработной платы исполнителей работ по разработке АС
производится по формуле:
Фз/п
= = (8000/22) * 100 = 36363,64
где — суммарная трудоемкость работ по
разработке АС, чел.ч. (чел.-дн.), расчет проводится, используя данные о
трудоемкости работ ( по таблице);
С — тарифная
ставка часовая (дневная) разработчиков и других исполнителей работ, р.
Себестоимость
машино-часа работы ПК или КСА определяется по формуле:
См-ч
= ,
Годовые амортизационные отчисления
по КСА считаются по формуле:
где СКСА —
стоимость ПК и прочего оборудования, входящего в КСА, используемого
при отладке АС;
На — норма
амортизации, (25% ).
Затраты на электроэнергию в год
Зэ определяются следующим образом:
Зэ = Wу · Cэ
· Tв = 0,22 * 2,61 * 1760 = 1010,59
(Тэвм = 8*(365-119) - 52*4 = 1760
часа)
где Wу — установленная
мощность, кВт;
Сэ — стоимость
силовой электроэнергии, р / кВт;
Тв — время, в
течение года, когда КСА потребляет электроэнергию, ч.
Зр = 20000 *
9% = 1800
Зм = 20000 *
10% = 2000
Годовой фонд времени Фд
устанавливается, исходя из номинального фонда времени и времени
профилактики оборудования и ремонтов:
Фд = S · h · D - Tпр
= 8 * 1 * (365-119) – 52 * 4 = 1760
где S — продолжительность смены,
ч.;
h — количество смен;
D — число рабочих дней в
году, дн.;
Tпр — время
ремонтов и профилактики оборудования в год, ч.
См-ч =
Кп = 36363,64*(1,1 + 1,26
+ 0,6 + 0,1) + 400*5,6 = 113512,74
4.5 Определение единовременных затрат на внедрение
Единовременные затраты
на внедрение АС включают затраты на разработку проекта, капитальные затраты
на комплекс технических средств (КТС), а также расходы на установку
КТС, его монтаж и наладку. Следует отметить, что при расчете
эффективности конкретной АС величина капитальных затрат Кi
определяется пропорционально доле времени использования средств
автоматизации в данной АС di . Это
объясняется тем, что один и тот же комплекс средств автоматизации
может использоваться в работе нескольких АС. Поэтому единовременные
затраты на внедрение i-й системы Кi определяются по формуле:
Кi = Зiпр
+ КИ · di ,
где Зiпр
—все предпроизводственные затраты;
КИ — величина
инвестиционных (капитальных) затрат;
di — коэффициент участия КСА.
Величина инвестиционных
(капитальных) затрат определяется по формуле:
КИ = ККТС + Км
+ Кинв + Кзд + Кос + Ктр + Ксоп
- Квыс = 10*25000 + 0 + 0 + 0 + 0 + 0 + 10*6000 - (31 * 7500) = 77550
где ККТС — сметная
стоимость КТС, р.;
Км , Кинв
, Кзд — затраты на установку, монтаж и запуск КТС в
работу, на производственный инвентарь, на строительство и реконструкцию
зданий для размещения КТС, р.;
Кос — сумма
оборотных средств, р.;
Ктр —
транспортно-заготовительные расходы, р.;
Ксоп —
сметная стоимость системы стандартного обеспечения применения КТС, р.;
Квыс —
сумма высвобожденных средств в результате ввода в действие КСА, р.
Примем значение di = 0.3 , так как комплекс средств
автоматизации используется не для одной системы.
Таким образом, единовременные затраты
на внедрение АИС в рублях составят:
К = 20000 + 77550*0.3 =
43265 руб.
4.6 Расчет текущих затрат на функционирование
Для расчета текущих
затрат воспользуемся первым методом, который предполагает определение
текущих затрат, посредством основных составляющих:
Зтек = ЗКСА + Ззп
,
где ЗКСА — годовые
текущие затраты на эксплуатацию КСА, р./год;
Ззп —
годовые затраты на заработную плату специалистов в условиях функционирования
АС с начислениями, р./год. Для функционирования АИС требуется администратор
1С с коэффициентом загрузки 0,3 и окладом в 15000 руб.
Затраты ЗКСА
определяются по формуле:
ЗКСА = ЗКТС · di + Зсоп = 10000*0.3 + 5000 =8000
где ЗКТС —
годовые затраты на эксплуатацию КТС без учета заработной платы
персонала, 10000 р./год;
Зсоп —
годовые затраты на поддержание и актуализацию системы обеспечения
применения КТС (хранение, обновление, контроль данных, программ и
другие операции), р./год;
Зтек = ЗКСА + Ззп = 8000 + (15000* 12 *
1,26)*0,3 = 76040 рублей.
4.7 Расчет экономических результатов от внедрения
Для оценки
экономических результатов от внедрения АС необходимо выявить ее
влияние на конечные результаты деятельности предприятия.
Годовая экономия от внедрения АС
Эг определяется по формуле:
Эг = Эi - Зтек ,
где m — количество
статей затрат, по которым может быть получена экономия;
Эi — экономия по
i-й статье затрат, т.р.;
Зтек — затраты
на функционирование АС.
Годовая экономия получена
по следующим статьям:
На заработной плате (с учетом
отчислений на социальные нужды):
— ИТР;
На материалах и сырье:
— на материалах для документов;
От сокращения:
непроизводительных
расходов.
Экономия на сокращении численности
составляет:
Э1 = 12*7000*1,26 = 105840
Экономия на уменьшении количества
используемых материалов для документов:
Э2 = = (500-250)*0.44*12+(50-10)*10*12=6120
Тогда годовая экономия от внедрения
составит:
Эг = 105840 + 6120 – 76040
=35920 рубдей.
4.8 Расчет экономической эффективности разработки
Для оценки эффективности
затрат на создание АС воспользуемся методом расчета чистой
дисконтированной стоимости (дохода). Этот метод предполагает, что
предприятие заранее задает минимально допустимую ставку процента, при
которой инвестиционные затраты (капитальные вложения) могут считаться
эффективными. Такая ставка процента называется расчетной ставкой
процента (“субъективная” ставка процента фирмы).
Базисом для
установления расчетной ставки может быть ставка процента на заемный
капитал, по который предприятие должно выплачивать кредитору проценты.
Если процентная ставка не учитывает инфляцию, то ее называют
номинальной ставкой процента in . Реальная ставка процента ir
учитывает уровень инфляции In .
Реальная ставка процента ir
рассчитывается по формуле Фишера:
ir = (in
– In) / (1 + In) = (0,24-0,08)/(1+0,08) = 0,15 (15%)
где – ir, in, In
заданы в десятичных дробях. Номинальная
ставка процента обычно принимается равной банковской ставке процента на заемный
капитал, который предприятие должно выплачивать кредитору (24%). Текущий
уровень инфляции – 8%.
Чистая дисконтированная
стоимость (доход) — это суммарный эффект за период функционирования
инвестиций (капиталовложений) с учетом приведения всех результатов и
затрат к начальному году (дисконтирование с помощью расчетной ставки
процента). Чистая дисконтированная стоимость (доход или интегральный
эффект) ЭI рассчитывается по формуле:
ЭI = Эjг · dj - Kj · dj ,
где Т — период функционирования
проекта, г.;
Kj —
инвестиционные затраты в j-м году, т.р.;
Эjг —
экономический результат (экономия, прибыль и амортизация) в j-м году,
т.р.;
dj —
коэффициент дисконтирования для года j. Коэффициент дисконтирования dj можно рассчитать по формуле:
dj = .
Чистая дисконтированная стоимость
равна:
ЭI = Эiг · di -K.
Расчет чистой дисконтированной
стоимости представлен в таблице 4.2.
Таблица 4.2 – Расчет чистой
дисконтированной стоимости.
|
Год
|
Инвестиционные затраты, т.р.
|
Дополнительная прибыль и амортизация, т.р.
|
Ряд платежей и поступлений, т.р.
|
Расчетная процентная ставка, %
|
|
Коэффициент дисконтиров.
|
Текущая дисконтир. стоимость, т.р.
|
|
2008
|
43265
|
|
-43265
|
|
-43265
|
|
2009
|
|
35920
|
35920
|
0,8621
|
30966,63
|
|
2010
|
|
35920
|
35920
|
0,7562
|
27162,70
|
|
Всего
|
43265
|
71840
|
28575
|
|
14864,33
|
Инвестиции в проект
считаются эффективными, если интегральный эффект ЭI — неотрицательное
число,( ЭI ³ 0). Интегральный эффект положителен (+14864,33), поэтому затраты на
внедрение можно считать эффективными. Средний срок окупаемости 1,5 года,
поэтому вложения можно считать эффективными.
Следует отметить, что
помимо чисто экономического эффекта, подсистема меняет процесс работы как
руководящего состава, так и рядового персонала. При этом у руководства
появляются новые возможности анализа взаиморасчетов, что в свою очередь позволяет
принимать более обоснованные решения. Для операторов дополнительный эффект заключается
в автоматизации рутинной работы, при этом деятельность оператора принимает
более творческий характер.
ЗАКЛЮЧЕНИЕ
В представленном дипломном проекте в соответствии с техническим заданием
разработана и реализована автоматизированное рабочее место учета объявлений в
МУП редакция газеты «Новости»
В процессе выполнения курсового проекта была проанализирована предметная
область участка работы, выделены основные функции.
Разработана модель функционирования системы по методологии SADT, логическая модель базы данных
системы в пакете ERWin.
В соответствие с моделью функционирования системы было реализовано программное
обеспечение АИС средствами MS Access и Borland Delphi 7.0 на основе модульной
архитектуры. Модули системы условно делятся на модуль реализации модули отчетов
и модули форм. Интерфейс системы снабжен удобной системой просмотра информации.
Система формирует различные виды отчетов: «Реестр оплаты объявлений»,
«Реестр по размещению объявлений», «Подсчет количества строк», «Подсчет
количества символов», «Аналитика соотношения объявлений».
СПИСОК
ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1.
Преддипломная
практика и дипломное проектирование по специальности «Автоматизированные
системы обработки информации и управления»: Методические указания / Сост.
Дерябкин В.П., Орищенко В.И. Самара, Самарский го. аэроксосм. ун-т. 1995. - 20
с.
2.
СТП СГАУ
6.1.4-97. Общие требования к оформлению учебных текстовых документов:
Методические указания. - Самара, Самарский гос. аэрокосм, ун-т, 1997, - 16 с.
3.
Информационная
технология. Комплекс стандартов и руководящих документов на автоматизированные
системы: (Сборник): ГОСТ 34.003-90, РД 50-680-88, РД 50-682-89, ГОСТ 34.201-89,
ГОСТ 34.602.89. М.: Изд-во стандартов, 1992. - 150 с.
4.
CASE-средства проектирования баз данных:
учебное пособие / Составитель: Чигарина Е.И. - Самара, Самарский гос. аэрокосм,
ун-т, 2001.-34 с.
5.
Райордан Р.
Основы реляционных баз/Пер. с англ. - 2е изд., испр. - М: Издательско-торговый
дом «Русская редакция», 2001. - 384 стр.: ил.
6.
Фролов А.В.,
Фролов Г.В. Базы данных в интернете: практическое руководство по созданию Web-приложений с
базами данных. - Изд. 2е, испр. - М: Издательско-торговый дом «Русская редакция», 2000. - 448 стр.:
ил.
7.
Технико-экономическое
обоснование создания автоматизированных систем и программных продуктов.
Методические указания / Составитель: Куренкова В.П. - Самара, Самарский гос.
аэрокосм, ун-т, 1996.-30 с.
8.
«О порядке
ведения кассовых операций в Российской федерации» (утвержденным Решением Совета
Директоров Центрального Банка России 22.09.1993 г. N 40);
9.
Вендров А.М.
Проектирование программного обеспечения экономических информационных систем.
– М.: Финансы и статистика, 2000;
Приложение
А
Диаграммы,
разработанные по методологии SADT
ФЕДЕРАЛЬНОЕ
АГЕНТСТВО ПО ОБРАЗОВАНИЮ
ГОСУДАРСТВЕННОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО
ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ
УНИВЕРСИТЕТ
имени акад. С.П.КОРОЛЕВА» (СГАУ)
УТВЕРЖДЕНО
А.В.00001-01 33 01-1-ЛУ
|
Подп. и дата
|
|
|
Инв. № дубл
|
|
|
Взам. инв. №
|
|
|
Подп. и дата
|
|
|
Инв. № подл.
|
|
АВТОМАТИЗИРОВАННОЕ
РАБОЧЕЕ МЕСТО УЧЕТА
ОБЪЯВЛЕНИЙ МУП РЕДАКЦИЯ ГАЗЕТЫ
«НОВОСТИ»
Руководство программиста
А.В.00001-01 33 01-1
Листов
2008
Предполагается, что специалист должен быть знаком с операционной системой
компьютера, на котором работает АИС (Microsoft Windows
98, MS Windows NT, MS Windows 2000, MS Windows XP) и владеет базовыми навыками работы в ней
Приложение АИС предназначено для работы на IBM-совместимых персональных компьютерах.
-
Компьютер,
используемый для разработки конфигураций:
-
Операционную
систему MS Windows 98/2000/XP/Server 2003;
-
Процессор Intel Pentium III 866 МГц и выше
-
Оперативную
память – 128 Мб (рекомендуется 512 Мб);
-
Жесткий диск (при
установке используется около 2 Мб);
-
Устройство чтения
компакт-дисков;
-
USB-порт;
-
SVGA-дисплей
Для нормальной работы программы в настройках экрана должна быть выбрана
16-битная (или выше) цветовая палитра с минимальным разрешением 800 на 600.
Для работы с программой, нужно скопировать файл базы данных и приложение
на компьютер в любую папку, которая будет доступна пользователям сети.
На компьютерах пользователей необходимо создать ярлык для запуска АРМа.
Войти в программу под пользователем «Администратор» и в справочнике «Пользователи»
указать имя и/или пароль для пользователей.
Заполнить справочник «Номенклатура».
Программа готова к работе.
Листинг
программы
unit main_form;
interface
uses
Windows, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,
Dialogs, Menus, DB, ADODB, ComCtrls, ToolWin;
type
TForm1 = class(TForm)
MainMenu1: TMainMenu;
N1: TMenuItem;
N2: TMenuItem;
N3: TMenuItem;
N4: TMenuItem;
N5: TMenuItem;
ADOConnection1: TADOConnection;
N6: TMenuItem;
ToolBar1: TToolBar;
ToolButton1: TToolButton;
ToolButton2: TToolButton;
ToolButton3: TToolButton;
ToolButton4: TToolButton;
ToolButton5: TToolButton;
ToolButton6: TToolButton;
ToolButton7: TToolButton;
ToolButton8: TToolButton;
ToolButton9: TToolButton;
N7: TMenuItem;
N8: TMenuItem;
N9: TMenuItem;
N10: TMenuItem;
StatusBar1: TStatusBar;
N11: TMenuItem;
Gjkmpjdfntkb1: TMenuItem;
N12: TMenuItem;
N13: TMenuItem;
N14: TMenuItem;
N15: TMenuItem;
N16: TMenuItem;
N17: TMenuItem;
N18: TMenuItem;
N19: TMenuItem;
N20: TMenuItem;
N21: TMenuItem;
N22: TMenuItem;
N23: TMenuItem;
ADOQuery1: TADOQuery;
N24: TMenuItem;
N25: TMenuItem;
N26: TMenuItem;
N27: TMenuItem;
procedure N2Click(Sender: TObject);
procedure N6Click(Sender: TObject);
procedure ToolButton1Click(Sender: TObject);
procedure N7Click(Sender: TObject);
procedure ToolButton5Click(Sender: TObject);
procedure N10Click(Sender: TObject);
procedure ToolButton3Click(Sender: TObject);
procedure FormCreate(Sender: TObject);
procedure N12Click(Sender: TObject);
procedure ToolButton7Click(Sender: TObject);
procedure N14Click(Sender: TObject);
procedure ToolButton9Click(Sender: TObject);
procedure N25Click(Sender: TObject);
procedure N27Click(Sender: TObject);
procedure N21Click(Sender: TObject);
procedure N19Click(Sender: TObject);
procedure N15Click(Sender: TObject);
procedure N17Click(Sender: TObject);
procedure N23Click(Sender: TObject);
procedure Gjkmpjdfntkb1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
uses frm_kont, frm_ceny, frm_dgvr, vhod_frm, frm_objava,
frm_oplata,
frm_genera, analitik, user_frm;
{$R *.dfm}
procedure TForm1.N2Click(Sender: TObject);
begin
Application.Terminate;
end;
procedure TForm1.N6Click(Sender: TObject);
begin
if not Assigned(kontr)then
kontr:=Tkontr.Create(self);
kontr.Show;
end;
procedure TForm1.ToolButton1Click(Sender: TObject);
begin
N6Click(nil);
end;
procedure TForm1.N7Click(Sender: TObject);
begin
if not Assigned(ceny)then
ceny:=Tceny.Create(self);
ceny.Show;
end;
procedure TForm1.ToolButton5Click(Sender: TObject);
begin
N7Click(nil);
end;
procedure TForm1.N10Click(Sender: TObject);
begin
if not Assigned(dogv)then
dogv:=Tdogv.Create(self);
dogv.Show;
end;
procedure TForm1.ToolButton3Click(Sender: TObject);
begin
N10Click(nil);
end;
procedure TForm1.FormCreate(Sender: TObject);
var put,cs:string;
begin
put:=ExtractFileDir(GetModuleName(GetModuleHandle('gazeta.exe')))+'\uchet_db.mdb;';
cs:='Provider=Microsoft.Jet.OLEDB.4.0;User ID=Admin;Data
Source='+put+
'Mode=Share Deny None;Extended
Properties="";Jet OLEDB:System database="";'+
'Jet OLEDB:Registry Path="";Jet OLEDB:Database
Password="";'+
'Jet OLEDB:Engine Type=5;Jet OLEDB:Database Locking
Mode=1;'+
'Jet OLEDB:Global Partial Bulk Ops=2;Jet OLEDB:Global
Bulk Transactions=1;'+
'Jet OLEDB:New Database Password="";Jet
OLEDB:Create System Database=False;'+
'Jet OLEDB:Encrypt Database=False;'+
'Jet OLEDB:Don''t Copy Locale on Compact=False;Jet
OLEDB:Compact Without Replica Repair=False;'+
'Jet OLEDB:SFP=False;';
ADOConnection1.ConnectionString:=cs;
ADOConnection1.Connected:=true;
parol_show:=Tparol_show.Create(self);
if parol_show.ShowModal = mrOk then begin
ADOQuery1.Parameters.ParamByName('F').Value:=parol_show.ComboBox1.Text;
ADOQuery1.Open;
if
ADOQuery1.FieldByName('PAROL').Value<>parol_show.Edit1.Text then
begin
ShowMessage('Вы ввели неправильный пароль');
Application.Terminate;
end;
end else begin
ShowMessage('Вы не ввели пароль');
Application.Terminate;
end;
if (parol_show.ComboBox1.Text='Оператор') then begin
N14.Enabled:=false;
N7.Enabled:=false;
Gjkmpjdfntkb1.Enabled:=false;
end;
if (parol_show.ComboBox1.Text='Кассир') then begin
N12.Enabled:=false;
N7.Enabled:=false;
N6.Enabled:=false;
Gjkmpjdfntkb1.Enabled:=false;
end;
end;
procedure TForm1.N12Click(Sender: TObject);
begin
if not Assigned(objavl)then
objavl:=Tobjavl.Create(self);
objavl.Height:=350;
objavl.Width:=850;
objavl.Show;
end;
procedure TForm1.ToolButton7Click(Sender: TObject);
begin
N12Click(nil);
end;
procedure TForm1.N14Click(Sender: TObject);
begin
if not Assigned(oplata)then
oplata:=Toplata.Create(self);
oplata.Show;
end;
procedure TForm1.ToolButton9Click(Sender: TObject);
begin
N14Click(self);
end;
procedure TForm1.N25Click(Sender: TObject);
var
SI: TStartupInfo;
PI: TProcessInformation;
begin
FillChar(SI, SizeOf(SI), 0);
SI.cb := SizeOf(SI);
DeleteFile('backup\arhiv.pak');
CreateProcess(nil,'compress.exe uchet_db.mdb backup\arhiv.pak',nil,nil,false,CREATE_NO_WINDOW,nil,nil,si,pi);
end;
procedure TForm1.N27Click(Sender: TObject);
var
SI: TStartupInfo;
PI: TProcessInformation;
begin
ADOConnection1.Connected:=false;
FillChar(SI, SizeOf(SI), 0);
SI.cb := SizeOf(SI);
DeleteFile('uchet_db.mdb');
CreateProcess(nil,'expand.exe backup\arhiv.pak
uchet_db.mdb',nil,nil,false,CREATE_NO_WINDOW,nil,nil,si,pi);
Sleep(3000);
ADOConnection1.Connected:=true;
end;
procedure TForm1.N21Click(Sender: TObject);
begin
generator:=Tgenerator.Create(self);
generator.Tag:=4;
generator.ShowModal;
end;
procedure TForm1.N19Click(Sender: TObject);
begin
generator:=Tgenerator.Create(self);
generator.Tag:=3;
generator.ShowModal;
end;
procedure TForm1.N15Click(Sender: TObject);
begin
generator:=Tgenerator.Create(self);
generator.Tag:=1;
generator.ShowModal;
end;
procedure TForm1.N17Click(Sender: TObject);
begin
generator:=Tgenerator.Create(self);
generator.Tag:=2;
generator.ShowModal;
end;
procedure TForm1.N23Click(Sender: TObject);
begin
analitika:=Tanalitika.Create(self);
analitika.ShowModal;
end;
procedure TForm1.Gjkmpjdfntkb1Click(Sender: TObject);
begin
if not Assigned(user)then
user:=Tuser.Create(self);
user.ADOTable1.Active:=true;
user.Width:=350;
user.Height:=125;
user.Show;
end;
end.