Унифицированный язык моделирования (uml) является стандартным инструментом для создания чертежей программного обеспечения
 Скачать 188 Kb.
|
|
ВВЕДЕНИЕ Унифицированный язык моделирования (UML) является стандартным инструментом для создания «чертежей» программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем. UML пригоден для моделирования любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это очень выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. Изучение UML удобнее всего начать с его концептуальной модели, которая включает в себя три основных элемента: базовые строительные блоки, правила, определяющие, как эти блоки могут сочетаться между собой, и некоторые общие механизмы языка. Несмотря на свои достоинства, UML - это всего лишь язык; он является одной из составляющих процесса разработки программного обеспечения, и не более того. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении прецедентов использования, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру [1]. В данном курсовом проекте разработана объектно-ориентированная модель информационной подсистемы для учета успеваемости студентов факультета. Модель разработана с помощью программного продукта Rational Rose 2003, с помощью языка UML. В первом разделе курсового проекта представлена основная характеристика предметной области, а также актуальность разработки объектно-ориентированной модели информационной подсистемы учета успеваемости студентов. Во втором разделе рассматривается создание диаграммы прецедентов, ее основная характеристика. В этом разделе выделены актеры, включенные в работу информационной подсистемы, а также рассмотрены их основные действия. В третьем разделе пояснительной записки рассматривается создание диаграммы последовательности (sequence diagrams). Данная диаграмма предназначена для моделирования процесса обмена сообщениями между объектами; В разделе четыре рассматривается диаграмма сотрудничества для прецедента информационной подсистемы «Добавить новую запись о студенте». В пятом разделе описывается диаграмма классов для прецедента «Добавление новой записи». В шестом разделе приводится и описывается диаграмма классов прецедента «Работы с БД», а также рассматриваются основные добавленные атрибуты и операции. В седьмом разделе приводится и описывается диаграммы состояний для программы. В этом же разделе приводится описание диаграммы компонентов для прецедентов информационной подсистемы «Добавление новой записи о студенте». В восьмом разделе пояснительной записки приводится и описывается диаграмма размещения проектируемой информационной подсистемы. В девятом разделе пояснительной записки приводится и описывается порядок генерации программного кода на языке С++ для данной информационной подсистемы. В заключении подведены основные итоги курсового проектирования и сформулированы перспективные направления развития темы курсового проекта. В приложение вынесены листинги кода проектируемой программы, сгенерированные RationalRose. 1. КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ 1.1 Общая характеристика Разрабатываемая информационная подсистема предназначена для использования в рамках информационной подсистемы для деканата факультета высшего учебного заведения «Университет» (учет успеваемости студентов). 1.2 Актуальность разрабатываемой подсистемы В современных условиях рыночно экономики большое значение имеет качество образования. Это приводит к тому, что все больше и больше молодых людей, понимая это, поступают в государственные высшие учебные заведения крупных городов. Такие образовательные учреждения, как правило, имеют статистику каждого факультета, у которой отображается популярность той или иной специальности. Так как в «Университете» насчитывается около десятка факультетов то подсчет всех критериев очень труд и требует внедрение и использование ПК. 1.3 Формулировка задач проектирования программный моделирование унифицированный Современная социально-экономическая обстановка в стране приводит к тому, что нередко студентам приходится подрабатывать на различных предприятиях, что сказывается на учебе и не редко приводит к отчислению студентов из ВУЗа. Таким образом, необходима подсистема, позволяющая быстро обновлять информацию в базе данных. Для эффективного функционирования системы подсчета успеваемости студентов, информационная подсистема учета студентов должна выполнять ряд задач. Деканат, в роли которого может выступать секретарь деканата или другое уполномоченное лицо осуществляет оперативный учет студентов. В его обязанности входит: добавление исчерпывающей информации о студенте в базу данных при поступление его на факультет. В качестве такой информации могут выступать фамилия, имя, отчество студента, его паспортные данные, включая дату рождения и место постоянной прописки, факультет, курс и группу; ежедневное занесение информации: о посещение занятий, об оценках на лабораторных, об оценках на семинарах, об оценках на практиках и т.д.; периодическое занесение оперативной информации обо всех видах ведомостей (например, экзаменационная, итоговая, аттестационная, промежуточная и т.д.). Этот небольшой список задач позволяет решить основные вопросы, связанные с учетом успеваемости студентов. 2. СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ При обобщении поставленной задачи можно преобразовать требования в диаграмму использования, с помощью которой моделируется система. Диаграмма прецедентов (использования) называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения (зависимости, обобщения и ассоциации) между ними. Диаграмма этого вида представляет важную информацию – это одно из основных преимуществ ее применения. Взглянув на варианты использования, можно понять какие функциональные возможности будут заложены в систему. Рассматривая действующих лиц можно выяснить, кто конкретно будет с ней взаимодействовать. Изучая все множество вариантов использования и действующих лиц, определятся сфера применения системы (что она будет делать). Это помогает узнать также, что она не будет делать, и внести коррективы. На рисунке 2.1 приведена диаграмма использования, спроектированная в среде RationalRose. Основным действующим лицом (актером) является деканат. Он выполняет четыре основных действия: занесение учетной информации в базу данных. Периодичность данной операции: ежедневно; просмотр базы данных. Подразумевает поиск необходимой информации по необходимости; добавление информации о всех видах ведомостей; Редактирование данных . Для создания диаграммы последовательности: Запустим интегрированную среду разработки Rational Rose 2003. Перейдем к главной диаграмме (Main) Use case: в браузере щелкнем на значке «+» рядом с представлением Use case, чтобы открыть представление; дважды щелкнув на главной диаграмме, откроем её. С помощью кнопки Use Case (вариант использования) панели инструментов поместим на диаграмму новый вариант использования. Назовем его «Занести учетную информацию в БД». Повторив этапы 3 и 4, поместим на диаграмму остальные варианты использования: просмотр БД; добавить сведения по ведомостям; редактировать данные; установление нагрузки преподавателям. С помощью кнопки Actor (действующее лицо) панели инструментов поместим на диаграмму новое действующее лицо.  Рисунок 2.1 – Диаграмма прецедентов Назовем его «Деканат». С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) добавим ассоциации между действующим лицом «Деканатом» и всеми вариантами использования. Рассмотренные выше варианты использования инициируют последовательность действий (транзакций) в базе данных в ответ на действия со стороны Деканат. Выводы 1. Была разработана диаграмма прецедентов, состоящая из одного актера. Основным действующим лицом является Деканат. Он выполняет три действия: «формирование документов», «Ввод данных» и «Занести учетную информацию в БД». 2. Проанализировав приведенную выше диаграмму использования наглядно видно, что наиболее важной и наиболее сложно реализуемой задачей информационной подсистемы является ввод и модификация информации в БД, так как от правильности выполнения этого прецедента будет зависеть в дальнейшем успешность учета успеваемости студентов. 3. СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. Рассмотрим вариант использования «Добавить студента в БД». Диаграмма последовательности приведена на рисунке 3.1.  Рисунок 3.1 – Диаграмма последовательности На приведенной выше диаграмме выделены следующие объекты соответствующих классов: Форма авторизации – объект класса AuthForm, отвечающая за авторизацию пользователя; Рабочая форма – объект класса Vedomost – форма, в которой выполняются все операции с БД, в частности заполнение ведомостей; Последовательность действий основного потока выглядит следующим образом: Оператор ПК авторизуется в системе. При этом он открывает необходимую форму для выбора необходимой операции. Пользователь выдает запрос на информацию Получает результат запроса из БД Оператор переходит в режим редактирования Вводит все необходимые поля в открытую форму. Нажимает на клавишу «Сохранить». При этом информация отправляется в СУБД. СУБД создает новую пустую запись. Генерирует изменяет значения полей в соответствии с введенными оператором ПК данными. Выводы 1. Была разработана диаграмма последовательности для варианта использования «Работа с базой данных». Этот вариант использования является наиболее важной и наиболее сложно реализуемой задачей информационной подсистемы. 2. При создании диаграммы были созданы четыре классов: три управляющих и один «сущность». 4. СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА Диаграммы сотрудничества – второй тип диаграмм взаимодействия – Collaboration Diagram – Г. Буч называет диаграммой объектов. Эта диаграмма не акцентирует внимание на последовательности передачи сообщений, она отражает наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие сообщений от клиентов к серверам. Диаграмма показывает взаимодействие между объектами, а не классами, то есть является мгновенным снимком объектов системы в некотором состоянии. Ведь объекты, в отличие от созданных на этапе проектирования классов, создаются и уничтожаются на всем протяжении работы программы. И в каждый момент имеется конкретная группа объектов, с которыми осуществляется работа. В курсовом проекте была разработана диаграмма сотрудничества, описывающая работу с бд (рисунок 4.1). Действующее лицо – Деканат. Используемые объекты: форма авторизации ( класс – AuthForm); форма работы с БД (класс Vedomost); управляющий БД (класс bd); На диаграмму были добавлены следующие сообщения, соотнесенные с операциями: Input() – ввод данных для авторизации. SForm() – открыть форму для работы с данными . Choose() – выбор операции. InputD() – ввод данных о студенте. Request() – послать запрос в БД для получения информации.  Рисунок 4.1 – Диаграмма сотрудничества ReturnD() – результат обработки запроса в БД. EditD() – редактирование или создание новой записи в БД. ChangeD() – отправление запроса в БД для редактирования. ReturnD() – результат редактирования БД. Close() - Закрытие приложения. Выводы Была спроектирована диаграмма сотрудничества для варианта использования «Работа с БД». Во многом от правильности выполнения этого прецедента будет зависеть в дальнейшем успешность оперативного учета и функционирования всей системы в целом. В диаграмму были добавлены десять сообщений, соотнесенные с соответствующими операциями 5. СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ Class diagram (диаграммы классов) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. На диаграммах классов отображаются некоторые классы и пакеты системы. Это статические картины фрагментов системы и связей между ними. Ознакомившись с классами модели, для более наглядного представления, они были сгруппированы по стереотипу (рисунок 5.1). Стереотипы - это механизм, позволяющий разделять классы на категории. В языке UML основными стереотипами являются: Boundary (граница), Entity (сущность) и Control (управление).Таким образом были созданы следующие пакеты: Entities (Сущности), Boundaries (Границы) и Control (Управление). В эти пакеты были помещены советующие им классы.  Рисунок 5.1 – Диаграмма пакетов Граничные классы (boundary classes) - это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами. Классы-сущности (entity classes) отражают основные понятия (абстракции) предметной области и, как правило, содержат хранимую информацию. Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каждого варианта использования имеется один управляющий класс, контролирующий последовательность событий этого варианта использования. В данном проекте данную функцию выполняет класс bd, а также AuthForm и Vedomost. Выводы В процессе разработки диаграммы классов был применен механизм пакетов. Были созданы три основных пакета, объединяющих классы по стереотипам. Была разработана диаграмма пакетов, являющаяся одной из форм диаграммы классов. 6. ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ После того как была, разработана диаграмма классов для варианта использования «Работа с базой данных», начинается ее заполнение. В качестве языка программирования был выбран C++, что позволило добавить к классам параметры операций, типы данных и типы возвращаемых значений. Атрибут – это элемент информации, связанный с классом. Они содержатся внутри класса, поэтому они скрыты от других классов. В связи с этим иногда требуется указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility). Для определения атрибутов и операций классов было произведено обращение к потоку событий. В результате к классам были добавлены дополнительные атрибуты и связи между классами (рисунок 6.1).  Рисунок 6.1 – Диаграмма классов для сценария «работы с БД» Назначение и описание основных методов классов были рассмотрены выше, в третьем и четвертом разделах. Выводы Была разработана диаграмма классов для сценария «работы с БД». Как видно из диаграммы, между классами существует определенная семантическая связь. На диаграмме для каждой семантической связи также наглядно отображена множественность, показывающая, сколько экземпляров одного класса взаимодействует с помощью этой связи с одним экземпляром другого класса в определенный момент времени. 7. СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ ДЛЯ КЛАССОВ И ДИАГРАММЫ КОМПОНЕНТОВ Диаграммы состояний (State) предназначена для отображения состояний объектов системы, имеющих сложную модель поведения. Состоянием (state) называется одно из возможных условий, в которых может существовать объект. Находясь в конкретном состоянии, объект может выполнять определенные действия. Например, может генерировать отчет, осуществлять некоторые вычисления или посылать событие другому объекту. С состоянием можно связывать действия пяти типов: деятельность, входное действие, выходное действие, событие и история состояния. Многие требования к классу Vedomost значительно изменяются при изменении состояния его экземпляра. Например, записи, заполнение которых приостановлено, ведут себя не так, как полностью заполненные записи, а те в свою очередь не так, как отмененные записи. На рисунке 7.1 приведена диаграмма состояния для программы. Этапы создания диаграммы состояний: Найти в браузере класс Main. Щелкнуть на классе правой кнопкой мыши и в открывшемся меню указать пункт Open State Diagram (Открыть диаграмму состояний). Добавление начального и конечного состояний: Нажать кнопку Start State (Начальное состояние) панели инструментов. Поместить это состояние на диаграмму. Нажать кнопку End State (Конечное состояние) панели инструментов. Поместить это состояние на диаграмму. Добавление состояний: На панели инструментов нажать кнопку State (Состояние). Поместить состояние на диаграмму. Назвать состояние Ожидание авторизации. На панели инструментов нажать кнопку State (Состояние). Поместить состояние на диаграмму. Добавить состояние Ввод данных. Добавить состояние Редактирование данных. Добавить состояние Сохранение данных Добавить состояние просмотр данных Добавить состояние вывод таблицы Добавить состояние завершение программы  Рисунок 7.1 – Диаграмма состояния для программы Описание состояний: Дважды щелкнуть мышью на состоянии ожидание авторизации. Перейти на вкладку Detail (Подробно). Щелкнуть правой кнопкой мыши в окне Actions (Действия). В открывшемся меню выберать пункт Insert (Вставить). Дважды щелкнуть мышью на новом действии. Назвать его StoreDate. Убедиться, что в окне When (Когда) указан пункт On Entry (На входе). Повторив шаги 3 - 7, добавить следующие действия: Collect Student Info, в окне When указать Entry until Exit (Выполнять до завершения); Редактирование данных, указав Entry until Exit (Выполнять до завершения); Нажать два раза на ОК, чтобы закрыть спецификацию. Добавление переходов: Нажать кнопку Transition (Переход) панели инструментов. Щелкнуть мышью на начальном состоянии. Провести линию перехода к состоянию Авторизация. Повторив шаги с первого по третий, создать следующие переходы: от состояния авторизация к состоянию ввод данных; от ввод данных к состоянию редактирование данных; от состояния редактирование данных к сохранению данных; от состояния сохранению данных к вводу данных; от состояния ввод данных к состоянию просмотр данных; от состояния просмотр данных к состоянию вывод таблицы от состояния вывод таблицы к состоянию ввода данных; от состояния вводу данных к конечному состоянию. Описание переходов: Дважды щелкнув мышью на переходе от состояния авторизация к состоянию ввод данных, открыть окно спецификации перехода. В поле Event (Событие) ввести фразу Dobavit' Zapis. Щелкнув на кнопке ОК, закрыть окно спецификации. В поле Event (Событие) ввести фразу Dobavit' k zapisi novuu informaciu. Перейти на вкладку Detail (Подробно). В поле Condition (Условие) введите Ne ostalis nezapolnenie polya. Была также создана диаграмма компонентов, отображающая распределение классов и объектов по компонентам при физическом проектировании. Как видно на рисунке 7.2 система была разложена на два компонента: сервер и клиент. К клиентской части приложения относятся классы InputForm и OptionVariant и объекты этих классов. К серверной части приложения отнесены все остальные классы и объекты этих классов. Uspevaemost.cpp Uspevaemost.h  Рисунок 7.2 – Диаграмма компонентов Выводы Была создана диаграмма состояний. Согласно этой диаграмме объекты программы могут находиться в одном из четырех состояний: инициализации, редактирования, просмотра и завершения. 8. СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм. Иногда диаграммы топологии называют диаграммами размещения.  Рисунок 8.1 – Диаграмма размещения Добавление узлов к диаграмме размещения: Дважды щелкнув мышью на представлении размещения в браузере, открыть диаграмму размещения. Нажать кнопку Processor (Процессор) панели инструментов. Щелкнув мышью на диаграмме, поместить туда процессор. Ввести имя процессора «server_bd». Повторив шаги 2—4, добавить следующие процессоры: «clients», На панели инструментов нажать кнопку Device (Устройство). Щелкнув мышью на диаграмме, поместить туда устройство. Назвать его «printers». Добавление связей: Нажать кнопку Connection (Связь) панели инструментов. Щелкнуть мышью на процессоре «server_bd». Провести линию связи к процессору «clients». Щелкнуть правой кнопкой мыши на процессоре «server_Bd» в браузере. В открывшемся меню выберать пункт New → Process (Создать → Процесс). Ввести имя процесса − ProgramExe. Щелкнуть правой кнопкой мыши на процессоре «clients» в браузере. В открывшемся меню выберать пункт New → Process (Создать → Процесс). Ввести имя процесса − ClientExe. Выводы Из диаграммы видно, что информационная подсистема учет успеваемости студентов построена на технологии «клиент-сервер». Это позволяет организовать одновременный доступ нескольких операторов ПК к базе данных. Клиентские программы будут работать в нескольких местах. Через локальную вычислительную сеть университета будет осуществляться сообщение этой части программы с главным сервером системы, с работающим программным обеспечением. В свою очередь, главный сервер посредством локальной сети будет сообщаться с сервером базы данных. С главным сервером соединен принтер. Главный сервер может находиться как в одном из корпусов, так и в главном корпусе университета. 9. ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C++ Язык C++ является одним из наиболее широко применяемых на практике объектно-ориентированных языков. Rational Rose интегрируется с C++ посредством генерации кода и обратного проектирования. В Rational Rose 2003 предусмотрена возможность генерации программного кода C++, а также интеграции с языком Visual C++ версии 6 компании Microsoft. При генерации с помощью Rational Rose 2003 программного кода Visual C++ применяется программа-мастер. Для запуска этого мастера необходимо выбрать пункт меню Tools → Visual C++ → Update Code, после чего стартует инструментальное средство обновления программного кода Visual C++ Update Code и появляется экран приглашения. Для продолжения работы необходимо щелкнуть мышью на Next. Rose выведет на экран окно выбора Select Components and Classes (рисунок 9.1). Перед генерацией класса в Visual C++ ему необходимо назначить компонент. Если компонент еще не назначен, выбрать режим Create a VC++ Component and Assign New Classes to It (Ctrl+R) в окне мастера. В этом режиме можно создать нужное число компонентов перед генерацией программы. Затем выбрать компоненты и/или классы модели для генерации программного кода. Чтобы изменить свойства генерации программного кода для компонентов и классов Visual C++, необходимо щелкнуть правой клавишей мыши на папке VC++ на этом экране. После этого можно установить любые свойства генерации, например контейнерный класс, свойства поддержки множественности связей, возможность автоматической генерации конструктора и деструктора, а также возможность автоматической генерации операций Get и Set или других функций-членов (member functions). После того как всем классам назначены компоненты, выбраны классы и/или компоненты для генерации и установлены все свойства генерации программного кода, необходимо щелкнуть мышью на Next. Появится итоговая страница со сведениями о том, какие классы и компоненты сгенерированы и какие ошибки выявлены в процессе генерации. Для генерации программного кода Rational Rose 2003 использует самую различную информацию, содержащуюся в модели. Анализируются множественность, имена ролей, включение и другие характеристики каждой связи. Просматриваются атрибуты, операции, видимость и другие детали каждого класса. Rational Rose 2003 выбирает нужные для генерации кода сведения из всех данных, вводимых в окнах спецификации различных элементов модели. Выводы На основании созданных моделей компонентов, представленных в проекте была произведена генерация программного кода на языке Visual C++. Листинги сгенерированного Rational Rose кода приложения для учета успеваемости студентов факультета на языке С++ приведены в Приложении А. Общий размер сгенерированных файлов составляет 2,90 КБ. ЗАКЛЮЧЕНИЕ В результате выполнения курсового проекта была разработана объектно-ориентированная модель информационной подсистемы учет успеваемости студентов. Данная разработка написана с помощью языка UML, с использованием среды разработки – программного продукта Rational Rose 2003. Были разработаны следующие диаграммы: диаграмма прецедентов; диаграмма последовательности; диаграмма сотрудничества; диаграмма классов; диаграмма состояния для классов; диаграмма компонентов; диаграмма размещения. Основным действующим лицом является оператор ПК. Он выполняет три действия: «просмотреть БД», «Добавить сведения по ведомости», «Занести учетную информацию в БД». Наиболее важной и наиболее сложно реализуемой задачей информационной подсистемы является ввод и модификация информации о студентах, так как от правильности выполнения этого прецедента зависит успешность оперативного учета в целом. Для решения этой задачи были созданы пять классов: два «управляющих», два «граничных»(Boundaries) и один «сущность». Информационная подсистема учета успеваемости студентов факультета на технологии «клиент-сервер». Это позволяет организовать одновременный доступ нескольких операторов ПК к базе данных. Клиентские программы будут работать в нескольких местах. Через локальную вычислительную сеть университета будет осуществляться сообщение этой части программы с главным сервером системы, с работающим программным обеспечением. В свою очередь, главный сервер посредством локальной сети будет сообщаться с сервером базы данных. С главным сервером соединен принтер. Главный сервер может находиться как в одном из корпусов, так и в главном корпусе университета. Были сгенерированы 8 файлов кода на языке С++ общим размером 2,90 кбайт. Разработанная в данном курсовом проекте модель позволяет производить добавление информации о студенте в базу данных при его обучении в университета, удаление ненужной информации при его отчислении или переводе из университета, ежедневное занесение оперативной информации о студентах и поиск необходимой информации. Спецификация UML не определяет конкретный процесс разработки, поэтому перспективным направлением разработки темы курсового проекта является наполнение сгенерированной модели функциональным кодом. БИБЛИОГРАФИЧЕСКИЙ СПИСОК Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. – М.: ДМК, 2000.- 432 с., ил. (Серия «для программистов»). Ляхов В. Ф. Информационные системы и технологии. Проектирование информационных систем часть 2. – Ставрополь: Издательство СевКавГТУ, 2006. – 137с.,ил. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. – М.: Издательство «Лори», 2000.- 581 с., ил. Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. – СПб.: Питер, 2002.- 432 с., ил. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. – М.: Издательский дом «Вильямс», 2001. – 496 с., ил. ГОСТ 2.105-95 ЕСКД. Общие требования к текстовым документам ГОСТ 2.004-88 ЕСКД. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах ввода ЭВМ ГОСТ 2.104-68 ЕСКД. Основные надписи ГОСТ 2.106-68 ЕСКД. Текстовые документы ГОСТ 2.109-73 ЕСКД. Основные требования к чертежам ГОСТ 2.301-68 ЕСКД. Форматы ПРИЛОЖЕНИЯ Приложение А ЛИСТИНГ КОДА ПРОГРАММЫ Листинг файла bd.cpp #include "bd.h" #include "Vedomost.h" //##ModelId=4B0B884A0127 bd::open_bd() { } //##ModelId=4B0B884D028F bd::take_info() { } //##ModelId=4B0B88630389 bd::save_info() { } //##ModelId=4B0B886A032B bd::close_bd() { } Листинг файла bd.h #ifndef BD_H_HEADER_INCLUDED_B4523A44 #define BD_H_HEADER_INCLUDED_B4523A44 class Vedomost; //##ModelId=4B0B883D009B class bd { public: //##ModelId=4B0B884A0127 open_bd(); //##ModelId=4B0B884D028F take_info(); //##ModelId=4B0B88630389 save_info(); //##ModelId=4B0B886A032B close_bd(); //##ModelId=4BADEEEF0357 Vedomost *1; private: //##ModelId=4B0B887900F2 name_bd; }; #endif /* BD_H_HEADER_INCLUDED_B4523A44 */ Листинг файла Dekanat.h #ifndef DEKANAT_H_HEADER_INCLUDED_B45230A2 #define DEKANAT_H_HEADER_INCLUDED_B45230A2 class AuthForm; //##ModelId=4B0B7C7801F5 class Dekanat { public: //##ModelId=4B0B7CA90029 input(); //##ModelId=4B0B7CC700C6 inputD(); //##ModelId=4B0B7CCD0058 editD(); //##ModelId=4BADEE91020F AuthForm *0..1; //##ModelId=4BADEE91020F AuthForm *0..1; private: //##ModelId=4B0B7C89009E Dekan; //##ModelId=4B0B7C94006F Zam_dekan; //##ModelId=4B0B83DE01A7 login; //##ModelId=4B0B83E40050 password; }; #endif /* DEKANAT_H_HEADER_INCLUDED_B45230A2 */ Листинг файла Dekanat.cpp #include "Dekanat.h" #include "AuthForm.h" //##ModelId=4B0B7CA90029 Dekanat::input() { } //##ModelId=4B0B7CC700C6 Dekanat::inputD() { } //##ModelId=4B0B7CCD0058 Dekanat::editD() { } Листинг файла AuthForm.h #ifndef AUTHFORM_H_HEADER_INCLUDED_B4523431 #define AUTHFORM_H_HEADER_INCLUDED_B4523431 //##ModelId=4AE6A84403D6 class AuthForm { public: //##ModelId=4B0B7D3301E2 SForm(); //##ModelId=4B0B7D4A00A9 Login(); private: //##ModelId=4B0B7D29000C login; //##ModelId=4B0B7D2B01C2 password; }; #endif /* AUTHFORM1_H_HEADER_INCLUDED_B4523431 */ Листинг файла AuthForm.cpp #include "AuthForm.h" //##ModelId=4B0B7D3301E2 AuthForm::SForm() { } //##ModelId=4B0B7D4A00A9 AuthForm:: Login () { } Листинг файла Vedomost1.cpp #include "Vedomost.h" //##ModelId=4B0B7DC800F9 Vedomost::choose() { } //##ModelId=4B0B7DCC0270 Vedomost::showD() { } //##ModelId=4B0B7DCE027F Vedomost::saveD() { } //##ModelId=4B0B7DD500AA Vedomost::close() { } Листинг файла Vedomost.h #ifndef VEDOMOST_H_HEADER_INCLUDED_B45226A4 #define VEDOMOST_H_HEADER_INCLUDED_B45226A4 //##ModelId=4B0B7D76030B class Vedomost { public: //##ModelId=4B0B7DC800F9 choose(); //##ModelId=4B0B7DCC0270 showD(); //##ModelId=4B0B7DCE027F saveD(); //##ModelId=4B0B7DD500AA close(); private: //##ModelId=4B0B7D9E003C number; //##ModelId=4B0B7DA80220 date; //##ModelId=4B0B7DAA01D2 fakultet; //##ModelId=4B0B7DAC1369 spec; //##ModelId=4B0B7DAE02FF group; //##ModelId=4B0B7DA802E1 kurs; //##ModelId=4B0B7DAA25AC subject; //##ModelId=4B0B7DADD59 prepodfio; //##ModelId=4B0B7DAE99FA studentfio; //##ModelId=4B0B7DA80F10 znum; //##ModelId=4B0B7DAABBD3 otsenka; //##ModelId=4B0B7DAC033D datasdachi; }; #endif /* VEDOMOST_H_HEADER_INCLUDED_B45226A4 */ |