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

_PAGE

_PAGE

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

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

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

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

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

Ставрополь 2011

информационная подсистема моделирование

• Пояснительная записка
• Введение
• 1 краткая характеристика предметной области
• 1.1 общая характеристика
• 1.2 актуальность разрабатываемой подсистемы
• 1.3 формулировка задач проектирования
• 2 создание диаграммы прецедентов
• 3 создание диаграммы последовательности
• 4 создание диаграммы сотрудничества
• 5 создание диаграммы классов
• 6 добавление деталей к описаниям операций и определение атрибутов классов. Добавление связей между классами.
• 7 создание диаграммы состояний для классов и диаграммы компонентов
• 8 создание диаграммы размещения
• 9 генерация программного кода c++
• Заключение
• Библиографический список
• Приложение А. Листинг кода приложения сгенерированные rational rose на языке с++

Rational Rose имеет весь необходимый набор визуальных средств проектирования. Только Rose поможет решить проблемы с кодогенерацией на определенном языке программирования. Rational Rose осуществляет такие подходы, как прямое и обратное проектирование. Такой арсенал позволит не только проектировать новую систему, но и доработать старую, произведя процесс обратного проектирования. Популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Corp. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое. Для того чтобы наиболее полно покрыть весь сегмент рынка средств проектирования и разработки, компания Rational выпускает несколько версий своего продукта. Каждый из них может решать как строго определенный круг задач, так и весь спектр проблем проектирования и разработки. В курсовом проекте разработана объектно-ориентированная модель информационной подсистемы учета абитуриентов университета. Модель разработана с помощью программного продукта Rational Rose 2000, с использованием языка UML.

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

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

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

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

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

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

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

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

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

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

информационная подсистема моделирование диаграмма

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

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

1.2 Актуальность разрабатываемой подсистемы Приемная комиссия «Университета» сегодня — это сложный учебно-хозяйственный комплекс с многочисленными внешними и внутренними связями. Большие возможности для совершенствования управления приемной комиссией предоставляет использование вычислительной техники и средств связи. В организационной системе наиболее трудоемкими являются процессы, связанные с обработкой информации — сбор, накопление, преобразование, отображение, хранение, передача и вывод. Ускорить эти процессы и облегчить труд персонала приемной комиссии позволяет информационная подсистема для учета абитуриентов.

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

— автоматизировать процесс регистрации, учета, обработки документов;

— повысить скорость прохождения документа;

— оптимизировать хранение документов;

— сэкономить ресурсы, расходуемые на подготовку новых документов;

— сократить время на поиск документа;

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

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

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

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

— просмотреть БД;

— добавить абитуриента в БД.

2 СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой прецедентов, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case — это описание сценария поведения, которому следуют действующие лица (Actors). Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.

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

Рисунок 2.1 — Диаграмма прецедентов «Добавить абитуриента в БД»

Основным действующим лицом (актером) является секретарь приемной комиссии «Университета». Он выполняет три основных действия:

— ввод данных абитуриента;

— просмотр БД. Подразумевает поиск необходимой информации по необходимости;

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

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

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

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

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

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

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

4. Назовем его «Просмотреть БД».

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

— Ввод данных абитуриента;

— Добавить абитуриента в БД;

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

7. Назовем его «Секретарь приемной комиссии».

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

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

Выводы

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

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

3. СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ Данный тип диаграмм может использоваться для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов. Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем.

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

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

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

— выбор формы поступления — объект класса FormPostuplen, отвечающий за выбор необходимой формы;

— форма обучения — объект класса InputForm

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

— добавление данных абитуриента — объект класса Zapis, инкапсулирующего в себе всю необходимую информацию об абитуриенте;

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

3. К «управляющим» классам относятся DBManager и TransactionManager. Они контролируют последовательность событий этого варианта использования.

4. К «граничным» классам относятся FormPostuplen и InputForm. Граничные классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами.

5. К классам «сущность» относятся Zapis и ZapisItem .

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

4. СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов. Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами. Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема — передачи сообщений.

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

— выбор формы поступления (класс — FormPostuplen);

— форма поступления (класс InputForm);

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

— запись об абитуриенте (класс Zapis);

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

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

1. Create () — создать новую форму о вводе данных абитуриента;

2. OpenForm () — открыть форму для ввода данных абитуриента;

3. EnterDate () — ввести данные об абитуриенте;

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

SaveInfo () — послать запрос в БД на сохранение информации Диаграмма сотрудничества (рисунок 4.1).

Рисунок 4.1 — Диаграмма сотрудничества «Ввод новой записи об абитуриенте»

Выводы

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

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

5 СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ Диаграмма классов является основным логическим представлением модели и содержит детальную информацию о внутреннем устройстве объектно-ориентированной программной системы или, используя современную терминологию, об архитектуре программной системы. На диаграммах классов отображаются некоторые классы и пакеты системы. Это статические картины фрагментов системы и связей между ними.

Ознакомившись с классами модели, для более наглядного представления, они были сгруппированы по стереотипу (рисунок 5.1).

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

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

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

Выводы

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

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

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

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

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

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

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

— zapis_namber: Integer — номер записи;

— abityrient _name: String — имя абитуриента;

— abityrient _sername: String — фамилия абитуриента;

— abityrient_lastname: String — отчество абитуриента;

— passportdata: String — отчество абитуриента

— fakultet: String — факультет абитуриента;

— specialnost: String — cпециальность абитуриента;

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

Выводы

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

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

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

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

7.1 Создание диаграммы состояний для класса Zapis

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

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

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

Этапы создания диаграммы состояний:

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

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

На рисунке 7.1 приведена диаграмма состояния для класса Zapis.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Add ZapisItems, указав 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. Провести линию перехода к состоянию Inizializaziya.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей. Cоздана диаграмма компонентов, отображающая распределение классов и объектов по компонентам. Как видно на рисунке 7.2

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

система была разложена на два компонента: сервер и клиент. К клиентской части приложения относятся классы InputForm и FormPostuplen и объекты этих классов. К серверной части приложения отнесены все остальные классы и объекты этих классов.

Выводы

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

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

8 СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм. Иногда диаграммы топологии называют диаграммами размещения[4]. Для каждой модели создается только одна такая диаграмма, отображающая процессоры (Processor), устройства (Device) и их соединения.

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

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

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

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

4. Ввести имя процессора «Server BD».

5. Повторив шаги 2—4, добавить следующие процессоры: «Server prilogenea», «KlientVorkStancia № 1», «KlientVorkStancia № 2».

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

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

8. Назвать его «Printer».

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

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

2. Щелкнуть мышью на процессоре «Server BD».

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

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

— от процессора «Server BD» к процессору «KlientVorkStancia № 1»;

— от процессора «Server prilogenia» к процессору «KlientVorkStancia № 2»;

— от процессора «Server prilogenia» к устройству «Printer».

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

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

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

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

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

— процесс ZapisClientExe на процессоре «KlientVorkStancia № 1»;

— процесс ATMClientExe на процессоре «KlientVorkStancia № 2».

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

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

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

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

— KlientVorkStancia № 1;

— KlientVorkStancia № 2.

Таким образом, диаграмма размещения для класса Zapis принимает вид, показанный на рисунке 8.1

Рисунок 8.1 — Диаграмма размещения для класса Zapis

Выводы

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

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

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

Язык C++ является одним из наиболее широко применяемых на практике объектно-ориентированных языков. Rational Rose интегрируется с C++ посредством генерации кода и обратного проектирования.

Процесс генерации программного кода состоит из пяти основных этапов:

1. Проверка модели.

Для проверки модели следует выполнить операцию главного меню: ToolsCheck Model (ИнструментыПроверить модель). Результаты проверки разработанной модели на наличие ошибок отображаются в окне журнала.

2. Создание компонентов.

Для создания компонента:

1. Откройте диаграмму Компонентов (Component).

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

3. Отображение классов на компоненты.

Каждый компонент исходного кода — это файл с исходным программным кодом для одного или нескольких классов. В C++ каждый класс отображается на два компонента с исходным кодом: файл заголовка и основной файл (тело). В PowerBuilder на один компонент отображается несколько классов. Компонентом с исходным программным кодом в PowerBuilder является файл библиотеки PowerBuilder (.pbl).

Третий этап процесса генерации программного кода — отображение каждого из классов на соответствующие компоненты. В PowerBuilder необходимо отобразить каждый класс на компонент перед генерацией программы.

4. Установка свойств генерации программного кода.

Для языка С++ в Rose предусмотрен ряд определенных свойств генерации программного кода. Можно установить несколько параметров генерации программного кода для классов, атрибутов, компонентов и других элементов модели. Этими свойствами определяется способ генерации программ. В Rose предлагаются общепринятые параметры по умолчанию.

5. Генерация программного кода.

Генерация программного кода в среде IBM Rational Rose 2003 возможна для отдельного класса или компонента. Для этого нужный элемент модели предварительно следует выделить в браузере проекта и выполнить операцию контекстного меню: Tools>C++>Code Generation — (Язык C++>Генерировать код). В результате этого будет открыто диалоговое окно с предложением выбора классов для генерации программного кода на выбранном языке программирования (рис. 9.1). После выбора соответствующих классов и нажатия кнопки OK программа Rational Rose 2003 выполняет кодогенерацию.

Рисунок 9.1 — Окно статуса компиляции Выводы

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение А

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

InputForm.cpp

//## begin module%1.2%.codegen_version preserve=yes

// Read the documentation to learn more about C++ code generator

// versioning.

//## end module%1.2%.codegen_version

//## begin module%4DFCA5EF01A5.cm preserve=no

// %X% %Q% %Z% %W%

//## end module%4DFCA5EF01A5.cm

//## begin module%4DFCA5EF01A5.cp preserve=no

//## end module%4DFCA5EF01A5.cp

//## Module: InputForm%4DFCA5EF01A5; Package body

//## Subsystem: Boundarys%4DFC8E190186

//## Source file: C: Program FilesRationalRose 2000C++sourceBoundarysInputForm.cpp

//## begin module%4DFCA5EF01A5.additionalIncludes preserve=no

//## end module%4DFCA5EF01A5.additionalIncludes

//## begin module%4DFCA5EF01A5.includes preserve=yes

//## end module%4DFCA5EF01A5.includes

InputForm.h

#include «InputForm.h»

//## begin module%4DFCA5EF01A5.declarations preserve=no

//## end module%4DFCA5EF01A5.declarations

//## begin module%4DFCA5EF01A5.additionalDeclarations preserve=yes

//## end module%4DFCA5EF01A5.additionalDeclarations

//## begin module%4DFCA5EF01A5.epilog preserve=yes

//## end module%4DFCA5EF01A5.epilog

FormPostuplen.cpp

//## begin module%1.2%.codegen_version preserve=yes

// Read the documentation to learn more about C++ code generator

// versioning.

//## end module%1.2%.codegen_version

//## begin module%4DFCA5CB038A.cm preserve=no

// %X% %Q% %Z% %W%

//## end module%4DFCA5CB038A.cm

//## begin module%4DFCA5CB038A.cp preserve=no

//## end module%4DFCA5CB038A.cp

//## Module: FormPostuplen%4DFCA5CB038A; Package body

//## Subsystem: Boundarys%4DFC8E190186

//## Source file: C: Program FilesRationalRose 2000C++sourceBoundarysFormPostuplen.cpp

//## begin module%4DFCA5CB038A.additionalIncludes preserve=no

//## end module%4DFCA5CB038A.additionalIncludes

//## begin module%4DFCA5CB038A.includes preserve=yes

//## end module%4DFCA5CB038A.includes

FormPostuplen.h

#include «BoundarysFormPostuplen.h»

//## begin module%4DFCA5CB038A.declarations preserve=no

//## end module%4DFCA5CB038A.declarations

//## begin module%4DFCA5CB038A.additionalDeclarations preserve=yes

//## end module%4DFCA5CB038A.additionalDeclarations

//## begin module%4DFCA5CB038A.epilog preserve=yes

//## end module%4DFCA5CB038A.epilog

Zapis.cpp

//## begin module%1.2%.codegen_version preserve=yes

// Read the documentation to learn more about C++ code generator

// versioning.

//## end module%1.2%.codegen_version

//## begin module%4DFCA5CB038A.cm preserve=no

// %X% %Q% %Z% %W%

//## end module%4DFCA5CB038A.cm

//## begin module%4DFCA5CB038A.cp preserve=no

//## end module%4DFCA5CB038A.cp

//## Module: FormPostuplen%4DFCA5CB038A; Package body

//## Subsystem: Boundarys%4DFC8E190186

//## Source file: C: Program FilesRationalRose 2000C++sourceBoundarysFormPostuplen.cpp

//## begin module%4DFCA5CB038A.additionalIncludes preserve=no

//## end module%4DFCA5CB038A.additionalIncludes

//## begin module%4DFCA5CB038A.includes preserve=yes

//## end module%4DFCA5CB038A.includes

// FormPostuplen

#include «BoundarysFormPostuplen.h»

//## begin module%4DFCA5CB038A.declarations preserve=no

//## end module%4DFCA5CB038A.declarations

//## begin module%4DFCA5CB038A.additionalDeclarations preserve=yes

//## end module%4DFCA5CB038A.additionalDeclarations

//## begin module%4DFCA5CB038A.epilog preserve=yes

//## end module%4DFCA5CB038A.epilog

Transaction manager. cpp

//## begin module%1.2%.codegen_version preserve=yes

// Read the documentation to learn more about C++ code generator

// versioning.

//## end module%1.2%.codegen_version

//## begin module%4DFC92D8035B.cm preserve=no

// %X% %Q% %Z% %W%

//## end module%4DFC92D8035B.cm

//## begin module%4DFC92D8035B.cp preserve=no

//## end module%4DFC92D8035B.cp

//## Module: TransactionMeneger%4DFC92D8035B; Package body

//## Subsystem: Control%4DFC8E200251

//## Source file: C: Program FilesRationalRose 2000C++sourceControlTransactionMeneger.cpp

//## begin module%4DFC92D8035B.additionalIncludes preserve=no

//## end module%4DFC92D8035B.additionalIncludes

//## begin module%4DFC92D8035B.includes preserve=yes

//## end module%4DFC92D8035B.includes

TransactionMeneger.h

#include «ControlTransactionMeneger.h»

//## begin module%4DFC92D8035B.declarations preserve=no

//## end module%4DFC92D8035B.declarations

//## begin module%4DFC92D8035B.additionalDeclarations preserve=yes

//## end module%4DFC92D8035B.additionalDeclarations

//## begin module%4DFC92D8035B.epilog preserve=yes

//## end module%4DFC92D8035B.epilog

DB Manager. h

//## begin module%1.2%.codegen_version preserve=yes

// Read the documentation to learn more about C++ code generator

// versioning.

//## end module%1.2%.codegen_version

//## begin module%4DFC92C902EE.cm preserve=no

// %X% %Q% %Z% %W%

//## end module%4DFC92C902EE.cm

//## begin module%4DFC92C902EE.cp preserve=no

//## end module%4DFC92C902EE.cp

//## Module: DBManager%4DFC92C902EE; Package specification

//## Subsystem: Control%4DFC8E200251

//## Source file: C: Program FilesRationalRose 2000C++sourceControlDBManager.h

#ifndef DBManager_h

#define DBManager_h 1

//## begin module%4DFC92C902EE.additionalIncludes preserve=no

//## end module%4DFC92C902EE.additionalIncludes

//## begin module%4DFC92C902EE.includes preserve=yes

//## end module%4DFC92C902EE.includes

Zapis.h

#include «EntityZapis.h»

// TransactionMeneger

#include «ControlTransactionMeneger.h»

//## begin module%4DFC92C902EE.declarations preserve=no

//## end module%4DFC92C902EE.declarations

//## begin module%4DFC92C902EE.additionalDeclarations preserve=yes

//## end module%4DFC92C902EE.additionalDeclarations

//## begin module%4DFC92C902EE.epilog preserve=yes

//## end module%4DFC92C902EE.epilog

#endif

InputForm.h

//## begin module%1.2%.codegen_version preserve=yes

// Read the documentation to learn more about C++ code generator

// versioning.

//## end module%1.2%.codegen_version

//## begin module%4DFC9495036B.cm preserve=no

// %X% %Q% %Z% %W%

//## end module%4DFC9495036B.cm

//## begin module%4DFC9495036B.cp preserve=no

//## end module%4DFC9495036B.cp

//## Module: FormPostuplen%4DFC9495036B; Package specification

//## Subsystem:

//## Source file: C: Program FilesRationalRose 2000C++sourceFormPostuplen.h

#ifndef FormPostuplen_h

#define FormPostuplen_h 1

//## begin module%4DFC9495036B.additionalIncludes preserve=no

//## end module%4DFC9495036B.additionalIncludes

//## begin module%4DFC9495036B.includes preserve=yes

//## end module%4DFC9495036B.includes

// InputForm

#include «InputForm.h»

//## begin module%4DFC9495036B.declarations preserve=no

//## end module%4DFC9495036B.declarations

//## begin module%4DFC9495036B.additionalDeclarations preserve=yes

//## end module%4DFC9495036B.additionalDeclarations

//## begin module%4DFC9495036B.epilog preserve=yes

//## end module%4DFC9495036B.epilog

#endif