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

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 22.06.2011
Размер файла 1,3 M

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

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

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

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

Министерство образования и науки Российской Федерации

ГОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Факультет информационных технологий и телекоммуникаций

Кафедра прикладной информатики

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К КУРСОВОМУ ПРОЕКТУ НА ТЕМУ:

Разработка объектно-ориентированной модели информационной подсистемы для библиотеки

Автор курсового проекта

Е. В. Романюк

Направление: 080800.62 «Прикладная информатика»

шифр, наименование

Группа: ПИБ-081

Обозначение курсового проекта

КП-СевКавГТУ-080800.62-061833-11

Ставрополь, 2011

Содержание

ВВЕДЕНИЕ

1 КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Общая характеристика

1.2 Актуальность разрабатываемой подсистемы

1.3 Формулировка задач проектирования

2 СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ

3 СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ

4 СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА

5 СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ

6 ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И

ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ

7 СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ ДЛЯ КЛАССОВ И

ДИАГРАММЫ КОМПОНЕНТОВ

8 СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ

9 ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C++

ЗАКЛЮЧЕНИЕ

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

Приложение А

ВВЕДЕНИЕ

Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, информационных систем, организационно-экономических систем, технических систем и других систем различной природы.

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

Среда Rose является лидирующей в области ускоренной разработки и поддерживает разнообразные диаграммы UML: Вариантов Использования, Активности, Последовательности, Кооперативные, Состояний, Компонентов и Размещения. Средства Rose для инжиниринга и реинжиниринга обеспечивают поддержку языков C++, Java, Visual Basic и DTD XML. Дополнительные надстройки для среды Rose позволяют расширить ее функции и работать с другими объектно - ориентированными языками программирования.

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

В данной курсовой работе была разработана объектно-ориентированная модель информационной подсистемы для управления, учета, контроля и ведения библиотеки. Модель разработана с помощью программного продукта Rational Rose 2007, с использованием языка UML.

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

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

В третьем разделе пояснительной записки рассматривается создание диаграммы последовательности (sequence diagrams). Данная диаграмма предназначенная для моделирования процесса обмена сообщениями между объектами;

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

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

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

В седьмом разделе приводится и описывается диаграммы состояний для класса WriteBook. В этом же разделе приводится описание диаграммы компонентов для прецедентов информационной подсистемы «Добавление новой записи о книге».

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

В девятом разделе пояснительной записки приводится и описывается порядок генерации программного кода на языке С++ для данной информационной подсистемы.

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

В приложение вынесены листинги кода проектируемой программы, сгенерированные RationalRose.

1. КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Общая характеристика

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

1.2 Актуальность разрабатываемой подсистемы

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

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

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

1.3 Формулировка задач проектирования

АИС "Библиотеки вуза" предназначена для пользования обслуживающего персонала библиотеки. Система предполагает ведения учета выдаваемых изданий, принятие новых печатных изданий и читателей, отслеживание читателей - задолжников.

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

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

- удаление старых записей о книге при ее потери;

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

2. СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ

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

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

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

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

- просмотр данных;

- поиск книги(указание название книги, автора, издание, год).

Пользователь - библиотекарь выполняет:

- ввод, редактирование данных о книге;

- просмотр данных;

- сохранение данных в базу;

- получение отчетов по запрашиваемым запросам, вывод данных о читателях, выданных книгах.

Администратор выполняет:

- управление всеми операциями;

- назначение прав доступа;

- просмотр и редактирование всех данных.

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

1. Запустим интегрированную среду разработки Rational Rose 2000.

2. Перейдем к главной диаграмме (Main) Use case:

- в браузере щелкнем на значке «+» рядом с представлением Use case, чтобы открыть представление;

- дважды щелкнув на главной диаграмме, откроем её.

3. С помощью кнопки Use Case (вариант использования) панели инструментов поместим на диаграмму новый вариант использования.

4. Назовем его «Просмотр данных».

5. Повторив этапы 3 и 4, поместим на диаграмму остальные варианты использования:

- получение отчетов;

- сохранение данных в базу;

- ввод, редактирование;

- управление всеми операциями;

- просмотр и редактирование всех данных;

- назначение прав доступа.

6. С помощью кнопки Actor (действующее лицо) панели инструментов поместим на диаграмму новое действующее лицо.

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

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

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

7. Назовем его «Пользователь - читатель».

8. Повторив шаги шесть и семь, поместим на диаграмму действующее лицо «Пользователь - библиотекарь», «Администратор»

9. С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) добавим ассоциации между действующим лицом «Пользователь - читатель», «Пользователь - библиотекарь», «Администратор» и всеми вариантами использования.

Выводы

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

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

3. СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ

Диаграмма Последовательности - это упорядоченная по времени диаграмма Взаимодействия, читать ее следует сверху вниз. Как упоминалось раньше, у каждого варианта использования имеется большое количество альтернативных потоков. Каждая диаграмма Последовательности описывает один из потоков варианта использования. Рассмотрим вариант использования «Добавить новую книгу в БД». Диаграмма последовательности приведена на рисунке 3.1.

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

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

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

На приведенной выше диаграмме выделены следующие объекты соответствующих классов:

- выбор книги - объект класса SelectBook, отвечающий за выбор необходимой формы;

- форма выбора о всех данных книги - объект класса InputForm - конкретной формы ввода данных о книге;

- управляющий БД - объект управляющего класса AdministratorDB, выполняющий функции СУБД;

- запись о книге - объект класса WriteBook, инкапсулирующего в себе всю необходимую информацию о новой книге;

- управляющий транзакциями - объект класса TransactionAdmin, берущий на себя функции СУБД по управлению транзакциями.

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

1. Пользователь - библиотекарь создает новую запись о книге в БД.

2. При этом он открывает необходимую форму для ввода данных о книге.

3. Вводит все необходимые поля в открытую форму.

4. Нажимает на клавишу «Сохранить».

5. При этом информация отправляется в СУБД, которая обозначена на диаграмме как «Управляющий БД».

6. СУБД создает новую пустую запись.

7. Генерирует изменяет значения полей в соответствии с введенными пользователем - библиотекарем данными.

8. Передает эту запись системе управления транзакциями, которая обозначена на диаграмме как «Управляющий транзакциями».

9. Система управления транзакциями осуществляет транзакцию.

10. Система управления транзакциями возвращает сообщение об успешности проведения транзакции или ошибке при её выполнении.

Выводы

1. Была разработана диаграмма последовательности для варианта использования «Ввод новой записи о книге». Этот вариант использования является наиболее важной и наиболее сложно реализуемой задачей информационной подсистемы.

2. При создании диаграммы были созданы пять классов: два управляющих, два «граничных»(Boundaries) и один «сущность».

4. СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА

Диаграммы сотрудничества (Collaboration) отображают поток событий в конкретном сценарии варианта использования. Эта диаграмма не акцентирует внимание на последовательности передачи сообщений, она отражает наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие сообщений от клиентов к серверам. Кооперативные диаграммы больше внимания заостряют на связях между объектами. В курсовом проекте была разработана диаграмма сотрудничества, описывающая ввод новой записи о книге при ее покупке в библиотеку (рисунок 4.1). Действующее лицо - Пользователь - библиотекарь. Используемые объекты:

- выбор книги ( класс - SelectBook);

- форма записи (класс InputForm);

- управляющий БД (класс AdministratorDB);

- запись о книге (класс WriteBook);

- управляющий записями(класс - TransactionAdmin).

На диаграмму были добавлены следующие сообщения, соотнесенные с операциями:

1. Create() - создать новую форму о вводе данных о книге.

2. OpenForm() - открыть форму для ввода данных о новой книге.

3. EnterDate() - ввести данные о книге.

4. SaveInfo() - нажать кнопку сохранить на форме.

5. SaveInfo() - послать запрос в БД на сохранение информации.

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

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

Рисунок 4.1 - Диаграмма сотрудничества

6. CreateEmptyRecord() - создать пустую запись в БД.

7. Редактирование вновь созданной записи: присвоение соответствующим полям таблицы ранее введенную иформацию.

8. SaveChange() - отправление команды в систему управления транзакциями на выполнение транзакции по изменению записи.

9. Возвращение результатов выполнения транзакции и вывод сообщения об ошибке, если транзакция не была завершена.

Выводы

1. Была спроектирована диаграмма сотрудничества для варианта использования «Ввод новой записи о книге». Во многом от правильности выполнения этого прецедента будет зависеть в дальнейшем успешность контроля ведения данных и функционирования всей системы в целом.

2. Да диаграмму были добавлены девять сообщений, соотнесенные с соответствующими операциями

5. СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ

Class diagram (диаграммы классов) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. На диаграммах классов отображаются некоторые классы и пакеты системы. Это статические картины фрагментов системы и связей между ними. В среде Rose диаграммы классов создаются в Логическом представлении модели. Главная диаграмма классов размещается непосредственно под Логическим представлением.

Ознакомившись с классами модели, для более наглядного представления, они были сгруппированы по стереотипу (рисунок 5.1). Стереотипы - это механизм, позволяющий разделять классы на категории. В языке UML основными стереотипами являются: Boundary (граница), Entity (сущность) и Control (управление).Таким образом были созданы следующие пакеты: Entities (Сущности), Boundaries (Границы) и Control (Управление). В эти пакеты были помещены советующие им классы.

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

Граничные классы (boundary classes) - это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами. В пакет «Boundaries» были добавлены следующие классы: класс InputForm(форма ввода данных о книге) и класс SelectBook(выбор книги).

Классы-сущности (entity classes) отражают основные понятия (абстракции) предметной области и, как правило, содержат хранимую информацию. В данный пакет были добавлен класс WriteBook. Также был создан и добавлен в пакет вспомогательный класс WriteHelp, предназначенный для того, чтобы облегчить контроль вводимых данных.

Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. В данном проекте данную функцию выполняет класс AdministratorDB, а также TransactionAdmin.

Выводы

1. В процессе разработки диаграммы классов был применен механизм пакетов. Были созданы три основных пакета, объединяющих классы по стереотипам.

2. Была разработана диаграмма пакетов, являющаяся одной из форм диаграммы классов.

6. ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ

После того как была, разработана диаграмма классов для варианта использования «Ввод новой записи о книге», начинается ее заполнение. В качестве языка программирования был выбран C++, что позволило добавить к классам параметры операций, типы данных и типы возвращаемых значений.

Атрибут - это элемент информации, связанный с классом. Они содержатся внутри класса, поэтому они скрыты от других классов. В связи с этим иногда требуется указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility). Для определения атрибутов и операций классов было произведено обращение к потоку событий. В результате к классам были добавлены дополнительные атрибуты и связи между классами(рисунок 6.1).

Рисунок 6.1 Диаграмма классов для сценария «ввести новую запись о книге»

Как видно из диаграммы, для добавления новой записи о книге, необходимо ввести следующую информацию(атрибуты класса WriteBook):

- Инвентарный номер: Integer;

- Шифр темы: Integer;

- Шифр книги: String;

- Автор:String;

- Наименование:String;

- Издательство:String;

- Год издания:Date;

- Количество страниц:Integer;

- Стоимость:Currency;

- Тип книги:String;

- Особенности:String.

Назначение и описание основных методов классов были рассмотрены выше, в третьем и четвертом разделах.

Выводы

1. Была разработана диаграмма классов для сценария «ввести новую запись о книге». Как видно из диаграммы, между классами существует определенная семантическая связь.

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

7. СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ ДЛЯ КЛАССОВ И ДИАГРАММЫ КОМПОНЕНТОВ

Диаграммы состояний (State) предназначена для отображения состояний объектов системы, имеющих сложную модель поведения. Состоянием (state) называется одно из возможных условий, в которых может существовать объект.

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

Многие требования к классу WriteBook значительно изменяются при изменении состояния его экземпляра. Например, записи, заполнение которых приостановлено, ведут себя не так, как полностью заполненные записи, а те в свою очередь не так, как отмененные записи.

На рисунке 7.1 приведена диаграмма состояния для класса WriteBook. Этапы создания диаграммы состояний:

1. Найти в браузере класс WriteBook.

2. Щелкнуть на классе правой кнопкой мыши и в открывшемся меню указать пункт Open State Diagram (Открыть диаграмму состояний).

Добавление начального и конечного состояний:

1. Нажать кнопку Start State (Начальное состояние) панели инструментов.

2. Поместить это состояние на диаграмму.

3. Нажать кнопку End State (Конечное состояние) панели инструментов.

4. Поместить это состояние на диаграмму.

Добавление состояний:

1. На панели инструментов нажать кнопку State (Состояние).

2. Поместить состояние на диаграмму.

3. Назвать состояние Cancelled.

4. На панели инструментов нажать кнопку State (Состояние).

5. Поместить состояние на диаграмму.

6. Назвать состояние Vipolnen.

7. На панели инструментов нажать кнопку State (Состояние).

8. Поместить состояние на диаграмму внутрь суперсостояния.

9. Назвать состояние Initialization.

10. На панели инструментов нажать кнопку State (Состояние).

11. Назвать состояние Priostanovlen.

Рисунок 7.1 - Диаграмма состояния для класса WriteBook

Описание состояний:

1. Дважды щелкнуть мышью на состоянии Initialization.

2. Перейти на вкладку Detail (Подробно).

3. Щелкнуть правой кнопкой мыши в окне Actions (Действия).

4. В открывшемся меню выберать пункт Insert (Вставить).

5. Дважды щелкнуть мышью на новом действии.

6. Назвать его StoreDate.

7. Убедиться, что в окне When (Когда) указан пункт On Entry (На входе).

8. Повторив шаги 3 -- 7, добавить следующие действия:

- Collect Book Info, в окне When указать Entry until Exit (Выполнять до завершения);

- Add WriteHelp , указав Entry until Exit (Выполнять до завершения);

9. Нажать два раза на ОК, чтобы закрыть спецификацию.

10. Дважды щелкнуть мышью на состоянии Otmenen.

11. Повторив шаги 2 -- 7, добавить действие Store cancellation data, указав On Exit (На выходе)

12. Нажать два раза на ОК, чтобы закрыть спецификацию.

13. Дважды щелкнуть мышью на состоянии Vipolnen.

14. Повторив шаги со второго по седьмой, добавить действие Create Otchet, указав Entry until Exit

15. Нажать два раза на ОК, чтобы закрыть спецификацию.

Добавление переходов:

1. Нажать кнопку Transition (Переход) панели инструментов.

2. Щелкнуть мышью на начальном состоянии.

3. Провести линию перехода к состоянию Initialization.

4. Повторив шаги с первого по третий, создать следующие переходы:

- от состояния Initialization к состоянию Priostanovlen;

- от Priostanovlen к состоянию Vipolnen;

- от состояния Inizializaziya к состоянию Cancelled;

- от состояния Cancelled к конечному состоянию;

- от состояния Vipolnen к конечному состоянию;

5. На панели инструментов нажать кнопку Transition to Self (Переход к себе).

6. Щелкнуть мышью на состоянии Priostanovlen.

Описание переходов:

1. Дважды щелкнув мышью на переходе от состояния Initialization к состоянию Priostanovlen, открыть окно спецификации перехода.

2. В поле Event (Событие) ввести фразу Dobavit' Zapis.

3. Щелкнув на кнопке ОК, закрыть окно спецификации.

4. Повторив шаги с первого по третий, добавить событие Otmenit' zapolnenie к переходу между стоянием Initialization и состоянием Otmenen.

5. Дважды щелкнув мышью на переходе от состояния Priostanovlen к состоянию Vipolnen, открыть окно его спецификации.

6. В поле Event (Событие) ввести фразу Dobavit' k zapisi novuu informaciu.

7. Перейти на вкладку Detail (Подробно).

8. В поле Condition (Условие) введите Ne ostavlya' pustye polya.

9. Щелкнув на кнопке ОК, закрыть окно спецификации.

10. Дважды щелкнуть мышью на рефлексивном переходе (Transition to Self) состояния Priostanovlen.

11. В поле Event (Событие) ввести фразу Dobavit' k zapisi novuu informaciu.

12. Перейти на вкладку Detail (Подробно).

13. В поле Condition (Условие) ввести ostautsya pustye polya.

14. Щелкнув на кнопке ОК, закрыть окно спецификации.

Была также создана диаграмма компонентов, отображающая распределение классов и объектов по компонентам при физическом проектировании. Как видно на рисунке 7.2 система была разложена на два компонента: сервер и клиент. К клиентской части приложения относятся классы InputForm и SelectBook и объекты этих классов. К серверной части приложения отнесены все остальные классы и объекты этих классов.

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

Выводы

1. Была создана диаграмма состояний для класса WriteBook. Согласно этой диаграмме объекты класса WriteBook могут находиться в одном из четырех состояний: инициализации, приостановки, отмены и завершения. Была также разработана диаграмма компонентов, разделяющая систему на 2 компонента: клиент и сервер.

2. Из диаграммы компонентов видно, что разрабатываемая подсистема будет работать по технологии «клиент-сервер». К клиентской части приложения относятся классы InputForm и SelectBook и объекты этих классов. К серверной части приложения отнесены все остальные классы и объекты этих классов.

8. СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм. Иногда диаграммы топологии называют диаграммами размещения. Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения. Пример диаграммы Размещения приведен на рисунке 8.1.

Рисунок 8.1 - Диаграмма размещения

Добавление узлов к диаграмме размещения:

1. Дважды щелкнув мышью на представлении размещения в браузере, открыть диаграмму размещения.

2. Нажать кнопку Processor (Процессор) панели инструментов.

3. Щелкнув мышью на диаграмме, поместить туда процессор.

4. Ввести имя процессора «Сервер базы данных».

5. Повторив шаги 2--4, добавить следующие процессоры: «сервер приложения», «клиентская рабочая станция №1», «клиентская рабочая станция №2».

6. На панели инструментов нажать кнопку Device (Устройство).

7. Щелкнув мышью на диаграмме, поместить туда устройство.

8. Назвать его «Принтер».

Добавление связей:

1. Нажать кнопку Connection (Связь) панели инструментов.

2. Щелкнуть мышью на процессоре «Сервер базы данных».

3. Провести линию связи к процессору «Сервер приложения».

4. Повторив шаги 1 ? 3, добавить следующие связи:

- от процессора «Сервер приложения» к процессору «Клиентская рабочая станция №1»;

- от процессора «Сервер приложения» к процессору «Клиентская рабочая станция №2»;

- от процессора «Сервер приложения» к устройству «Принтер».

Добавление процессов:

1. Щелкнуть правой кнопкой мыши на процессоре «Сервер приложения» в браузере.

2. В открывшемся меню выберать пункт New > Process (Создать > Процесс).

3. Ввести имя процесса ? WriteServerExe.

4. Повторить шаги 1 ? 3, добить процессы:

- процесс WriteClientExe на процессоре «Клиентская рабочая станция №1»;

- процесс ATMClientExe на процессоре «Клиентская рабочая станция №2».

Показ процессов на диаграмме:

1. Щелкнуть правой кнопкой мыши на процессоре «Сервер приложения».

2. В открывшемся меню выбрать пункт Show Processes (Показать процессы).

3. Повторив шаги 1 и 2, показать процессы на следующих процессорах:

- клиентская рабочая станция №1;

- клиентская рабочая станция №2.

Выводы

1. Из диаграммы видно, что информационная подсистема контроля ведения и добавления книг построена на технологии «клиент-сервер». Это позволяет организовать одновременный доступ нескольких операторов ПК к базе данных.

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

9. ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C++

Язык C++ является одним из наиболее широко применяемых на практике объектно-ориентированных языков. Rational Rose интегрируется с C++ посредством генерации кода и обратного проектирования. В Rational Rose 2000 предусмотрена возможность генерации программного кода C++, а также интеграции с языком Visual C++ версии 6 компании Microsoft.

При генерации с помощью Rational Rose 2000 программного кода Visual C++ применяется программа-мастер. Для запуска этого мастера необходимо выбрать пункт меню Tools > Visual C++ > Update Code, после чего стартует инструментальное средство обновления программного кода Visual C++ Update Code и появляется экран приглашения. Для продолжения работы необходимо щелкнуть мышью на Next. Rose выведет на экран окно выбора Select Components and Classes (рисунок 9.1). Перед генерацией класса в Visual C++ ему необходимо назначить компонент. Если компонент еще не назначен, выбрать режим Create a VC++ Component and Assign New Classes to It (Ctrl+R) в окне мастера. В этом режиме можно создать нужное число компонентов перед генерацией программы. Затем выбрать компоненты и/или классы модели для генерации программного кода.

Чтобы изменить свойства генерации программного кода для компонентов и классов Visual C++, необходимо щелкнуть правой клавишей мыши на папке VC++ на этом экране. После этого можно установить любые свойства генерации, например контейнерный класс, свойства поддержки множественности связей, возможность автоматической генерации конструктора и деструктора, а также возможность автоматической генерации операций Get и Set или других функций-членов (member functions).

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

Рисунок 9.1 - Окно выбора компонентов и классов программы-мастера Update Code

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

Выводы

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

2. Листинги сгенерированного Rational Rose кода приложения для контроля и ведения книг в библиотеке на языке С++ приведены в Приложении А. Общий размер сгенерированных файлов составляет 7,38 КБ.

ЗАКЛЮЧЕНИЕ

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

Данная разработка написана с помощью языка UML, с использованием среды разработки - программного продукта Rational Rose 2007.

Были разработаны следующие диаграммы:

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

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

- диаграмма сотрудничества;

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

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

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

- диаграмма размещения.

Основными действующими лицами являются пользователь - читатель, пользователь - библиотекарь, администратор. Они выполняют такие действия: «просмотр данных», «получение отчетов», «сохранение данных в базу», «ввод, редактирование», «управление всеми операциями», «просмотр и редактирование всех данных», «назначение прав доступа».

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

Информационная подсистема контроля ведения книг на технологии «клиент-сервер». Это позволяет организовать одновременный доступ нескольких операторов ПК к базе данных.

Клиентские программы будут работать в нескольких местах. Через локальную вычислительную сеть краевой библиотеки будет осуществляться сообщение этой части программы с главным сервером системы, с работающим программным обеспечением. В свою очередь, главный сервер посредством локальной сети будет сообщаться с сервером базы данных. С главным сервером соединен принтер. Были сгенерированы 12 файлов кода на языке С++ общим размером 7,38 КБ.

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. - М.: ДМК, 2000.- 432 с., ил. (Серия «для программистов»).

2. Трофимов С. А. Case-технологии: практическая работа в Rational

Rose / С. А. Трофимов. - М.: ЗАО «Издательский дом БИНОМ», 2001. - 372

с., ил.

3. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство «Лори», 2000.- 581 с., ил.

4. Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. - СПб.: Питер, 2002.- 432 с., ил.

5. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом «Вильямс», 2001. - 496 с., ил.

6. James Rumbaugh, Ivar Jacobson, Grady Booch. The Unified Modelin

Language Reference Manual, Second Edition. Boston: Addison-Wesley, 2005.

7. ГОСТ 2.105-95 ЕСКД. Общие требования к текстовым документам

8. ГОСТ 2.104-68 ЕСКД. Основные надписи

9. ГОСТ 2.106-68 ЕСКД. Текстовые документы

10. ГОСТ 2.109-73 ЕСКД. Основные требования к чертежам

11. ГОСТ 2.301-68 ЕСКД. Форматы

Приложение А

Листинги кода приложения для контроля ведения книг в библиотеке, сгенерированные Rational Rose на языке С++

A.1 Листинг файла SelectBook.h

// Copyright (C) 1991 - 1999 Rational Software Corporation

#if defined (_MSC_VER) && (_MSC_VER >= 1000)

#pragma once

#endif

#ifndef SELECTBOOK_H_HEADER_INCLUDED_B2090074

#define SELECTBOOK_H_HEADER_INCLUDED_B2090074

//##ModelId=4DF4C3620082

class SelectBook

{

public:

//##ModelId=4DF4C489024C

Boolean Create();

//##ModelId=4DF4F2AD013A

InputForm *theInputForm;

};

#endif /* SELECTBOOK_H_HEADER_INCLUDED_B2090074 */

A.2 Листинг файла SelectBook.cpp

// Copyright (C) 1991 - 1999 Rational Software Corporation

#include "stdafx.h"

#include "InputForm.h"

#include "SelectBook.h"

//##ModelId=4DF4C489024C

Boolean SelectBook::Create(){

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

A.3 Листинг файла InputForm.h

// Copyright (C) 1991 - 1999 Rational Software Corporation

#if defined (_MSC_VER) && (_MSC_VER >= 1000)

#pragma once

#endif

#ifndef INPUTFORM_H_HEADER_INCLUDED_B209063F

#define INPUTFORM_H_HEADER_INCLUDED_B209063F

//##ModelId=4DF4C3990398

class InputForm

{

public:

//##ModelId=4DF4C4C80212

OpenForm();

//##ModelId=4DF4C4D203DF

EnterData();

//##ModelId=4DF4C4E803B7

SaveInfo();

//##ModelId=4DF4F2BA0234

AdministratorDB *theAdministratorDB;

};

#endif /* INPUTFORM_H_HEADER_INCLUDED_B209063F */

A.4 Листинг файла InputForm.cpp

// Copyright (C) 1991 - 1999 Rational Software Corporation

#include "stdafx.h"

#include "DBManager.h"

#include "InputForm.h"

//##ModelId=4DF4C4C80212

InputForm::OpenForm()

{

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

//##ModelId=4DF4C4D203DF

InputForm::EnterData()

{

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

//##ModelId=4DF4C4E803B7

InputForm::SaveInfo()

{

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

A.5 Листинг файла WriteBook.h

// Copyright (C) 1991 - 1999 Rational Software Corporation

#if defined (_MSC_VER) && (_MSC_VER >= 1000)

#pragma once

#endif

#ifndef WRITEBOOK_H_HEADER_INCLUDED_B2094DB5

#define WRITEBOOK_H_HEADER_INCLUDED_B2094DB5

//##ModelId=4DF4C3F400B6

class WriteBook

{

public:

//##ModelId=4DF4C5DA03C7

Boolean CreateEmptyRecord();

//##ModelId=4DF4C5E10039

Boolean EnterInformation();

//##ModelId=4DF4C5ED0057

Boolean BookInfo();

//##ModelId=4DF4F2E200A6

WriteHelp *theWriteHelp;

private:

//##ModelId=4DF4EEFE0049

Integer Инвентарный номер;

//##ModelId=4DF4EEFE0049

//##ModelId=4DF4EF92014D

Integer Шифр темы;

//##ModelId=4DF4EFA80337

String Шифр книги;

//##ModelId=4DF4EFBB01BB

String Автор;

//##ModelId=4DF4EFC101F7

String Наименование;

//##ModelId=4DF4EFC9035F

String Издательство;

//##ModelId=4DF4EFDA01CF

Date Год издания;

//##ModelId=4DF4EFE302A1

Integer Кол-во страниц;

//##ModelId=4DF4EFF5002B

Currency Стоимость;

//##ModelId=4DF4EFFC0139

String Тип книги;

//##ModelId=4DF4F004008F

String Особенности;

Integer Инвентарный номер;

//##ModelId=4DF4EEFE0049

//##ModelId=4DF4EF92014D

Integer Шифр темы;

//##ModelId=4DF4EFA80337

String Шифр книги;

//##ModelId=4DF4EFBB01BB

String Автор;

//##ModelId=4DF4EFC101F7

String Наименование;

//##ModelId=4DF4EFC9035F

String Издательство;

//##ModelId=4DF4EFDA01CF

Date Год издания;

//##ModelId=4DF4EFE302A1

Integer Кол-во страниц;

//##ModelId=4DF4EFF5002B

Currency Стоимость;

//##ModelId=4DF4EFFC0139

String Тип книги;

//##ModelId=4DF4F004008F

String Особенности;

Integer Инвентарный номер;

//##ModelId=4DF4EEFE0049

//##ModelId=4DF4EF92014D

Integer Шифр темы;

//##ModelId=4DF4EFA80337

String Шифр книги;

//##ModelId=4DF4EFBB01BB

String Автор;

//##ModelId=4DF4EFC101F7

String Наименование;

//##ModelId=4DF4EFC9035F

String Издательство;

//##ModelId=4DF4EFDA01CF

Date Год издания;

//##ModelId=4DF4EFE302A1

Integer Кол-во страниц;

//##ModelId=4DF4EFF5002B

Currency Стоимость;

//##ModelId=4DF4EFFC0139

String Тип книги;

//##ModelId=4DF4F004008F

String Особенности;

Integer Инвентарный номер;

//##ModelId=4DF4EF92014D

Integer Шифр темы;

//##ModelId=4DF4EFA80337

String Шифр книги;

//##ModelId=4DF4EFBB01BB

String Автор;

//##ModelId=4DF4EFC101F7

String Наименование;

//##ModelId=4DF4EFC9035F

String Издательство;

//##ModelId=4DF4EFDA01CF

Date Год издания;

//##ModelId=4DF4EFE302A1

Integer Кол-во страниц;

//##ModelId=4DF4EFF5002B

Currency Стоимость;

//##ModelId=4DF4EFFC0139

String Тип книги;

//##ModelId=4DF4F004008F

String Особенности;

};

#endif /* WRITEBOOK_H_HEADER_INCLUDED_B2094DB5 */

A.6 Листинг файла WriteBook.cpp

// Copyright (C) 1991 - 1999 Rational Software Corporation

#include "stdafx.h"

#include "ZapisItem.h"

#include "Zapis.h"

//##ModelId=4DF4C5DA03C7

Boolean WriteBook::CreateEmptyRecord()

{

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

//##ModelId=4DF4C5E10039

Boolean WriteBook::EnterInformation()

{

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

//##ModelId=4DF4C5ED0057

Boolean WriteBook::BookInfo()

{

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

A.7 Листинг файла AdministratorDB.h

// Copyright (C) 1991 - 1999 Rational Software Corporation

#if defined (_MSC_VER) && (_MSC_VER >= 1000)

#pragma once

#endif

#ifndef _INC_DBMANAGER_453CF383009F_INCLUDED

#define _INC_DBMANAGER_453CF383009F_INCLUDED

class TransactionAdmin;

class WriteBook;

//Система управления базой данных

//##ModelId=4DF4C3BE0032

class AdministratorDB

{

public:

//##ModelId=4DF4C5CD0133

SaveInfo();

//##ModelId=4DF4F2C801E4

WriteBook *theWriteBook;

//##ModelId=4DF4F41F000D

TransactionAdmin *theTransactionAdmin;

};

#endif /* ADMINISTRATORDB_H_HEADER_INCLUDED_B2096D24 */

A.8 Листинг файла AdministratorDB.cpp

// Copyright (C) 1991 - 1999 Rational Software Corporation

#include "stdafx.h"

#include "TransactionAdmin.h"

#include "WriteBook.h"

#include "AdministratorDB.h"

//##ModelId=4DF4C5CD0133

AdministratorDB::SaveInfo()

{

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

A.9 Листинг файла TransactionAdmin.h

// Copyright (C) 1991 - 1999 Rational Software Corporation

#if defined (_MSC_VER) && (_MSC_VER >= 1000)

#pragma once

#endif

#ifndef TRANSACTIONADMIN_H_HEADER_INCLUDED_B2092498

#define TRANSACTIONADMIN_H_HEADER_INCLUDED_B2092498

class WriteBook;

//##ModelId=4DF4C42000E8

class TransactionAdmin

{

public:

//##ModelId=4DF4C5E602B9

SaveChange();

//##ModelId=4DF4C5F4016F

SaveIntoDB();

//##ModelId=4DF4F2D102FC

WriteBook *theWriteBook;

//##ModelId=4DF4F4230067

WriteHelp *theWriteHelp;

};

#endif /* TRANSACTIONADMIN_H_HEADER_INCLUDED_B2092498 */

A.10 Листинг файла TransactionAdmin.cpp

// Copyright (C) 1991 - 1999 Rational Software Corporation

#include "stdafx.h"

#include "WriteBook.h"

#include "TransactionAdmin.h"

//##ModelId=4DF4C5E602B9

TransactionAdmin::SaveChange()

{

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

//##ModelId=4DF4C5F4016F

TransactionAdmin::SaveIntoDB()

{

// TODO: Add your specialized code here.

// NOTE: Requires a correct return value to compile.

}

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


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

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