4) Требования к составу и параметрам технических средств.
4.1) Intel Pentium II – 433 MHz, или аналог.
4.2) 32 Mb ОЗУ (64 рекомендуется)
4.3) ОС Windows 9x, 200x, XP.
4.4) клавиатура, манипулятор типа «мышь»
4.5) устройство типа «стандартный монитор» с разрешением 1024x768 пикс.
5) Требования к информационной и программной совместимости.
Программный комплекс должен иметь понятный графический интерфейс (MFC ver. 4.0), включать меню и удобные для данной области исследований поля для ввода (Edit Box, List Box, и т.п.). Программа должна сохранять данные в текстовой файл. Обязательными требованиями при разработке кода ПК являются использование следующих конструкций языка С++:
закрытые и открытые члены классов;
наследование;
конструкторы с параметрами и копирования;
деструкторы;
абстрактные базовые классы;
виртуальные функции;
обработка исключительных ситуаций;
динамическое создание объектов;
Рекомендуется также включить в программу дружественные функции, переопределение функций или операторов, шаблонные классы.
1.5. Требования к программной документации.
Программная документация должна содержать пояснительную записку и исходный код программы.
Желательно составить руководство для данного приложения, т.к. в противном случае будет затруднительно эффективно использовать его для решения задач, не имея базового опыта работы в данной области.
1.6. Стадии и этапы разработки:
Разработка технического задания, описание вариантов использования ПК, срок до 30.04.2006
Создание прототипа интерфейса пользователя, срок до 20.04.2006.
Разработка объектной модели, срок до 27.04.2006.
Построение диаграммы программных классов, срок до 27.04.2006.
Описание поведения ПК, срок до 23.04.2006.
Построение диаграмм действий, срок до 23.04.2006.
Исполнитель: Кондратьев В.О., ст.гр.3371
1.7. Порядок контроля и приема.
Курсовой проект должен включать оттестированный ПК и пояснительную записку. Пояснительная записка проекта должна иметь следующую структуру:
техническое задание;
описание процесса проектирования ПК;
руководство оператора;
исходные тексты ПК.
В процессе приема работы исполнитель обязан продемонстрировать работу ПК в тех рамках, которые оговорены в «требованиях к содержанию пояснительной записки» и в «задании на курсовое проектирование». Обязательным условием сдачи проекта является наличие технического задания к приложению, построение диаграмм на основе UML нотации для данной программы или ее самых значимых составных частей и исходные коды (желательно на языке MS VC++ 6.0).
2. Описание процесса проектирования пк.
2.1. Диаграмма классов.
Диаграмма классов (ClassTicket diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.
Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду структурную статическую модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представлением таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка 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 используются диаграммы последовательности. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно - слева направо в виде горизонтальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Второе измерение диаграммы последовательности - вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа "раньше-позже".
Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней [http://khpi-iip.mipk.kharkiv.edu/library/case/leon/index.html]. Диаграмма, представленная ниже, раскрыта для метода DlgEmpl::OnAddE().
Диаграмма 3. Диаграмма последовательностей, раскрыта для метода добавления служащего.
DlgEmpl– объект класса диалогового окнаCDialog.
CEmpl– объект класса «служащие».