Разработка информационной системы в контексте AS-IS и TO-BE
Введение
справочный система
программный диаграмма
Стремительное развитие и повсеместное применение
информационных технологий, превращение информации в ценнейший ресурс
жизнедеятельности обусловливает движение человечества к информационному
обществу. В условиях перехода к информационному обществу ведение эффективного
бизнеса и достижение высокого качества жизни возможны только при условии
эффективного управления информационными ресурсами. Сегодня потребитель должен
иметь возможность получать требуемую информацию в нужном виде, в приемлемые
сроки, практически в любом месте и за умеренную плату.[1]
Справочная система предназначена для получения
пользователем максимально точной (релевантной) информации по интересующей его
(и ограниченной базой статей) теме. Обычно выбор статьи происходит по иерархии
разделов справки. Справочные системы часто комбинируются с поисковыми
системами, где выборка релевантных статей определяется по заданным ключевым
словам или (при полнотекстовом поиске) частью предложения.
Таким образом, справочная система - это, в
данном случае, программный продукт, позволяющий пользователю получить точную
информацию по теме, либо задав некоторые условия поиска, либо выбрав
необходимую информацию из списка.
Так как в данной системе используется большой
объем данных, будет целесообразно разместить их в базе данных под управлением
некоторой СУБД.
Вследствие значительного жизненного цикла может
оказаться, что в процессе создания системы внешние условия изменились. Обычно
внесение изменений в проект на поздних этапах создания справочной системы -
весьма трудоемкий и дорогостоящий процесс. Поэтому для успешной реализации
крупного проекта необходимо, чтобы инструментальные средства, на которых он
реализуется, были достаточно гибкими к изменяющимся требованиям.
Данный курсовой проект посвящен анализу и
проектированию к разработке информационной системы «Учет успеваемости». Для
этой цели были выбраны инструментальные средства визуального проектирования
BPWin и Rational Rose.
1. Предмет разработки в контексте AS-IS
и TO-BE
.1 Предисловие
Для построения бизнес-процессов можно
использовать Case-средства, BPwin,
All Fusion Process, Modeler,
графический редактор Vision и другие.
В данном случае предпочтение было отдано BPWin.
При этом были использованы диаграммные техники: IDEF0 и DFD для построения
декомпозиции.
1.2 Модель AS-IS
Построению модели AS-IS предшествовало
обследование информационной системы «Учёт успеваемости», а именно управление
ведомостями института. Упомянутое включало в себя информацию о названии
факультета, названии специальности, о сотрудниках, полная информация о
специальности, полная информация о факультете, полная информация об студенте.
На рисунке 1.1 представлена контекстная
диаграмма модели AS-IS
бизнес-процесса «Учёт успеваемости».
Рисунок 1.1 - Контекстная диаграмма модель AS-IS
Данная контекстная диаграмма изображает
функционирование системы в целом. Основная цель - это получения информации об
успеваемости студентов на факультете и об студентах, обучающихся на этом
факультете. Контекстная диаграмма имеет следующие данные и объекты, связывающие
между собой работы: стрелки входа - название факультета или фамилия студента
или специальность студента; стрелка выхода - полная информация о специальностях
или студентах.
Приведем декомпозицию процесса «Учёт
успеваемости студентов».
Рисунок 1.3 - Декомпозиция процесса «Получение
информации о студенте»
Декомпозиция процесса «Учет успеваемости
стедентов», приведенная на рисунке 1.3, была выполнена в виде DFD.
Диаграмма типа DFD
позволяет увидеть передаваемые процессы:
1) Регистрация ведомостей;
2) Журнал ведомостей;
) Обработка ведомостей;
) Вложение папки;
) Архивация ведостей;
) Выдача сотрудникам;
Рисунок 1.4 - Диаграмма дерева узлов модели AS-IS
На рисунке 1.4 показано дерево узлов модели «AS-IS».
Модель трехуровневая, нижние уровни были представлены в виде списков.
1.3 Модель TO-BE
Модель TO-BE
описывает возможное будущее состояние предметной области, в которое она
перейдёт в результате оптимизации существующей системы и внедрения новых
технологий.
При этом предмет разработки должен поддерживать
такие задачи как:
- Регистрация ведомостей;
- Запись в журналах;
- Выдача сотрудникам.
На рисунке 1.5 представлена контекстная
диаграмма модель TO-BE.
Рисунок 1.5 - Контекстная диаграмма модель TO-BE
На рисунке 1.5 представлена контекстная
диаграмма модели «TO-BE».
Данная модель покажет, насколько эффективнее станет работа информационной
системы при внедрении компьютерной информационной системы. Декомпозируем
контекстную диаграмму, чтобы представить себе, насколько изменились процессы,
которые мы видели в «AS-IS».
Декомпозиция контекстной диаграммы модели TO-BE
в диаграмму IDEF0 изображена
на рисунке 1.6.
Рисунок 1.6 - Декомпозиция модели TO-BE
На рисунке 1.6 мы видим декомпозированную
контекстную диаграмму. Процессы остались те же, но теперь управляющую роль для
них выполняет не «бумажный» каталог, а компьютерная программа, которая может
использоваться как сотрудниками (для добавления, обновления или удаления
данных), так и пользователями - клиентами. В результате внедрения КИС мы имеем:
§ Время выполнения операций значительно
сократилось. Теперь сотруднику для добавления и поиска данных, достаточно
отрыть программу и внести в нее данные или найти необходимые;
§ Время добавления, обновления, удаления данных
существенно сокращается при использовании КИС.
Рисунок 1.7 - Диаграмма дерева узлов модели TO-BE
Как видно из рисунка 1.7 количество уровней и
узлов существующей модели уменьшилось благодаря автоматизации некоторых
процессов.
1.4 Цели и задачи информационной
системы «Учет успеваемости»
В результате анализа существующей ситуации и
создания новой модели организации бизнес-процессов, можно сформулировать цель и
задачи предмета разработки - «Учет успеваемости».
Преимущества разрабатываемого программного
продукта были подробно рассмотрены и проанализированы в разделе 1.2, поэтому мы
не будем их повторять.
Задачи информационной системы «Учет
успеваемости»:
1) Обеспечить удобный поиск информации (поиск
по полному или частичному совпадению);
2) Обеспечить корректный и полный вывод информации
о студенте;
) Обеспечить корректный и полный вывод
информации о факультете;
) Обеспечить удобное редактирование базы
данных и корректное её сохранение.
В процессе обследования предметной области была
построена и изучена модель AS-IS. На основании модели AS-IS, была построена
модель TO-BE, были определены цели и задачи будущего предмета разработки.
2.Техническое задание на предмет
разработки
.1 Предисловие
Модель вариантов использования предназначается
для определения требований к системе. Она включает в себя актеров, варианты
использования и связи между ними. Для отображения этой модели язык UML
предлагает использовать диаграммы Use Case (вариант использования) совместно с
моделями State Diagram (диаграммы состояний) и Activity Diagram (диаграммы
деятельности/активности). Последние используются для конкретизации вариантов
использования системы.
2.1 Модель вариантов использования
информационной системы «Учет успеваемости»
Модель вариантов использования описывает
функциональное назначение системы или, другими словами, то, что система будет
делать в процессе своего функционирования. Диаграмма вариантов использования
является исходным концептуальным представлением или концептуальной моделью
системы в процессе ее проектирования и разработки.
2.2 Действующие лица
Большинство систем имеет множество категорий
пользователей. Поэтому каждая категория пользователей представляется отдельным
действующим лицо (актером). Актер - это любая сущность, взаимодействующая с
системой извне.
В данном проекте выделены следующие действующие
лица:
Администратор - сотрудник информационной
системы, в обязанности которого входит своевременное редактирование базы
данных.
Пользователь - любой человек, который может
просматривать информацию.
2.3 Варианты использования
Актеры взаимодействуют с системой с помощью так
называемых вариантов использования. Каждый вариант использования определяет
некоторый набор действий, совершаемый системой при диалоге с актером.
· Редактирование базы данных.
· Просмотр базы.
· Добавление нового студента.
· Добавление нового факультета.
· Удаление записи.
· Редактирование записи.
· Сохранение изменений.
· Поиск по фамилии.
· Поиск по специальности.
2.4
Диаграмма вариантов использования
На диаграмме вариантов использования показывают
взаимодействия между всеми действующими лицами и вариантами использования.
Диаграмма должна показывать, какие действующие лица инициируют варианты
использования, а также должна отображать, когда действующие лица получают
информацию от вариантов использования.
Основные взаимодействия между действующими
лицами и вариантами использования задаются с помощью связи коммуникации.
Задается в виде простой стрелки. Направление стрелки показывает, кто инициирует
связь (всегда действующее лицо) и какой вариант использования отправляет
информацию внешнему действующему лицу [2].
Диаграмма вариантов использования изображена на
рисунке 2.1.
На рисунке 2.2 представлена детализация варианта
использования информационной системы «Учет успеваемости».
Рисунок 2.1 - Диаграмма вариантов использования
2.5 Описание вариантов использования
.5.1 Прецедент «Использование БД»
Назначение: данный вариант использования
описывает возможность редактирования данных. Основной поток событий: cистема
запрашивает требуемое действие (удаление студента, удаление факультета,
изменение данных о студенте, изменение данных о факультете, добавление нового
факультета, добавление нового студента).После того, как Администратор указывает
действие, выполняется один из подчиненных потоков: удалить студента, удалить
факультет, изменить данные о студенте, изменить данные о факультете, добавить
новый факультет, добавить нового студента.
) Удалить студента:
Администратор указывает необходимого студента.
Система выдает запрос на подтверждение удаления.
После подтверждения удаления система удаляет из
базы данных информацию об студенте.
) Удалить факультет
Администратор указывает необходимый факультет.
Система выдает запрос на подтверждение удаления.
После подтверждения удаления система удаляет из
базы данных информацию о факультете.
) Изменить данные о студенте
Администратор указывает необходимого студента.
Система дает возможность редактирования.
После этого Администратор изменяет необходимые
поля.
) Изменить данные о факультете
Администратор указывает необходимый факультет.
Система дает возможность редактирования.
После этого Администратор изменяет необходимые
поля.
) Добавление нового факультета
Система выдает бланк с пустыми полями.
Администратор заполняет все поля.
Происходит сохранение данных.
) Добавление нового студента
Система выдает бланк с пустыми полями.
Администратор заполняет все поля.
Происходит сохранение данных.
Альтернативные потоки.
) Если данные неверны, то выдается
соответствующее сообщение об ошибке и изменений в БД не происходит.
) Если оператор после изменений нажал кнопку
«Отменить изменения», то заново считываются из БД старые данные и новые не
сохраняются.
Предсловия. Отсутствуют.
Постсловия.Если изменения в БД прошли успешно,
выдается об этом сообщение, в противном случае - сообщение об ошибке.
В ходе работы над частью проекта, представленной
в данном разделе выполнено:
Определение списка действующих лиц с указанием
их ролей;
Определение вариантов использования;
Построение диаграммы вариантов использования;
Описание вариантов использования.
3. Моделирование данных к предмету
разработки
.1 Предисловие
Для моделирования данных в данном курсовом
проекте в качестве инструментария был выбран CASE-пакет ERwin, наиболее полно
отвечающий требованиям проектирования различного типа БД.
3.2 Выбор инструментария,
диаграммных техник
Основой для построения моделей данных послужили
результаты обследования целевой деятельности с построением модели AS-IS
и TO-BE.
В качестве инструментария для моделирования данных ERwin.
3.3 Логическая модель данных
После выявления отношений между сущностями была
построена логическая модель, показанная ниже:
Рисунок 3.3.1 - Модель данных на уровне
сущностей
Рисунок 3.3.2 - Модель на уровне определений
Рисунок 3.3.3 - Модель данных на уровне
атрибутов
Рисунок 3.3.4 - Модель на уровне первичных
ключей
3.4 Физическая модель данных
Первым этапом физического проектирования БД
является преобразование отношений, созданных на основе логической модели
данных, в такую форму, которая может быть реализована в среде целевой СУБД. Для
реализации БД данного проекта в качестве целевой СУБД будет выбран Microsoft
SQL Server 2000.
Рисунок 3.4.1 - Физическая модель на уровне
колонок
В ходе выполнения части курсового проекта,
представленной в данном разделе, было выполнено:
Выделение сущностей и атрибутов модели данных с
использованием бизнес-процессов;
Определение отношений между сущностями;
Построение логических моделей данных,
представленных на различных уровнях;
Определение в качестве базовой СУБД MS
SQL Server
2005, с построением физической модели данных.
4. Логическое моделирование предмета
разработки
.1 Предисловие
Ниже в разделе представлены результаты
дальнейшего развития логической модели ПО, начало создания которой было
положено в разделе «Техническое задание на предмет разработки». Разумеется,
язык моделирования и инструментария его реализации остались прежними: UML и
Rational Rose .
.2 Выделение классов анализа
.2.1 Способы выделения классов
анализа
Класс анализа представляет собой абстракцию
одного или более классов и/или подсистем в проекте системы. Эта абстракция
имеет следующие характеристики:
класс анализа сосредоточен на представлении
только функциональных требований (нефункциональные требования рассматриваются
на стадиях проектирования и реализации);
класс анализа не обязан поддерживать какие-либо
интерфейсы в понятии операций и их сигнатур (поведение должно быть описано в
текстовой форме);
классы анализа связаны в основном отношением
«ассоциация»;
классы анализа всегда можно отнести к одному из
типов: граничный, управляющий или сущность.
.2.2 Глоссарий предметной области
Глоссарий предназначен для описания терминологии
предметной области. Он может быть использован как неформальный словарь данных
системы. Словарь нужен для того, чтобы обнаружить классы и объекты (или
кандидатов на роль классов и объектов) [2].
Для составления глоссария будем использовать
классический подход Йордана, в котором кандидаты на роль классов и объектов
выбираются из списка осязаемых элементов предметной области (предметы,
устройства, события, структуры, роли, места, внешние системы).
В таблице 1 приведены термины глоссария и их
значения.
Таблица 1. Глоссарий предметной области
№
|
Термин
|
Значение
|
1
|
Пользователь
|
Все
пользователи системы имеют возможность просматривать каталог, выполнять
поиск, фильтрацию данных.
|
2
|
Администратор
|
Сотрудники
информационной системы, имеют возможность редактировать БД.
|
2
|
Поиск
информации
|
Выбор
таких записей из базы данных, которые попадают под заданные пользователем
критерии поиска.
|
3
|
Редактирование
базы данных
|
Просмотр,
добавление, удаление, редактирование, сохранение изменений в записях БД.
|
4
|
База
данных «Учет успеваемости»
|
1.
Совокупность таблиц БД, хранящих информацию о студентах и факультетах. 2.
Визуальное представление данных о студентах и факультетах в программе.
|
5
|
Просмотр
базы
|
Просмотр
всех записей базы дынных.
|
6
|
Добавление
записи
|
Добавление
очередной записи в базу данных.
|
7
|
Удаление
записи
|
Удаление
записи из базы данных.
|
8
|
Редактирование
записи
|
Внесение
изменений и дополнений в определенную запись базы данных.
|
9
|
Сохранение
изменений
|
Сохранение
внесенных в базу данных изменений.
|
10
|
Поиск
по фамилии
|
Выбор
таких записей из базы данных, которые попадают под заданные пользователем
фамилию или начало фамилии студента.
|
11
|
Поиск
по специальности
|
Выбор
таких записей из базы данных, которые попадают под заданную пользователем специальность
студента.
|
User - класс,
определяющий пользователя системы, его параметры, роли
LoginForm
- класс, представляющий собой форму аутентификации
AdminForm
- форма, позволяющая выполнять административные функции, такие как: добавление,
редактирование и удаление студентов, факультетов или специальностей
Search - поиск по
заданным критериям.
4.3 Поведение предмета разработки
Трактуя все приложение как класс, представим
поведение предмета разработки в виде диаграммы состояний (рисунок 4.3.1).
Рисунок 4.3.1- Диаграмма деятельности системы в
целом.
Диаграмма состояний описывает возможные
последовательности состояний и переходов, которые в совокупности характеризуют
поведение предмета разработки как единого целого в течение его жизненного
цикла.
.4.1 Вариант использования
«Использование БД»
Класс анализа не обязан поддерживать какие-либо
интерфейсы и понятия операций и сигнатур. Вместо этого поведения должно быть
описано в текстовом формате в соответствии с особенностями класса
(обязанностями).
Классы анализа связаны друг с другом отношением
«ассоциация». Направленность ассоциаций не слишком важна в анализе, но
существенна в проектировании. Также в процессе анализа могут использоваться
отношения «обобщения».
Классы анализа всегда можно отнести к одному из
типов: граничный, управляющий или сущность. Эти три стереотипа
стандартизированы в UML и используются, чтобы помочь разработчикам различать
назначения (действия) различных классов.
В языке UML взаимодействие элементов
рассматривается в информационном аспекте их коммуникации, т. е.
взаимодействующие объекты обмениваются между собой некоторой информацией. При
этом информация принимает форму законченных сообщений. Другими словами, хотя
сообщение и имеет информационное содержание, оно приобретает дополнительное
свойство оказывать направленное влияние на своего получателя. Это полностью
согласуется с принципами объектно-ориентированного анализа и проектирования,
когда любые виды информационного взаимодействия между элементами системы должны
быть сведены к отправке и приему сообщений между ними.
Для моделирования взаимодействия объектов в
языке UML используются соответствующие диаграммы взаимодействия: диаграмма
последовательности и диаграмма кооперации [3].
4.4.2 Вариант использование «Поиск
информации»
Диаграмма последовательности прецедента «Поиск
информации» представлена на рисунке 4.4.2.1.
Рисунок 4.4.2. - Диаграмма последовательности
прецедента «Поиск информации»
Здесь показано взаимодействие пользователя с
интерфейсом и объектами поиска.
На рисунке 4.4.2.3 показана диаграмма кооперации
прецедента «Поиск информации».
Рисунок 4.4.2.3 - Диаграмма кооперации
прецедента «Поиск информации»
Диаграмма кооперации дублирует диаграмму
последовательности. Она выглядит более компактной, но в ней сложнее отследить
последовательность действий. На рисунке 4.4.2.4 представлен макет экранной
формы страницы поиска. Данный макет разработан в интегрированной среде
разработки Borland
Delphi 7.
Рисунок 4.4.2.4 - Макет экранной формы для
страницы поиска.
4.5. Статическая модель предмета
разработки
.5.1. Диаграмма классов интерфейса
предмета разработки
4.5.1 Вариант использования
(прецедент) «Поиск информации» - основной поток (подчиненный поток «Поиск
информации по ФИО»)
.5.1.2 Диаграмма классов к прецеденту
«Поиск информации»
Диаграмма последовательности «Поиск информации»
- основной поток (подчиненный поток «Поиск информации по ФИО») представлена на
рисунке 4.5.1.
Рисунок 4.5.1.2 - Диаграмма последовательности
«Поиск информации» - основной поток (подчиненный поток «Поиск информации по
ФИО»).
В результате логического моделирования предмета
разработки были обследованы и построены следующие диаграммы:
диаграмма деятельности системы в целом;
диаграмма деятельности к сервисам
предоставляемым администратору и менеджеру системы;
диаграмма последовательности для описанных
прецедентов;
диаграмма кооперации для описанных прецедентов;
диаграммы классов для статической модели,
описанных прецедентов, клиентской и серверной части проектов.
Так же были спроектированы макеты экранных форм.
5. Физическое моделирование предмета
разработки
.1 Предисловие
В качестве инструмента разработки был выбран
Borland Delphi 7. Выбранная СУБД - SQL Server 2000.
5.2 Диаграммы последовательности с
учётом языка реализации
Диаграмма последовательности прецедента «Поиск
информации» показана на рисунке 5.2.1
Рисунок 5.2.1 - Диаграмма последовательности
прецедента «Поиск информации»
5.3 Компоненты клиентской части
приложения
Диаграмма компонентов позволяет определить
архитектуру разрабатываемой системы, установив зависимости между программными
компонентами, в роли которых может выступать исходный, бинарный и исполняемый
код.
Реализация компонента осуществляется с
использованием классов и их взаимодействий, которые отображаются в логическом
представлении. В логическом представлении каждый класс реализует, как минимум,
один компонент.
Диаграмма компонентов к проекту «Учет
успеваемости» приведена на рисунок 5.3..1.
Рисунок 5.3.1 - Диаграмма компонентов серверной
части проекта
Здесь показано физическое взаимодействие
основных модулей программы.
.4 Развёртывание приложения
Диаграмма развертывания применяется для
представления общей конфигурации и топологии распределенной программной системы
и содержит распределение компонентов по отдельным узлам системы. Кроме того,
диаграмма развертывания показывает наличие физических соединений - маршрутов
передачи информации между аппаратными устройствами, задействованными в
реализации системы [3].
Диаграмма развертывания представлена на рисунке
3.6
Рисунок 5.4.1 - Диаграмма развертывания проекта
Здесь представлена фундаментальная
структурно-организационная схема программных систем.
В результате физического моделирования предмета
разработки была исследована физическая модель проекта и на основании ее были
построены диаграммы последовательности ко всем прецедентам (с учетом языка
реализации), диаграммы компонентов клиентской и серверной части, а так же
диаграмма развертывания проекта.
Заключение
В данном проекте была создана модель AS-IS.
Результаты анализа и улучшения бизнес-процессов были представлены в модели TO-BE.
На основе модели TO-BE
построена модель данных, проведено как логическое, так и физическое
моделирование предмета разработки.
Анализ и проектирование программного обеспечения
являются начальными и значительными этапами в жизненном цикле разработки
программного продукта. Поэтому очень важно уделить должное внимание этим
этапам.
В ходе данной работы были освоены наиболее часто
употребляемые на реальных проектах средства автоматизированного проектирования,
такие как Rational
Rose, BpWin,
ErWin, Microsoft
Visio. Были изучены
возможности, достоинства и недостатки каждой из перечисленных систем. С
использованием этих средств был спроектирован программный продукт
информационная система «Учет успеваемости». Поставленные в работе цели были
выполнены успешно.
Литература
.Коналлен
Д. Разработка Web-приложений с использованием UML и его расширения. - М.:
Вильямс, 2001. - 288 с.: ил.
.Технология
программирования: Моделирование программных систем: Метод. указания и задания к
лабораторным работам / Авт.-сост. Л.Ф. Дробушевич. - Мн.: БГУ, 2003. - 66 с.
.Буч
Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя: Пер.с англ. -
М.: ДМК, 2000.- 360 с.: ил.
.Руководство
по программному пакету ERwin. [Режим доступа
http://www.emanual.ru/download/www.eManual.ru_510.html]
.Бугай
О.В., Бухвалова И.А., Ковальков А.Т., Разоренов Н.А. Методические указания по
выполнению дипломного проекта для студентов специальности Т10.02.00
«Программное обеспечение информационных технологий». Мн., 2003.