23
изучение общих принципов и концепций автоматизации
делопроизводства;
изучение IT структуры компании;
проведение анализа архитектур ИС;
построение различных моделей ИС;
разработка концептуальной информационно-технологической модели
ИС;
исследование параметров входного потока ИС.
2.2 Функциональная модель ИС
Функциональная модель строится для того чтобы ответить и
задокументировать ответы на вопросы:
для кого строится ИС;
какие функции выполняет ИС.
Заказчиком является учреждение НОУ «ЮНИКОМ ПЛЮС», которое
проводит различные обучающие курсы, связанные с ИТ. На этих курсах
клиенты также могут освоить рабочие профессии (для этого нужно пройти
несколько определенных курсов) и получить подтверждающие документы об
образовании.
К освоению дополнительных общеобразовательных программ
допускаются любые лица без предъявления требований к уровню образования.
К освоению дополнительных профессиональных программ допускаются:
лица, имеющие среднее профессиональное и (или) высшее
образование;
лица, получающие среднее профессиональное и (или) высшее
образование;
не имеющие медицинских противопоказаний для обучения по
программам учреждения.
Клиент, желающий пройти определенные курсы, сначала записывается
на них. Когда набирается определенное количество желающих пройти
определенный курс, из них формируется группа, с которой проводятся занятия.
24
Во время занятий клиент выполняет определенные практические работы и
сдает экзамены. На основании этого ставится итоговая оценка. По завершении
клиенту выдается сертификат, а в случае, если он освоил какую-либо
профессию, выдается свидетельство (с приложением).
На рисунке 2 приведена диаграмма USE CASE для рассматриваемой ИС.
Рисунок 2 - USE CASE диаграмма функциональная модель
ЮНИКОМ ПЛЮС
На основании этой диаграммы определены актеры – в терминах UML
(директор, клиент, менеджер) для кого строится ИС.
Определены прецеденты – варианты использования (USE CASE’s) – овалы.
Тем самым выявлен и детализирован функционал. Внутри прецедентов
описаны соответствующие сценарии их использования.
2.3 Логическая модель ИС
Логическая модель ИС представляет собой конечную диаграмму классов,
на которой представлено взаимодействие сущностей, управляющих и
пограничных классов, выявленных на начальном этапе проектирования и в
25
процессе моделирования взаимодействий. Модель взаимодействий служит
источником информации не только о том, какие классы, помимо сущностей,
выявленных в начале разработки, должны существовать в системе, но и о том,
как они взаимодействуют и связаны друг с другом, а также какими методами
они обладают.
Рисунок 3 - Диаграмма классов ИС
Диаграмма на рисунке 3 иллюстрирует основные классы – сущности и
различные ассоциации (связи) между ними.
2.4 Динамическая модель ИС
Диаграммы последовательностей изображенные на рисунках 4 и 5
относится к динамическому виду системы. Для диаграммы последовательности
ключевым моментом является динамика взаимодействия объектов во времени.
При этом диаграмма последовательности имеет как бы два измерения. Одно
представлено слева направо в виде линии жизни (lifeline) (период времени
26
существования) отдельного объекта, участвующего во взаимодействии, а
второе - вертикальной временной осью, направленной сверху вниз.
Рисунок 4 - Оформление записи на прохождение курса
Рисунок 5 - Заключение договора на прохождение курса
Взаимодействие объектов реализуется посредством сообщений,
посылаемые одними объектами другим. Сообщения появляются в том порядке,
в котором они показаны – сверху вниз.
2.5 Физическая модель ИС
В результате анализа моделей ИС, описанных ранее, было принято
архитектурное решение: ИС должна быть реализована как клиент-серверное
27
приложение в трехуровневой архитектуре. Этот факт зафиксирован в виде ряда
UML диаграмм, составляющих в совокупности физическую модель
проектируемой ИС .
Диаграмма компонентов. Для создания конкретной физической системы
необходимо реализовать все элементы логического представления в
конкретные материальные сущности. Для описания таких реальных сущностей
предназначено физическое представление модели. Базовыми элементами
физического представления системы в нотации UML являются компоненты,
которые представляют собой физически существующие части системы,
которые обеспечивают реализацию классов и отношений, а также
функционального поведения моделируемой программной системы.
На рисунках 6 и 7 показан состав компонентов (фрагменты системы) в
виде диаграммы компонентов.
Рисунок 1—Физическая модель.
Диаграмма модулей. Компоненты ИС
28
Рисунок 2- Физическая модель. Диаграмма размещений
Выводы к главе 2. Вторая глава выпускной квалификационной работы
посвящена теоретическим исследованиям связанным с объектом
автоматизации.
При написании технико-экономической характеристики деятельности
компании была подробно рассмотрена деятельность всей компании в целом, ее
функциональные возможности.
В данной главе также был подробно описан основной бизнес-процесс
компании. В настоящее время все расчеты осуществляются посредством MS
Excel, что значительно усложняет работу сотрудников.
Итогом Главы 2 является построение (описание) объектной модели
прототипа ИС. Предполагаемая гипотеза для этой главы: Построенная
объектная модели ИС позволит:
сформулировать алгоритм решение задачи текущей ИС;
29
получить основу для формирования пакета документации и
инструкций для пользователей (заказчика);
моделировать предпроектное решение.
В результате анализа было принято решение о разработке и внедрении
программного комплекса, который направлен на автоматизацию части
документооборота учреждения.
30
Глава 3. Практическая часть
3.1 Разработка системной архитектуры
Системная архитектура – это организация системы, включающая
основные компоненты, связи между ними, как они взаимодействуют для
удовлетворения системных требований, и принципы их проектирования и
развития.
Системная архитектура состоит из трех взаимосвязанных компонентов –
прикладной архитектуры, архитектуры данных и технической архитектуры.
Кратко рассмотрим состав каждого компонента.
В состав прикладной архитектуры входят:
прикладные системы (приложения), обеспечивающие исполнение
бизнес-функций и бизнес-процессов;
интерфейсы взаимодействия прикладных систем между собой и с
внешними системами и источниками или потребителями данных;
средства и методы разработки и сопровождения приложений.
Архитектура данных включает в себя:
автоматизированные базы данных, обеспечивающие накопление,
хранение и обработку данных, определяемых бизнес-архитектурой;
применяемые для этого системы управления базами данных или
хранилищами данных;
правила и средства санкционирования доступа к данным.
Техническая архитектура в свою очередь состоит из сетевой
архитектуры и архитектуры платформ. Сетевая архитектура включает в себя:
локальные и территориальные вычислительные сети;
используемые в сетях коммуникационные протоколы, сервисы и
системы адресации;
аварийные планы по обеспечению бесперебойной работы сетей в
условиях чрезвычайных обстоятельств.
Архитектура платформ включает в себя:
31
аппаратные средства вычислительной техники;
операционные и управляющие системы, утилиты и офисные
программные системы;
аварийные планы по обеспечению бесперебойной работы аппаратуры
(главным образом - серверов) и баз данных в условиях чрезвычайных
обстоятельств.
Согласно уставу предприятия, руководство текущей деятельностью
компании осуществляется единоличным исполнительным органом –
директором.
На данный момент имеются проблемы взаимодействия между
участниками ИС - передача информации затруднена. Не соблюдены меры
информационной безопасности – каждый сотрудник имеет доступ к локальным
дискам, на которых хранятся все документы и расчеты. Так как локальных
дисков большое количество, затрудняется поиск нужного документа, поэтому
сотрудники иногда вынуждены использовать электронную почту для обмена
документами.
3.2 Разработка схемы базы данных
Проектирование таблиц базы данных.
Для выполнения физического проекта будущей базы данных была
использована реляционная модель представления данных, так как подавляющее
большинство современных СУБД реализовано именно на основе этой модели.
На основании логической модели данных и выделенных сущностей
системы автоматизации были выделены таблицы базы данных.
В ходе детального рассмотрения результатов анализа предметной
области было выявлено большое количество информационных полей, которые
должны храниться для каждой из сущностей при этом выделились еще
некоторые сущности.
В целях устранения избыточности хранимых данных была проведена
нормализация таблиц баз данных.
32
Нормализация – это процесс приведения структур данных в состояние,
обеспечивающее лучшие условия выборки, включения, изменения и удаления
данных. Это достигается разбиением одной большой таблицы на две более
мелкие таблицы. Конечной целью нормализации является получение такого
проекта базы данных, в котором каждый факт появляется лишь в одном месте,
т. е. исключена избыточность. Это делается не столько с целью экономии
памяти, сколько для исключения возможной противоречивости хранимых
данных.
В ходе проведения нормализации все таблицы базы данных были
приведены к третьей нормальной форме, так как третья нормальная форма
обеспечивает хороший баланс между пользой от устранения дублирования
данных и накладными расходами вычислительных ресурсов, затрачиваемых на
обеспечение целостности данных. Кроме того, с возрастанием уровня
нормализации таблиц возрастает сложность запросов для добавления, выборки,
изменения и удаления данных.
В базе данных представлены следующие отношения:
Группа
Запись
Клиент
Клиент_в_группе
Курс
Курсы_профессии
Практика
Практика_клиента
Приложение
Профессия
Сертификат
Экзамен
Экзамен_клиента