Разработка программы для оценки через систему тестирования знаний

Сферы применения методологии RAD. Особенности создания программного продукта, предназначенного для редактирования тестов. Рассмотрение моделей жизненного цикла: каскадная, спиральная. Этапы построения начальной контекстной диаграммы. Анализ DFD-диаграммы.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 19.09.2012
Размер файла 1,9 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Введение

программный редактирование методология диаграмма

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

Проект должна быть разработана в сроки, указанные заказчиком, и в то же время не содержать ошибок проектирования и минимальное количество ошибок реализации, поэтому потребуется использование RAD-среды разработки.

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

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

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

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

Данный проект должна удовлетворять следующим требованиям:

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

2. Достаточная информация обо всех объектах.

3. Многофункциональность.

Рекомендуемые аппаратные требования:

· процессор Intel Pentium IV 1.7 ГГц;

· 512MB оперативной памяти;

· 16MB видеопамяти;

· Свободное местно на жестком диске, равный 25Мб.

Требования к программному обеспечению: ОС MS Windows XP или выше, набор драйверов.

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

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

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

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

Завершает работу заключение, в которое входит краткое описание действий, произведенных в каждом из разделов.

В приложение 1 приведён полный состав сопутствующей проекту документации, с оглавлением состава и с краткими выдержками их содержимого.

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

Цели и задачи работы

Цель работы: Создание программы, которая осуществляет создание тестов и их прохождение.

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

Задачи работы:

1. Разработать программу, в которой будет возможность составление тестов и сохранение их в формате tes. Развёрнутое функциональное наименование проекта: «Система тестирования знаний».

2. Реализация всевозможных функций.

3. Более детальна настройка аудио треков.

Новизна работы

Поиск альтернативных программ в сети Internet дал много результатов, но у этой программы свои плюсы не доступные в других программах.

Практическая значимость

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

Структура и объем работы

Пояснительная записка к курсовой работе состоит из введения, трех разделов и заключения, содержит 18 рисунков и 3 таблицы. Список использованной литературы содержит 21 наименований. Общий объём пояснительной записки - 55 страниц машинописного текста, введение - 5 страницы, основная часть - 31 страницы, заключение - 1, приложения - 21 страниц.

Во введении изложено описание и структура курсовой работы.

В первом разделе представлено описание предметной области.

Во втором разделе описано проектирование программного продукта.

В третьем разделе описана программная реализация.

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

В приложение 1 описание техническое задание.

В приложение 2 описание руководство пользователя.

В приложение 3 представлен листинг программы

1. Описание предметной области

Создание программного продукта, предназначенного для создания и редактирование тестов, а потом их прохождение с оценкой знания в той или форме.

Для достижения поставленной цели должно быть реализовано:

изучение структуры создания и редактирования тестов;

изучение основной документации, необходимой для создания и редактирования тестов;

создание основных модулей проекта;

ознакомление со структурой организации создания и редактирования тестов;

формирование пакета документации;

проведение тестирования и отладка проекта;

проект должен иметь интуитивно-понятный интерфейс;

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

Задачи программного продукта:

Проект должен представлять собой приложение, предназначенное для создания и редактирования тестов. Он должен включать в себя все необходимые компоненты для создания и редактирования тестов.

Придерживаться сроков работ и выполнить все требования, предъявляемые к работе и указанные в техническом задании. После завершения проектирования, провести тестирование программы и внедрение.

В процессе создания должно быть налажено тесное взаимодействие с заказчиком, что бы принять во внимание изменения, которые он может внести в проект.

Входные данные: учебный материал.

Выходные данные: тесты для прохождения тестирования.

Проект представляет собой программный продукт, предназначенный для создания и редактирования тестов. Данная программа была разработана во время изучения курса «Создание RAD-приложений».

Работа с программой проходит в одном режиме - режиме пользователя. В нем выполняются все действия по работе с программой.

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

1. Требования бизнеса:

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

· Программа должна быть масштабируема, что подразумевает внедрение в дальнейшем в программу новых модулей или функций.

2. Требования пользователя:

· Быть надежной в работе, то есть сохранять все изменения, внесенные пользователем после подтверждения, и выдавать их при дальнейшем запуске системы;

· устойчиво работать в течение длительного времени;

· работать под операционной системой семейства Windows;

· выдавать в сообщениях понятную информацию;

· иметь надписи на кнопках понятные для пользователя;

· иметь эргономичное цветовое оформление;

· иметь надписи, свободно читаемые (кегль шрифта 10-14 пт.);

· быть способной параллельно работать с другими приложениями.

3. Функциональные требования:

· Должна быть обеспечена возможность ввода, изменения данных и их удаления;

· в программе должен быть удобный понятный и интерфейс;

· при вводе некорректных данных система не должна переходить в неопределенное состояние, а только уведомить оператора об ошибке.

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

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

2. Определены требования пользователя к ПП. Решение данной задачи позволяет наиболее точно выполнить все требования, предъявленные заказчиком к данному программному продукту, во избежание дальнейших доработок программного продукта в случае неполной удовлетворенности заказчика.

3. Определены функциональные требования к ПП, для обеспечения устойчивости и гибкости ПП.

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

5. Составлено техническое задание. Систематизирует все требования к программному продукту и позволяет приступить к практической части проекта.

2. Проектирование программного обеспечения

2.1 Жизненный цикл программного продукта

У каждого программного продукта существует свой жизненный цикл (ЖЦ). ЖЦ - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПП и заканчивается моментом полного изъятия ПП из эксплуатации. Современный рынок программного обеспечения требует, чтобы выпуск программ был быстрым, а его дальнейшая эксплуатация - долговременной и надежной. Для достижения этого необходима хорошая организация и тщательное планирование всего жизненного цикла программного продукта. Жизненный цикл программ состоит из нескольких этапов: Анализ предметной области, проектирование, реализация, анализ и тестирование, эксплуатация.

В настоящее время широкое распространены 2 модели жизненного цикла:

1. Каскадная

2. Спиральная

Каскадная

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

Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе.

Будучи активно используема, эта модель продемонстрировала свою «проблемность» в подавляющем большинстве ИТ проектов, за исключением, может быть, отдельных проектов обновления программных систем для критически-важных программно-аппаратных комплексов. Практика показывает, что в реальном мире, особенно в мире бизнес систем, каскадная модель не должна применяться. Специфика таких систем (если можно говорить о «специфике» для подавляющего большинства создаваемых систем) - требования характеризуются высокой динамикой корректировки и уточнения, невозможностью четкого и однозначного определения требований до начала работ по реализации (особенно, для новых систем) и быстрой изменчивостью в процессе эксплуатации системы.

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

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

Преимуществами каскадной модели являются:

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

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

· Удобна для ПП, где уже в начале достаточно полно сформулированы все требования.

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

Спиральная

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

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

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

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

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

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

Преимущества:

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

- От этапа к этапу можно переходить до завершения работ на предыдущем этапе.

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

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

2.2 Фаза проектирования

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

На фазе проектирования происходит:

1. Описание модели и сценариев поведения продукта в контексте среды разработки и языков программирования. Стадию проектирования можно разделить на 2 пункта:

a. Внешние спецификации;

b. Внутренние спецификации.

Внешние спецификации включают в себя:

- внешние интерфейсы;

- функциональное наполнение, видимое пользователю;

- взаимодействие между процессами;

- форматы файлов;

Внутренние спецификации включают в себя:

- реализация интерфейсов;

- реализация функционального наполнения;

- внутренние структуры данных;

- описание алгоритмов;

- внутренняя обработка ошибок.

2. План тестирования. Данный план работает по следующим пунктам:

- структура и среда тестовой системы;

- методология тестирования;

- периодичность тестирования.

3. План информационной разработки.

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

· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

· DFD (Data Flow Diagrams) диаграммы потоков данных;

На стадии проектирования ПП модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

SADT-диаграмма

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

Диаграммы - главные компоненты модели, все функции ПП и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.

Простейшая диаграмма для данной системы представлена на рисунке (Рис.2.2.1.). Управляющей информацией являются стандарты рисования, входными данными служат инструменты для рисования, снизу воздействует пользователь, который осуществляет все операции и, наконец, результат выхода - готовый рисунок.

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

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

Рис.2.2.1. SADT-диаграмма

Рис.2.2.2. Декомпозиция SADT-диаграммы

DFD-диаграмма

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

Рис. 2.2.3. DFD - диаграмма

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

2. Была построена модель и сценарии поведения продукта в контексте среды разработки и языков программирования. Это позволило определить полный состав, структуру и функциональные возможности разрабатываемого ПП и приступить к программной реализации.

3.Программная реализация

3.1 Выбор средства для разработки

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

C++ Builder

Интегрированная среда обеспечивает скорость визуальной разработки, продуктивность повторно используемых компонент в сочетании с мощью языковых средств C++, усовершенствованными инструментами и разномасштабными средствами доступа к базам данных. C++ Builder может быть использован везде, где требуется дополнить существующие приложения расширенным стандартом языка C++, повысить быстродействие и придать пользовательскому интерфейсу качества профессионального уровня. Профессиональные средства языка C++ интегрированы в визуальную среду разработки. C++ Builder предоставляет быстродействующий компилятор с языка Borland C++, эффективный инкрементальный загрузчик и гибкие средства отладки, как на уровне исходных инструкций, так и на уровне ассемблерных команд - в расчете удовлетворить высокие требования программистов-профессионалов.

C++ Builder позволяет решать следующий круг задач:

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

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

· Создавать современный пользовательский интерфейс для любых ранее разработанных программ DOS и Windows. Нередко в учреждении или фирме существуют и успешно эксплуатируются прикладные программы, разработанные в разное время, разными коллективами, для разных операционных систем. С помощью C++ Builder эти приложения можно снабдить современным удобным оконным интерфейсом, объединить разрозненные приложения в единую систему, обеспечить их стилистическое единство, наладить обмен информации между приложениями.

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

· Создавать мощные системы работы с локальными и удаленными базами данных любых типов. Подход, используемый в C++ Builder, позволяет получить доступ к базам, созданным на любой платформе: InterBase, Microsoft Access, FoxPro, Paradox, dBase, Sybase, Microsoft SQL, Oracle и др.

· Создавать базы данных многих типов с помощью инструментария C++ Builder.

· Автономно отлаживать приложения работы с базами данных на локальном сервере InterBase, поставляемом вместе с C++ Builder, с последующим выходом в сеть.

· Формировать и печатать из приложения сложные отчеты, включающие таблицы, графики т.п. самого различного назначения.

· Связываться из своего приложения с такими продуктами Microsoft, как Word, Excel и другие, используя все их богатейшие возможности.

· Создавать системы помощи (Help), как для своих приложений, так и для любых других, с которыми, в частности, можно работать просто через Windows.

· Создавать профессиональные программы установки приложений Windows, учитывающие всю специфику и все требования Windows. В частности, для этого можно использовать поставляемую вместе с C++ Builder программу InstallShield Express.

· и много другое.

Достоинства и недостатки C++ Builder

Достоинства

1. Все преимущества C, хотя более медлителен.

2. Классы и объекты делают программы более масштабируемыми.

3. Строгая типизированность - защищает от ошибок.

4. Полная объектная инкапсуляция делает программы более надежными, исключая проблемы с указателями и переполнением буфера.

Недостатки

1. Небольшое количество конструкций высокого уровня делают разработку менее эффективной.

2. Частое использование указателей памяти и необходимость управления распределением памяти для программиста часто приводит к ошибкам.

3. Строгая типизированность тормозит разработку.

MS Access

База данных в MS Access представляет собой совокупность инструментов для ввода, хранения, просмотра, выборки и управления информацией. К этим средствам относятся таблицы, формы, отчеты, запросы.

Программный продукт MS Access представляет собой настольную систему управления базами данных (СУБД). Понятие "настольная" СУБД указывает на то, что все операции с базой данных осуществляются на локальном компьютере пользователя. То есть база данных в MS Access - совокупность инструментов для ввода, хранения, просмотра, выборки и управления информацией. К этим средствам относятся таблицы, формы, отчеты, запросы. Противоположностью настольной системе является распределенная база данных, т. е. такая архитектура, при которой ядро БД работает на выделенном сервере; там же обычно хранятся и данные. Через локальную или глобальную сеть пользователь посредством установленного на своем компьютере программного обеспечения посылает запросы и получает ответы. Такие системы предназначены для работы с большим количеством клиентов, и зачастую в качестве серверов в них функционируют компьютеры более сложные и мощные. Так же программа успешно работает и в сетях, правда, с ограниченным числом клиентов.

Идеальная среда для внедрения MS Access - малый и средний бизнес, связанный с интенсивным товара и документооборотом. При желании на Access вполне можно написать продвинутую бухгалтерскую или кадровую программу.

Преимуществами перед другими средами разработки могут служить следующие критерии:

Возможность быстрой и интуитивной разработки (до десятков раз быстрее разработки на визуальных языках программирования);

Разработка доступна даже новичку (Для разработки простейших решений не требуется даже владения языками программирования).

Полноценное хранилище данных, поддерживающее транзакции, индексы, типы данных, ограничения, связи.

Язык запросов SQL

Delphi

Delphi - язык и среда программирования, относящаяся к классу RAD- (Rapid Application Development _ «Средство быстрой разработки приложений») средств CASE - технологии. Delphi сделала разработку мощных приложений Windows быстрым процессом, доставляющим вам удовольствие. Приложения Windows, для создания которых требовалось большое количество человеческих усилий, например в C++, могут быть легко написаны одним человеком, использующим Delphi.

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

Любой из данных языков программирования подходит под описания RAD.

- необязательность полного завершения работ на каждом из этапов жизненного цикла (спиральная модель);

- обязательное вовлечение пользователей в процесс разработки проекта;

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

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

Для проекта «Система тестирования знаний» был выбран язык программирования Delphi. На нем в наше время реализуются как простые, домашние программы, так и сложнейшие проекты для самых ведущих корпораций мира.

3.2 Реализация программного продукта

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

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

· определяется необходимость распределения данных;

· производится анализ использования данных;

· определяются требования к аппаратным ресурсам;

· определяются способы увеличения производительности;

· завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

Таким образом, на фазе реализации происходит:

1. Разработка программного обеспечения:

2. Подготовка к внедрению.

3. Контроль и регулировка основных показателей проекта.

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

Для того чтобы было просто ориентироваться в нашей программе, я сделал справку с помощью программы «Система тестирования знаний».

Рис.3.2.1 Главное окно «Система тестирования знаний».

Здесь показано, что можно выбрать готовый проект и создать новый.

Рис.3.2.2 Окно создания нового проекта

Project Title - Это название справки

Copyright - Защищено авторским правом

Остальные пункты не нужны.

Рис.3.2.3 Окно ввода данных для каждой блок-схемы.

Topics - это странички справки.

В эти странички пишем необходимые нам данные.

В программе удобно из справки вызвать нужную нам страничку.

Рис.3.2.4 Окно «Проектировщика расположения» в будущей справке.

Здесь в первую очередь нажимаем на кнопку Book, затем вставляем нужные нам странички (Topics) с нужным нам пояснением. Далее вставляем готовые странички с помощью кнопки Topics.

Потом двойным щелчком на значок Book в окне - переименовываем название Система тестирования знаний.

Кнопка Remove - отвечает за удаление ненужных страничек.

Рис.3.2.5. Окно «Проектировщика расположения» в будущей справке.

Потом во вкладке File выбираем сохранить как и сохраняем нашу справку.

3.3 Работа справки в программе «Система тестирования знаний»

void __fastcall TForm3::Button3Click(TObject *Sender) - описана функция нажатия кнопки, т.е. при нажатие кнопки выполняется:

{

Application->HelpCommand(HELP_CONTEXT,3); - открывается 3 страница справки (вычисление).

}

Стадия подготовки к внедрению включает в себя SADT и DFD-диаграммы, которые были представлены в предыдущем разделе.

Фаза внедрения состоит из этапов:

1. комплексные испытания;

2. подготовка кадров для эксплуатации;

3. подготовка документации;

4. сдача заказчику;

5. ввод в эксплуатацию;

6. сопровождение системы;

7. поддержка;

8. сервисное обслуживание.

В ходе программной реализации была проделана следующая работа:

1. Была выбрана среда разработки (Delphi 6.0) для реализации ПП и проведено сравнение с другими языками программирования, для определения наиболее подходящей подходящее к данному проекту по функциональным возможностям и скорости разработки ПП.

2. Разработан графический интерфейс. Для обеспечения наиболее удобного восприятия пользователем.

3. Написано руководство пользователя, с помощью которого пользователи смогут подробно изучить ПП.

4. Создана справки с помощью программы «Система тестирования знаний». Реализован программный код.

Заключение

1. В процессе данной работы были достигнуты заданные цели и выполнены все задачи, поставленные перед автором.

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

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

4. Выбраны технологии реализации программной системы: выбрана среда разработки Delphi для реализации ПП и приведены обоснования для этого выбора.

5. Реализованы основные алгоритмы и модули программной системы, в результате чего получили готовый ПП.

6. Составлено руководство пользователя, для более полного представления о возможностях ПП.

7. Произведено тестирование и отладка программного обеспечения, для того чтобы программа работала исправно без всяческих ошибок.

Список использованной литературы

1.Дж. Банкел, Фундаментальные алгоритмы и структура данных в Delphi изд. Москва Dia Soft 2003г.Дж. Банкел, Фундаментальные алгоритмы и структура данных в Delphi изд. Москва Dia Soft 2003г.

2.Брябрин В.М. Программное обеспечение персональных ЭВМ. Изд. 2-е, стер. - М.: Наука, 1989г.

3.Архангельский А.Я., Программирование в Delphi 7. - М.: Бином, 2005. -1152 с.

4.Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. М., "МетаТехнология", 1993.

5.Рассел Арчибальд. Модели жизненного цикла высокотехнологичных проектов. http://www.pmo.ru/models.php.

6.Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. http://www.citforum.ru/database/ case/index.shtml.

7.Дарахвелидзе П , Марков Е. Программирование в Delphi 7 изд. БХВ-Петербург 2003г.

8.Сергей Орлик, Введение в программную инженерию и управление жизненным циклом ПО. Модели жизненного цикла программного обеспечения. - Электронные текстовые данные. Моделирование и анализ систем. Практикум. Черемных С.В. 2001 г.

9.Case-технологии: Консалтинг в автоматизации бизнес-процессов Г. Н. Калянов. 2004 г.

10.Интеллектуальные информационные системы. Андрейчиков А.В., Андрейчикова О.Н. 2000г.

11.Методические рекомендации по выполнению работ для студентов. Шкарина Л.Н.

12.Структурный подход к программированию. Хьюз Дж., Мичтом Дж. 1980 г.;

13.Надежность программного обеспечения систем обработки данных. Шураков В. В. 1987 г.;

14.Ильина О.П. Организация и технология разработки информационной базы АСУ. Учебн. пособие. - М.: Наука, 1986 г.

15.Мартин Дж. Организация баз данных в вычислительных системах. - М.: Мир, 1980.

16.Глушаков С.В., Клевцов А.Л., Теребилов С.А. Программирование на Delphi 5.0. - Харьков: Фолио, 2002. - 518 с.

17.Microsoft Windows 2000 Sever. Учебный курс MCSE. Пер. с англ.-2е издание, переработанное. - М.:Издательско-торговый дом «Русская Редакция», 2001 г.

18.Благодомских В.А., Енгибарян М.А., Ковалевская Е.В., Экономика, разработка и использование программного обеспечения ЭВМ - М. Финансы и статистика, 1995.

19.Котляров В.П., Минаев Д.В.. Методы и средства автоматизации тестирования программного проекта. Учебное пособие. - СПб.: Изд-во Санкт-Петербургского государственного технического университета, 1998.

20.Семенов А.И., Семенова О.В. Практикум по программированию на Турбо Паскале: Учеб. пособие для вузов. В 2-х ч. Ч.1. - 3-е изд. - Абакан: Изд-во Хакасского государственного университета им. Н.Ф.Катанова, 2004 г.

21.Шкарина Л.Н. Методические рекомендации по выполнению научно-исследовательских работ для студентов информационных специальностей. - Абакан; Издательство Хакасского государственного университета им. Н.Ф. Катанова, 2003.

Приложение

П.1. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Программный продукт «Система тестирования знаний»

1. Введение

ПП «Система тестирования знаний» предназначен для создания и редактирования тестов.

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

Основанием для разработки программного продукта является задание по предмету «Создание RAD-приложений» Института информатики и телематики ГОУ ВПО «Хакасский Государственный Университет им. Н.Ф. Катанова» «27» января 2011 года.

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

Назначение системы - создания и редактирования тестов.

4. Состав выполняемых функций.

Программа «Система тестирования знаний» должна:

· Редактировать аудио файлы.

· Сохранять создание треки.

5. Требования к программному изделию.

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

Входные данные

1. Создание нового теста или загрузка уже недавно созданного теста.

Требования к входным данным

Тестовые файлы должны быть в формате TES (*.tes).

Выходные данные

1. Тестовый файл с разрешение *.tes.

Требования к выходным данным.

1. Файл должен иметь расширение *.tes.

2. Файл должен иметь DOS кодировку.

5.2. Требования к надежности

1. Система не должна содержать явных ошибок, обнаруживаемых тестированием.

2. Система не должна переходить в неопределенное состояние при неправильных действиях пользователя.

5.3. Условия эксплуатации

1. Система должна быть рассчитана на пользователя, не обязательно знакомого с программированием для ЭВМ (в том числе и на языке Delphi) и управлением операционной системой.

2. Интерфейс строится на основе выбора действий с использованием манипулятора мыши.

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

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

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

Для работы пользователей необходимо:

- Компьютер с процессором класса Intel Pentium 4 или совместимый.

- Оперативная память не менее 512 Mb

- Установленная ОС Windows 2000/XP

- Свободного дискового пространства не менее 10 Мб

- Наличие манипулятора «мышь»

- Наличие CD-ROMа

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

ПП «Система тестирования знаний» должен работать в ОС Windows 2000/XP

5.6. Требования к маркировке и упаковке

Особых требований к маркировке и упаковке не предусмотрено.

5.7. Требования к транспортировке и хранению

Данный программный продукт хранится и может эксплуатироваться с диском объёмом больше 10 Мб.

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

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

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

Испытание представленной программы и контроль качества ее работы провести на базе предмета «Создание RAD-приложений» Института Информатики и телематики ГОУ ВПО «Хакасский Государственный Университет им. Н.Ф.Катанова». Во время испытаний проверить работу системы по следующим позициям:

- Запуск системы.

- Проверка работы создания тестов.

- Проверка генерации новых тестов из уже существующих.

8. Требования к составу и содержанию работ по внедрению программного средства в эксплуатацию

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

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

- Постановка задачи

- Сбор исходных данных

- Анализ существующих методов решения задачи

- Определение требований к системе

- Определение входных и выходных данных

- Выбор языка программирования

- Разработка алгоритма решения задачи

- Написание программного кода

- Оформление документации по программе

- Сдача в эксплуатацию

- Сопровождение и исправление ошибок

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

СОСТАВИЛ:

Разработчик Хаитов И. Д.

СОГЛАСОВАНО:

Преподаватель по дисциплине Глущенко Н. В.

«Создание RAD-приложений»

П.2. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

Назначение программы

Программный продукт «Система тестирования знаний» предназначен для создания и редактирования тестов. С программой справиться любой начинающий пользователь. Данная программа позволит пользователям создать свои тесты.

Системные требования.

IBM - совместимый персональный компьютер,

Процессор Pentium 4,

512 Mb RAM - Оперативной памяти,

25 Mb Свободного места на жестком диске,

MS Windows 2000 и выше, или Windows XP и выше;

Описание интерфейса программы.

Запустите программу - файл test.exe. После запуска программы Вы увидите главное окно программы:

Рис.5.1 Главное окно программы для тестирования.

Рис.5.2 Главное окно программы для редактирования тестов

Описание основных элементов интерфейса

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

В редактирования тестов в верхнем левом углу находиться вкладка Файл, при нажатие открываться меню с: открыть файл, новый тест, сохранить все, закрыть все и выход.

Рис.5.3 Файл.

В программе тестирования в верхнем левом углу находиться вкладка Файл, при нажатие открываться меню с: открыть тест и выход.

Рис.5.4 Файл.

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

Рис.5.5 Тест.

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

Рис.5.6 Настройки.

Основные принципы и порядок работы

Работа с программой начинается с создание теста в редакторе тестов программы «Test v.1.0».

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

Извлечение данных возможно из тестовых файлов следующих формата: TES (*.tes).

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

Рис. 5.7 Новый тест.

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

При создании теста нужно вводить данные по вопросу, варианты ответов и правильный вариант ответа.

Рис. 5.8 Первый вопрос теста.

После завершения редактирования теста производится его сохранение.

Сохранение теста можно произвести в тестовый файл тех же форматов, что и извлечение. Сохранение в формате tes производится, как и с любым текстовым файлом.

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

Рис. 5.9 Пароль.

Рис. 5.10 Открытый тест.

Проходим, тест и далее программа выдает результат тестирования.

Рис. 5.11 Результаты тестирования.

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

Некоторые моменты, которые следует учитывать, при работе

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

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

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

Условия распространения

Созданная программа будет распространяться платно.

Информация о разработчиках

Данный программный продукт разработан студентом 3 курса Института информатики и телематики, группа 38: Хаитов И. Д.

Установка программного продукта

Программу «Система тестирования знаний» не нужно устанавливать. Достаточно запустить двойным щелчком мыши и программа работает.

Удаление программного продукта

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

П.3. ПРОГРАММНЫЙ КОД

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, Menus, ExtCtrls, uEncrypt;

type

// Временной тип

TPrTime = Record

Min: Byte;

Sec: Byte;

end;

TForm1 = class(TForm)

MainMenu1: TMainMenu;

N11: TMenuItem;

Panel1: TPanel;

Lbl_Last: TLabel;

Lbl_FQuestion: TLabel;

BtnV1: TButton;

BtnV2: TButton;

BtnV3: TButton;

BtnV4: TButton;

MQuestion: TMemo;

MIAbout: TMenuItem;

Timer1: TTimer;

MITest: TMenuItem;

MITBegin: TMenuItem;

MIOpenFile: TMenuItem;

Memo_Temp: TMemo;

MV1: TMemo;

MV2: TMemo;

MV3: TMemo;

MV4: TMemo;

OpenDialog1: TOpenDialog;

GBox: TGroupBox;

MIExit: TMenuItem;

MITEnd: TMenuItem;

LblNameTest: TLabel;

Label1: TLabel;

Label2: TLabel;

PanelButton: TPanel;

Label3: TLabel;

Lbl_NomQuestion: TLabel;

N1: TMenuItem;

MI_OptionInfoAnsver: TMenuItem;

Label4: TLabel;

Label5: TLabel;

Edit1: TEdit;

Edit2: TEdit;

Label6: TLabel;

Edit3: TEdit;

procedure FormCreate(Sender: TObject);

function DecTime(Var aa:TPrTime; Sender: TObject): string;

procedure PrTimeOut(Sender: TObject);

procedure Timer1Timer(Sender: TObject);

procedure MIOpenFileClick(Sender: TObject);

procedure MIAboutClick(Sender: TObject);

procedure PrFillFileds(Sender: TObject);

procedure MITBeginClick(Sender: TObject);

procedure PrClickButton(Sender: TObject);

procedure MIExitClick(Sender: TObject);

procedure MI_OptionInfoAnsverClick(Sender: TObject);

procedure PrGetDataTest(Sender: TObject);

procedure FormClose(Sender: TObject; var Action: TCloseAction);

procedure MITEndClick(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

// Изменено

PrPasswordTestData: string;

PrTimeTestData: TPrTime;

PrKolQuestionTestData: byte;

// --- Суммарное количество вопросов теста

PrSymKolQuestionTestData: byte;

end;

var

Form1: TForm1;

PrTimeLast: TPrTime;

PrTimeFull: TPrTime;

// поряд. номер вопроса

NomQuestion: Byte;

// кол-во прав. ответов

PrVAnsverOK: Byte;

PriznakExit:boolean;

// --- Массив храняший номера вопросов ---

PrOrderQuestion: array [1..255] of byte;

implementation

uses Unit3;

{$R *.DFM}

procedure TForm1.FormCreate(Sender: TObject);

begin

GBox.Visible:=False;

Timer1.Enabled:=False;

PrTimeLast.Min:=0;

PrTimeLast.Sec:=0;

MITBegin.Enabled:=True;

MITEnd.Enabled:=False;

NomQuestion:=1;

Memo_Temp.Lines.Clear;

PrVAnsverOK:=0;

PanelButton.Visible:=True;

// --- Работа с пунктом меню "Настройки" ---

MI_OptionInfoAnsver.Enabled:=false;

//Инициация

PriznakExit:=false;

end;

// --- Форматирование времени ---

Function PrFormatConvert(aa:TPrTime): String;

begin

if aa.Min<=9 then result:='0'+IntToStr(aa.Min)

else result:=IntToStr(aa.Min);

if aa.Sec<=9 then result:=result+':0'+IntToStr(aa.Sec)

else result:=result+':'+IntToStr(aa.Sec);

end;

// Изменение времени.

function TForm1.DecTime(Var aa:TPrTime; Sender: TObject): string;

begin

if aa.Sec=0 then

if aa.Min>0 then

begin

dec(aa.Min);

aa.Sec:=59;

end

else PrTimeOut(Sender)

else dec(aa.Sec);

result:=PrFormatConvert(aa);

end;

// Действия при отсутсвии времени или досрочном ответе

procedure TForm1.PrTimeOut(Sender: TObject);

begin

// --- Вывод Стат. инф. о проведени теста ---

if NomQuestion=PrKolQuestionTestData then

begin

Timer1.Enabled:=False;

PanelButton.Visible:=False; // Отключение клавиш ответов.

ShowMessage('Ответов (общее кол-во\правильных):'+#13+#10

+IntToStr(NomQuestion)+'\'+IntToStr(PrVAnsverOK)); //PrStatisticsTest(Sender);

edit1.Text:= IntToStr(PrVAnsverOK);

edit2.Text:= IntToStr(NomQuestion-PrVAnsverOK);

edit3.Text:= IntToStr(NomQuestion);

Abort;

end;

// --- Восстановление времени на вопрос ---

PrTimeLast:=PrTimeTestData;

// Увеличение номера вопроса на 1

inc(NomQuestion);

PrFillFileds(Sender);


Подобные документы

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

    презентация [159,1 K], добавлен 27.12.2013

  • Понятие и этапы жизненного цикла программного обеспечения как некоторых событий, которые происходят с системой компьютера в процессе ее создания, внедрения и сопровождения. Модели данного процесса: каскадная, спиральная, их отличительные особенности.

    доклад [33,5 K], добавлен 06.04.2015

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

    курсовая работа [1,4 M], добавлен 07.03.2013

  • Требования к технологии проектирования программного обеспечения (ПО). Состав и описание стадий полного жизненного цикла ПО. Классификация моделей жизненного цикла ПО, их особенности. Методологии разработки ПО, приёмы экстремальный программирование.

    презентация [874,4 K], добавлен 19.09.2016

  • Характеристика программных средств, использованных при разработке сайта. Параметры аппаратных средств для демонстрации ПП. Особенности архитектуры программного обеспечения. Анализ модели жизненного цикла программного продукта. Построение Gant-диаграммы.

    курсовая работа [886,9 K], добавлен 30.05.2015

  • Понятие технологии разработки программы. Основа проектирования программного обеспечения. Модели жизненного цикла, возникшие исторически в ходе развития теории проектирования программного обеспечения. Спиральная (spiral), каскадная и итерационная модели.

    презентация [1,0 M], добавлен 11.05.2015

  • Стадии жизненного цикла ИС и его стандарты. Методологии, поддерживающие спиральную модель. Каскадная и инкрементная модели, их достоинства и недостатки. Основные, вспомогательные и организационные процессы жизненного цикла. Сравнительный анализ моделей.

    курсовая работа [186,4 K], добавлен 21.05.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.