close

Вход

Забыли?

вход по аккаунту

?

Министерство высшего и

код для вставкиСкачать
Министерство образования Российской Федерации
ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Факультет информатики
Кафедра прикладной информатики
Допустить к защите в ГАК
зав. кафедрой прикладной
информатики, проф., д.т.н.
_____________ С.П. Сущенко
"____" ____________ 2003 г.
Козгов Алексей Михайлович
ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ СИСТЕМЫ
АВТОМАТИЗАЦИИ ДЕЯТЕЛЬНОСТИ ИНФОРМАЦИОННОЙ
СЛУЖБЫ КОМПАНИИ
Дипломная работа
Научный руководитель
Ст. преподаватель
А.М. Бабанов
Исполнитель
студент группы 1482
А.М. Козгов
Электронная версия дипломной работы помещена
в электронную библиотеку. Файл
Администратор
Томск – 2003
РЕФЕРАТ
Объем: 60 страниц, 10 иллюстраций, 4 источника, 5 приложений
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ, SADT, ER-МОДЕЛЬ, БАЗА ДАННЫХ,
УЧЕТ
ОСНОВНЫХ
СРЕДСТВ,
УЧЕТ
ЗАЯВОК
НА
ОБСЛУЖИВАНИЕ,
АВТОМАТИЗАЦИЯ
Объект исследования: бизнес – процессы деятельности ИТ службы компании.
Цель работы: исследовать бизнес – процессы, описать их с помощью SADT, начать
реализацию автоматизированной системы в части учета основных средств и материалов, а
также учета заявок на обслуживание.
Результаты: построена SADT – модель, реализована система автоматизации учета основных средств и материалов, а также учета заявок на обслуживание.
Область применения: в информационном отделе предприятия.
Прогноз о развитии и внедрении: внедрение первой очереди на одном из предприятий
Томска, с дальнейшим развитием функциональности.
2
ОГЛАВЛЕНИЕ
Реферат ............................................................................................................................................... 2
ОГЛАВЛЕНИЕ .................................................................................................................................. 3
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, УСЛОВНЫХ ОБОЗНАЧЕНИЙ, ЕДИНИЦ, СИМВОЛОВ И
ТЕРМИНОВ ....................................................................................................................................... 4
ВВЕДЕНИЕ ........................................................................................................................................ 5
1. Анализ бизнес – процессов ........................................................................................................ 6
1.1. Учет основных средств и материалов ................................................................................... 6
1.2. Учет заявок на обслуживание в части ИТ сервиса .............................................................. 7
1.3. Ведение договоров .................................................................................................................. 8
1.4. Формирование бюджета ......................................................................................................... 9
1.5. Ведение корпоративных проектов......................................................................................... 9
1.6. Резюме .................................................................................................................................... 10
2. Формализация бизнес – процессов ......................................................................................... 11
2.1. SADT ................................................................................................................................... 11
2.1.1. Блоки ................................................................................................................................ 12
2.1.2. Дуги .................................................................................................................................. 13
2.1.3. Синтаксис SADT-моделей ............................................................................................. 16
2.1.3.1. Система представляется одним блоком.................................................................. 16
2.1.3.2 Идентификация декомпозиции номерами узлов .................................................... 17
2.1.3.3. Коды ICOM гарантируют стыковку диаграмм ...................................................... 17
2.1.3.4. Обозначения для менее распространенных интерфейсов по дугам .................... 19
2.1.4. Процесс моделирования................................................................................................. 20
2.2. SADT – модель функционирования Информационной Службы ..................................... 23
3. Информационное моделирование системы .............................................................................. 26
3.1. Множество Сущностей......................................................................................................... 27
3.2. Множество Связей ................................................................................................................ 27
3.3. ER - диаграмма ...................................................................................................................... 28
4. Реализация системы .................................................................................................................... 30
4.1. Преобразование ER-модели в реляционную модель......................................................... 30
4.2. Paradox 7................................................................................................................................. 31
4.3. Borland Delphi – среда реализации клиентской части автоматизированной системы 32
4.4. Развитие системы ............................................................................................................... 33
Заключение....................................................................................................................................... 35
Список использованных источников............................................................................................. 36
Приложение 1. SADT - модель....................................................................................................... 37
Приложение 2. Руководство программиста .................................................................................. 51
П2.1. Установка системы............................................................................................................. 51
П2.2. Изменение кода системы ................................................................................................... 51
Приложение 3. Руководство пользователя ................................................................................... 53
Приложение 4. Список файлов ...................................................................................................... 57
Приложение 5. Список файлов в электронной версии дипломной работы ............................... 59
Приложение 6. Акт приема – передачи в промышленную эксплуатацию ................................ 60
3
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ, УСЛОВНЫХ ОБОЗНАЧЕНИЙ,
ЕДИНИЦ, СИМВОЛОВ И ТЕРМИНОВ
АСУ –
Автоматизированные Системы Управления
ИТ
–
Информационные Технологии
ПО
–
Программное Обеспечение
SADT –
Structured Analysis & Design Technique
ОС
–
Основные Средства
КП
–
Корпоративный Проект
БД
-
База Данных
4
ВВЕДЕНИЕ
В современном мире основным средством поддержки бизнеса, как системы, являются
Информационные Технологии (ИТ). ИТ сопровождают целые отделы. Ранее они назывались
отделами АСУ.
Сейчас обязанности отделов гораздо шире, чем было раньше, но количество людей,
работающих в них, значительно меньше. Некоторые компании, в целях более качественного
получения ИТ сервиса, пошли по пути упразднения своих отделов, во всех подразделениях, а
функции отдела вывели на обслуживающую организацию.
Вместо отдела остается один сотрудник, так называемый специалист по ИТ, который
отвечает за организацию всего ИТ - сервиса. Если предприятие является частью компании,
то помимо основных обязанностей специалист по ИТ отвечает за ведение корпоративных
проектов (КП) по ИТ, а также формирует большое количество отчетной информации для
компании.
В таких условиях, без средств автоматизации, не обойтись. Но прежде чем начать автоматизацию необходимо выяснить предметную область, формально описать ее, выделить
критические задачи и в первую очередь их автоматизировать.
Таким образом, ставится задача автоматизации деятельности информационной службы компании. Данная задача разбивается на этапы, а именно выявление бизнес – процессов
протекающих на предприятии в части ИТ, формальное описание выявленных процессов, определение первой очереди процессов для начальной реализации, создание автоматизированной системы. Этому и посвящена данная работа.
5
1. АНАЛИЗ БИЗНЕС – ПРОЦЕССОВ
Исходя из поставленной задачи об автоматизации деятельности информационной
службы компании, выделяем первым этапом описание предметной области. Для получения
описания первым шагом был проведен анализ по выявлению бизнес – процессов протекающих в этой службе. Выявлено пять основных процессов:
1. Учет основных средств и материалов ИТ - службы
2. Учет заявок на обслуживание ИТ
3. Ведение договоров по ИТ
4. Формирование бюджета ИТ - службы
5. Ведение корпоративных проектов по ИТ
1.1. УЧЕТ ОСНОВНЫХ СРЕДСТВ И МАТЕРИАЛОВ
Основным инструментом ИТ является компьютер. Компьютер, с точки зрения бухгалтерского учета, является основным средством (ОС), а его составные части - материалами.
Для эффективной работы на компьютере существует множество периферийных устройств
(принтер, сканер, модем и т.д.), которые также являются основными средствами. Кроме этого, ОС является также и программное обеспечение (ПО).
На среднем предприятии основных средств большое количество, в связи с этим необходимо организовать их учет не только по бухгалтерии, но и по ИТ - службе. С точки зрения
этой службы ОС имеют описание, состояние, местонахождение, обслуживание, пользователя. Так же важно учитывать динамику средств в процессе работы – их модернизацию, перемещение, списание.
Поступление основных средств и материалов также является нетривиальной задачей.
Для приобретения ОС необходимо сделать следующие действия:
-
заключить договор поставки ОС
-
получить ОС
-
оприходовать по бухгалтерии ОС
-
разместить на рабочем месте сотрудника ОС
Весь жизненный цикл ОС можно представить следующим образом:
-
Поступление
o Провести конкурс среди поставщиков ОС и выбрать одного или несколько
o Заключить договор с поставщиком ОС
ƒ
Проект договора
6
ƒ
Согласование со всеми службами предприятия
ƒ
Подписание
o Оплатить ОС, согласно договора
o Получить ОС
o Получить бухгалтерские документы
o Закрыть договора поставки
-
Постановка на учет
o Поставить на баланс предприятия
o Присвоить инвентарный номер
o Разместить на складе
o Приклеить инвентарный номер
-
Распределение
o Определить рабочие места, подлежащие замене ОС
o Определить новые места
o Распределить ОС, освободившиеся при замене
-
Обслуживание
o Провести ремонт ОС
o Провести модернизацию ОС
o Провести замену ОС
-
Списание
Определенные этапы жизненного цикла ОС, должны отражаться в бухгалтерском учете предприятия, для этого необходимо формировать соответствующие документы, отвечающие требованиям и правилам ведения бухучета.
Сразу становится очевидным необходимость в автоматизации данного бизнес–
процесса. При этом нужно продумать организацию учета по ИТ в части описания ОС и их
состояния в любой момент времени. Кроме этого есть еще набор документов, которые необходимо формировать при прохождении жизненного цикла ОС, а именно документы на вынос
ОС за пределы организации, например на ремонт. Без системы автоматизированного учета,
что вы ответите на вопрос проверяющего: «Где находится принтер с №30000002345?»?
1.2. УЧЕТ ЗАЯВОК НА ОБСЛУЖИВАНИЕ В ЧАСТИ ИТ СЕРВИСА
Работая с техническими и аппаратными средствами, пользователи постоянно сталкиваются с проблемами. Так появляется понятие заявки на решение возникшей проблемы. Теперь возникает вопрос о том, кто должен исполнять данную заявку и в какие сроки, также
7
необходимо проконтролировать качество исполнения и время. Но кроме этого появляется
еще один естественный вопрос: а насколько существенна данная проблема, и как она решается, и вообще, не является ли эта проблема чисто пользовательской, и не относится ли к
компетентности сотрудника. Для ответа на поставленные вопросы без автоматизированной
системы учета необходимо было бы обработать большое количество документов.
Этапы данного бизнес – процесса выглядят следующим образом:
-
Регистрация заявки
-
Определение исполнителя
-
Передача заявки исполнителю
-
Исполнение заявки
-
Мониторинг проблем:
o возникновение
o решение
1.3. ВЕДЕНИЕ ДОГОВОРОВ
Согласно нормативным актам, регламентирующим правила ведения бизнеса, все выплаты и все, что связано с перечислением денежных средств со счетов организации, попадающее в затратную часть бухучета, необходимо проводить только согласно договорам. Таким образом, возникает необходимость в организации процесса заключения договора, оплаты и контроля исполнения его условий. Контроль необходим не только за исполнением условий договора, но и за процессом заключения договора, а так же оплаты.
Заключение договора имеет следующие этапы:
-
Проведение конкурса по выбору контрагента
-
Разработка проекта договора
-
Согласование проекта договора со всеми службами предприятия
-
Устранение замечаний
-
Подписание
Оплата договора:
-
Выставление счета контрагентом
-
Подписание счета службой по ИТ
-
Подписание счета финансовой службой
-
Подписание счета директором
-
Оплата счета через банк
8
При прохождении всех этапов организация, как система, может давать сбои, поэтому
необходимо проводить постоянный контроль состояния системы.
1.4. ФОРМИРОВАНИЕ БЮДЖЕТА
Организация является частью компании. Согласно регламентам ведения бизнеса все
денежные средства, которые идут на удовлетворение потребностей организации, формируются через бюджет. Его надо планировать, утверждать, получать и исполнять. У ИТ – службы есть свой бюджет, который является частью всего бюджета организации. Бюджет ИТ –
службы также необходимо планировать и исполнять. Период планирования имеет разные
рамки, 5 лет, 1 год, квартал, месяц.
ИТ бюджет формируется на основе:
-
Неизменной части заключенных договоров
-
Неизменной части планируемых договоров
-
Переменной части всех договоров
-
Разовых затрат
До конца месяца необходимо реализовать весь бюджет. При реализации бюджета может возникнуть три состояния:
-
Бюджет не выполнен
-
Бюджет исполнен
-
Бюджет перевыполнен
Приемлемо только состояние точного исполнения бюджета. В случае невыполнения бюджета необходимо перераспределить переменную часть договоров, либо допустить разовую затрату. А если бюджет перевыполнен, то часть платежей идет как корректировка бюджета на
следующий период.
1.5. ВЕДЕНИЕ КОРПОРАТИВНЫХ ПРОЕКТОВ
Когда предприятие является частью компании, то неизбежно происходит процесс
внедрения каких-то решений разработанных компанией и рассчитанных на автоматизацию
процессов протекающих в рамках всей компании.
Корпоративный проект (КП) протекает следующим образом:
-
Бизнес – план проекта
-
Договора проекта
-
Бюджет проекта
9
-
Реализация проекта
-
Закрытие проекта
Основные этапы КП пересекаются с другими бизнес – процессами службы ИТ.
Само понятие КП накладывает определенную ответственность на реализацию КП. Поэтому
функция контроля, за состоянием КП, очень важна для службы ИТ. А данную потребность
реализовать без автоматизированной системы очень сложно. Кроме этого, в один момент
времени, может протекать сразу несколько КП, которые находятся в разном состоянии.
1.6. РЕЗЮМЕ
Из приведенного анализа видно, что не имея системы автоматизации быстро и адекватно реагировать на возникающие потребности предприятия очень сложно. Кроме этого
компания постоянно запрашивает большое количество разрозненной информации, для сбора
которой приходится затрачивать очень много времени. Из всего этого следует, что система
автоматизации необходима.
10
2. ФОРМАЛИЗАЦИЯ БИЗНЕС – ПРОЦЕССОВ
Одним из средств формализации бизнес – процессов является SADT. SADT (аббревиатура выражения Structured Analysis and Design Technique - методология структурного
анализа и проектирования) - это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности.[1]
Данное средство позволяет однозначно описать бизнес – процессы, при этом языком
понятным как разработчику, так и заказчику. При этом SADT – модели отражают не только
сами бизнес – процессы, но и их взаимодействие как внутри себя, так и между собой, учитывая, что идет на вход, что получается на выходе, какой механизм действует и какое управление происходит.
2.1.
SADT
Основные элементы SADT – диаграмм схематично изображены на рис. 2.1.1.
Вход при наличии управления преобразуется в выход с помощью "механизма" (исполнителя).
Рис. 2.1.1. Основные элементы SADT - диаграмм
Выходы одного блока могут быть входами или управлениями (или исполнителями)
для других блоков. (Блоки именуются, а дуги помечаются с использованием естественного
языка.) Дуги могут разветвляться и соединяться, а каждый блок может быть подвергнут декомпозиции, т. е. разделен как целое на свои составляющие на более детальной диаграмме.
Входы, управления и выходы определяют интерфейсы между блоками, а исполнители позволяют при необходимости в определенной степени объединять объекты. Границы блоков и
диаграмм должны быть согласованы, а возникающая иерархическая, взаимосвязанная сово-
11
купность диаграмм является моделью. Благодаря объяснению термина "декомпозиции" каждая грамматическая форма имеет свое строго определенное значение. [1]
Описание системы с помощью SADT называется моделью. В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной
системе источником естественного языка служат люди, описывающие систему, а источником
графического языка - сама методология SADT.
Модель SADT можно представить в виде древовидной структуры диаграмм, где верхняя диаграмма является наиболее общей, а самые нижние наиболее детализированы.
SADT-модель - это описание системы, у которого есть единственный субъект, цель и
одна точка зрения. Целью служит набор вопросов, на которые должна ответить модель. Точка зрения - позиция, с которой описывается система. Цель и точка зрения - это основополагающие понятия SADT.
Описание модели SADT организовано в виде иерархии взаимосвязанных диаграмм.
Вершина этой древовидной структуры представляет собой самое общее описание системы, а
ее основание состоит из наиболее детализированных описаний.
Диаграмма является основным рабочим элементом при создании модели. Разработчик
диаграмм и моделей обычно называется аналитиком, или, в терминологии SADT, автором.
Диаграммы имеют собственные синтаксические правила, отличающиеся от синтаксических
правил моделей. Графика SADT позволяет определить различные системные функции и показать, как функции влияют друг на друга.
Каждая SADT-диаграмма содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними. Диаграмме дается название, которое располагается в центре нижней части ее бланка. На каждой диаграмме написана стандартно идентифицирующая ее информация: автор диаграммы, частью какого проекта является работа, дата создания или последнего
пересмотра диаграммы, статус диаграммы. Вся идентифицирующая информация располагается в верхней части бланка диаграммы.
2.1.1. Блоки
Функциональные блоки на диаграммах изображаются прямоугольниками. Блок представляет функцию или активную часть системы, поэтому названиями блоков служат глаголы
или глагольные обороты.
Кроме того, SADT требует, чтобы в диаграмме было не менее двух и не более шести
блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном
12
для чтения, понимания и использования. Другими словами, SADT-диаграммы и SADTмодели наглядны.
В отличие от других графических методов структурного анализа в SADT каждая сторона блока имеет особое, вполне определенное назначение. Левая сторона блока предназначена для входов, верхняя - для управления, правая - для выходов, нижняя - для механизмов.
Такое обозначение отражает определенные системные принципы: входы преобразуются в
выходы, управление ограничивает или предписывает условия выполнения преобразований,
механизмы показывают, кто, что и как выполняет функция.
Блоки SADT никогда не размещаются на диаграмме случайным образом. Они размещаются по степени важности, как ее понимает автор диаграммы. В SADT этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое
один блок оказывает на другие блоки диаграммы.
Расположение блоков на странице отражает авторское определение доминирования.
Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, SADT-аналитик может перенумеровать блоки в
соответствии с порядком их доминирования. Порядок доминирования может обозначаться
цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на
наибольшее доминирование, 2 - на следующее после наибольшего, и т.д.
Блоки в SADT должны быть перенумерованы. Номера блоков служат однозначными
идентификаторами для системных функций и автоматически организуют эти функции в иерархию модели. Используя номера блоков и оценивая влияние, которое один блок оказывает
на другой; аналитик может организовать модель по принципу функционального доминирования. Это позволяет согласовать иерархический порядок функций в модели с уровнем влияния каждой функции на остальную часть системы.
2.1.2. Дуги
Дуги на SADT-диаграмме изображаются одинарными линиями со стрелками на концах. Для функциональных SADT-диаграмм дуга представляет множество объектов.
Так как в SADT дуги изображают объекты, они описываются (помечаются) существительными или существительными с определениями, располагающимися достаточно близко к
линии дуги.
Между объектами и функциями возможны четыре отношения: вход, управление, выход, механизм. Каждое из этих отношений изображается дугой, связанной с определенной
стороной блока. По соглашению левая сторона блока предназначена для входных дуг, верх13
няя сторона - для управленческих дуг, правая сторона - для выходных дуг, нижняя сторона для дуг механизмов. Таким образом, стороны блока чисто графически сортируют объекты,
изображаемые касающимися блока дугами.
Входные дуги изображают объекты, используемые и преобразуемые функциями.
Управленческие дуги представляют информацию, управляющую действиями функций.
Обычно управляющие дуги несут информацию, которая указывает, что должна выполнять
функция. Выходные дуги изображают объекты, в которые преобразуются входы. Дуги механизмов отражают, по крайней мере частично, как функции (т.е. функции системы) реализуются.
Итак, SADT-диаграмма составлена из блоков, связанных дугами, которые определяют, как блоки влияют Друг на друга. Это влияние может выражаться либо в передаче выходной информации к другой функции для дальнейшего преобразования, либо в выработке
управляющей информации, предписывающей, что именно должна выполнять другая функция.
Таким образом, SADT-диаграммы не являются ни блок-схемами, ни просто диаграммами потоков данных. Это предписывающие диаграммы, представляющие входныевыходные преобразования и указывающие правила этих преобразований. Дуги на них изображают интерфейсы между функциями системы, а также между системой и ее окружающей
средой.
В методологии SADT требуется только пять типов взаимосвязей между блоками для
описания их отношений: управление, вход, обратная связь по управлению, обратная связь по
входу, выход-механизм. Связи по управлению и входу являются простейшими, поскольку
они отражают прямые воздействия, которые интуитивно понятны и очень просты. Отношение управления возникает тогда, когда выход одного блока непосредственно влияет на блок
с меньшим доминированием. Отношение входа возникает тогда, когда выход одного блока
становится входом для блока с меньшим доминированием.
Обратная связь по управлению и обратная связь по входу являются более сложными,
поскольку они представляют итерацию или рекурсию. А именно выходы из одной функции
влияют на будущее выполнение других функций, что впоследствии влияет на исходную
функцию. Обратная связь по управлению возникает тогда, когда выход некоторого блока
влияет на блок с большим доминированием. Связь по входной обратной связи имеет место
тогда, когда выход одного блока становится входом другого блока с большим доминированием.
14
Связи "выход-механизм" встречаются нечасто и представляют особый интерес. Они
отражают ситуацию, при которой выход одной функции становится средством достижения
цели для другой.
Дуга в SADT редко изображает один объект. Обычно она символизирует набор объектов. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными сложными способами. Вся дуга или ее часть может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках. Для объяснения того, как дуги представляют разъединение и соединение наборов объектов, в SADT были
разработаны специальные соглашения относительно представления и описания разветвлений
и соединений дуг.
Разветвления дуг, изображаемые в виде расходящихся линий, означают, что все содержимое дуг или его часть может появиться в каждом ответвлении дуги. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь дуги
может быть помечена или не помечена в соответствии со следующими правилами:
-
непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением (т.е. все объекты принадлежат этим ветвям);
-
ветви, помеченные после точки разветвления, содержат все объекты или их
часть, указанные в метке дуги перед разветвлением (т.е. каждая метка ветви
уточняет, что именно содержит ветвь).
Слияние дуг в SADT, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом
слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания
нового набора объектов, возникшего после объединения. Кроме того, каждая ветвь перед
слиянием может помечаться или не помечаться в соответствии со следующими правилами:
-
непомеченные ветви содержат все объекты, указанные в общей метке дуги после слияния (т.е. все объекты исходят из всех ветвей);
-
помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния (т.е. метка ветви ясно указывает,
что содержит ветвь).
Одна SADT-диаграмма сложна сама по себе, поскольку она содержит от трех до шести блоков, связанных множеством дуг. Для адекватного описания системы требуется несколько таких диаграмм. Диаграммы, собранные и связанные вместе, становятся SADTмоде-лью. В SADT дополнительно к правилам синтаксиса диаграмм существуют правила
синтаксиса моделей.
15
2.1.3. Синтаксис SADT-моделей
Синтаксис SADT-моделей позволяет аналитику определить границу модели, связать
диаграммы в одно целое и обеспечить точное согласование между диаграммами. Никакой
другой метод структурного анализа не позволяет так точно, как SADT, соединять диаграммы
в тщательно организованные комплекты, называемые моделями.
2.1.3.1. Система представляется одним блоком
SADT-модель является иерархически организованной совокупностью диаграмм. Диаграммы обычно состоят из двух-шести блоков, каждый из которых потенциально может
быть детализирован на другой диаграмме. Каждый блок может пониматься как отдельный
тщательно определенный объект. Разделение такого объекта на его структурные части (блоки и дуги, составляющие диаграмму) называется декомпозицией.
Декомпозиция формирует границы, и каждый блок в SADT рассматривается как формальная граница некоторой части целой системы, которая описывается. Другими словами,
блок и касающиеся его дуги определяют точную границу диаграммы, представляющей декомпозицию этого блока. Эта диаграмма, называемая диаграммой с потомком, описывает
все, связанное с этим блоком и его дугами, и не описывает ничего вне этой границы. Декомпозируемый блок называется родительским блоком, а содержащая его диаграмма - соответственно родительской диаграммой. Таким образом, SADT-диаграмма является декомпозицией некоторого ограниченного объекта.
Принцип ограничения объекта встречается на каждом уровне. Один блок и несколько
дуг на самом верхнем уровне используются для определения границы всей системы. Этот
блок описывает общую функцию, выполняемую системой. Дуги, касающиеся этого блока,
описывают главные управления, входы, выходы и механизмы этой системы. Диаграмма, состоящая из одного блока и его дуг, определяет границу системы и называется контекстной
диаграммой модели. Таким образом, этот блок изображает границу системы: все, лежащее
внутри него, является частью описываемой системы, а все, лежащее вне него, образует среду
системы.
16
2.1.3.2 Идентификация декомпозиции номерами узлов
SADT-модели развиваются в процессе структурной декомпозиции сверху вниз. Сначала декомпозируется один блок, являющийся границей модели, на одной диаграмме, которая имеет от двух до шести блоков, затем декомпозируется один (или больше) из этих блоков
на другой диаграмме с двумя-шестью блоками и т.д. Название диаграммы совпадает с названием декомпозируемого блока. Результатом этого процесса является модель, диаграмма
верхнего уровня которой описывает систему в общих терминах "черного ящика", а диаграммы нижнего уровня описывают очень детализированные аспекты и операции системы.[3]
Таким образом, каждая диаграмма представляет собой некоторую законченную часть
всей модели. В методологии SADT идентифицируется каждая диаграмма данной модели посредством того, что называется "номер узла". Номер узла для контекстной диаграммы имеет
следующий вид: название модели или аббревиатура, косая черта, заглавная буква A (Activity
в функциональных диаграммах), дефис и ноль.
С-номера применяются для связки диаграмм при движении как вверх, так и вниз по
иерархии модели. Обычно С-номер диаграммы, декомпозирующей некоторый блок, впервые
появляется непосредственно под этим блоком на родительской диаграмме. Это образует "направленную вниз" связь от родительской диаграммы к диаграмме-потомку.
Как только образуется направленная вниз связь, на диаграмме-потомке формируется
ссылка на родительскую диаграмму. В области контекста SADT-бланка (правый верхний
угол) автор изображает каждый блок родительской диаграммы маленькими квадратиками,
заштриховывает квадратик декомпозируемого блока и размещает С-номер родительской
диаграммы возле заштрихованного квадратика. Это образует "направленную вверх" (к родительской диаграмме) связь. Метод соединения диаграмм посредством однозначно определенных номеров гарантирует, что именно нужная версия диаграммы станет частью модели.
Другими словами, при использовании С-номеров осуществляется тщательный контроль за
введением новых диаграмм в иерархию модели.
2.1.3.3. Коды ICOM гарантируют стыковку диаграмм
Хорошая методология структурного анализа, позволяющая создавать отдельные диаграммы, должна гарантировать правильное соединение всех диаграмм для образования согласованной модели. SADT-диаграммы имеют внешние дуги -дуги, как бы выходящие наружу и ведущие к краю страницы. Эти дуги являются интерфейсом между диаграммой и остальной частью модели. SADT требует, чтобы все внешние дуги диаграммы были согласова17
ны с дугами, образующими границу этой диаграммы. Другими словами, диаграмма должна
быть "состыкована" со своей родительской диаграммой. Обычно это означает, что внешние
дуги согласованы по числу и наименованию (но не обязательно по расположению) с дугами,
касающимися декомпозированного блока родительской диаграммы.
В SADT принята система обозначений, позволяющая аналитику точно идентифицировать и проверять связи по дугам между диаграммами. Эта схема кодирования дуг -"ICOM" получила название по первым буквам английских эквивалентов слов вход (Input), управление
(Control), выход (Output), механизм (Mechanism). Коды ICOM чрезвычайно эффективны, поскольку они позволяют аналитику быстро проверять согласованность внешних дуг диаграммы с граничными дугами соответствующего блока родительской диаграммы. Они также
обеспечивают согласованность декомпозиции, поскольку все дуги, входящие в диаграмму и
выходящие из нее, должны быть учтены.
Если вы начинаете строить диаграмму следующего уровня, то дуги, касающиеся декомпозируемого блока, используются в качестве источников и приемников для дуг, которые
вы создаете на новой диаграмме. После завершения диаграммы ее внешние дуги стыкуются с
родительской диаграммой для обеспечения согласованности. Одним из способов такой стыковки может служить присваивание кодов ICOM внешним дугам новой диаграммы согласно
следующим правилам:
-
представьте себе рисунок новой диаграммы внутри разлагаемого блока. Продлите внешние дуги почти до края диаграммы. Зрительно соедините каждую
внешнюю дугу диаграммы с соответствующей граничной дугой декомпозируемого блока.
-
присвойте код каждой зрительной связи. Используйте I для входных дуг, С для связей между дугами управления, О - для связей между выходными дугами, М - для связей между дугами механизма.
-
добавьте после каждой буквы цифру, соответствующую положению данной
дуги среди других дуг того же типа, касающихся родительского блока. Причем
входные и выходные дуги пересчитываются сверху вниз, а дуги управлений и
механизмов пересчитываются слева направо. Теперь запишите каждый код
около окончания каждой внешней дуги.
При следовании схеме кодирования ICOM создается совокупность неявных связующих звеньев между страницами, которые можно быстро изменить при изменении границ.
Эти неявные межстраничные связующие звенья облегчают процесс чтения и рецензирования
SADT-диаграмм, а также проверку, насколько согласованно произведена декомпозиция. Коды ICOM упрощают также работу, связанную с внесением вручную локальных изменений в
18
диаграмму, и объединяют различные варианты диаграмм так, что они хорошо стыкуются в
модели. Коды ICOM являются одним из наиболее важных вкладов SADT в технологию графического моделирования. Они обеспечивают требуемую строгость, позволяя в то же время
авторам работать независимо, чертить разборчиво и выбирать без ущерба для предыдущей
работы подходящую терминологию на последующих уровнях детализации.[3]
2.1.3.4. Обозначения для менее распространенных интерфейсов по дугам
Номера узлов, С-номера и коды ICOM управляют подавляющим большинством ситуаций внутренних связей в модели. Однако между родительскими диаграммами и диаграммами-потомками могут возникать некоторые специфические ситуации, в которых разумное
использование синтаксиса модели улучшает описание модели, а именно: (1) при разветвлении и соединении внешних дуг; (2) при изменении входных дуг на управляющие и наоборот;
(3) когда дуги "входят в тоннель". Однако необходимо учесть, что такие средства изображения следует использовать только в особых ситуациях для прояснения и упрощения описания
системы. Их следует применять для удобства, а не как прикрытие плохого анализа систем.
Во всех этих случаях данные при пересечении границ диаграмм сохраняются, т. е. все входные данные некоторым образом используются для образования всех выходных данных.
Ключом для понимания таких ситуаций является то, что дуги SADT изображают иерархические наборы.
Одна из особых ситуаций заключается в разветвлении или соединении внешних дуг
между диаграммами. Например, две внешние выходные дуги на диаграмме могут быть частями общей выходной дуги на границе блока. Это может произойти, если аналитик вместо
того, чтобы обычным способом соединить их на диаграмме, оставляет это соединение неявным. Узнать об этом непоказанном соединении или разветвлении можно только, заметив, что
коды ICOM для двух разных дуг совпадают.
Особая ситуация возникает также тогда, когда входная дуга превращается в дугу
управления и наоборот. Это происходит, если дуга управления (или входная), касающаяся
границы блока, используется при декомпозиции диаграммы как входная (или соответственно
управленческая) дуга.
Две другие особые ситуации возникают, когда дуги "входят в тоннель" между диаграммами. Дуга "входит в тоннель", либо (1) если она является внешней дугой, которая отсутствует на родительской диаграмме (имеет скрытый источник), либо (2) если она касается
блока, но не появляется на диаграмме, которая его декомпозирует (имеет скрытый приемник). Тоннельные дуги от скрытого источника начинаются скобками, чтобы указать, что эти
19
дуги идут из какой-то другой части модели или прямо извне модели. Тоннельные дуги,
имеющие скрытый приемник, кончаются скобками, чтобы отразить тот факт, что такая дуга
идет к какой-то другой части модели или выходит из нее или что она не будет более в этой
модели рассматриваться.
2.1.4. Процесс моделирования
В значительной мере успех методологии SADT объясняется ее графическим языком,
хотя не менее ценным является сам процесс моделирования. Процесс моделирования в SADT
включает сбор информации об исследуемой области, документирование полученной информации и представление ее в виде модели и уточнение модели посредством итеративного рецензирования. Кроме того, этот процесс подсказывает вполне определенный путь выполнения согласованной и достоверной структурной декомпозиции, что является ключевым моментом в квалифицированном анализе системы. SADT уникальна в своей способности обеспечить как графический язык, так и процесс создания непротиворечивой и полезной системы
описаний.[3]
SADT является методологией в полном смысле, потому что она объединяет итеративный процесс создания модели, нотации, управляющие конфигурацией модели, язык ссылок
для диаграмм, язык функций моделей с графическим языком описания системы, а также рекомендации по реализации аналитических проектов. Нотации, управляющие конфигурацией,
гарантируют, что новые диаграммы будут корректно встроены в иерархическую структуру
модели. Язык ссылок в SADT, правила сокращений для ссылок, адресованных к отдельным
частям диаграммы, облегчают оформление замечаний при рецензировании модели. Язык
функций позволяет декларативно определять правила работы системы, что часто является
особенно важным завершающим шагом в описании системы.
На рис. 2.1.4.1. изображен процесс моделирования в SADT, описанный с помощью
SADT-диаграммы. Диаграмма отражает тот факт, что процесс моделирования в SADT является итеративной последовательностью шагов, приводящих к точному описанию системы.
Высокая эффективность этого процесса обусловлена его организацией, в основе которой лежит разделение функций, выполняемых участниками создания SADT-проектов: эксперты
являются источниками информации, авторы создают диаграммы и модели, библиотекарь координирует обмен письменной информацией, читатели рецензируют и утверждают модели, а
Комитет технического контроля принимает и утверждает модель.
20
Рис. 2.1.4.1. «Процесс моделирования»
В процессе моделирования сведения об изучаемой системе получают с помощью испытанной методики сбора информации - опросов или интервью. Для получения наиболее
полной информации SADT предлагает использовать различные ее источники (например, читать документы, опрашивать людей, наблюдать за работой системы). Независимо от конкретного источника информации методология SADT рекомендует руководствоваться определенной целью при его использовании. Это означает, что необходимо определить свои потребности в информации прежде, чем выбрать очередной источник. Во время опроса графический язык SADT используется как средство для заметок, которые служат основой для построения диаграмм.
Создание модели (блок 2 на рис. 2.1.4.1.) - это второй важный этап в процессе моделирования, на котором аналитик документирует полученные им знания о данной проблемной
области, представляя их в виде одной или нескольких SADT-диаграмм. Процесс создания
модели осуществляется с помощью специального метода детализации ограниченного субъекта. Коротко говоря, в SADT автор вначале анализирует объекты, входящие в систему, а затем использует полученные знания для анализа функций системы. На основе этого анализа
создается диаграмма, в которой объединяются сходные объекты и функции. Этот конкретный путь проведения анализа системы и документирования его результатов является уникальной особенностью методологии SADT.
21
Моделирование в SADT - инженерная дисциплина. Это означает, что модели создаются, исходя из действительной ситуации, и что эти модели проходят через серию последовательных улучшений до тех пор, пока они в точности не будут представлять реальный мир.
Одной из основных компонент методологии SADT является итеративное рецензирование, в
процессе которого автор и эксперт многократно совещаются (устно и письменно) относительно достоверности создаваемой модели. Итеративное рецензирование называется циклом
автор/читатель.
Цикл автор/читатель начинается в тот момент, когда автор принимает решение распространить информацию о какой-либо части своей работы с целью получения отзыва о ней.
Материал для распространения оформляется в виде "папок" - небольших пакетов с результатами работы, которые критически обсуждаются другими специалистами в течение определенного времени. Сделанные письменные замечания также помещаются в папку в виде нумерованных комментариев. Папки с замечаниями являются, таким образом, обратной связью, которую авторы получают на свою работу. Читатели - это те, кто читает и критикует
создаваемую модель (см. блок 4 на рис. 2.1.4.1.), а затем помещает замечания в папки. Их работа возможна благодаря тому, что графический язык SADT-диаграмм позволяет создавать
диаграммы и модели, которые можно легко и быстро читать. (Простота графического языка
потому не случайна. Она позволяет получить представление о системе, на основе которого
можно дать обоснованное заключение о достоверности модели.)
Обычно отдельная папка рецензируется одновременно несколькими читателями, и все
их замечания поступают к определенному сроку к автору. Затем автор отвечает на каждое
замечание и обобщает критику, содержащуюся в замечаниях. С помощью таких обсуждений
можно достаточно быстро обмениваться идеями. Таким образом, методология SADT поддерживает как параллельный, так и асинхронный просмотр модели, что является наиболее
эффективным способом распределения работы в коллективе. Это показывает, что моделирование в SADT является инженерной дисциплиной, потому что итеративная коллективная
деятельность - признак инженерной деятельности. Это связано с тем, что модель в SADT
очень редко создается одним автором. На практике над различными частями модели могут
совместно работать множество авторов, потому что каждый функциональный блок модели
представляет отдельный субъект, который может быть независимо проанализирован и декомпозирован. Таким образом, модель сама координирует работу коллектива авторов, в то
время как процесс моделирования SADT координирует совместное рецензирование возникающих идей.
Организация своевременной обратной связи имеет важнейшее значение для эффективного моделирования, потому что устаревшая информация потенциально способна свести
22
на нет все усилия по разработке системы. Вот почему SADT выделяет специальную роль наблюдателя за процессом рецензирования. На рис. 2.1.4.1. показано, что эту роль выполняет
библиотекарь, который является главным координатором процесса моделирования в SADT,
обеспечивая своевременное и согласованное распространение рабочих материалов. Библиотекарь распространяет полученные от авторов папки, контролирует их движение, рассылает
напоминания о своевременном возвращении авторам папок с замечаниями и о сроках ответов авторов на предложения читателей. Кроме того, библиотекарь печатает законченные модели после того, как они одобрены и приняты к использованию.
Вспомним, что SADT-модели создаются с конкретной целью, и эта цель записана на
диаграмме А-0 модели. В каком-то смысле эта цель определяет, как будет использоваться
модель. Таким образом, как только завершено создание модели с требуемым уровнем детализации и модель проверена, она может применяться для достижения поставленной цели.
В процессе SADT-моделирования рекомендуется выделить специальную группу людей, ответственных за то, что создаваемая в процессе анализа модель будет точна и используема в дальнейшем. Эта группа, называемая Комитетом технического контроля (см. блок 5
на рис. 2.1.4.1.), отвечает за контроль качества моделей, создаваемых авторами SADTпроекта. Комитет следит за выполняемой работой и ее соответствием конечным целям всего
проекта. Члены Комитета обсуждают модель и оценивают, насколько она может быть использована и будет использована соответствующим образом в ходе выполнения проекта для
достижения его глобальных целей.
Таким образом, Комитет технического контроля находится в наиболее выгодном положении при определении текущего направления развития проекта и выработке предложений по его корректировке. Комитет реализует это с помощью рецензий. Модели, которые
достигли желаемого уровня детализации и точности с точки зрения технических требований,
направляются членам Комитета технического контроля для обсуждения и утверждения. Комитет оценивает, насколько применима данная модель. Если модель признана Комитетом
применимой, она публикуется. В противном случае авторам направляются замечания для необходимой доработки.[1]
2.2. SADT – МОДЕЛЬ ФУНКЦИОНИРОВАНИЯ ИНФОРМАЦИОННОЙ СЛУЖБЫ
Одним из инструментов моделирования по технологии SADT, является BPWin. Данный инструмент реализует основные элементы SADT – диаграмм. Используя инструментарий BPWin, была построена SADT - модель бизнес – процессов информационной службы
компании. Учитывая то, что выявленные бизнес – процессы взаимосвязаны между собой и
23
протекают как один процесс, модель построена в контексте одного бизнес – процесса «Обеспечить использование ИТ на предприятии». SADT – модель этого бизнес – процесса приведена в приложении 1.
Главная диаграмма изображена на рис. 2.2.1. Эта диаграмма представляет, в виде черного ящика, бизнес – процесс с его входами, выходами, управлением и механизмом. Так как
процесс носит периодический характер и постоянно возобновляется, то выход при переходе
на следующую итерацию становится входом.
Основным делением данного процесса является его представление в виде двух, реализация спланированного развития ИТ и подготовка бюджета на следующий период. Данное
представление изображено на рис. 2.2.2. как декомпозиция главной диаграммы.
Во всех процессах явно или неявно присутствует механизм «Служба по ИТ», а также
управление «Стандарты организации, нормативные акты, законы». Чтобы не загромождать
SADT – модель множеством дуг, данные дуги введены в тоннель. При необходимости явного
указания дуги выводятся из тоннеля.
Рис. 2.2.1. - Главная диаграмма SADT-модели: «ИТ сервис предприятия»
24
Рис. 2.2.2. – SADT – диаграмма второго уровня
Декомпозиция блока «Реализовать спланированное развитие ИТ» показывает, каким
образом протекают процессы реализации планов предыдущего периода.
Декомпозиция блока «Подготовить бюджет на следующий период» показывает, как
протекают процессы, связанные с планированием будущего периода.
Полная SADT-модель, реализованная с помощьюBPWin, приведена в приложении 1.
Процессы, связанные с реализацией спланированного ИТ, соответственно разделяются на приобретение нового обеспечения и на обслуживание, как самого обеспечения, так и
проблем возникающих у пользователей с этим обеспечением.
Процессы, связанные с планированием, формируются путем заключения новых договоров, которые являются основой формирования бюджета, а также путем планирования переменной части затрат, которые неявно присутствуют в контексте заключенных договоров.
Часть договоров являются долгосрочными, их стоимость также влияет на процесс формирования бюджета.
25
3. ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ СИСТЕМЫ
Проведя анализ бизнес – процессов и формально описав их, используя методологию
SADT, подошли к этапу практической реализации автоматизированной системы. На этом
этапе необходимо определить бизнес – процессы первой очереди, которые являются наиболее важными и критическими и именно их необходимо автоматизировать.
Учитывая, что основным элементом ИТ является оборудование, стало понятно, что
бизнес – процесс учета основных средств и материалов является ключевым для всей автоматизированной системы.
Вторым по степени важности стоит процесс учета заявок на обслуживание ИТ. Этот
процесс непосредственно связан с учетом ОС через пользователей, и также является ключевым.
Эти бизнес – процессы для руководства и сотрудников других отделов являются основными. Потому, как они протекают, происходит оценка деятельности ИТ – службы. Если
данным процессам недостаточно уделить внимание, то нет необходимости заниматься другими бизнес – процессами, так как они мало влияют на оценку эффективности службы и на
оценку в целом не повлияют.
Таким образом, получаем, что реализовывать в первую очередь необходимо следующие бизнес – процессы:
-
Учет основных средств и материалов ИТ - службой
-
Учет заявок на обслуживание ИТ
Прежде чем начать автоматизировать данные бизнес – процессы нужно спроектировать информационную модель будущей базы данных.
Одной из наиболее популярных семантических моделей данных является модель
«Сущность - Связь» или ER – модель (Entity Relationship Model). Модель была предложена
Ченом в 1976 г. Эта модель является наиболее наглядной и удобной. Если весь процесс перехода от предметной области к базе данных (БД) представить в следующем виде:
1. Представления о предметной области в голове человека
2. Информационная структура
3. СУБД ориентированное представление
4. Машино - ориентированное представление,
то ER – модель будет стоять на втором уровне.
Таким образом, для построения информационной модели была выбрана модель «Сущность - Связь» или ER – модель.
26
3.1. МНОЖЕСТВО СУЩНОСТЕЙ
Сущность – это «предмет», который может быть идентифицирован некоторым способом, отличающим его от других предметов.
Каждая сущность относится к некоторому отличному от других набору или множеству сущностей.
Атрибут – это отображение между множеством сущностей и множеством значений.
Типы сущностей и атрибуты данной модели:
Организация (код организации, наименование, индекс, область, город, адрес, телефон)
Сотрудник (код сотрудника, фамилия, имя, отчество, пол, дата рождения)
Здание (код здания, индекс, область, город, адрес)
Помещение (код помещения, номер, наименование, число рабочих мест)
Рабочее место (код рабочего места, номер, наименование)
Обслуживание (код обслуживания, дата заявки, время заявки, что случилось, дата исполнения, время исполнения, причина возникновения, что сделано
для устранения)
Внешнее обслуживание (дата заявки, время заявки)
Обеспечение (код обеспечения, дата начала, дата конца)
Программное обеспечение (код ПО, имя пользователя, пароль)
Дистрибутив (код дистрибутива, наименование, версия, наличие лицензии, условия
лицензии, количество рабочих мест, стоимость лицензии, где расположен дистрибутив)
Оборудование (код оборудования, серийный номер, инвентарный номер, принадлежность (основное средство или материал), дата постановки на учет,
стоимость балансовая, стоимость остаточная)
Классификатор (код классификатора, тип, модель)
3.2. МНОЖЕСТВО СВЯЗЕЙ
Связь – ассоциация установленная между сущностями.
Множество связей можно представить как отношение, построенное на n множествах
сущностей.
Типы связей и ограничения на отображения:
Здания организации (организация, здание, 1:N)
Помещения здания (здание, помещение, 1:N)
27
РМ помещения (помещение, рабочее место, 1:N)
Штатный сотрудник (организация, сотрудник, дата приема на работу, должность, телефон внутренний, телефон городской, M:N)
Размещение сотрудника (сотрудник, рабочее место, 1:N)
Сотрудник заявитель (сотрудник, обслуживание, 1:N)
Обслуживающий сотрудник (сотрудник, внешнее обслуживание, 1:N)
Собственность (организация, оборудование, 1:N)
Использование (организация, оборудование, 1:N)
Обслуживающая организация (организация, внешнее обслуживание, 1:N)
Расположение обеспечения (рабочее место, обеспечение, 1:N)
Обслуживание обеспечения (обеспечение, обслуживание, 1:N)
Передача заявки (обслуживание, внешнее обслуживание, 1:1)
Инсталляция ПО (дистрибутив, ПО, 1:N)
Тип оборудования (классификатор, оборудование, 1:N)
3.3. ER - ДИАГРАММА
Каждое множество сущностей представляется в ER – диаграмме помеченным прямоугольником. Каждое множество связей изображается помеченным ромбом. Множества сущностей, которые участвуют во множестве связей присоединяются к последнему дугами.
На рис.3.3.1. изображена ER – модель информационного описания бизнес – процессов: учет основных средств и материалов по ИТ – службе, учет заявок на обслуживание по
ИТ.
В представлении ER – модели использовано иерархическое обобщение, включающее
супертип «Обеспечение» и подтипы «Программное обеспечение» и «Оборудование». Обобщение имеет в середине соединений круг, в который вписана буква «d». Буква «d» указывает,
что это непересекающийся классификатор. Двойная дуга, идущая от супертипа говорит о
полной классификации.
28
Рис. 3.3.1. - ER-модель системы
29
4. РЕАЛИЗАЦИЯ СИСТЕМЫ
Прежде чем приступить к реализации системы необходимо определить инструментарий. Учитывая, что система является однопользовательской, построение по клиент/серверной технологии неоправданно, целесообразней организовать построение локальной БД. Одним из средств построения локальных БД является Paradox. Инструментом создания таблиц в формате Paradox является Database Desktop.
Для реализации клиентской части системы была выбрана среда для разработки приложений под Windows - Borland Delphi 5.0.
ER – модель БД на прямую не ложится в табличное представление Paradox. Наиболее
удобным представлением модели данных (МД) является СУБД – ориентированная МД. В
данном случае выбирается реляционная МД или R - модель, которая напрямую трансформируется в табличное представление Paradox.
4.1. ПРЕОБРАЗОВАНИЕ ER-МОДЕЛИ В РЕЛЯЦИОННУЮ МОДЕЛЬ
Правила преобразования ER – модели в R - модель:
1. Каждое множество сущностей трансформируется в отдельное отношение.
2. Множество связей типа 1:1 и 1:N реализуются дублированием ключа отношения,
возле которого стоит 1, в другое, возле которого стоит N.
3. Связи типа N:M представляются отдельным отношением, причем они строятся на
первичных ключах множеств сущностей, участвующих во множествах связей.
4. Если множество связей имеет собственные атрибуты, для него создается самостоятельное отношение с ключами отношений сущностей.
Используя приведенные правила преобразования, получаем реляционную схему изображенную на рис.4.1.1. На рисунке приведены полные наборы атрибутов отношений. Дуги
представляют связи между первичными ключами и внешними ключами отношений.
30
Рис. 4.1.1. - Реляционная модель системы
4.2. PARADOX 7
Для реализации структуры базы данных выбран Paradox 7. Этот выбор обусловлен
тем, что система является однопользовательской, и целесообразней в такой ситуации использовать локальную БД. Таковой и является Paradox.
31
Так как реляционная модель на прямую переносится в табличное представление, которое реализуется формированием таблиц Paradox, то создаем по средством Database Desktop
соответствующие таблицы.
Database Desktop, поставляемый в месте с Delphi, является системой создания табличных представлений БД в любом формате, в том числе и для Paradox.
Набор отношений трансформируется в следующие таблицы:
-
«Организация» - "Organization"
-
«Сотрудник» - "Employee"
-
«Штатный сотрудник» - "Staff employee"
-
«Здание» - "Building"
-
«Помещение» - "Premises"
-
«Рабочее место» - "Working place"
-
«Обслуживание» - "Service"
-
«Внешнее обслуживание» - "External service"
-
«Оборудование» - "Equipment"
-
«Классификатор» - "Qualifier"
-
«ПО» - "Software"
-
«Дистрибутив» - "Distribution program"
-
«Обеспечение» - "Provision"
Набор полей у таблиц полностью соответствует набору атрибутов отношений. Таким
образом, получили БД реализованную на Paradox, с описанным выше набором таблиц.
4.3.
BORLAND DELPHI – СРЕДА РЕАЛИЗАЦИИ КЛИЕНТСКОЙ ЧАСТИ
АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ
Средством реализации клиентской части системы выбрано Borland Delphi.
Borland Delphi – это интегрированная среда для разработки приложений под Windows,
включающая следующие компоненты:
-
Высокопроизводительный компилятор с языка высокого уровня в машинный код;
-
Объектно-ориентированные модули и компоненты;
-
Визуальное построение приложений из прототипов;
-
Средства построения БД;
Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений как в клиент/серверной архитектуре, так и в локальной
32
БД. Он предлагает легкость разработки и быстрое время проверки готового программного
блока.[2]
На сегодняшний день работа в Delphi является самым продуктивным методом создания приложений для Windows.Общая продуктивность инструментов создания ПО определяется следующими пятью важнейшими аспектами:
1. качеством визуальной среды разработки;
2. скоростью работы компилятора и быстродействием откомпилированных программ;
3. мощностью языка программирования и его сложностью;
4. гибкостью и масштабируемостью используемой архитектуры баз данных;
5. наличием поддерживаемых средой разработки шаблонов проектирования и использования.[4]
С помощью инструментария Delphi была реализована клиентская часть системы, автоматизирующая следующие функции бизнес - процессов:
4.4.
-
Ввод, хранение и изменение информации об основных средствах;
-
Ввод, хранение и изменение информации о заявках.
РАЗВИТИЕ СИСТЕМЫ
На сегодняшний день система внедряется на предприятии, и будет иметь активное
практическое применение. На этом процесс реализации автоматизированной системы ИТ
деятельности на предприятии не закончен. Идет постоянная работа по развитию системы. В
будущем планируется реализовать остальные бизнес – процессы, выявленные и описанные в
SADT. А также ведется активное выявление и построение классификаторов для организации
систем статистической обработки данных, планирования мероприятий по улучшению качества обслуживания, а также предупреждению возникновения неполадок и ошибок в работе
сотрудников предприятия с оборудованием и ПО. Кроме этого планируется реализация формирования документов, необходимых для отделов параллельно участвующих в ведении хозяйства, таких как бухгалтерия, а также системы учета движения документов как внутри
Службы по ИТ, так и в рамках предприятия и компании. Так же процесс построения SADT –
модели еще не закончен. Он будет идти параллельно с реализацией системы, а также будет
происходить дальнейшее выявление бизнес – процессов протекающих как в Службе по ИТ,
так и в других службах связанных с ИТ. Как минимум это бухгалтерия и плановофинансовый отдел.
Таким образом, получаем следующее развитие системы:
33
1. Дальнейшее развитие SADT модели.
2. Реализация системы автоматизации остальных, выявленных и описанных, бизнес –
процессов.
3. Разработка системы статистической обработки накопленной информации
4. Разработка системы формирования документов необходимых для взаимодействующих отделов, согласно установленной форме.
5. Постоянное реагирование на изменения, происходящие в предметной области.
6. Документооборот, в частности входящие и исходящие документы.
В дальнейшем возможна миграция на клиент/серверную технологию и создание нескольких разных клиентских приложений.
34
ЗАКЛЮЧЕНИЕ
В заключении перечислим основные результаты проделанной работы:
1. Выявлены и описаны основные бизнес – процессы.
2. Построена SADT - модель, описывающая выявленные бизнес – процессы как единую систему.
3. Построена ER-модель, описывающая предметную область в рамках очерченных на
данный момент первоочередных потребностей.
4. Реализована реляционная модель путем перехода от ER-модели.
5. Построена База Данных в рамках реляционной модели.
6. Реализована клиентская часть автоматизированной системы учета основных
средств и материалов, а также учета заявок на обслуживание, как основа единой
полнофункциональной системы автоматизации деятельности Службы по ИТ.
7. Начато внедрение системы на предприятии (установлено на рабочем месте и идет
опытная эксплуатация, набирается статистика, как сбоев, так и заявок).
35
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. http://www.interface.ru/ - Книга по SADT моделированию
2. Тиори Т., Фрай Дж. Проектирование структур баз данных: в 2-х кн. –
М.: «Мир», 1995.
3. Марка Д.А., МакГоуэн К.Л.: SADT: Методология структурного анализа и проектирования. – М.: Мета Технология, 1993.
4. Стив Тейксейра, Ксавье Пачеко: Delphi 5. Руководство разработчика: в 2-х кн. –
М: «Вильямс», 2000.
36
ПРИЛОЖЕНИЕ 1. SADT - МОДЕЛЬ
37
38
39
40
41
42
43
44
45
46
47
48
49
50
ПРИЛОЖЕНИЕ 2. РУКОВОДСТВО ПРОГРАММИСТА
Автоматизированная система учета основных средств и материалов, а также учета
заявок реализована по средствам: Клиентская часть - Borland Delphi 5.0; База данных - Paradox 7. Сами таблицы базы данных создавались при помощи программы Data base Desktop,
которая поставляется вместе с Delphi.
П2.1. УСТАНОВКА СИСТЕМЫ
Для установки системы на рабочее место пользователя в первую очередь необходимо
прописать базу данных в системе Windows, через BDE administrator, в поставке Windows,
расположенного в панели управления, либо через SQL Explorer поставляемого в месте с Delphi.
Для этого необходимо:
1.
Скопировать директорию «BD» в то место, где у вас будет физически находиться база данных, которую вы будете резервно копировать, согласно регламенту на предприятии.
2.
С помощью описанных выше инструментов создаете новый алиас БД. Называете его “DBTNP”, указываете путь до файлов БД, то место, куда вы скопировали директорию «BD».
Далее необходимо исполняемый файл «sammdtnp.exe» скопировать в то место, где
будет храниться система учета.
Затем необходимо на рабочем столе пользователя создать ярлык и указать ему, что он
ссылается на данный исполняемый файл и назвать его «Система учета TNP». Все система
готова к работе.
П2.2. ИЗМЕНЕНИЕ КОДА СИСТЕМЫ
Для внесения, каких либо изменений в программный код системы необходимо:
1. Запустить Delphi.
2. Открыть проект системы.
3. Если необходимо внести изменения в существующие формы системы, то следует
открыть соответствующий файл с расширением «.pas», согласно приложению 4.
Внести изменения. Далее выполнить действия с 5 пункта данного описания.
51
4. Если необходимо внести изменения в код программы путем создания новой формы, то следует, во-первых, создать эту форму, а во-вторых, организовать ее вызов,
корректируя существующие формы.
5. Провести перекомпиляцию программного кода.
6. Полученный после перекомпиляции исполняемый файл с расширением “.exe”, необходимо скопировать на место старого файла.
Структура БД описана в соответствующем разделе отчета. Для внесения изменений в
структуру таблиц необходимо с помощью средств редактирования таблиц БД открыть соответствующий файл, его название соответствует названию таблицы, и внести изменения, после чего сохранить. В случае если необходимо добавить к структуре БД новую таблицу, то
вы создаете новую таблицу Paradox 7 с помощью любого средства и сохраняете ее в директорию с базой данных. После чего для использования данной таблицы в клиентской части
необходимо создать соответствующие связи в коде программы и провести перекомпиляцию,
и замену исполняемого файла.
52
ПРИЛОЖЕНИЕ 3. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ
Для начала работы с системой необходимо запустить программу. Для этого два раза
нажать на ярлык с подписью «Система учета TNP» на рабочем столе вашего компьютера.
Если вы не обнаружили у себя на рабочем столе такого ярлыка, то вам либо не установили
программу, либо не создали ярлык, для того чтобы он у вас появился, обратитесь к администратору.
После того, как вы запустите ярлык, на рабочем столе вашего компьютера, в левом
верхнем углу появиться форма, вида как показано на рис. П.3.1.
Рис. П.3.1. «Главная форма»
Если вы начинаете работу с программой на данном предприятии, при этом с программой никто до вас не работал, то в первую очередь необходимо заполнить форму о вашем
предприятии, затем ввести здания, помещения и рабочие места сотрудников, а также сам
список сотрудников. Для этого необходимо из множества меню главной формы выбрать
«Добавить/Изменить». Появится список подменю данного меню.
Описание меню главной формы:
«Заявка»
«Принять» - открывает форму для заполнения первичной информации о поступившей заявки на обслуживание. Рекомендация: «заполнять лучше всего в
момент принятия заявки»
«Передать» - открывает форму для заполнения информации о передаче заявки
обслуживающей организацией.
«Исполнить» - открывает форму для заполнения информации об исполнении
заявки, что сделано для устранения и почему возникло.
«Оборудование»
«Новый приход» - открывает форму для заполнения информации о вновь поступившем оборудовании.
«Ввод в эксплуатацию» - открывает форму для заполнения информации о
вводе в эксплуатацию (установку на рабочее место) оборудования.
53
«Модернизация» - открывает форму для заполнения данных о процессе модернизации оборудования (увеличение балансовой стоимости)
«Перемещение» - открывает форму для заполнения данных о перемещении
оборудования в другое место.
«Передать в ремонт» - открывает форму для заполнения информации о передачи техники на ремонт.
«выдать на временное хранение» - открывает форму для заполнения выдачи
на временное хранение, например в командировку.
«Арендованное» - открывает форму для заполнения информации об арендованном оборудовании.
«В аренде» - открывает форму для заполнения информации о переданном в
аренду оборудовании.
«Добавить/Изменить»
«Организацию» - открывает форму для заполнения информации об организации
«Сотрудника» - открывает форму для заполнения информации о сотрудниках
«Здание» - открывает форму для заполнения информации о зданиях
«Помещение» - открывает форму для заполнения информации о помещениях
«Рабочее место» - открывает форму для заполнения информации о рабочих
местах
«Общая форма» - открывает форму для просмотра общей информации обо
всех зданиях организации, сотрудников организации, и т.д.
«Закрыть» - подменю не имеет, при нажатии закрывает программу.
Для внесения информации о новом предприятии необходимо нажать левой кнопкой
мыши на подменю «Организацию», меню «Добавить/Изменить». Откроется окно, показанное
на рис. П.3.2. Как показано на рисунке данная форма имеет несколько незаполненных полей,
над полями надписи, указывающие какую информацию необходимо занести в это поле.
«Наименование организации» - необходимо занести имя вводимой организации. Если
хотите изменить информацию о уже веденной организации, то выберите из выпадающего
списка, который появится при нажатии кнопки выпадающего меню справа от места ввода
наименования организации. При этом остальные поля отобразят ту информацию, которая
храниться в БД по данному предприятию.
54
Рис.П.3.2 «Форма добавления новой организации»
Заполняем остальные поля формы. Далее если мы хотим добавить новую запись, то
смотрим, установлен ли указатель в левом нижнем углу на «добавить», при этом кнопка
внизу слева имеет название добавить, в случае если выбрать «изменить», то кнопка будет
иметь название «изменить», как показано на рис. П.3.3.
Рис. П3.3 «Форма добавить новую организацию с кнопкой изменить»
Далее нажимаем на эту кнопку и соответственно получаем тот результат, который
отображен в названии кнопки.
Таким образом, по аналогии заполняются все остальные формы программы. Кроме
этого, существует другое представление данных используемых в программе, это представление приведено на рис.П.3.4. Данная форма вызывается нажатием на подменю «Общая форма», меню «Добавить/Изменить».
55
Рис. П.3.4. «Общая форма»
На рис. П.3.4. видим, что чуть выше середины находится ряд закладок с надписями
«Здания», «Помещения», и т.д. На каждой из них находится информация в виде списка, соответствующая названию закладки. Выводимые данные относятся к выбранному предприятию, из списка предприятий находящегося в верхнем левом углу формы.
Таким образом, организовано отображение данных, а также модифицирование и внесение новой информации. Для организации работы пользователя достаточно описания этого
функционала для дальнейшей работы с системой.
Описание всех подменю меню главной формы приведено выше. Предполагается, что
пользователь системы имеет навыки работы на компьютере, хотя, учитывая область применения системы, такое замечание очевидно.
56
ПРИЛОЖЕНИЕ 4. СПИСОК ФАЙЛОВ
«sammdtnp.exe» - исполняемый файл программы.
*.db – файлы базы данных, имена соответствуют названию таблиц:
«Organization.db»
«Employee.db »
«Staff employee.db »
«Building.db »
«Premises.db »
«Working place.db »
«Service.db »
«External service.db »
«Equipment.db »
«Qualifier.db »
«Software.db »
«Distribution program.db »
«Provision.db »
«UnitMain.pas, UnitMain.pas,dfm» - модуль главного окна.
«UnitOrganization.pas, UnitOrganization,dfm» - модуль окна работы с организациями.
«UnitEmployee.pas, UnitEmployee,dfm» - модуль окна работы с сотрудниками.
«UnitStaffEmployee.pas, UnitStaffEmployee,dfm» - модуль окна работы с со штатными сотрудниками.
«UnitBuilding.pas, UnitBuilding,dfm» - модуль окна работы со зданиями.
«UnitPremises.pas, UnitPremises,dfm» - модуль окна работы с помещениями.
«UnitService.pas, UnitService,dfm» - модуль окна работы с заявками на обслуживание.
«UnitExternalService.pas, UnitExternalService,dfm» - модуль окна работы с заявками на обслуживание в стороннюю организацию.
«UnitEquipment.pas, UnitEquipment,dfm» - модуль окна работы с оборудованием.
«UnitQualifier.pas, UnitQualifier,dfm» - модуль окна работы с классификатором оборудования.
«UnitSoftware.pas, UnitSoftware,dfm» - модуль окна работы с ПО.
«UnitDistributionProgram.pas, UnitDistributionProgram,dfm» - модуль окна работы с дистрибутивами ПО.
«UnitProvision.pas, UnitProvision,dfm» - модуль окна работы с обеспечением оборудованием и
ПО сотрудников через рабочие места.
57
«DBTNP.pas, DBTNP.dfm»-модуль данных, содержит не визуальные компоненты работы с
базой данных.
«UnitGlobal.pas, UnitGlobal,dfm» -модуль формы вывода общей информации
58
ПРИЛОЖЕНИЕ 5. СПИСОК ФАЙЛОВ В ЭЛЕКТРОННОЙ
ВЕРСИИ ДИПЛОМНОЙ РАБОТЫ
Директория …/ Kozgov
Название файла
Размер, Кбайт
Описание
Diplom.doc
404,5
Текст дипломной работы
Diplom.ppt
573,4
Презентация работы для MS Power Point
версии 7.0.
59
ПРИЛОЖЕНИЕ 6. АКТ ПРИЕМА – ПЕРЕДАЧИ В
ПРОМЫШЛЕННУЮ ЭКСПЛУАТАЦИЮ
60
Документ
Категория
Типовые договоры
Просмотров
121
Размер файла
1 160 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа