Назначение курсовой работы
Курсовая работа является важной составляющей курса и самостоятельной инженерно-расчётной работой студента. Курсовая работа завершает подготовку по дисциплине «Основы объектно-ориентированного программирования».
Темой курсового проекта является «Создание программного комплекса средствами объектно-ориентированного программирования». Работа выполняется путём:
инфологического моделирования предметной области;
построения логической модели проектируемой информационной системы;
проектирования физической структуры приложения;
создания проекта средствами Visual C++.
В ходе выполнения курсовой работы предполагается проведение студентом всех этапов работ по проектированию информационной системы, решающей задачу автоматизации работы предприятия связи (по вариантам). Качественное проектирование позволяет избежать многих проблем будущей реальной системы. Результатом работы студента является обоснованный проект информационной системы, гарантирующий решение поставленных заказчиком задач за указанную сумму и в указанные сроки.
Примерное содержание пояснительной записки
Пояснительная записка оформляется на листах формата А4.
Первая страница – титульный лист, оформленный по общим правилам. Описание работы должно включать:
техническое задание постановку задачи;
объектно-ориентированную модель задачи;
структуру модели на языке UML
контракты классов;
проектирование конструкторов и деструкторов классов
разработку методики тестирования классов и тестовых наборов данных;
выводы по работе;
сценарий диалога с пользователем;
количественные характеристики программы;
текст программы.
Пример выполнения курсовой работы
Для выполнения курсовой работы необходим пакет Visual Studio, содержащий среду Visual C++. Цель курсовой работы состоит в том, чтобы разработать оттестированный программный комплекс, простой и понятный конечному пользователю.
1) Задание. Пусть необходимо разработать на объектно-ориентированном языке программный комплекс(ПК) для администратора гостиницы. ПК должен хранить информацию о проживающих клиентах, номерах и служащих гостиницы. Администратор гостиницы может добавлять, удалять и изменять эту информацию. Ему могут потребоваться следующие сведения:
- список работников гостиницы;
- список свободных номеров с указанием его вместимости;
- прейскурант цен;
- справка о жильцах гостиницы (ФИО, срок проживания, номер);
- отчет о работе гостиницы за месяц;
2) Описание процесса проектирования пк.
Диаграмма классов.
Диаграмма классов (ClassTicket diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.
Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду структурную статическую модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представлением таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов. В общем случае пакет структурной статической модели может быть представлен в виде одной или нескольких диаграмм классов. Декомпозиция некоторого представления на отдельные диаграммы выполняется с целью удобства и графической визуализации структурных взаимосвязей предметной области. При этом компоненты диаграммы соответствуют элементам статической семантической модели. Модель системы, в свою очередь, должна быть согласована с внутренней структурой классов, которая описывается на языке UML [http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html]. На диаграмме 1, представленной ниже, указана диаграмма классов ПК.
Диаграмма 1 - Диаграмма классов объектной модели ПК
Диаграмма действий.
При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций. Традиционно для этой цели использовались блок-схемы или структурные схемы алгоритмов. Каждая такая схема акцентирует внимание на последовательности выполнения определенных действий или элементарных операций, которые в совокупности приводят к получению желаемого результата. Алгоритмические и логические операции, требующие выполнения в определенной последовательности, окружают нас постоянно. Важно подчеркнуть то обстоятельство, что с увеличением сложности системы строгое соблюдение последовательности выполняемых операций приобретает все большее значение. Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения состояний и переходов. Отличие заключается в семантике состояний, которые используются для представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами - переходы от одного состояния действия к другому. Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Именно они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Метамодель UML предоставляет для этого необходимые термины и семантику. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. При этом каждое состояние может являться выполнением операции некоторого класса либо ее части, позволяя использовать диаграммы деятельности для описания реакций на внутренние события системы. В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения [http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html]. Диаграммах 2, 3 раскрыты действия для методов DlgRooms::OnAddR() и DlgClients::OnAddC().
Диаграмма 2 - Диаграмма действий, раскрытая для метода
добавления комнаты
Диаграмма 3 - Диаграмма действий, раскрытая для метода
поселения проживающего
Диаграмма последовательностей.
В языке UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя. Любые виды информационного взаимодействия между элементами системы должны быть сведены к отправке и приему сообщений между ними. Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду два аспекта взаимодействия. Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Однако временной аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в языке UML используются диаграммы последовательности. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно - слева направо в виде горизонтальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Второе измерение диаграммы последовательности - вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа "раньше-позже".
Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней [http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html]. Диаграмма 4 представляет действия для метода DlgEmpl::OnAddE().
Диаграмма 4 - Диаграмма последовательностей, раскрыта
для метода добавления служащего
DlgEmpl – объект класса диалогового окна CDialog.
CEmpl – объект класса «служащие».
Use Case – диаграмма.
Визуальное моделирование в UML можно представить, как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Разработка диаграммы вариантов использования преследует цели:
- Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
- Сформулировать общие требования к функциональному поведению проектируемой системы.
- Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
- Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика". Действительно, подробная детализация данной диаграммы на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. А согласно рекомендациям именно эти аспекты должны быть скрыты от разработчика на диаграмме вариантов использования. В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно, некоторых интерфейсов, и отношений между этими элементами. При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе [http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html]. На диаграмме 5 изображены функциональные характеристики ПК.
Диаграмма 5 - Use Case –диаграмма, представляющая
функциональные характеристики ПК
Описание интерфейса.
Внешний вид главного диалогового окна, выглядит таким образом (рис.1):
Рисунок 1 - Главное диалоговое окно
Таблица 1 Конструкция главного диалогового окна.
Наименование элемента формы |
Тип элемента формы |
Действие пользователя |
Отклик системы |
“Проживающие” |
кнопка |
одинарный щелчок левой кнопкой мыши |
открытие диалогового окна «Проживающие» |
“Номера” |
кнопка |
одинарный щелчок левой кнопкой мыши |
открытие диалогового окна «Номера» |
“Служащие” |
кнопка |
одинарный щелчок левой кнопкой мыши |
открытие диалогового окна «Служащие» |
“Отчет” |
кнопка |
одинарный щелчок левой кнопкой мыши |
открытие диалогового окна «Отчет» |
“Выход” |
кнопка |
одинарный щелчок левой кнопкой мыши |
завершение работы с программой |
Нажатие на кнопку «Проживающие» приводит к появлению следующего диалогового окна.
Добавление
проживающего
Удаление
выбранного
проживающего
Закрытие
диалогового окна
Список
проживающих
Рисунок 2 - Диалоговое окно для просмотра сведений о проживающих
Таблица 2 Конструкция диалогового окна для просмотра сведений о проживающих
Наименование элемента формы |
Тип элемента формы |
Действие пользователя |
Отклик системы |
«Фио», «Паспорт», «Номер», «Заселение», «Выселение» |
статическая надпись |
--------------------- |
--------------------- |
“Добавить” |
кнопка |
одинарный щелчок левой кнопкой мыши |
Открытие диалогового окна ввода проживающего |
“Удалить” |
кнопка |
одинарный щелчок левой кнопкой мыши |
удаление выбранного проживающего из списка |
“Выход” |
кнопка |
одинарный щелчок левой кнопкой мыши |
Закрытие диалогового окна и сохранение данных в файл |
Список |
Список |
двойной щелчок правой кнопкой мыши |
открытие окна добавления проживающего в котором можно изменить сведения выбранного проживающего |
Нажатие на кнопку «Добавить» приводит к появлению следующего диалогового окна.
Рисунок 3 - Диалоговое окно для добавления/изменения проживающего.
Таблица 3. Конструкция диалогового окна добавления проживающего
Наименование элемента формы |
Тип элемента формы |
Действие пользователя |
Отклик системы |
«Фио», «Паспорт», «Занимаемый Номер», «Заселение», «Выселение», «Номер», «Тип», «Занято», «Цена» |
статическая надпись |
--------------------- |
--------------------- |
“EditBox1” |
окно для ввода текста |
одинарный щелчок левой кнопкой мыши |
появление I-курсора на месте клика в EditBox1 |
“EditBox2” |
окно для ввода текста |
одинарный щелчок левой кнопкой мыши |
появление I-курсора на месте клика в EditBox2 |
“DataTime Picker1”
|
окно для ввода даты |
одинарный щелчок левой кнопкой мыши |
появление I-курсора на месте клика в DataTime Picker1 |
“DataTime Picker2”
|
окно для ввода даты |
одинарный щелчок левой кнопкой мыши |
появление I-курсора на месте клика в DataTime Picker2 |
List Box |
Список |
------------------ |
---------------------- |
“Ok” |
кнопка |
одинарный щелчок левой кнопкой мыши |
Сохранение проживающего и закрытие окна |
“Cancel” |
кнопка |
одинарный щелчок левой кнопкой мыши |
Отмена ввода и закрытие окна |