Материалы для студентов→ Курсовая работа /

Создание программного комплекса средствами объектно-ориентированного программирования

Скачать файл
Добавил: fafnir
Размер: 318.5 KB
Добавлен: 29.04.2015
Просмотров: 1464
Закачек: 1
Формат: doc

Министерство образования РФ

Санкт-Петербургский государственный

электротехнический университет «ЛЭТИ»

каф. ВТ

Объектно-ориентированное программирование

Пояснительная записка

к курсовому проекту

«Создание программного комплекса средствами объектно-ориентированного программирования»

Работу выполнил

ст.гр.3371

Кондратьев В.

Работу проверил:

Павловский М.

Санкт Петербург 2006

Содержание:

1. Техническое задание

Введение ……………………………………………………………………………………….…………..3

Основания для разработки ………………………………………………………….………..…3

Назначение разработки……………….……………….……………………………….…….……3

Требования к программе…………………………………………..……………………...………3

Требования к программной документации…………………………………….……..…4

Стадии и этапы разработки ………………………………………………………….………..…4

Порядок контроля и приема..………………………………………………………………….…5

Описание процесса проектирования  ПК

Диаграмма классов. …….………………………..……………………………………….………..5

2.2.    Диаграммадействий…………..……….…………………..…………………………………..…..7

2.3.    Диаграмма последовательностей..…………………………………….……………….….…9

2.4.UseCase – диаграмма………………………………………………………………………..…….11

2.5.    Описание интерфейса. …………………………………………………………………………….13

2.6.    Руководство пользователя……………………………………………………………………….22

3.  Исходные тексты ПК. ………………………………………………………………………………….…..……27

1. Техническое задание.

1.1. Введение.

Целью данной курсовой работы является проектирование и разработка на объектно-ориентированном языке ПК для администратора гостиницы. В ПК должна храниться информация о проживающих клиентах, номерах и служащих гостиницы. Администратор гостиницы может добавлять, удалять и изменять эту информацию. Ему могут потребоваться следующие сведения:

- список работников гостиницы;

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

- прейскурант цен;

- справка о жильцах гостиницы (ФИО, срок проживания, номер);

- отчет о работе гостиницы за месяц;

1.2. Основания для разработки.

Курсовой проект по дисциплине «Объектно-ориентированное программирование».

1.3. Назначение разработки

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

1.4. Требования к программе.

1) требования к функциональным характеристикам.

ПК должен поддерживать возможность

а) добавление информации о номерах, служащих и проживающих,

б) удаление информации о номерах, служащих и проживающих

в) изменение информации о номерах, служащих и проживающих

г) запись данных в файл

д) чтение данных из файла и просмотр сведений о номерах, служащих и проживающих

2) требования к надежности.

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

3) условия эксплуатации.

ПК  может эффективно функционировать на любом персональном компьютере с процессором семействаIntel, или совместимым с ним по набору инструкций процессором. Также в обязательные требования входит операционная системаWindows 9x,XP, 200x, с набором динамически подключаемых библиотекMfc40.dll, илиMfc32r.dll,  32 Мб ОЗУ (желательно 64 Мб) и 1 Мб свободного места (программа + текстовые файлы для хранения данных сумме занимают 180 Кб в файловой системеNTFS). Для работы с ПК требуется один человек, администратор гостиницы.

4) требования к составу и параметрам технических средств.

4.1)IntelPentiumII – 433MHz, или аналог.

4.2) 32Mb ОЗУ (64 рекомендуется)

4.3)ОС Windows 9x, 200x, XP.

4.4) клавиатура, манипулятор типа «мышь»

4.5) устройство типа «стандартный монитор» с разрешением 1024x768 пикс.

5) требования к информационной и программной совместимости.

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

  • закрытые и открытые члены классов;
  • наследование;
  • конструкторы с параметрами и копирования;
  • деструкторы;
  • абстрактные базовые классы;
  • виртуальные функции;
  • обработка исключительных ситуаций;
  • динамическое создание объектов;

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

1.5. Требования к программной документации.

Программная документация должна содержать пояснительную записку и исходный код программы.

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

1.6. Стадии и этапы разработки:

  1. Разработка технического задания, описание вариантов использования ПК, срок до 30.04.2006
  2. Создание прототипа интерфейса пользователя, срок до 20.04.2006.
  3. Разработка объектной модели, срок до 27.04.2006.
  4. Построение диаграммы программных классов, срок до 27.04.2006.
  5. Описание поведения ПК, срок до 23.04.2006.
  6. Построение диаграмм действий, срок до 23.04.2006.

Исполнитель: Кондратьев В.О., ст.гр.3371

1.7.Порядок контроля и приема.

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

  • техническое задание;
  • описание процесса проектирования  ПК;
  • руководство оператора;
  • исходные тексты ПК.

В процессе приема работы исполнитель обязан продемонстрировать работу ПК в тех рамках, которые оговорены в «требованиях к содержанию пояснительной записки» и в «задании на курсовое проектирование». Обязательным условием сдачи проекта является наличие технического задания к приложению, построение диаграмм на основеUML нотации для данной программы или ее самых значимых составных частей и исходные коды (желательно на языкеMSVC++ 6.0).

2. Описание процесса проектирования  ПК.

2.1. Диаграмма классов.

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

Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду структурную статическую модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представлением таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языкаUML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов. В общем случае пакет структурной статической модели может быть представлен в виде одной или нескольких диаграмм классов. Декомпозиция некоторого представления на отдельные диаграммы выполняется с целью удобства и графической визуализации структурных взаимосвязей предметной области. При этом компоненты диаграммы соответствуют элементам статической семантической модели. Модель системы, в свою очередь, должна быть согласована с внутренней структурой классов, которая описывается на языкеUML[http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html].На диаграмме, представленной ниже, указана диаграмма классов ПК.

Диаграмма 1. Диаграмма классов объектной модели ПК.

Диаграмма действий.

При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций. Традиционно для этой цели использовались блок-схемы или структурные схемы алгоритмов. Каждая такая схема акцентирует внимание на последовательности выполнения определенных действий или элементарных операций, которые в совокупности приводят к получению желаемого результата. Алгоритмические и логические операции, требующие выполнения в определенной последовательности, окружают нас постоянно. Важно подчеркнуть то обстоятельство, что с увеличением сложности системы строгое соблюдение последовательности выполняемых операций приобретает все большее значение. Для моделирования процесса выполнения операций в языкеUML используются так называемые диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения состояний и переходов. Отличие заключается в семантике состояний, которые используются для представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами - переходы от одного состояния действия к другому. Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Именно они позволяют реализовать в языкеUML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. МетамодельUML предоставляет для этого необходимые термины и семантику. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. При этом каждое состояние может являться выполнением операции некоторого класса либо ее части, позволяя использовать диаграммы деятельности для описания реакций на внутренние события системы. В контексте языкаUML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения[http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html].Диаграммы, представленные ниже, раскрыты для методовDlgRooms::OnAddR() иDlgClients::OnAddC().

Диаграмма 2. Диаграмма действий, раскрытая для метода добавления комнаты.

Диаграмма 3. Диаграмма действий, раскрытая для метода поселения проживающего.

2.3. Диаграмма последовательностей.

В языкеUML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя. Любые виды информационного взаимодействия между элементами системы должны быть сведены к отправке и приему сообщений между ними. Для моделирования взаимодействия объектов в языкеUML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду два аспекта взаимодействия. Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Однако временной аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в языкеUML используются диаграммы последовательности. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно - слева направо в виде горизонтальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Второе измерение диаграммы последовательности - вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа "раньше-позже".

Линия жизни объекта (objectlifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней[http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html].Диаграмма, представленная ниже, раскрыта для метода DlgEmpl::OnAddE().

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

DlgEmpl – объект класса диалогового окнаCDialog.

CEmpl – объект класса «служащие».

2.4.UseCase – диаграмма.

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

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

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

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (usecase) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика".  Действительно, подробная детализация данной диаграммы на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. А согласно рекомендациям именно эти аспекты должны быть скрыты от разработчика на диаграмме вариантов использования. В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно, некоторых интерфейсов, и отношений между этими элементами. При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе[http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html].На диаграмме, представленной ниже, изображены функциональные характеристики ПК.

Диаграмма 4UseCase –диаграмма, представляющая функциональные характеристики ПК

2.5.Описание интерфейса.

Внешний вид главного диалогового окна,  выглядит таким образом:

рис.2.5.1. Главное диалоговое окно.

табл.2.5.1. Конструкция главного диалогового окна.

Нажатие на кнопку «Проживающие» приводит к появлению следующего диалогового окна.

рис 2.5.2 Диалоговое окно для просмотра сведений о проживающих.

табл.2.5.2. Конструкция диалогового окна для просмотра сведений о проживающих

Нажатие на кнопку «Добавить» приводит к появлению следующего диалогового окна.

рис 2.5.3 Диалогового окна для добавления/изменения проживающего.

табл.2.5.3. Конструкция диалогового окна добавления проживающего

Нажатие на кнопку «Номера» главного диалогового окна приводит к появлению следующего диалогового окна.

рис 2.5.4  Диалоговое окно для просмотра номеров.

табл.2.5.4. Конструкция диалогового окна просмотра номеров.

Нажатие на кнопку «Добавить» приводит к появлению следующего диалогового окна.

рис 2.5.5  Диалоговое окно для добавления/изменения номера.

табл.2.5.5. Конструкция диалогового окна добавления/изменения номера.

Нажатие на кнопку «Служащие» главного диалогового окна приводит к появлению следующего диалогового окна.

рис 2.5.6  Диалоговое окно для просмотра сведений о служащих.

табл.2.5.6. Конструкция диалогового окна просмотра сведений о служащих.

Нажатие на кнопку «Добавить» приводит к появлению следующего диалогового окна.

рис 2.5.6  Диалоговое окно для добавления/изменения служащего.

табл.2.5.6. Конструкция диалогового окна добавления/изменения служащего.

Нажатие на кнопку «Отчет» главного диалогового окна приводит к появлению следующего диалогового окна.

рис 2.5.7  Диалоговое окно для отчета.

табл.2.5.7. Конструкция диалогового окна просмотра отчета.

2.6. Руководство пользователя.

1. Запустите файлhotel.exe.На экране появится окно «Гостиница» (рис. 2.6.1)

рис.2.6.1. Главное диалоговое окно программы.

2. Для просмотра/редактирования сведений о проживающих нажмите кнопку «Проживающие». Появится диалоговое окно «Проживающие»(рис. 2.6.2)

рис.2.6.2. Диалоговое окно для работы с проживающими.

2.1 Для поселения проживающего нажмите кнопку «Добавить». Появится диалоговое окно «Добавление проживающего» (рис 2.6.3)

рис.2.6.3. Диалоговое окно для поселения проживающего.

2.1.2 Введите данные и нажмите кнопку «Поселить». Если не хотите поселять нового проживающего, нажмите «Отмена».

2.2. Для выселения проживающего выделите его из списка и нажмите кнопку «Удалить»

рис.2.6.4. Выселение проживающего.

2.3. Для перехода в главное окно нажмите кнопку «Выход». Данные автоматически сохранятся в файл.

3. Для просмотра/редактирования сведений о номерах нажмите кнопку «Номера» главного диалогового окна. Появится диалоговое окно «Номера» (рис. 2.6.5)

рис.2.6.5 Номера

3.1 Для отображения только свободных номеров поставьте флажок «Свободные номера».

3.2. Для добавления номера нажмите кнопку «Добавить». Появится диалоговое окно «Добавление комнаты» (рис 2.6.6)

рис.2.6.6 Добавление номера

Введите данные и нажмите кнопку «Добавить». Для отмены действия нажмите кнопку «Отмена».

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

3.4. Для сохранения данных и перехода в главное окно нажмите кнопку «Сохранить».  Если не хотите сохранять изменения, нажмите кнопку «Отмена».

4. Для просмотра/редактирования сведений о служащих нажмите кнопку «Служащие» главного диалогового окна. Появится диалоговое окно «Служащие» (рис. 2.6.7)

рис.2.6.7Служащие.

4.1. Для того чтобы добавить служащего нажмите кнопку «Добавить». Появится окно «Добавление служащего» (рис 2.6.8)

рис.2.6.8 Добавление служащего.

4.2. Введите данные и нажмите кнопку «Добавить». Для отмены операции добавления нажмите «Отмена».

4.3. Для удаление служащего выберите его из списка и нажмите кнопку «Удалить».

4.4. Для сохранения данных и перехода в главное окно нажмите кнопку «Сохранить».  Если не хотите сохранять изменения, нажмите кнопку «Отмена».

5. Для просмотра отчета о работе гостиницы нажмите кнопку «Отчет» главного диалогового окна. Появится окно «Отчет» (рис 2.6.9)

рис.2.6.9 Просмотр отчета.

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

5.2. для перехода в главное диалоговое окно нажмите кнопку «Выйти».

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

3.Исходные тексты ПК.

//Person.h

#include "ListEmpl.h"

#include <iostream.h>

classCPerson {

public:

CStringfio;

CString passport;

CPerson(){};

virtual ~CPerson(){};

virtualvoid SetFio(CString fio0)=0;

virtual void SetPassport(CString passport0)=0;

};

class CEmpl: public CPerson{

CString post;

public:

CEmpl(){};

void SetFio(CString fio0);

void SetPassport(CString passport0);

void SetPost(CString post0);

CString GetFio(){

return fio;

}

CString GetPassport(){

return passport;

}

CString GetPost(){

return post;

}

};

class CClient: public CPerson{

CTime dataZ;

CTime dataV;

CString room;

public:

void SetFio(CString fio0);

void SetPassport(CString passport0);

void SetDataZ(CTime data0){

dataZ=data0;

}

void SetDataV(CTime period0){

dataV=period0;

}

void SetRoom(CString room0){

room=room0;

}

CString GetRoom(){

return room;

}

CString GetFio(){

return fio;

}

CString GetPassport(){

return passport;

}

CTime GetDataZ(){

return dataZ;

}

CTime GetDataV(){

return dataV;

}

};

class CRoom{

CString number;

CString capasity;

CString occupy;

CString price;

public:

void SetPrice(CString price0){

price=price0;

}

void SetNumber(CString number0){

number=number0;

}

void SetCapasity(CString capasity0){

capasity=capasity0;

}

void SetOccupy(CString occupy0){

occupy = occupy0;

}

CRoom(CString oc="0    "){occupy=oc;}

CString GetOccupy(){

return occupy;

}

bool SetOccupyDown(){

int oc = atoi(occupy);

char ch[2];

UINT len;

if (oc>0){

oc-=1;

occupy=itoa(oc,ch,10);

len = occupy.GetLength();

if (len>5) {occupy=occupy.Left(5);}

else

while (len<5){

occupy+=' ';

len = occupy.GetLength();

}

return true;

}

else

return false;

}

bool SetOccupyUp(){

int oc = atoi(occupy);

int cap = atoi(capasity);

char ch[6];

UINT len;

if (oc<cap){

oc+=1;

occupy=itoa(oc,ch,10);

len = occupy.GetLength();

if (len>5) {occupy=occupy.Left(5);}

else

while (len<5){

occupy+=' ';

len = occupy.GetLength();

}

return true;

}

else

return false;

}

CString GetNumber(){

return number;

}

CString GetCapasity(){

return capasity;

}

CString GetPrice(){

return price;

}

};

// DlgClients.cpp : implementation file

//

#include "stdafx.h"

#include "kurs.h"

#include "DlgClients.h"

#include "DlgAddClient.h"

#include "DlgRooms.h"

#ifdef _DEBUG

#define new DEBUG_NEW

#undef THIS_FILE

static char THIS_FILE[] = __FILE__;

#endif

DlgClients::DlgClients(CWnd* pParent /*=NULL*/)

: CDialog(DlgClients::IDD, pParent)

{

//{{AFX_DATA_INIT(DlgClients)

m_listC = _T("");

//}}AFX_DATA_INIT

}

void DlgClients::DoDataExchange(CDataExchange* pDX)

{

CDialog::DoDataExchange(pDX);

//{{AFX_DATA_MAP(DlgClients)

DDX_LBString(pDX, IDC_LISTC, m_listC);

//}}AFX_DATA_MAP

CListBox* pLB=(CListBox*) GetDlgItem(IDC_LISTC);

pLB->ResetContent();

CString str("");

CString str1("");

CElem<CClient> *buf = LC.beg;

CTime ct1;

CTime ct2;

fstream File("Rooms.txt",ios::in);

CRoom R;

char ch[25];

while (!File.eof()){

File.getline(ch,25,'\n');

str=ch;

if (str!=""){

str1=str.Left(5);

R.SetNumber(str1);

str1=str.Mid(5,5);

R.SetCapasity(str1);

str1=str.Mid(10,5);

R.SetOccupy(str1);

str1=str.Right(5);

R.SetPrice(str1);

LR.AddEl(R);

}

}

File.close();

while (buf !=0){

ct1 = buf->inf.GetDataZ();

ct2 = buf->inf.GetDataV();

str1.Format(_T("%02d/%02d/%2d  %02d/%02d/%2d"),ct1.GetDay(),ct1.GetMonth(),ct1.GetYear(),

ct2.GetDay(),ct2.GetMonth(),ct2.GetYear());

str = buf->inf.GetFio()+buf->inf.GetPassport()+buf->inf.GetRoom()+str1 ;

pLB->AddString(str);

buf = buf->next;

}

}

BEGIN_MESSAGE_MAP(DlgClients, CDialog)

//{{AFX_MSG_MAP(DlgClients)

ON_BN_CLICKED(IDC_AddCl, OnAddCl)

ON_BN_CLICKED(IDC_DelCl, OnDelCl)

//}}AFX_MSG_MAP

END_MESSAGE_MAP()

// DlgClients message handlers

void DlgClients::OnAddCl()

{

DlgAddClient dlgAC;

CListBox* pLB=(CListBox*) GetDlgItem(IDC_LISTC);

int result = dlgAC.DoModal();

CString str("");

CElem<CRoom> *buf = LR.beg;

if(result==IDOK){

CClient C;

C.SetPassport(dlgAC.m_PassportClient);

C.SetRoom(dlgAC.m_number);

C.SetDataZ(dlgAC.m_Data1);

C.SetDataV(dlgAC.m_Data2);

C.SetFio(dlgAC.m_fio);

LC.AddEl(C);

CString str1("");

int i;

fstream FileInfo("Information.txt",ios::app);

CTime ct1;

CTime ct2;

ct1 = C.GetDataZ();

ct2 = C.GetDataV();

str1.Format(_T("%02d/%02d/%2d  %02d/%02d/%2d"),ct1.GetDay(),ct1.GetMonth(),ct1.GetYear(),

ct2.GetDay(),ct2.GetMonth(),ct2.GetYear());

str = C.GetRoom()+str1+' '+C.GetFio()+C.GetPassport()+"\n";

i = str.GetLength();

FileInfo.write(str,i);

FileInfo.close();

fstream File("Rooms.txt",ios::out);

File.clear();

buf = LR.beg;

while (buf->inf.GetNumber() !=dlgAC.m_number)

buf = buf->next;

buf->inf.SetOccupyUp();

buf = LR.beg;

while(buf != 0){

str = buf->inf.GetNumber()+buf->inf.GetCapasity()+buf->inf.GetOccupy()+buf->inf.GetPrice()+"\n";

i = str.GetLength();

File.write(str,i);

buf = buf->next;

}

File.close();

LR.DelAllElem();

UpdateData(false);

}

LR.DelAllElem();

UpdateData(false);

}

void DlgClients::OnOK()

{

fstream File("Clients.txt",ios::out);

File.clear();

CString str("");

CElem<CClient> *buf = LC.beg;

int i;

CString str1("");

CTime ct1;

CTime ct2;

while(buf != 0){

ct1 = buf->inf.GetDataZ();

ct2 = buf->inf.GetDataV();

str1.Format(_T("%02d/%02d/%2d  %02d/%02d/%2d"),ct1.GetDay(),ct1.GetMonth(),ct1.GetYear(),

ct2.GetDay(),ct2.GetMonth(),ct2.GetYear());

str = buf->inf.GetFio()+buf->inf.GetPassport()+buf->inf.GetRoom()+str1+"\n";

i = str.GetLength();

File.write(str,i);

buf = buf->next;

}

File.close();

LC.DelAllElem();

LR.DelAllElem();

CDialog::OnOK();

}

void DlgClients::OnDelCl()

{

CListBox* pLB=(CListBox*) GetDlgItem(IDC_LISTC);

CString str;

CString str1;

CString str2;

if (pLB->GetCurSel() !=-1){

pLB->GetText(pLB->GetCurSel(), str);

str1=str.Mid(15,11);

str2=str.Mid(26,5);

CElem<CClient> *buf = LC.beg;

CTime ct(atoi(str.Mid(37,4)),atoi(str.Mid(34,2)),atoi(str.Mid(31,2)),0,0,0);

CTime ct2(atoi(str.Mid(49,4)),atoi(str.Mid(46,2)),atoi(str.Mid(43,2)),0,0,0);

while(buf != 0){

if ( (buf->inf.GetPassport()==str1) && (buf->inf.GetRoom()==str2)

&& (buf->inf.GetDataZ().GetYear()==ct.GetYear())

&& (buf->inf.GetDataZ().GetDay()==ct.GetDay())

&& (buf->inf.GetDataZ().GetMonth()==ct.GetMonth())

&& (buf->inf.GetDataV().GetYear()==ct2.GetYear())

&& (buf->inf.GetDataV().GetDay()==ct2.GetDay())

&& (buf->inf.GetDataV().GetMonth()==ct2.GetMonth())){

break;

} else

buf = buf->next;

}

CElem<CRoom> *bufR = LR.beg;

while((bufR!= 0) && (bufR->inf.GetNumber()!=buf->inf.GetRoom()))

bufR = bufR->next;

bool b;

b=bufR->inf.SetOccupyDown();

if(!b)

AfxMessageBox("Выселение невозможно!");

if(b){

LC.DelEl(buf);

fstream File("Rooms.txt",ios::out);

File.clear();

CString str("");

int i;

bufR = LR.beg;

while(bufR != 0){

str = bufR->inf.GetNumber()+bufR->inf.GetCapasity()+bufR->inf.GetOccupy()+bufR->inf.GetPrice()+"\n";

i = str.GetLength();

File.write(str,i);

bufR = bufR->next;

}

File.close();

LR.DelAllElem();

UpdateData(false);

}

}

else

AfxMessageBox("Проживающий не выбран!");

}