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

Разработка информационной системы в контексте 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. Глоссарий предметной области

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.