Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Разработка информационной системы в контексте AS-IS и TO-BE

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

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 26.01.2013
Размер файла 914,5 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Введение

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

Стремительное развитие и повсеместное применение информационных технологий, превращение информации в ценнейший ресурс жизнедеятельности обусловливает движение человечества к информационному обществу. В условиях перехода к информационному обществу ведение эффективного бизнеса и достижение высокого качества жизни возможны только при условии эффективного управления информационными ресурсами. Сегодня потребитель должен иметь возможность получать требуемую информацию в нужном виде, в приемлемые сроки, практически в любом месте и за умеренную плату.[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].

Диаграмма вариантов использования изображена на рисунке 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 Глоссарий предметной области

Глоссарий предназначен для описания терминологии предметной области. Он может быть использован как неформальный словарь данных системы. Словарь нужен для того, чтобы обнаружить классы и объекты (или кандидатов на роль классов и объектов) [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.4 Взаимодействие объектов и экранные формы

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

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].

Диаграмма развертывания представлена на рисунке 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_510.html]

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

Размещено на Allbest.ru

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены