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

 

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

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

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

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

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

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

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

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

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

Содержание

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

ПРИЛОЖЕНИЕ А Листинг, сгенерированный Rational Rose на языке С++

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управляющие воздействия запаздывают по причинам несвоевременного возврата ведомостей и направлений с выставленными оценками в деканаты.

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

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

-снижение времени на подготовку экзаменационных сессий;

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

-уменьшение ошибок в приказах о переводе студентов с курса на курс;

-увеличение достоверности и подробности анализа успеваемости и организованности проведения сессий;

-повышение качества обучения на основе анализа оценок.

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

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

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

Деятельность деканата является одной из основных и сложных в работе BУЗА. Работникам деканатов приходится выполнять огромный объем работы по учету контингента студентов, обеспечению учебного процесса, предоставлению информации в различные подразделения ВУЗа. При этом всю информацию необходимо представлять в различных форматах. Необходимость внедрения информационной подсистемы, автоматизирующей основные функции образовательного процесса на лицо.

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

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

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

-редактирование оценок по результатам экзаменов;

-формирование ведомости;

-просмотр итогов сессии по факультету;

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

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

Диаграмма прецедентов (англ. <#"justify">- каждый вариант использования относится как минимум к одному действующему лицу;

каждый вариант использования имеет инициатора;

каждый вариант использования приводит к соответствующему результату (результату с «бизнес-значением»).

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

-составить ведомость. Периодичность: в соответствии с учебным планом;

-просмотр итогов сессии. Подразумевает поиск информации по необходимости;

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

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

1.Нужно открыть интегрированную среду разработки Rational Rose 2000.

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

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

-Составить ведомость;

-Внести результаты сессии;

-Добавить студента в БД;

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

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

5.Назовем его «Секретарь деканата».

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

Эти варианты использования инициируют последовательность действий в базе данных в ответ на действия со стороны «Секретарь деканата».

Выводы

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

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

программа учет информационная ориентированный

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

Диаграмма последовательности (англ. <#"justify">Рассмотрим вариант использования «Добавить студента в БД». Диаграмма последовательности приведена на рисунке 3.1.

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

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

-форма обучения - объект класса FormStudent;

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

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

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

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

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

1.Секретарь деканата создает новую запись о студенте в БД.

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Рисунок 6.1 - Диаграмма классов для сценария «Ввод данных студента»

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

Student_Name: String - имя студента;

Student_Sername: String - фамилия студента;

Student_Lastname: String - отчество студента;

-Fakultet:String - факультет;

-Data:Date - дата cдачи экзамена;

-Specialnost:String - cпециальность студента;

-Kurs:Int - курс;

-Marks- оценка.

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

Выводы

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

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

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

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

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

Многие требования к классу InputInformation значительно изменяются при изменении состояния его экземпляра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.В поле Condition (Условие) введите Ne ostalis nezapolnenie polya.

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

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

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

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

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

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

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

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

Выводы

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

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

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

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм. Иногда диаграммы топологии называют диаграммами размещения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

Выводы

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

Были сгенерированы 12 файлов кода на языке С++ общим размером 7,38 КБ.

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

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

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

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

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

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

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

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

6.ГОСТ 2.004-88 ЕСКД. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах ввода ЭВМ

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

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

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

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

ПРИЛОЖЕНИЕ А

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

A.1 Листинг файла DBMeneger.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_INCLUDEDTransactionManager; InputInformation;

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

//##ModelId=453CF383009FDBManager

{:

//##ModelId=454DF91303DA* theTransactionManager;

//##ModelId=454DF99B01F5* theInputInformation;

//##ModelId=453CF4550169SaveInfo(Integer ZakazID);

};

#endif /* _INC_DBMANAGER_453CF383009F_INCLUDED */

}.2 Листинг файла DBMeneger.cpp

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

#include "stdafx.h"

#include "TransactionManager.h"

#include "InputInformation.h"

#include "DBManager.h"

//##ModelId=453CF4550169DBManager::SaveInfo(Integer ZakazID)

{

// TODO: Add your specialized code here.

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

}.3 Листинг файла FormExems.cpp

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

#include "stdafx.h"

#include "FormStudent.h"

#include "FormExems.h"

//##ModelId=453CE6830108FormExems::Create()

{

// TODO: Add your specialized code here.

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

}.4 Листинг файла FormExems.h

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

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

#pragma once

#endif

#ifndef _INC_FORMEXEMS_453CE5400276_INCLUDED

#define _INC_FORMEXEMS_453CE5400276_INCLUDEDFormStudent;

//Форма экзаменационной ведомости

//##ModelId=453CE5400276

class FormExems

{:

//##ModelId=454DF8FD00AD* theInputForm;

//##ModelId=453CE6830108Create();

};

#endif /* _INC_FORMEXEMS_453CE5400276_INCLUDED */.5 Листинг файла FormStudent.cpp

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

#include "stdafx.h"

#include "DBManager.h"

#include "FormStudent.h"

//##ModelId=453CF349025EFormStudent::Form()

{

// TODO: Add your specialized code here.

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

}

//##ModelId=453CF3C70346FormStudent::InsertData()

{

// TODO: Add your specialized code here.

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

}

//##ModelId=453CF4440006FormStudent::SaveInfo()

{

// TODO: Add your specialized code here.

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

}.6 Листинг файла FormStudent.h

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

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

#pragma once

#endif

#ifndef _INC_FORMSTUDENT_453CF313010C_INCLUDED

#define _INC_FORMSTUDENT_453CF313010C_INCLUDEDDBManager;

//Форма ввода информации о студенте

//##ModelId=453CF313010C

class FormStudent

{:

//##ModelId=454DF90C03DA* theDBManager;

//##ModelId=453CF349025EForm();

//##ModelId=453CF3C70346InsertData();

//##ModelId=453CF4440006SaveInfo();

};

#endif /* _INC_FORMSTUDENT_453CF313010C_INCLUDED */.7 Листинг файла InformationItem.cpp

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

#include "stdafx.h"

#include "InformationItem.h"

//##ModelId=454DF234029AInformationItem::Create()

{

// TODO: Add your specialized code here.

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

}

//##ModelId=454DF24203BDInformationItem::SetInfo(Integer ID)

{

// TODO: Add your specialized code here.

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

}

//##ModelId=454DF25101C0InformationItem::GetInfo()

{

// TODO: Add your specialized code here.

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

}.8 Листинг файла InputInformation.cpp

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

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

#pragma once

#endif

#ifndef _INC_INFORMATIONITEM_454DF0B10348_INCLUDED

#define _INC_INFORMATIONITEM_454DF0B10348_INCLUDED

//##ModelId=454DF0B10348InformationItem

{:

//##ModelId=454DF234029ACreate();

//##ModelId=454DF24203BDSetInfo(Integer ID = 0);

//##ModelId=454DF25101C0GetInfo();:

//##ModelId=4DD93BE9033CInformationID;

};

#endif /* _INC_INFORMATIONITEM_454DF0B10348_INCLUDED */.9 Листинг файла InputInformation.h

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

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

#pragma once

#endif

#ifndef _INC_INPUTINFORMATION_453CF3E40275_INCLUDED

#define _INC_INPUTINFORMATION_453CF3E40275_INCLUDEDInformationItem;

//Добавление данных о студенте

//##ModelId=453CF3E40275

class InputInformation

{:

//##ModelId=454DF92B028A* theZapisItem;

//##ModelId=453CF4630336CreateEmptyRecord();

//##ModelId=453CF47D010DStudentInfo();

//##ModelId=453CF48801B3(Integer zapis_namber, String Student_Name, String Student_Sername, String Student_Lastname, Integer Group, String Fakultet, int Kurs, int marks, String subject, Data Data);:

//номер записи

//##ModelId=454DF14702F4zapis_namber;

//Фамилия студента

//##ModelId=454DF15F017CStudent_Name;

//Отчество студента

//##ModelId=454DF19B01AAStudent_Sername;

//Группа

//##ModelId=454DF1DB021AStudent_Lastname;

//##ModelId=4DEB4A400242Group;

//Факультет

//##ModelId=454DF1F40252Fakultet;

//Курс

//##ModelId=454DF20A0236Kurs;

//##ModelId=4DD93AA2032Cmarks;

//##ModelId=4DE2566E0177subject;

//##ModelId=4DE25A000261Data;

};

#endif /* _INC_INPUTINFORMATION_453CF3E40275_INCLUDED */.11 Листинг файла TransactionManager.cpp

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

#include "stdafx.h"

#include "InputInformation.h"

#include "InformationItem.h"

#include "TransactionManager.h"

//##ModelId=453CF47300C2TransactionManager::SaveChange()

{

// TODO: Add your specialized code here.

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

}

//##ModelId=453CF4990348TransactionManager::SaveIntoDB(Integer Zapis_ID)

{

// TODO: Add your specialized code here.

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

}.12 Листинг файла TransactionManager.h

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

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

#pragma once

#endif

#ifndef _INC_TRANSACTIONMANAGER_453CF3F901E9_INCLUDED

#define _INC_TRANSACTIONMANAGER_453CF3F901E9_INCLUDEDInputInformation;InformationItem;

//Система управления транзакциями

//##ModelId=453CF3F901E9TransactionManager

{:

//##ModelId=454DF91B0219* theZapis;

//##ModelId=454DF923036F* theInformationItem;

//##ModelId=453CF47300C2SaveChange();

//##ModelId=453CF4990348SaveIntoDB(Integer Zapis_ID);

};

#endif /* _INC_TRANSACTIONMANAGER_453CF3F901E9_INCLUDED */

Министерство образования и науки Российской Федерации ГОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Факультет информационных технологий и телекоммуник

Больше работ по теме: