Разработка информационной системы библиотеки

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

Содержание

• Введение
• 1. Анализ предметной области задания
• 2. Разработка диаграммы вариантов использования
• 2.1 Построение диаграммы вариантов использования
• 2.2 Оценка трудозатрат на разработку ПО на основе диаграммы вариантов использования
• 2.2.1 Определение весовых показателей действующих лиц
• 2.2.2 Определение весовых показателей вариантов использования
• 2.2.3 Определение технической сложности проекта
• 2.2.4 Определение уровня квалификации разработчиков
• 2.2.5 Оценка трудозатрат проекта
• 3. Разработка диграммы классов
• 4. Разработка диаграмм последовательностей
• 5. Разработка диаграмм компонентов
• 6. Разработка диаграмм развертывания
• Заключение
• Список использованных источников
• Приложения


Введение

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

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

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

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

– создание каталогов книг;

– генерация гистограмм читательского спроса;

– учет выдачи и сдачи книг;

– напоминания пользователям о необходимом возврате книг.



1. Анализ предметной области задания

Информационная система библиотека должна содержать следующие сведения о объектах.

Читатель

Атрибуты: фамилия, имя, отчество, телефон, адрес, номер читательского билета, дата регистрации, дата перерегистрации, выданные книги (инвентарный номер книги, дата выдачи);

Библиотекарь

Атрибуты: фамилия, имя, отчество, телефон, дата регистрации.

Администратор

Атрибуты: фамилия, имя, отчество, телефон, дата регистрации.

Выходные документы информационной системы библиотеки.

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

Бизнес-правила информационной системы библиотеки.

– читатель может быть зарегистрирован только один раз;

– общее количество книг, выданных одному читателю, не может превышать 10;

– книги выдаются на срок не более 15 дней;

– напоминание читателям делается через 5 дней после истечения срока сдачи;

– сведения о выданных книгах сохраняются в течение года.

Информационная система должна иметь три подсистемы: подсистема

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



2. Разработка диаграммы вариантов использования

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

библиотечный диаграмма читательский каталог

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

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

Основными элементами (предметами языка UML), отображаемыми на диаграмме вариантов использования, являются: вариант использования, актер, системная граница примечание.

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

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

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

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

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

1 Отношение ассоциации:

– между актерами и вариантами использования «Аутентификация»;

– между вариантом использования «Аутентификация» и вариантом использования «Просмотр имеющихся книг в библиотеке»;

– между вариантом использования «Аутентификация» и вариантом использования «Просмотр аннотации книги»;

– между вариантом использования «Аутентификация» и вариантом использования «Формирование запроса на выдачу книги»;

– между вариантом использования «Аутентификация» и вариантом использования «Обработка запроса на выдачу книг»;

– между вариантом использования «Аутентификация» и вариантом использования «Просмотр каталогов»;

– между вариантом использования «Аутентификация» и вариантом использования «Редактирование книжного фонда»;

– между вариантом использования «Аутентификация» и вариантом использования «Сортировка книг по каталогам»;

– между вариантом использования «Аутентификация» и вариантом использования «Редактирование информации о читателях»;

– между вариантом использования «Аутентификация» и вариантом использования «Администрирование системы»;

– между вариантом использования «Аутентификация» и вариантом использования «Хранение данных»;

2 Отношение расширения:

– вариант использования «Запрос на выдачу книги» может быть расширен вариантом использования «Формирование карточки напоминания».

– вариант использования «Просмотр каталогов» может быть расширен вариантам использования «Формирование гистограммы читательского спроса на книги по каталогам».

3 Отношение включения:

– вариант использования «Запрос на выдачу книг» может включать в себя варианты использования «Выбор каталога», «Ввод информации о сроках возврата книги».

Итоговая диаграмма вариантов использования для разрабатываемого программного обеспечения информационной системы салона красоты, выполненная в CASE-средстве Enterprise Architect 7.5, представлена в приложении А.

2.2 Оценка трудозатрат на разработку ПО на основе диаграммы вариантов использования

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

Все действующие лица системы делятся на три типа: простые, средние и сложные. Простое действующее лицо представляет внешнюю систему с четко определенным программным интерфейсом (API). Среднее действующее лицо представляет либо внешнюю систему, взаимодействующую с данной системой посредством протокола наподобие TCP/IP, либо личность, пользующуюся текстовым интерфейсом (например, ASCII-терминалом). Сложное действующее лицо представляет личность, пользующуюся графическим интерфейсом (GUI). Подсчитанное количество действующих лиц каждого типа умножается на соответствующий весовой коэффициент из таблицы 2.1, затем вычисляется общий весовой показатель A.

Таблица 2.1 Весовые коэффициенты действующих лиц

Тип действующего лица	Весовой коэффициент
Простое	1
Среднее	2
Сложное	3



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

2.2.2 Определение весовых показателей вариантов использования

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

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

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

Таблица 2.2 Весовые коэффициенты вариантов использования

Тип варианта использования	Описание	Весовой коэффициент
Простой	3 или менее транзакций	5
Средний	От 4 до 7 транзакций	10
Сложный	Более 7 транзакций	15

Сложность вариантов использования для проектируемого продукта представлена в таблице 2.3.

Таблица 2.3 Сложность вариантов использования

Вариант использования	Тип	Весовой коэффициент
Аутентификация	Средний	10
Просмотр списка услуг	Простой	5
Оформление заказа	Сложный	15
Формирование счёта клиенту	Сложный	15
Ввод информации о клиенте	Простой	5
Ввод заказанных услуг	Простой	5
Просмотр истории заказов	Средний	10
Просмотр списка сотрудников	Простой	5
Вариант использования	Тип	Весовой коэффициент
Удаление информации о сотруднике	Простой	5
Увольнение сотрудника	Средний	10
Прием на работу (добавление сотрудника)	Простой	5
Изменение информации о сотруднике	Простой	5
Перемещение сотрудника	Средний	10
Просмотр списка материалов	Простой	5
Добавление материала	Простой	5
Удаление материала	Простой	5
Редактирование информации о материале	Простой	5
Формирование справки о распределении материалов	Сложный	15
Просмотр списка услуг	Простой	5
Редактирование услуги	Простой	5
Добавление услуги	Простой	5
Удаление услуги	Простой	5
Учет выдачи материалов мастерам	Сложный	15
Сумма весовых коэффициентов:	175

Общий весовой показатель равен:

UCP = 5 * 15 + 4 * 10 + 4 * 15 = 175.

В результате получаем показатель UUCP:

UUCP = А + UCP = 6 + 175 = 181.

2.2.3 Определение технической сложности проекта

Техническая сложность проекта (TCF -- technical complexity factor) вычисляется с учетом показателей технической сложности.

Каждому показателю присваивается значение Ti в диапазоне от 0 до 5 (0 означает отсутствие значимости показателя для данного проекта, 5 -- высокую значимость). Значение TCF вычисляется по следующей формуле:

TCF = 0.6 + (0.01 * (? Ti Весi)).



Настройка показателей технической сложности проекта, выполненная в CASE-средстве Enterprise Architect 7.5, представлена на рисунке 2.1.

Вычислим значение TCF:

TCF = 0.6 + (0.01 * 47.00) = 1.07.

Рисунок 2.1 Настройка показателей технической сложности проекта

2.2.4 Определение уровня квалификации разработчиков

Уровень квалификации разработчиков (EF -- environmental factor) вычисляется с учетом показателей F1 - F8 по формуле:

EF = 1.4 + (-0.03 * (? Fi Весi)).

Каждому показателю присваивается значение в диапазоне от 0 до 5. Для показателей F1 - F4 0 означает отсутствие, 3 - средний уровень, 5 - высокий уровень.

Для показателя F5 0 означает отсутствие мотивации, 3 - средний уровень, 5 - высокий уровень мотивации. Для F6 0 означает высокую нестабильность требований, 3 - среднюю, 5 - стабильные требования. Для F7 0 означает отсутствие специалистов с частичной занятостью, 3 - средний уровень, 5 - все специалисты с частичной занятостью. Для показателя F8 0 означает простой язык программирования, 3 - среднюю сложность, 5 - высокую сложность. Настройка показателей уровня квалификации разработчиков, выполненная в CASE-средстве Enterprise Architect 7.5, представлена на рисунке 2.2.

Рисунок 2.2 Настройка показателей уровня квалификации разработчиков

Вычислим значение EF:

EF = 1.4 + (-0.03 * 21.50) = 0.755.

В результате получаем окончательное значение UCP (use case points):

UCP = UUCP * TCF * EF = 181 * 1.07 * 0.755 = 146.

2.2.5 Оценка трудозатрат проекта

Для разрабатываемой системы примем 20 человеко-часов на одну UCP. Таким образом, общее количество человеко-часов на весь проект равно 146 * 20 = 2920. Если принять стоимость часа работы равной 40 денежным единицам, то стоимость проекта будет равна 2920 * 40 = 116800 денежным единицам.

Расчет трудозатрат проекта в CASE-средстве Enterprise Architect 7.5 представлен на рисунке 2.3.

Рисунок 2.3 Расчет трудозатрат проекта в CASE-средстве Enterprise Architect 7.5



3. Разработка диграммы классов

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

Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).

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

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

Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями в языке UML являются:

– Зависимости (dependency relationship);

– Ассоциации (association relationship);

– Обобщения (generalization relationship)

Диаграмма классов занимает центральное место при проектировании программной системы с использованием объектно-ориентированного подхода к разработке ПО. Большинство современных CASE-средств осуществляют автоматическую генерацию кода основываясь именно на этой диаграмме.

Диаграмма классов в нашем случае представляет собой собственно базу данных. [4]

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

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

1 Читатель:

– Код читателя;

– Фамилия;

– Имя;

– Отчество;

– Телефон;

– Адрес;

– Номер читательского билета;

– Дата регистрации;

– Дата перерегистрации;

– Выданные книги;

– Инвентарный номер книги;

– Дата выдачи;

2 Книжный фонд:

– Код книги;

– Название книги;

– Авторы книги;

– Год издательства;

– Количество экземпляров;

– Список инвентарных номеров;

3 Библиотекарь:

– Код библиотекаря;

– Фамилия;

– Имя;

– Отчество;

– Телефон;

4 Систематический каталог:

– фантастика;

– поэзия;

– стихи;

– поэмы;

– повести;

5 Администратор:

– Код администратора;

– Имя;

– Фамилия;

– Отчество;

– Телефон;

В конечном счёте была построена диаграмма классов, выполненная в CASE-средстве Enterprise Architect 7.5, которая представлена в приложении Б.



4. Разработка диаграмм последовательностей

Диаграмма последовательности -- диаграмма, на которой показано взаимодействие объектов (обмен между ними сигналами и сообщениями), упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления. [4]

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

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

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

- процесс авторизации читателя;

- процесс выдачи книги библиотекарем;

- процесс редактирования книжного фонда администратором.

Все диаграммы выполнены в CASE-средстве Enterprise Architect 7.5, представлены на рисунках 4.1 - 4.3.

Диаграмма процесса авторизации пользователя состоит из трёх линий жизни, которые представляют Пользователя, ИС «Библиотека» и СУБД. После ввода пользователем логина и пароля, данные проверяются в СУБД. В зависимости от результата проверки в программе или открывается главная форма, или выводится сообщение о неверном логине или пароле.



Рисунок 4.1 Диаграмма процесса авторизации читателя

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



Рисунок 4.2 Диаграмма процесса выдачи книги библиотекарем

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



Рисунок 4.3 Диаграмма процесса редактирование книжного фонда



5. Разработка диаграмм компонентов

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

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

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

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

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

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

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

Диаграмма компонентов информационной системы «Библиотека» представлена на рисунке 5.1.

Рисунок 5.1 Диаграмма компонентов ИС «Библиотека»

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

- файлы, связанные с разработкой программы;

- файлы, необходимые для хранения данных;

- файлы, описывающие интерфейс программы.

Большая часть компонентов помечена стереотипом «interface». Такие компоненты представляют основные формы приложения, необходимые для взаимодействия пользователя с программой. Компонент «Главная форма» является самым значимым среди них, так как является связующим звеном.

Компонент «База данных» помечен стереотипом «datastore» и относится непосредственно к СУБД.

Компоненты, помеченные стереотипами «library», «source» и «executable» относятся к процессу создания приложения в среде разработки.



6. Разработка диаграмм развертывания

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

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

Узлы устройств -- это физические вычислительные ресурсы со своей памятью и сервисами для выполнения программного обеспечения, такие как обычные ПК, мобильные телефоны. Узел среды выполнения -- это программный вычислительный ресурс, который работает внутри внешнего узла и который предоставляет собой сервис, выполняющий другие исполняемые программные элементы.

В данном случае к физическим узлам относятся сервер базы данных (среда выполнения - СУБД Microsoft SQL Server 2013) и персональный компьютер пользователя (среда выполнения - ODBC драйвер, платформа Microsoft.NET Framework). Кроме того, одним из компонентов для пользовательской машины является исполняемый файл информационной системы. На диаграмме он связан с ПК, но вынесен отдельно, так как приложение не обязательно должно устанавливаться и может быть запущено с внешнего носителя.

Диаграмма развертывания разрабатываемого программного обеспечения, выполненная в CASE-средстве Enterprise Architect 7.5, представлена в приложении В.



Заключение

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

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

- диаграмма классов;

- диаграмма последовательности;

- диаграмма компонентов;

- диаграмма развертывания.

В результате выполнения курсовой работы:

- спроектирована информационная система салона красоты;

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

- выявлены главные функции организации;

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

- составлена схема базы данных;

- разработаны диаграммы вариантов использования, компонентов, развёртывания, которые наглядно показывают структуру нашей информационной системы, внутреннее взаимодействие и взаимодействие с внешними компонентами;



Список использованных источников

1 Лекции по дисциплине «Системы управления базами данных» для студентов специальности 1-40 01 01 Программное обеспечение информационных технологий специализации 1-40 01 01 01 Компьютерные системы и ИНТЕРНЕТ технологии/ сост. И. Б. Бураченок;

2 Лекции по дисциплине «Технологии разработки программного обеспечения» для студентов специальности 1-40 01 01 Программное обеспечение информационных технологий специализации 1-40 01 01 01 Компьютерные системы и ИНТЕРНЕТ технологии/ сост. С.П.Чеботарёв;

3 Введение в системы управления базами данных [Электронный ресурс]. - Режим доступа: http://citforum.ru/database/dblearn/;

4 Википедия -свободная энциклопедия [Электронный ресурс]/A wikipedia project - Режим доступа: http://ru.wikipedia.org/wiki/Инструменты_UML-моделирования. - Дата доступа: 18.11.2012;

5 Подключение процедур в C# [Электронный ресурс]. - Режим доступа: http://workmake.ru/bazyi-dannyih/sql-zaprosyi-podrobnaya-instruktsiya-po-sozdaniyu-i-ispolzovaniyu-sql-zarosov-primeryi-razlichnyih-sql-zaprosov/;

6 Создание запросов [Электронный ресурс]. - Режим доступа: http://codingcraft.ru/sql_queries.php;



Приложение А

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



Приложение Б

Диаграмма классов



Приложение В

Диаграмма развёртывания

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

...