Объектно-ориентрованная модель информационной подсистемы «Автосервис»

Важнейшими характеристиками любой системы являются ее структура и процесс функционирования. Под структурой системы понимают устойчивую во времени совокупность взаимосвязей между ее элементами или компонентами. Именно структура связывает воедино все элементы и препятствует распаду системы на отдельные компоненты. Структура системы может отражать самые различные взаимосвязи, в том числе и вложенность элементов одной системы в другую. В этом случае принято называть более мелкую или вложенную систему подсистемой. Процесс функционирования системы тесно связан с изменением ее свойств или поведения во времени. При этом важной характеристикой системы является ее состояние, под которым понимается совокупность свойств или признаков, которые в каждый момент времени отражают наиболее существенные особенности поведения системы. Общим свойством всех моделей является их подобие оригинальной системе или системе-оригиналу. Важность построения моделей заключается в возможности их использования для получения информации о свойствах или поведении системы-оригинала. При этом процесс построения и последующего применения моделей для получения информации о системе-оригинале получил название моделирование. Рассмотрение особенностей языка UML связано с вопросами логического или информационного моделирования систем. Общая модель системы содержит некоторую важную информацию о функциональных особенностях данной системы, которые дают представление о ее дальнейшем поведении. Целью курсового проекта является разработка объектно-ориентрованной модели информационной подсистемы «Автосервис» с использованием языка UML. Для построения информационной подсистемы была использована система моделирования Rational Rose 2000 Enterprise v.6.5.

1. Краткая характеристика предметной области

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

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

— ввод информации о заказе клиента;

— формирование и получение отчетности;

— ведение общей базы данных;

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

Для описания структуры подсистемы «Автосервис» используется язык UML (Unified Modeling Language). Унифицированный язык моделирования (UML) является стандартным инструментом для создания «чертежей» программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем. Язык UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру. Некоторые особенности системы лучше всего моделировать в виде текста, другие — графически. На самом деле во всех интерфейсных системах существуют структуры, которые невозможно представить с помощью одного лишь языка программирования. UML — графический язык, это позволяет решить проблему визуализации. Язык UML предназначен, прежде всего, для разработки программных систем. Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, скажем, документооборот в юридических системах, структуру и функционирование системы, осуществлять проектирование аппаратных средств.

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

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

Для построения информационной подсистемы была использована система моделирования Rational Rose 2000.

Выводы

1. Задача разработки информационной подсистемы для учета заказов заключается в описании стандартными средствами языка UML всех происходящих в отделе процессов, связанных с занесением данных в БД и получением отчетности в информационной подсистеме «Автосервис» .

2. Для разработки объектно-ориентированной модели требуемой подсистемы необходимо создать все базовые диаграммы языка UML и выполнить генерацию программного кода каркаса приложения на языке С++.

2. Создание диаграммы прецедентов

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

Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой [1, 2]. Действующее лицо — это роль, которую пользователь играет по отношению к системе [1, 2]. Действующие лица представляют собой роли, а не конкретных людей или наименования работ.

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

Используя методы Rational Rose 2000, согласно заданию курсового проектирования, была создана диаграмма прецедентов (рисунок 2.1).

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

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

Конкретная цель диаграмм вариантов использования — это документирование вариантов использования (все, входящее в сферу применения системы), действующих лиц (все вне этой сферы) и связей между ними [1, 2].

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

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

Опишем более подробно диаграммe прецедентов (рисунок 2.1).

Действующие лица:

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

2. Менеджер — занимается оформлением заказа, вносит его в базу данных. Также менеджер, на основании заказа клиента, выдаёт задание мастеру-ремонтнику на техническое обслуживание транспортного средства.

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

4. Транспортное средство — автомобиль или иное транспортное средство клиента, которое может быть на ремонте или техническом обслуживании.

Базовый вариант использования «Заказ» — этот вариант использования дает возможность зафиксировать в базе данных (БД) информационной подсистемы «Автосервис» все заявки клиентов.

Выводы

1. Изучена предметная область и создана диаграмма прецедентов.

2. Диаграмма прецедентов включает пять вариантов использования и четыре актера.

3. Базовым вариантом использования, наиболее важным для реализации системы, является вариант использования «Заказ» .

4. С прецедентом «Заказ» взаимодействуют актеры «Клиент» и «Менеджер». Данные базового варианта использование используются актером «Мастер-ремонтник» .

3. Создание диаграммы последовательности

Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования [1 — 4]. Для варианта использования «Заказ клиента» создана диаграмма последовательности (рисунок 3.1).

Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами. Sequence diagram — это диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений [1, 2]. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени — вдоль оси Y.

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение изображается в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице, сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, показать самоделегирование (self-delegation) сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

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

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

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

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

Выводы

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

2. Создана диаграмма последовательности. Созданы классы и методы.

На диаграмме последовательностей представлено действующее лицо «Менеджер» и восемь объектов: три формы, для создания удобного пользовательского интерфейса, а также пять классов и методы:

1. Form_Zakaz {Open_form (), Input_data (), Input_worker (), Input_kind_work () } - класс формы.

2. Form_klient {open_form ()} - класс формы.

3. Form_Ysluga {Open_form ()} - класс формы.

4. Work_BD{Save ()} - класс записи введенной в БД информации.

5. Print_data {Print ()} - класс печати.

4. Создание диаграммы сотрудничества

Диаграммы сотрудничества (Collaboration diagram) — второй тип диаграмм взаимодействия. Г. Буч collaboration diagram называет диаграммой объектов [1, 2]. Действительно, эта диаграмма отличается от предыдущей тем, что она не акцентирует внимание на последовательности передачи сообщений, она отражает наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие сообщений от клиентов к серверам. Так как временная шкала не участвует в демонстрации сообщений, то эта диаграмма получается компактней и как нельзя лучше подходит для того, чтобы окинуть одним взглядом взаимодействие всех объектов.

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

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

Так как диаграммы сотрудничества схожи с диаграммами последовательностей, то согласно созданной выше диаграмме последовательности для варианта использования «Заказ», была создана диаграмма сотрудничества для варианта использования «Заказ» (рисунок 4.1).

Рисунок 4.1 — Диаграмма сотрудничества для варианта использования «Заказ»

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

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

5. Создание диаграммы классов

Диаграммы классов (Class diagram) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов [1, 2]. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях:

— в нотации, предложенной Г. Бучем;

— в нотации ОМТ;

— в нотации Unified (унифицированной нотации).

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

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

На одних показывают некоторое подмножество классов и отношения между классами подмножества.

На других отображают то же подмножество, но вместе с атрибутами и операциями классов.

Третьи соответствуют только пакетам классов и отношениям между ними. По умолчанию существует одна диаграмма классов, называемая Главной (Main) и располагающаяся непосредственно под «Логическим представлением» в браузере. На этой диаграмме показывают пакеты классов модели. Внутри каждого пакета также имеется «Главная диаграмма», включающая в себя все классы этого пакета (рисунок 5.1).

Рисунок 5.1 — Главная диаграмма классов После создания главой диаграммы классов создается диаграмма классов для варианта использования «Заказ» (рисунок 5.2).

Рисунок 5.2 — Диаграмма классов для варианта использования «Заказ»

К классам на диаграмме добавлены стереотипы. Стереотип «entity» указан для класса «Form_Zakaz», стереотип «boundary» для классов «Form_klient» и «Form_Ysluga», стереотип «control» — для классов «Print_date» и «Work_BD» .

Соответствующие классы объединены в пакеты:

1. «Date» — классы «Form_Zakaz «» Form_klient «, «Form_Ysluga «;

2. «BD» — класс «Work_BD «;

3. «Print» — класс «Print_date «

Для каждого пакета создана диаграмма классов. Диаграмма классов для пакета «Date» представлена на рисунке 5.3.

Рисунок 5.3 — Диаграмма классов пакета «Date»

Диаграмма классов для пакета «BD» представлена на рисунке 5.4.

Рисунок 5.4 — Диаграмма классов пакета «BD»

Диаграмма классов для пакета «Print_date» показана на рисунке 5.5.

Рисунок 5.5 — Диаграмма классов пакета «Print_date»

Выводы

1. Созданы три пакета «Date», «Print_date» и «BD» .

2. Классы, реализующие варианта использования «Заказ», были помещены в указанные пакеты.

3. Создана главная диаграмма классов и три диаграммы классов для соответствующих пакетов.

4. Соответствующие классы объединены в пакеты:

— «Date» — классы" Form_Zakaz «,» Form_klient" ," Form_Ysluga" ;

— «BD «- классы «Work_BD «;

— «Print» — класс «Print_date» .

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

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

Рисунок 6.1 — Диаграмма классов со связями и атрибутами Выводы

1. Произведено добавление атрибутов и типов значений.

2. Созданы связи между классами.

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

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

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

На диаграмме имеются два специальных состояния — начальное (start) и конечное (stop). Процессы, происходящие в тот момент, когда объект находится в определенном состоянии, называются действиями (actions) [1, 2].

С состоянием можно связывать следующие данные: деятельность, входное действие, выходное действие и событие.

Входное действие (entry action) — это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

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

Событие (event) — это то, что вызывает переход из одного состояния в другое. Событие размещают на диаграмме вдоль линии перехода.

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

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

В данном курсовом проекте диаграмма состояний создается для класса «Work_BD». Она представлена на рисунке 7.1.

Рисунок 7.1 — Диаграмма состояний для класса «Work_BD»

На данной диаграмме расположены начальное и конечное состояние, состояния «Cancel» (Отменен), «Filled» (Выполнен), «Insert_zakaz» (Ввод данных), «Initialization» (Инициализация), «Save» (Сохранен).

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

1. «Initialization» — действие «Create new ID» (создание идентификатора).

2. «Cancel» — действие «Cancel_vvod» (откат транзакции записи).

3. «Filled» — действие «Record_date» (занесение данных в БД).

4. «Save» — действие «Save_data» (сохранение данных в БД).

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

Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. После создания они сразу добавляются к диаграмме компонентов.

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

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

Диаграмма компонентов, созданная в курсовом проекте, представлена на рисунке 7.2.

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

Для каждого класса создана спецификация пакета и тело пакета. Они соединяются с помощью связей Dependency.

8. Создание диаграммы размещения

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

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

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

Как видно на рисунке 8.1, информационная подсистема «Автосервис» содержит два сервера (сервер приложений и сервер БД), две клиентские рабочие станции и сетевой принтер.

9. Генерация программного кода C++

Язык C++ является одним из наиболее широко применяемых на практике объектно-ориентированных языков. Rational Rose интегрируется с C++ посредством генерации кода и обратного проектирования. В Rational Rose 2000 предусмотрена возможность генерации программного кода C++, а также интеграции с языком Visual C++ версии 6 компании Microsoft. Для генерации программного кода на стандартном C++ необходимо: создать компоненты, определить компоненты для классов, установить свойства генерации программного кода, выбрать класс или компонент для генерации на диаграмме классов или компонентов, выбрать в меню Tools > C++ > Code Generation (рисунок 9.1).

Рисунок 9.1 — Генерации программного кода

Первый этап процесса генерации программного кода — создание компонентов для классов. Это файлы с расширениями *. cpp (файл реализации) и *. h (заголовочный файл). На рисунке 9.2 изображено окно результатов генерации программного кода.

Рисунок 9.2 — Окно результатов генерации программного кода

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

Фрагмент листинга сгенерированного программного кода на языке С++ представлен в приложении А.

Выводы

1. Произведена генерация программного кода на языке С++ для объектно-ориентрованной модели информационной подсистемы «Автосервис» .

2. Сгенерированный код на С++ содержит файлы с расширениями *. cpp (файл реализации) и *. h (заголовочный файл).

Заключение

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

В ходе проектирования было выполнено построение всех диаграмм, предусмотренных заданием на проектирование, а именно:

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

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

— диаграммы поведения;

— диаграммы взаимодействия;

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

— диаграммы состояний;

— диаграммы деятельностей;

— диаграммы реализации;

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

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

Все диаграммы в данном курсовом проекте разработаны с помощью системы моделирования Rational Rose 2000 Enterprise v.6.5.

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

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

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

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

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

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

Приложение А

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

WorkBD.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%47681E8C00BB.cm preserve=no

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

//## end module%47681E8C00BB.cm

//## begin module%47681E8C00BB.cp preserve=no

//## end module%47681E8C00BB.cp

//## Module: workBD%47681E8C00BB; Package specification

//## Subsystem: BD%47681DDC030D

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

#ifndef workBD_h

#define workBD_h 1

//## begin module%47681E8C00BB.additionalIncludes preserve=no

//## end module%47681E8C00BB.additionalIncludes

//## begin module%47681E8C00BB.includes preserve=yes

//## end module%47681E8C00BB.includes

// Printes

#include «PrintPrintes.h»

//## begin module%47681E8C00BB.declarations preserve=no

//## end module%47681E8C00BB.declarations

//## begin module%47681E8C00BB.additionalDeclarations preserve=yes

//## end module%47681E8C00BB.additionalDeclarations

//## begin module%47681E8C00BB.epilog preserve=yes

//## end module%47681E8C00BB.epilog

#endif

ZakazExe.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%47681E0B0186.cm preserve=no

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

//## end module%47681E0B0186.cm

//## begin module%47681E0B0186.cp preserve=no

//## end module%47681E0B0186.cp

//## Module: ZakazExe%47681E0B0186; Task specification

//## Subsystem: Date%47681DC100EA

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

#ifndef ZakazExe_h

#define ZakazExe_h 1

//## begin module%47681E0B0186.additionalIncludes preserve=no

//## end module%47681E0B0186.additionalIncludes

//## begin module%47681E0B0186.includes preserve=yes

//## end module%47681E0B0186.includes

// ClientExe

#include «DateClientExe.h»

// YslugaExe

#include «DateYslugaExe.h»

// workBD

#include «BDworkBD.h»

//## begin module%47681E0B0186.declarations preserve=no

//## end module%47681E0B0186.declarations

//## begin module%47681E0B0186.additionalDeclarations preserve=yes

//## end module%47681E0B0186.additionalDeclarations

//## begin module%47681E0B0186.epilog preserve=yes

//## end module%47681E0B0186.epilog

#endif

WorkBD.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%47681E8C00BB.cm preserve=no

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

//## end module%47681E8C00BB.cm

//## begin module%47681E8C00BB.cp preserve=no

//## end module%47681E8C00BB.cp

//## Module: workBD%47681E8C00BB; Package specification

//## Subsystem: BD%47681DDC030D

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

#ifndef workBD_cpp

#define workBD_cpp 1

//## begin module%47681E8C00BB.additionalIncludes preserve=no

//## end module%47681E8C00BB.additionalIncludes

//## begin module%47681E8C00BB.includes preserve=yes

//## end module%47681E8C00BB.includes

// Printes

#include «PrintPrintes.cpp»

//## begin module%47681E8C00BB.declarations preserve=no

//## end module%47681E8C00BB.declarations

//## begin module%47681E8C00BB.additionalDeclarations preserve=yes

//## end module%47681E8C00BB.additionalDeclarations

//## begin module%47681E8C00BB.epilog preserve=yes

//## end module%47681E8C00BB.epilog

#endif

ZakazExe.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%47681E0B0186.cm preserve=no

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

//## end module%47681E0B0186.cm

//## begin module%47681E0B0186.cp preserve=no

//## end module%47681E0B0186.cp

//## Module: ZakazExe%47681E0B0186; Task specification

//## Subsystem: Date%47681DC100EA

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

#ifndef ZakazExe_cpp

#define ZakazExe_cpp 1

//## begin module%47681E0B0186.additionalIncludes preserve=no

//## end module%47681E0B0186.additionalIncludes

//## begin module%47681E0B0186.includes preserve=yes

//## end module%47681E0B0186.includes

// ClientExe

#include «DateClientExe.cpp»

// YslugaExe

#include «DateYslugaExe.cpp»

// workBD

#include «BDworkBD.cpp»

//## begin module%47681E0B0186.declarations preserve=no

//## end module%47681E0B0186.declarations

//## begin module%47681E0B0186.additionalDeclarations preserve=yes

//## end module%47681E0B0186.additionalDeclarations

//## begin module%47681E0B0186.epilog preserve=yes

//## end module%47681E0B0186.epilog

#endif