Объектно–ориентированная модель информационной подсистемы «Трудоустройство»
Диаграммы состояний являются хорошо известным методом описания поведения систем. Они изображают все возможные состояния, в которых может находиться конкретный объект, а также изменения состояния объекта, которые происходят в результате влияния некоторых событий на этот объект. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса, чтобы показать… Читать ещё >
Объектно–ориентированная модель информационной подсистемы «Трудоустройство» (реферат, курсовая, диплом, контрольная)
Содержание ВВЕДЕНИЕ
1 КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ
2 СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ
3 СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ
4 СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА
5 СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ
6 ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ. ДОБАВЛЕНИЕ СВЯЗЕЙ МЕЖДУ КЛАССАМИ
7 СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ ДЛЯ КЛАССОВ И ДИАГРАММЫ КОМПОНЕНТОВ
8 СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ
9 ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА С++
ЗАКЛЮЧЕНИЕ
3
БИБЛИОГРАФИЧЕСКИЙ СПИСОК Приложение А. Листинг кода приложения на языке С++
Унифицированный язык моделирования (UML, Unified Modeling Language) является преемником методов объектно-ориентированного анализа и проектирования (OOA&D), которые появились в конце 80-х и начале 90-х годов.
Язык UML в его текущем состоянии включает в себя нотацию и метамодель. Нотация представляет собой совокупность графических элементов, которые используются в моделях. Метамодель является средством придания языку UML большей строгости.
В данном курсовом проекте разработана объектно-ориентированная модель информационной подсистемы трудоустройство. Данная модель разработана с помощью программного продукта Rational Rose 2000 Enterprise Edition, с помощью языка UML.
1 КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ
Сейчас, в условиях рыночной экономики, когда везде требуются высококвалифицированные специалисты, преимущественно экономических специальностей, очень много людей, не удовлетворяющих данным параметрам, остаются без работы. Именно они и обращаются к услугам бирж труда, причем их число значительно выросло по сравнению с 1991 г.
Только регистрация безработных без использования автоматизации — очень трудоемкая работа, а ведь биржи труда не только производят регистрацию людей, у них много функций:
— регистрация вакантных мест;
— трудоустройство безработных и других лиц, желающих получить работу;
— изучение конъюнктуры рынка труда и предоставление информации о ней;
— тестирование лиц, желающих получить работу;
— профессиональная ориентация и профессиональная переподготовка безработных;
— выплата пособий.
При автоматизации значительно сократится время и трудоемкость осуществления этих операций.
1.1 Общая характеристика
В данном курсовом проекте разработана объектно-ориентированная модель информационной подсистемы «Трудоустройство». Потребности и предложения на рынке трудовых ресурсов можно проследить на бирже труда. В курсовом проекте представлена объектно-ориентированная модель информационной подсистемы которая автоматизирует работу агентства по трудоустройству.
1.2 Актуальность разрабатываемой подсистемы
База данных, используемая при работе агентства по трудоустройству, хранит данные о клиентах, их квалификации и критериях работы. В задачу агентства входят предоставление информации об имеющихся вакансиях, создание анкеты клиента, занесение данных о клиенте в базу данных. Служба приема заявок принимает заявку клиента. Передает данные администратору БД. После администратор делает запросов базу данных о наличии вакансий по критериям, представленным клиентом и выдает информацию клиенту.
Данная объектно-ориентированная модель информационной подсистемы должна обеспечивать возможность добавления новых данных о клиентах, изменении старых данных, если это необходимо, создание заявок, справок.
2 СОЗДАНИЕ ДИАГРАММЫ ПРЕЦИДЕНТОВ
Диаграммы прецедентов описывают функциональность информационной системы, которая будет видна пользователям. Каждая функциональность изображается в виде «прецедентов использования» (use case) или просто прецедентов. Прецедент — это типичное взаимодействия пользователя с системой, которое при этом:
- описывает видимую пользователем функцию,
— может представлять различные уровни детализации,
— обеспечивает достижение конкретной цели, важной для пользователя.
Use case (вариант использования) это функциональное требование. Данный вид диаграмм в основном используется для описания функциональных требований к системе, для описания предметной области с целью лучшего понимания функционирования системы.
Основные элементы диаграммы use case: use case (вариант использования), актеры (представляют собой некоторую роль, которую играет пользователь по отношению к системе), связи и отношения между актерами и use case.
На рисунке 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. Повторив пункты 6 и 7, поместим на диаграмму действующих лиц и назовем их:
— Служба приема.
— Администратор.
9. Создадим абстрактный Вариант Использования «Backorder item» («Отклонить заказ»).
10. Добавим ассоциацию между действующим лицом «Клиент» и вариантом использования «Подача заявки на работу».
11. Повторим пункт 10 для остальных действующих лиц.
12. Добавим связи расширения между вариантом использования «Отклонить заявку» и вариантом использования «Обработать заявку»:
3 Создание диаграммы последовательности
Это диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. На ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются. Одно из основных назначений данной диаграммы — отобразить последовательность действий для части или целого варианта использования (use case).
Рисунок 3.1 — Диаграмма последовательности Объект — это нечто, заключающее в себе некоторые данные и поведение.
Класс — это некая сущность, представляющая собой как бы черновик объекта; определяет данные и поведение, которыми должен обладать объект.
На диаграмме приведены следующие объекты соответствующих классов:
— выбор варианта заявки — объект класса OrederForm;
— анкета заявки — объект класса Form — конкретной формы ввода данных о клиенте;
— администратор — объект управляющего класса ADM;
— заявка № 1234 — объект класса Claim;
— управляющий транзакциями — объект класса Transaction;
Для создания диаграммы последовательности были совершены следующие действия:
1. Создаем диаграмму последовательности: на панели задач выбираем Interaction Diagram, затем тип диаграммы: Sequence.
2. Добавляем на созданную диаграмму действующие лица и объекты с помощью соответствующих кнопок панели инструментов.
3. Добавляем сообщения на диаграмму с помощью кнопки Object Message (Сообщение объекта).
4. Выполняем соотнесение объектов с классами с помощью меню каждого объекта Open Specification (Открыть спецификацию).
4 Создание диаграммы сотрудничества
На данной диаграмме экземпляры объектов изображаются в виде пиктограмм, также как на диаграмме последовательности стрелки обозначают сообщения, однако их временная последовательность указывается посредством нумерации сообщений. Можно сказать, что диаграммы кооперации (сотрудничества) и последовательности очень похожи, они несут одну и ту же информацию, отличаются они лишь представлением информации.
Рисунок 4.1 — Диаграмма сотрудничества Для создания диаграммы сотрудничества необходимо:
1. На панели задач выбираем Interaction Diagram, затем тип диаграммы: Collaboration.
2. Добавляем действующее лицо — Клиент и используемые объекты:
— выбор варианта заявки (класс — OrederForm);
— анкета (класс Form);
— администратор (класс ADM);
— заявка № 1234 (класс Claim);
— управляющий транзакцией (класс — Transaction);
3. Добавляем на диаграмму следующие сообщения, соотнесенные с операциями:
— Create () — создать новую форму для ввода данных о клиенте.
— Open () — открыть анкету для ввода данных о клиенте.
— Enter () — ввести данные о клиенте.
— Save () — нажать кнопку сохранить на форме.
— SaveForm () — послать запрос в БД на сохранение информации.
— Create () — создать пустую запись в БД.
— Save in BD () — сохранение записи в базе данных.
5 Создание диаграммы классов
Диаграмма классов по праву занимает одно из центральных мест не только в UML, но и в объектно-ориентированном подходе вообще. Данная диаграмма включает в себя большой набор понятий моделирования. Диаграмма классов описывает типы объектов системы и различные статические отношения, которые существуют между ними. Существуют два основных вида статических отношений, это ассоциации и подтипы. На диаграммах классов также изображаются атрибуты классов, операции классов и ограничения, которые накладываются на связи между объектами.
Рисунок 5.1 — Главная диаграмма классов Рисунок 5.2 — Диаграмма классов.
Рисунок 5.3 — Стереотипы классов.
Граничные классы (boundary classes) — это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами. В пакет «Boundaries» были добавлены следующие классы: класс Form (анкета клиента) и класс OrederForm (выбор варианта заявки).
Рисунок 5.4 — Главная диаграмма класса пакета «Boundaries»
Классы сущности (entity classes) — отражают основные понятия (абстракции) предметной области и, как правило, содержат хранимую информацию. В данный пакет были добавлен класс Claim.
Рисунок 5.5 — Главная диаграмма класса пакета «Entities»
Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. В данном проекте данную функцию выполняет класс Control, а также ControlTranz.
Рисунок 5.5 — Главная диаграмма класса пакета «Control»
Создание диаграммы классов:
1. Создадим пакеты:
а) щелкнем правой кнопкой мыши на логическом представлении браузера;
б) в открывшемся меню выберите пункт New >Package;
в) назовем новый пакет Entities;
г) повторим пункты, а — б и создадим пакеты Boundaries и Control.
2. Создадим диаграмму классов для сценария AddNewForm:
а) щелкнем правой кнопкой мыши на логическом представлении браузера;
б) в открывшемся меню выберите пункт New >Class Diagram;
в) назовем её AddNewForm;
г) дважды щелкнув мышью на этой диаграмме в браузере, откроем ее;
д) перетащим из браузера на диаграмму классы OrederForm, Form, Claim, ADM и Transaction;
Полученная диаграмма классов показана на рисунке 5.2.
7. Добавим стереотипы к классам:
а) щелкнем правой кнопкой мыши на классе OrederForm диаграммы;
б) в открывшемся меню выберем пункт Open Specification;
в) в поле стереотипа выберем Boundary;
г) нажмем кнопку Apply и кнопку OK;
8. Действуя аналогично добавим стереотипы к классам как показано на рисунке 5.3.
9. Объединим классы в пакеты:
а) в браузере перетащим класс OrederForm на пакет Boundaries;
б) перетащим класс Form на пакет Boundaries;
в) перетащим классы ADM и Transaction на пакет Control;
г) перетащим класс Claim на пакет Entities.
10. Добавим диаграммы классов к каждому пакету:
а) в браузере щелкнем правой кнопкой мыши на пакете Boundaries;
б) в открывшемся меню выберите пункт New >Class Diagram.
в) введем имя новой диаграммы Main;
г) откроем её;
д) перетащим на нее из браузера классы OrederForm и Form.
Главная диаграмма классов пакета Boundaries представлена на рисунке 5.4.
11. Действуя аналогично добавим диаграммы классов к оставшимся пакетам. Их главные диаграммы представлены соответственно на рисунках 5.5 и 5.6.
6 ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ
Атрибут — это элемент информации, связанный с классом. Они содержатся внутри класса, поэтому они скрыты от других классов. В связи с этим иногда требуется указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility). Для определения атрибутов и операций классов было произведено обращение к потоку событий. В результате к классам были добавлены дополнительные атрибуты и связи между классами (рисунок 6.1).
Рисунок 6.1 — Диаграмма классов для сценария «Составление заявки»
На данной стадии был создан новый класс FormItem с присвоенным ему стереотипом Entity и следующими атрибутами:
§ ItemID: Integer;
§ IDescription: String.
И операциями:
§ Create (): Boolean;
§ SetInfo (ID: Integer = 0): Boolean.
Добавляем ассоциации:
а) нажимаем кнопку Unidirectional Association;
б) проводим ассоциацию от класса OrderForm к классу Form;
в) действуя аналогично, создаем ассоциации как показано на рисунке 6.2.
г) щелкнем правой кнопкой мыши на однонаправленной ассоциации между классами OrderForm и Form со стороны класса OrderForm;
д) в открывшемся меню выберим пункт Multiplicity >Zero or One;
е) щелкнем правой кнопкой мыши на другом конце однонаправленной ассоциации;
ж) в открывшемся меню выберите пункт Multiplicity >Zero or One;
з) действуя аналогично, добавим на диаграмму значения множественности для остальных ассоциаций, как показано на рисунке 6.3.
Рисунок 6.2 — Добавление связей между классами.
Рисунок 6.3 — Ассоциации сценария AddNewForm.
7. СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ ДЛЯ КЛАССОВ И ДИАГРАММЫ КОМПОНЕНТОВ
Диаграммы состояний являются хорошо известным методом описания поведения систем. Они изображают все возможные состояния, в которых может находиться конкретный объект, а также изменения состояния объекта, которые происходят в результате влияния некоторых событий на этот объект. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса, чтобы показать динамику поведения единственного объекта.
Рисунок 7.1 — Диаграмма состояний Создание диаграммы:
1. Найдем в браузере класс Order.
2. Щелкнем на классе правой кнопкой мыши и в открывшемся меню укажим пункт New >Statechart Diagram. Назовем её «State». Двойной щелчок на имени откроет диаграмму.
3. Добавим начальное и конечное состояние на диаграмму:
4. Выполним описание состояний на диаграмме:
Диаграмма компонентов отображает организацию компонентов и зависимости между ними. Компонент — это физический элемент реализации (компоненты исходного кода, бинарного кода, выполняемые компоненты) с четко определенным интерфейсом, предназначенный для использования в качестве заменяемой части системы. Каждый компонент представляет собой реализацию некоторых классов системы.
Рисунок 7.2 — Зависимость между пакетами Построение диаграммы компонентов:
1. Создаем пакеты для компонентов: New->Package (Создать пакет) и присваиваем им названия соответственно: Entities, Boundaries и Control.
2. Отображаем зависимости между созданными пакетами с помощью кнопки Dependecy (Зависимость) панели инструментов: от пакета Boundaries к пакету Control; от пакета Control к пакету Entities (рисунок 7.2).
3. Добавляем компоненты к пакетам с помощью кнопок Package Specefication (Спецификация пакета) и Package Body (Тело пакета) панели инструментов и аналогично отображаем зависимости:
4. Создаем диаграмму компонентов системы: New->Component Diagramm и выполняем размещение компонентов на диаграмме компонентов.
5. Помещаем на диаграмму компонентов спецификацию задачи ZakazClientExe и ZakazServerExe с помощью кнопки Task Specification (Спецификация задачи) панели инструментов.
6. Выполняя соотнесение классов с компонентами, как показано на рисунке 7.3, получаем диаграмму компонентов.
Рисунок 7.3 — Диаграмма компонентов
8. СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ
Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами разрабатываемой системы. Одним из существенных понятий данного вида диаграмм является понятие узел. Узел представляет собой некоторый тип вычислительного устройства, как правило, самостоятельную часть аппаратуры.
Рисунок 8.1 — Диаграмма размещения Создание диаграммы размещения:
1. Добавьте узлы к диаграмме Размещения:
а) дважды щелкнув мышью на представлении размещения в браузере, откройте диаграмму размещения;
б) нажмите кнопку Processor (Процессор) панели инструментов;
в) щелкнув мышью на диаграмме, поместите туда процессор;
г) введите имя процессора Сервер базы данных;
д) действуя аналогично, добавьте следующие процессоры:
1) Сервер приложения;
2) Клиентская рабочая станция № 1;
3) Клиентская рабочая станция № 2.
е) на панели инструментов нажмите кнопку Device (Устройство);
ж) щелкнув мышью на диаграмме, поместите туда устройство;
з) назовите его Принтер.
4. Добавьте связи на диаграмме:
а) нажмите кнопку Connection (Связь) панели инструментов;
б) щелкните мышью на процессоре Сервер базы данных.
в) проведите линию связи к процессору Сервер приложения.
г) действуя аналогично, добавьте следующие связи:
1) от процессора Сервер приложения к процессору Клиентская рабочая станция № 1;
2) от процессора Сервер приложения к процессору Клиентская рабочая станция № 2;
3) от процессора Сервер приложения к устройству Принтер.
5. Выполните добавление процессов на диаграмме:
а) щелкните правой кнопкой мыши на процессоре Сервер приложения в браузере;
б) в открывшемся меню выберите пункт New >Process (Создать >Процесс);
в) введите имя процесса — OrderServer. exe;
г) действуя аналогично, добавьте процессы:
1) процесс OrderClient. exe на процессоре Клиентская рабочая станция № 1;
2) процесс ATMClient. exe на процессоре Клиентская рабочая станция № 2.
6. Выполните показ процессов на диаграмме:
а) щелкните правой кнопкой мыши на процессоре Сервер приложения;
б) в открывшемся меню выберите пункт Show Processes (Показать процессы);
в) действуя аналогично, покажите процессы на следующих элементах:
1) процессор Клиентская рабочая станция № 1;
2) процессор Клиентская рабочая станция № 2.
9. ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C++
Язык C++ является одним из наиболее широко применяемых на практике объектно — ориентированных языков. Rational Rose интегрируется с C++ посредством генерации кода и обратного проектирования. В Rational Rose 2000 предусмотрена возможность генерации программного кода C++.
При генерации с помощью Rational Rose 2000 Enterprise Edition программного кода на стандартном C++ необходимо:
1. Создать компоненты;
2. Определить компоненты для классов;
3. Установить свойства генерации программного кода;
4. Выбрать класс или компонент для генерации на диаграмме Классов или Компонентов;
5. Выбрать в меню: Tools > C++ > Code Generation
6. Выбрать в меню: Tools > C++ > Browse Header или Browse Body для просмотра сгенерированного программного кода.
Первый этап процесса генерации программного кода — создание компонентов для классов. Это файлы с расширениями *. cpp (файл реализации) и *. h (заголовочный файл). В С++ данный этап не является обязательным. Если не описать компоненты, Rational Rose сгенерирует файлы *. cpp и *. h для каждого класса. Тем не менее, рекомендуется создавать компоненты, что позволит управлять отображением классов на компоненты и моделировать зависимости между компонентами.
Следующим шагом является установка свойств генерации программного кода для классов, компонентов и других элементов модели.
Рисунок 9.1 — Окно выбора компонентов и классов программы Для генерации программного кода Rational Rose 2000 использует самую различную информацию, содержащуюся в модели. Анализируются множественность, имена ролей, включение и другие характеристики каждой связи. Просматриваются атрибуты, операции, видимость и другие детали каждого класса. Rational Rose 2000 выбирает нужные для генерации кода сведения из всех данных, вводимых в окнах спецификации различных элементов модели.
заключение
В данном курсовом проекте была разработана объектно-ориентированная модель информационной подсистемы «Трудоустройство». Данная разработка написана с помощью языка UML, с использованием среды разработки — программного продукта Rational Rose 2000.
Были разработаны следующие диаграммы:
— диаграмма прецедентов;
— диаграмма последовательности;
— диаграмма сотрудничества;
— диаграмма классов;
— диаграмма состояния для классов;
— диаграмма компонентов;
— диаграмма размещения.
Всё это позволяет автоматизировать работу биржи труда.
Данный курсовой проект позволяет вести учет клиентов, выдавать им информацию о существующих вакансиях, изменять и добавлять данные.
В конце был сгенерирован ко C++.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. — М.: ДМК, 2000. — 432 с., ил. (Серия «для программистов»).
2. Боггс У., Боггс М. UML и Rational Rose: Пер. с англ. — М.: Издательство «Лори», 2000. — 581 с., ил.
3. Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. — СПб.: Питер, 2002. — 432 с., ил.
Приложение А
Листинг программного кода на языке C++
//## 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%476 854 5800EA.cm preserve=no
// %X% %Q% %Z% %W%
//## end module%476 854 5800EA.cm
//## begin module%476 854 5800EA.cp preserve=no
//## end module%476 854 5800EA.cp
//## Module: ADM%476 854 5800EA; Package body
//## Subsystem: Control%476 8514C02EE
//## Source file: C: Program FilesRationalRose 2000C++sourceControlADM.cpp
//## begin module%476 854 5800EA.additionalIncludes preserve=no
//## end module%476 854 5800EA.additionalIncludes
//## begin module%476 854 5800EA.includes preserve=yes
//## end module%476 854 5800EA.includes
// ADM
#include «ControlADM.h»
//## begin module%476 854 5800EA.declarations preserve=no
//## end module%476 854 5800EA.declarations
//## begin module%476 854 5800EA.additionalDeclarations preserve=yes
//## end module%476 854 5800EA.additionalDeclarations
моделирование диаграмма информационный класс
// Class ADM
ADM:ADM ()
//## begin ADM: ADM%47 6825B2032C_const.hasinit preserve=no
//## end ADM: ADM%47 6825B2032C_const.hasinit
//## begin ADM: ADM%47 6825B2032C_const.initialization preserve=yes
//## end ADM: ADM%47 6825B2032C_const.initialization
{
//## begin ADM: ADM%47 6825B2032C_const.body preserve=yes
//## end ADM: ADM%47 6825B2032C_const.body
}
ADM:ADM (const ADM &right)
//## begin ADM: ADM%47 6825B2032C_copy.hasinit preserve=no
//## end ADM: ADM%47 6825B2032C_copy.hasinit
//## begin ADM: ADM%47 6825B2032C_copy.initialization preserve=yes
//## end ADM: ADM%47 6825B2032C_copy.initialization
{
//## begin ADM: ADM%47 6825B2032C_copy.body preserve=yes
//## end ADM: ADM%47 6825B2032C_copy.body
}
ADM:~ADM ()
{
//## begin ADM:~ADM%47 6825B2032C_dest.body preserve=yes
//## end ADM:~ADM%47 6825B2032C_dest.body
}
ADM & ADM: operator=(const ADM &right)
{
//## begin ADM: operator=%47 6825B2032C_assign.body preserve=yes
//## end ADM: operator=%47 6825B2032C_assign.body
}
int ADM: operator==(const ADM &right) const
{
//## begin ADM: operator==%47 6825B2032C_eq.body preserve=yes
//## end ADM: operator==%47 6825B2032C_eq.body
}
int ADM: operator≠(const ADM &right) const
{
//## begin ADM: operator≠%47 6825B2032C_neq.body preserve=yes
//## end ADM: operator≠%47 6825B2032C_neq.body
}
//## Other Operations (implementation)
void ADM: SaveForm ()
{
//## begin ADM: SaveForm%47 682 651 000 °F.body preserve=yes
//## end ADM: SaveForm%47 682 651 000 °F.body
}
// Additional Declarations
//## begin ADM%47 6825B2032C.declarations preserve=yes
//## end ADM%47 6825B2032C.declarations
//## begin module%476 854 5800EA.epilog preserve=yes
//## end module%476 854 5800EA.epilog
//## 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%476 8542F038A.cm preserve=no
// %X% %Q% %Z% %W%
//## end module%476 8542F038A.cm
//## begin module%476 8542F038A.cp preserve=no
//## end module%476 8542F038A.cp
//## Module: ADM%476 8542F038A; Package specification
//## Subsystem: Control%476 8514C02EE
//## Source file: C: Program FilesRationalRose 2000C++sourceControlADM.h
#ifndef ADM_h
#define ADM_h 1
//## begin module%476 8542F038A.additionalIncludes preserve=no
//## end module%476 8542F038A.additionalIncludes
//## begin module%476 8542F038A.includes preserve=yes
//## end module%476 8542F038A.includes
// Claim
#include «EntitiesClaim.h»
// Transaction
#include «ControlTransaction.h»
//## begin module%476 8542F038A.declarations preserve=no
//## end module%476 8542F038A.declarations
//## begin module%476 8542F038A.additionalDeclarations preserve=yes
//## end module%476 8542F038A.additionalDeclarations
//## begin ADM%47 6825B2032C.preface preserve=yes
//## end ADM%47 6825B2032C.preface
//## Class: ADM%47 6825B2032C
//## Category: Control%476 838 2500BB
//## Subsystem: Control%476 8514C02EE
//## Persistence: Transient
//## Cardinality/Multiplicity: n
class ADM
{
//## begin ADM%47 6825B2032C.initialDeclarations preserve=yes
//## end ADM%47 6825B2032C.initialDeclarations
public:
//## Constructors (generated)
ADM ();
ADM (const ADM &right);
//## Destructor (generated)
~ADM ();
//## Assignment Operation (generated)
ADM & operator=(const ADM &right);
//## Equality Operations (generated)
int operator==(const ADM &right) const;
int operator≠(const ADM &right) const;
//## Other Operations (specified)
//## Operation: SaveForm%4 768 265 1000F
void SaveForm ();
//## Get and Set Operations for Associations (generated)
//## Association: %4 768 473 2037A
//## Role: ADM:%476 847 330 167
const Transaction * get_the_Transaction () const;
void set_the_Transaction (Transaction * value);
//## Association: %476 8477D03B9
//## Role: ADM:%476 8477E03B9
const UnboundedSetByReference get_the_Claim () const;
void set_the_Claim (UnboundedSetByReference value);
// Additional Public Declarations
//## begin ADM%47 6825B2032C.public preserve=yes
//## end ADM%47 6825B2032C.public
protected:
// Additional Protected Declarations
//## begin ADM%47 6825B2032C.protected preserve=yes
//## end ADM%47 6825B2032C.protected
private:
// Additional Private Declarations
//## begin ADM%47 6825B2032C.private preserve=yes
//## end ADM%47 6825B2032C.private
private: //## implementation
// Data Members for Associations
//## Association: %4 768 473 2037A
//## begin ADM:%476 847 330 167.role preserve=no public: Transaction {0.1 -> 0.1RHN}
Transaction *the_Transaction;
//## end ADM:%476 847 330 167.role
//## Association: %476 8477D03B9
//## begin ADM:%476 8477E03B9.role preserve=no public: Claim {1 -> 0. nRHN}
UnboundedSetByReference the_Claim;
//## end ADM:%476 8477E03B9.role
// Additional Implementation Declarations
//## begin ADM%47 6825B2032C.implementation preserve=yes
//## end ADM%47 6825B2032C.implementation
};
#endif