Моделирование процессов ИС 'Магазин ноутбуков'

Моделирование процессов ИС 'Магазин ноутбуков'

Содержание

Введение

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

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

.2 Модель AS-IS

.3 Модель TO-BE

.4 Цели и задачи предмета разработки

Резюме

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

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

.2 Список действующих лиц

.3 Список вариантов использования

.4 Диаграммы вариантов использования и их описание

2.4.1 Главная диаграмма

.4.2 Прецедент «Вход в систему»

.4.3 Прецедент «Администрирование БД»

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

Резюме

3. Моделирование данных

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

.2 Логическая модель данных

.3 Физическая модель данных

Резюме

4. Логическое моделирование предмета разработки

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

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

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

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

4.4.1 Вариант использования «Вход в систему»

.4.2 Вариант использования «Администрирование БД»

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

4.5 Статическая модель предмета разработки к проекту ИС «Магазин ноутбуков»

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

.5.2 Диаграмма классов к прецеденту «Администрирование БД»

.5.3 Диаграмма классов к прецеденту «Использование БД»

.5.4 Диаграмма классов клиентской части приложения

.5.5 Диаграмма классов серверной части приложения

Резюме

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

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

.2 Диаграммы компонентов

5.2.1 Диаграмма компонентов клиентской части приложения

.2.2 Диаграмма компонентов серверной части приложения

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

Резюме

Заключение

Литература

Введение

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

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

На сегодняшний день существует целая система инженерных принципов для создания экономичного ПО с заданными характеристиками качества. Для достижения этих целей создано множество инструментальных средств, одними которых являются: Rational Rose, предназначенное для моделирования, разработки и поддержки ПО, BPwin - средство для визуального моделирования бизнес-процессов, ERwin - CASE-средство для проектирования и документирования баз данных, Microsoft Visio - мощное решение для создания диаграмм для формализации и передачи информации о процессах, инфраструктуре и приложениях.

Целью данной курсовой работы является моделирование к разработке информационной системы «Магазин ноутбуков». Упомянутое включает моделирование бизнес-процессов AS-IS и TO-BE, построение логической и физической модели данных, а также логической и физической моделей приложения. При работе используются следующие инструментальные средства: Visio, BPwin, ERwin и Rational Rose.

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

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

Для построения моделей бизнес-процессов можно использовать CASE-средства BPwin, AllFusion Process Modeler, графический редактор Visio и другие инструментальные средства. В данном случае предпочтение было отдано BPwin. При этом были использованы диаграммные техники IDEF0, DFD.

1.2    Модель AS-IS

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

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

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

На основании полученной при этом информации была построена модель AS-IS, показанная на диаграммах ниже и представляющая собой «снимок» существующего положения дел.

На рисунке 1 представлена контекстная диаграмма процесса «Магазин ноутбуков», а на рисунке 2 представлена его декомпозиция.

Рисунок 1 - Контекстная диаграмма деятельности магазина ноутбуков

Рисунок 2 - DFD-диаграмма деятельности магазина ноутбуков

1.3    Модель TO-BE

Существенным недостатком модели AS-IS является создание идеализированной модели, особенно в том случае, когда модель создается под влиянием знаний (точки зрения) руководителя. Помимо этого, к наиболее распространенным ошибкам можно отнести такие как:

·        бесполезные, неуправляемые и дублирующие функции;

·        неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время);

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

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

С учетом сказанного была построена модель TO-BE, показанная на диаграммах ниже (см. рис. 3-4).

Рисунок 1.3. - Контекстная диаграмма процесса «Деятельность магазина по продаже ноутбуков»

Рисунок 1.4. - Декомпозиция контекстной диаграммы процесса «Деятельность магазина по продаже ноутбуков»

1.4    Цели и задачи предмета разработки

В соответствии с моделью TO-BE целью предмета разработки является упрощение документооборота. При этом разрабатываемая ИС должна поддерживать следующие режимы работы:

)Администрирование БД (создание записей, обновление записей, удаление записей).

)Использование БД (просмотр записей, сортировка записей, поиск записей).

Резюме

В процессе выполнения работы, представленной в данном разделе, было выполнено:

·   обследование целевой деятельности работы магазина ноутбуков;

·        построение модели AS-IS, являющейся снимком существующего положения дел;

·        построение модели TO-BE, по реорганизации существующей ситуации;

·        определение целей и задач предмета разработки.

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

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

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

Язык моделирования может быть представлен нотациями UML, Буча, OMT и др. В данном случае нами была выбрана нотация UML, а в качестве инструментального средства - Rational Rose.

2.2    Список действующих лиц

<Любой пользователь> - <Является общей сущностью для администратора и клиента>

<Администратор> - <Редактирует записи (добавляет, обновляет, удаляет)>

<Клиент> - <Просматривает товары, производит поиск по интересующим параметрам>

2.3    Список вариантов использования

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

-       Вход в систему

-       Администрирование БД:

-       Создание записей;

-       Обновление записей;

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

-       Использование БД:

-       Поиск записи;

-       Сортировку записей;

-       Просмотр записей.

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

2.4.1 Главная диаграмма

Главная диаграмма представлена на рисунке 5.

Рисунок 5 - Контекстная диаграмма ИС "Магазин ноутбуков"

2.4.2 Прецедент «Вход в систему»

Этот прецедент представлен на рисунке 5 и не нуждается в декомпозиции, а его описание дано ниже.

Назначение: данный вариант использования позволяет зарегистрированному пользователю (клиенту или администратору) войти в систему для использования ее функционала.

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

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

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

Постусловие: если вариант использования завершится успешно, то система предоставляет пользователю функционал в соответствии с его ролью. В противном случае приложение завершит свое выполнение.

2.4.3 Прецедент «Администрирование БД»

На рисунке 6 дана декомпозиция прецедента «Администрирование БД».

Рисунок 6 - Декомпозиция прецедента «Администрирование БД»

Ниже дано описание прецедента.

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

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

) Создание записей:

-   Система предоставляет специальную форму для добавления информации о товарах.

-       Администратор на указанной форме вводит всю необходимую информацию. После ввода всех необходимых данных система добавляет новые товары в БД.

2) Обновление записей:

-   Система предоставляет специальную форму для обновления информации о ноутбуках.

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

3) Удаление записей:

-   Система предоставляет специальную форму для удаления информации о ноутбуках.

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

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

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

2)Не заполнены обязательные поля или заполнены неверно при обновлении информации о товаре: если во время выполнения подчиненного потока «Обновление информации о товаре», система обнаружит, что Администратор не заполнил все необходимые поля или заполнил их неверными данными, то выдается сообщение о допущенных ошибках. Администратор может либо исправить ошибки и повторить попытку добавления информации, либо отменить операцию, после чего основной поток начнется сначала.

)Добавление отменено: если во время выполнения подчиненного потока «Добавление информации», Администратор решил не добавлять данные, добавление не производится, и основной поток начинается сначала.

)Обновление отменено: если во время выполнения подчиненного потока «Обновление информации о товаре», Администратор решил не обновлять информацию о товаре, обновление не производится, и основной поток начинается сначала.

)Удаление отменено: если во время выполнения подчиненного потока «Удаление товара», Администратор решил не удалять товар, удаление не производится, и основной поток начинается сначала.

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

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

На рисунке 7 дана декомпозиция прецедента «Использование БД».

Ниже дано описание прецедента.

Рисунок 7 - Декомпозиция прецедента «Использование БД»

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

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

) Сортировка записей: система предоставляет возможность отсортировать информацию о ноутбуках.

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

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

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

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

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

Резюме

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

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

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

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

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

3.      Моделирование данных

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

Основой для построения модели данных послужили результаты обследования целевой деятельности с построением моделей AS-IS и TO-BE. В качестве инструментария для моделирования данных было отдано предпочтение CASE-средству ERwin.

3.2    Логическая модель данных

В результате анализа DFD-диаграммы декомпозиции процесса «Деятельность магазина по продаже ноутбуков» (модель TO-BE), выполнения необходимой нормализации (до 3 н.ф.), определения отношений между сущностями была построена логическая модель данных, представленная на различных уровнях на рисунках 8-12.

Рисунок 8 - Логическая модель на уровне сущностей

Рисунок 9 - Логическая модель на уровне атрибутов

Рисунок 10 - Логическая модель на уровне ключей

Рисунок 11 - Логическая модель на уровне определений

Рисунок 12 - Логическая модель данных на уровне презентаций

3.3    Физическая модель данных

После выбора в качестве базовой СУБД, была построена физическая модель данных, показанная ниже на рисунках 13-14.

Рисунок 13 - Физическая модель на уровне колонок

Рисунок 14 - Физическая модель «Магазин ноутбуков» на уровне первичных ключей

Резюме

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

·        выделение сущностей и атрибутов модели данных;

·        определение отношений между сущностями;

·        построение логических моделей, представленной на различных уровнях;

·        определение в качестве СУБД MS SQL с построением физической модели данных.

логический интерфейс серверный прецедент

4.      Логическое моделирование предмета разработки

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

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

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

Для выделения классов анализа был создан глоссарий предметной области, представленный в таблице 1.

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

С использованием данного глоссария были выделены классы для варианта использования ИС «Магазин ноутбуков», которые могут быть сгруппированы следующим образом, представленным в таблице 2.

Таблица 2 - Классы анализа

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

Поведение системы, если ее трактовать как объект класса, может быть представлено в виде следующих диаграмм деятельности, представленных на рисунках 15-17.

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

Рисунок 16 - Диаграмма деятельности «Работа в роли администратора»

Рисунок 17 - Диаграмма деятельности «Работа в роли клиента»

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

4.4.1 Вариант использования «Вход в систему»

На рисунке 18 приведена диаграмма последовательности с иллюстрацией сообщений основного потока.

На рисунке 19 приведена диаграмма кооперации с иллюстрацией сообщений основного потока.

На рисунке 20 показана экранная форма к диаграммам, представленным выше.

Рисунок 18 - Диаграмма последовательности основного потока

Рисунок 19 - Диаграмма кооперации основного потока

Рисунок 20 - Экранная форма основного потока

4.4.2 Вариант использования «Администрирование БД»

На рисунках 21-24 приведены диаграммы последовательностей: с иллюстрацией сообщений основного потока и декомпозицией каждого из этих сообщений в виде отдельных диаграмм.

Рисунок 21 - Диаграмма последовательности основного потока

Рисунок 22 - Диаграмма последовательности основного потока (создание записи)

Рисунок 23 - Диаграмма последовательности основного потока (обновление записи)

Рисунок 24 - Диаграмма последовательности основного потока (удаление записи)

На рисунках 25-28 приведены диаграммы кооперации: с иллюстрацией сообщений основного потока и декомпозицией каждого из этих сообщений в виде отдельных диаграмм.

Рисунок 25 - Диаграмма коопераций основного потока

Рисунок 26 - Диаграмма коопераций основного потока (создание записи)

Рисунок 27 - Диаграмма коопераций основного потока (обновление записи)

Рисунок 28 - Диаграмма коопераций основного потока (удаление записи)

На рисунках 29-30 показаны экранные формы к диаграммам, представленным выше.

Рисунок 29 - Экранная форма основного потока*

*Примечание: эта форма используется удаления данных.

Рисунок 30 - Экранная форма основного потока (создание записи/обновления записи)

На рисунках 31-33 приведены диаграммы последовательностей: с иллюстрацией сообщений основного потока и декомпозицией каждого из этих сообщений в виде отдельных диаграмм.

Рисунок 31 - Диаграмма последовательности основного потока

Рисунок 32 - Диаграмма последовательности основного потока (просмотр/сортировка записей)

Рисунок 33 - Диаграмма последовательности основного потока (поиск записей)

На рисунках 34-36 приведены диаграммы кооперации: с иллюстрацией сообщений основного потока и декомпозицией каждого из этих сообщений в виде отдельных диаграмм.

Рисунок 34 - Диаграмма коопераций основного потока

Рисунок 35 - Диаграмма коопераций основного потока (просмотр/сортировка записей)

Рисунок 36 - Диаграмма коопераций основного потока (поиск записей)

На рисунках 37-38 показаны экранные формы к диаграммам, представленным выше.

Рисунок 37 - Экранная форма основного потока*

*Примечание: эта форма используется для просмотра и сортировки данных.

Рисунок 38 - Экранная форма основного потока (поиск записи)

4.5    Статическая модель предмета разработки к проекту ИС «Магазин ноутбуков»

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

Диаграмма классов пользовательского интерфейса программы ИС «Магазин ноутбуков» представлена на рисунке 39.

Рисунок 39 - Диаграмма классов пользовательского интерфейса проекта в целом

4.5.2 Диаграмма классов к прецеденту «Администрирование БД»

Диаграмма классов к варианту использования «Администрирование БД» представлена на рисунке 40.

Рисунок 40 - Диаграмма классов варианта использования «Администрирование БД»

4.5.3 Диаграмма классов к прецеденту «Использование БД»

Диаграмма классов к варианту использования «Использование БД» представлена на рисунке 41.

Рисунок 41 - Диаграмма классов варианта использования «Использование БД»

4.5.4 Диаграмма классов клиентской части приложения

Диаграмма классов клиентской части приложения ИС «Магазин ноутбуков» представлена на рисунке 42.

Рисунок 42 - Диаграмма классов клиентской части приложения

4.5.5 Диаграмма классов серверной части приложения

Диаграмма классов серверной части приложения ИС «Магазин ноутбуков» представлена на рисунке 43.

Рисунок 43 - Диаграмма классов серверной части приложения

Резюме

В ходе дальнейшего логического моделирования ПО, описанного в данном разделе, было выполнено:

·   выделены классы анализа;

·        выполнено моделирование поведения предмета разработки, в виде диаграмм деятельности;

·        выполнено построение моделей взаимодействия объектов к вариантам использования с проработкой экранных форм;

·        выполнение построения статической модели ПО с привлечением диаграммы классов.

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

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

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

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

В связи с тем, что имена классов с учетом языка реализации совпадают с именами, указанными в разделе 4.5, то в их представлении нет необходимости.

5.2    Диаграммы компонентов

5.2.1 Диаграмма компонентов клиентской части приложения

Диаграмма компонентов клиентской части приложения представлена на рисунке 44.

Рисунок 44 - Компоненты, составляющие клиентскую часть приложения ИС «Магазин ноутбуков»

5.2.2 Диаграмма компонентов серверной части приложения

Диаграмма компонентов серверной части приложения представлена на рисунке 45.

Рисунок 45 - Компоненты, составляющие серверную часть приложения ИС «Магазин ноутбуков»

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

Диаграмма развертывания к приложению ИС «Распределение студентов» представлена на рисунке 46.

Рисунок 46 - Диаграмма развертывания приложения ИС «Магазин ноутбуков»

Резюме

В данном случае физическое моделирование сводилось к:

·  уточнению диаграмм последовательности с учетом языка реализации C#;

·        уточнению диаграмм классов с учетом языка реализации;

·        построению диаграмм компонентов;

Заключение

Результатом выполнения курсовой работы является разработанная и спроектированная информационная система «Магазин ноутбуков». Построена модель текущего состояния дел и выявлены недостатки ее реализации, в результате чего разработана схема, предлагающая замену бумажного носителя информации на электронный, а именно - базу данных.

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

Тем самым достигнуто сокращение времени и повышение качества разработки ПО, обеспечена высокая степень его независимости от конкретных разработчиков, а также снижены затраты на разработку и сопровождение ПО.

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

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

Литература

1.   Маклаков С.В. BРwin и ERwin. CASE-средства разработки информационных систем. / С.В. Маклаков. - 2-е изд., испр. и доп. - М.: ДИАЛОГ-МИФИ, 2001. - 304 с.

2.      Буч Г. Язык UML: Руководство пользователя / Г. Буч, Д. Рамбо, А. Джекобсон; пер. с англ. - М.: ДМК, 2000. - 432 с.

.        Трофимов С.А. CASE-технологии: практическая работа в Rational Rose / С.А. Трофимов. - 2-е изд. - М.: Бином - Пресс, 2002. - 288 с.

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

.        Бугай О.В. Системы автоматизированного проектирования ПО. / О.В. Бугай - Мн.:2008. - 51 с.

.        Бугай О.В. Моделирование к разработке программного обеспечения в Visio./ О.В. Бугай. - Мн.: 2010. - 63 с.