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

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

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

Содержание

• Введение
• 1. Предмет разработки в контексте AS-IS и TO-BE
• 1.1 Предисловие
• 1.2 Модель AS-IS
• 1.3 Модель TO-BE
• 1.4 Цели и задачи предмета разработки
• Резюме
• 2. Техническое задание на предмет разработки
• 2.1 Предисловие
• 2.2 Список действующих лиц
• 2.3 Список вариантов использования
• 2.4 Диаграммы вариантов использования и их описание
• 2.4.1 Главная диаграмма
• 2.4.2 Прецедент «Вход в систему»
• 2.4.3 Прецедент «Администрирование БД»
• 2.4.4 Прецедент «Использование БД»
• Резюме
• 3. Моделирование данных
• 3.1 Предисловие
• 3.2 Логическая модель данных
• 3.3 Физическая модель данных
• Резюме
• 4. Логическое моделирование предмета разработки
• 4.1 Предисловие
• 4.2 Выделение классов анализа
• 4.3 Поведение предмета разработки
• 4.4 Взаимодействие объектов и экранные формы к прецедентам
• 4.4.1 Вариант использования «Вход в систему»
• 4.4.2 Вариант использования «Администрирование БД»
• 4.4.3 Вариант использования «Использование БД»
• 4.5 Статическая модель предмета разработки к проекту ИС «Магазин ноутбуков»
• 4.5.1 Диаграмма классов интерфейса предмета разработки
• 4.5.2 Диаграмма классов к прецеденту «Администрирование БД»
• 4.5.3 Диаграмма классов к прецеденту «Использование БД»
• 4.5.4 Диаграмма классов клиентской части приложения
• 4.5.5 Диаграмма классов серверной части приложения
• Резюме
• 5. Физическое моделирование предмета разработки
• 5.1 Предисловие
• 5.2 Диаграммы компонентов
• 5.2.1 Диаграмма компонентов клиентской части приложения
• 5.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 целью предмета разработки является упрощение документооборота. При этом разрабатываемая ИС должна поддерживать следующие режимы работы:

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

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

Резюме

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

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

· построение модели 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 - Декомпозиция прецедента «Администрирование БД»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

Резюме

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

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

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

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

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

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 - Глоссарий предметной области

№	Термин	Значение
1	Форма для управления данными о фирме	Форма, на которой отображаются поля для добавления фирмы или редактирования данных о фирме.
2	Форма для управления данными о поставщике	Форма, на которой отображаются поля для добавления поставщика или редактирования данных о поставщике.
3	Форма для управления данными о ноутбуках	Форма, на которой отображаются поля для добавления ноутбуков или редактирования данных о них.
4	Форма для управления данными в каталоге	Форма, на которой отображаются поля для добавления товара в каталог или редактирования данных о товаре.
5	Форма для управления данными секции	Форма, на которой отображаются поля для добавления секции или редактирования данных о секции.
6	Форма для управления данными о фирме-производителе	Форма, на которой отображаются поля для добавления фирмы или редактирования данных о фирме.
7	Форма входа в систему	Форма, которая открывается при запуске приложения
8	Главная форма	Форма, которая открывается после успешного входа в систему
9	Базовый класс БД	Класс управления данными в БД и приложении

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

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

№	Класс	Значение
1	Граничные	Форма для управления данными о фирме, Форма для управления данными о поставщике, Форма для управления данными о ноутбуках, Форма для управления данными в каталоге, Форма для управления данными секции, Форма для управления данными о фирме-производителе, Главная форма, Базовый класс БД.
2	Управляющие	Программа управления.
3	Сущности	Каталог, Поставщик, Продукция, Фирма, Страна, Секция

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 - Экранная форма основного потока (создание записи/обновления записи)

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

На рисунках 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 с.

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

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

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

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

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