Разработка информационной системы в контексте AS-IS и TO-BE

справочный система программный диаграмма

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

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

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

Так как в данной системе используется большой объем данных, будет целесообразно разместить их в базе данных под управлением некоторой СУБД.

Вследствие значительного жизненного цикла может оказаться, что в процессе создания системы внешние условия изменились. Обычно внесение изменений в проект на поздних этапах создания справочной системы — весьма трудоемкий и дорогостоящий процесс. Поэтому для успешной реализации крупного проекта необходимо, чтобы инструментальные средства, на которых он реализуется, были достаточно гибкими к изменяющимся требованиям.

Данный курсовой проект посвящен анализу и проектированию к разработке информационной системы «Учет успеваемости». Для этой цели были выбраны инструментальные средства визуального проектирования BPWin и Rational Rose.

1. Предмет разработки в контексте AS-IS и TO-BE

1.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) Журнал ведомостей;

3) Обработка ведомостей;

4) Вложение папки;

5) Архивация ведостей;

6) Выдача сотрудникам;

Рисунок 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) Обеспечить корректный и полный вывод информации о студенте;

3) Обеспечить корректный и полный вывод информации о факультете;

4) Обеспечить удобное редактирование базы данных и корректное её сохранение.

В процессе обследования предметной области была построена и изучена модель AS-IS. На основании модели AS-IS, была построена модель TO-BE, были определены цели и задачи будущего предмета разработки.

2.Техническое задание на предмет разработки

2.1 Предисловие

Модель вариантов использования предназначается для определения требований к системе. Она включает в себя актеров, варианты использования и связи между ними. Для отображения этой модели язык UML предлагает использовать диаграммы Use Case (вариант использования) совместно с моделями State Diagram (диаграммы состояний) и Activity Diagram (диаграммы деятельности/активности). Последние используются для конкретизации вариантов использования системы.

2.1 Модель вариантов использования информационной системы «Учет успеваемости»

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

2.2 Действующие лица

Большинство систем имеет множество категорий пользователей. Поэтому каждая категория пользователей представляется отдельным действующим лицо (актером). Актер — это любая сущность, взаимодействующая с системой извне.

В данном проекте выделены следующие действующие лица:

Администратор — сотрудник информационной системы, в обязанности которого входит своевременное редактирование базы данных.

Пользователь — любой человек, который может просматривать информацию.

2.3 Варианты использования

Актеры взаимодействуют с системой с помощью так называемых вариантов использования. Каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером.

Приведем список возможных вариантов использования программного продукта:

· Редактирование базы данных.

· Просмотр базы.

· Добавление нового студента.

· Добавление нового факультета.

· Удаление записи.

· Редактирование записи.

· Сохранение изменений.

· Поиск по фамилии.

· Поиск по специальности.

2.4 Диаграмма вариантов использования

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

Основные взаимодействия между действующими лицами и вариантами использования задаются с помощью связи коммуникации. Задается в виде простой стрелки. Направление стрелки показывает, кто инициирует связь (всегда действующее лицо) и какой вариант использования отправляет информацию внешнему действующему лицу.

Диаграмма вариантов использования изображена на рисунке 2.1.

На рисунке 2.2 представлена детализация варианта использования информационной системы «Учет успеваемости».

Рисунок 2.1 — Диаграмма вариантов использования

2.5 Описание вариантов использования

2.5.1 Прецедент «Использование БД»

Назначение: данный вариант использования описывает возможность редактирования данных. Основной поток событий: cистема запрашивает требуемое действие (удаление студента, удаление факультета, изменение данных о студенте, изменение данных о факультете, добавление нового факультета, добавление нового студента).После того, как Администратор указывает действие, выполняется один из подчиненных потоков: удалить студента, удалить факультет, изменить данные о студенте, изменить данные о факультете, добавить новый факультет, добавить нового студента.

1) Удалить студента:

— Администратор указывает необходимого студента.

— Система выдает запрос на подтверждение удаления.

— После подтверждения удаления система удаляет из базы данных информацию об студенте.

2) Удалить факультет

— Администратор указывает необходимый факультет.

— Система выдает запрос на подтверждение удаления.

— После подтверждения удаления система удаляет из базы данных информацию о факультете.

3) Изменить данные о студенте

— Администратор указывает необходимого студента.

— Система дает возможность редактирования.

— После этого Администратор изменяет необходимые поля.

4) Изменить данные о факультете

— Администратор указывает необходимый факультет.

— Система дает возможность редактирования.

— После этого Администратор изменяет необходимые поля.

5) Добавление нового факультета

— Система выдает бланк с пустыми полями.

— Администратор заполняет все поля.

— Происходит сохранение данных.

6) Добавление нового студента

— Система выдает бланк с пустыми полями.

— Администратор заполняет все поля.

— Происходит сохранение данных.

Альтернативные потоки.

1) Если данные неверны, то выдается соответствующее сообщение об ошибке и изменений в БД не происходит.

2) Если оператор после изменений нажал кнопку «Отменить изменения», то заново считываются из БД старые данные и новые не сохраняются.

Предсловия. Отсутствуют.

Постсловия.Если изменения в БД прошли успешно, выдается об этом сообщение, в противном случае — сообщение об ошибке.

В ходе работы над частью проекта, представленной в данном разделе выполнено:

— Определение списка действующих лиц с указанием их ролей;

— Определение вариантов использования;

— Построение диаграммы вариантов использования;

— Описание вариантов использования.

3. Моделирование данных к предмету разработки

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. Логическое моделирование предмета разработки

4.1 Предисловие

Ниже в разделе представлены результаты дальнейшего развития логической модели ПО, начало создания которой было положено в разделе «Техническое задание на предмет разработки». Разумеется, язык моделирования и инструментария его реализации остались прежними: UML и Rational Rose .

4.2 Выделение классов анализа

4.2.1 Способы выделения классов анализа

Класс анализа представляет собой абстракцию одного или более классов и/или подсистем в проекте системы. Эта абстракция имеет следующие характеристики:

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

класс анализа не обязан поддерживать какие-либо интерфейсы в понятии операций и их сигнатур (поведение должно быть описано в текстовой форме);

классы анализа связаны в основном отношением «ассоциация»;

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

4.2.2 Глоссарий предметной области

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

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

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

Таблица 1. Глоссарий предметной области

User — класс, определяющий пользователя системы, его параметры, роли

LoginForm — класс, представляющий собой форму аутентификации

AdminForm — форма, позволяющая выполнять административные функции, такие как: добавление, редактирование и удаление студентов, факультетов или специальностей

Search — поиск по заданным критериям.

4.3 Поведение предмета разработки

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

Рисунок 4.3.1- Диаграмма деятельности системы в целом.

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

4.4 Взаимодействие объектов и экранные формы

4.4.1 Вариант использования «Использование БД»

Класс анализа не обязан поддерживать какие-либо интерфейсы и понятия операций и сигнатур. Вместо этого поведения должно быть описано в текстовом формате в соответствии с особенностями класса (обязанностями).

Классы анализа связаны друг с другом отношением «ассоциация». Направленность ассоциаций не слишком важна в анализе, но существенна в проектировании. Также в процессе анализа могут использоваться отношения «обобщения».

Классы анализа всегда можно отнести к одному из типов: граничный, управляющий или сущность. Эти три стереотипа стандартизированы в UML и используются, чтобы помочь разработчикам различать назначения (действия) различных классов.

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

Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия: диаграмма последовательности и диаграмма кооперации.

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. Статическая модель предмета разработки

4.5.1. Диаграмма классов интерфейса предмета разработки

4.5.1 Вариант использования (прецедент) «Поиск информации» - основной поток (подчиненный поток «Поиск информации по ФИО«)

4.5.1.2 Диаграмма классов к прецеденту «Поиск информации»

Диаграмма последовательности «Поиск информации» — основной поток (подчиненный поток «Поиск информации по ФИО») представлена на рисунке 4.5.1.

Рисунок 4.5.1.2 — Диаграмма последовательности «Поиск информации» — основной поток (подчиненный поток «Поиск информации по ФИО»).

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

— диаграмма деятельности системы в целом;

— диаграмма деятельности к сервисам предоставляемым администратору и менеджеру системы;

— диаграмма последовательности для описанных прецедентов;

— диаграмма кооперации для описанных прецедентов;

— диаграммы классов для статической модели, описанных прецедентов, клиентской и серверной части проектов.

Так же были спроектированы макеты экранных форм.

5. Физическое моделирование предмета разработки

5.1 Предисловие

В качестве инструмента разработки был выбран Borland Delphi 7. Выбранная СУБД — SQL Server 2000.

5.2 Диаграммы последовательности с учётом языка реализации

Диаграмма последовательности прецедента «Поиск информации» показана на рисунке 5.2.1

Рисунок 5.2.1 — Диаграмма последовательности прецедента «Поиск информации»

5.3 Компоненты клиентской части приложения

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

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

Диаграмма компонентов к проекту «Учет успеваемости» приведена на рисунок 5.3.1.

Рисунок 5.3.1 — Диаграмма компонентов серверной части проекта Здесь показано физическое взаимодействие основных модулей программы.

5.4 Развёртывание приложения

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

Диаграмма развертывания представлена на рисунке 3.6

Рисунок 5.4.1 — Диаграмма развертывания проекта Здесь представлена фундаментальная структурно-организационная схема программных систем.

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

Заключение

В данном проекте была создана модель AS-IS. Результаты анализа и улучшения бизнес-процессов были представлены в модели TO-BE. На основе модели TO-BE построена модель данных, проведено как логическое, так и физическое моделирование предмета разработки.

Анализ и проектирование программного обеспечения являются начальными и значительными этапами в жизненном цикле разработки программного продукта. Поэтому очень важно уделить должное внимание этим этапам.

В ходе данной работы были освоены наиболее часто употребляемые на реальных проектах средства автоматизированного проектирования, такие как Rational Rose, BpWin, ErWin, Microsoft Visio. Были изучены возможности, достоинства и недостатки каждой из перечисленных систем. С использованием этих средств был спроектирован программный продукт информационная система «Учет успеваемости». Поставленные в работе цели были выполнены успешно.

1.Коналлен Д. Разработка Web-приложений с использованием UML и его расширения. — М.: Вильямс, 2001. — 288 с.: ил.

2.Технология программирования: Моделирование программных систем: Метод. указания и задания к лабораторным работам / Авт.-сост. Л. Ф. Дробушевич. — Мн.: БГУ, 2003. — 66 с.

3.Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. — М.: ДМК, 2000.— 360 с.: ил.

4.Руководство по программному пакету ERwin. [Режим доступа http://www.emanual.ru/download/www.eManual.ru₅₁₀.html]

5.Бугай О. В., Бухвалова И. А., Ковальков А. Т., Разоренов Н. А. Методические указания по выполнению дипломного проекта для студентов специальности Т10.02.00 «Программное обеспечение информационных технологий». Мн., 2003.