Практикум (3 курс, осенний семестр 2017 года) — различия между версиями

Материал из Кафедра математической кибернетики
Перейти к: навигация, поиск
 
(не показана 1 промежуточная версия 1 участника)
Строка 1: Строка 1:
[[Категория:Семинары кафедры математической кибернетики]]
+
[[Категория:Семинары кафедры математической кибернетики (архив)]]
  
 
= Общая информация =
 
= Общая информация =
Строка 159: Строка 159:
 
Максимальная оценка за работу: 100 баллов
 
Максимальная оценка за работу: 100 баллов
  
'''Тема 1:''' [[Media: Prac_318_algorithms.pdf| знакомство со структурами данных, алгоритмами и сложностью]]
+
'''Тема 1:''' [[Media: Prac_318_algorithms.pdf| знакомство со структурами данных, алгоритмами и сложностью.]]
 +
 
 +
'''Тема 2:''' [[Media: Cpp11_1112.pdf| знакомство со стандартом 11 языка C++.]]
  
 
= Критерии выставления оценки =
 
= Критерии выставления оценки =

Текущая версия на 18:20, 9 февраля 2019


Общая информация

Программа курса

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

Первый блок: общие навыки

Задание 1: Git

Обязательно для получения положительной оценки.

Крайний срок сдачи: 17.09.2017, 23:59.

Максимальная оценка за выполнение в срок: 20 баллов.

Штраф за невыполнение в срок: -2 балла за каждый день сверх крайнего срока, но не ниже ноля баллов за задание.

Собственно задание:

  1. Зарегистрироваться в системе Gitlab сервера mks1.cs.msu.ru с логином, позволяющим легко идентифицировать зарегистрировавшегося (предпочтительно - ФамилияИО латинскими буквами).
  2. Обратиться к ведущему с просьбой добавиться в проект "prac-sandbox" (песочницу).
  3. От своего имени (через свой логин в Gitlab) дополнить дерево ревизий проекта "prac-sandbox" чем-нибудь похожим вот на это: от текущей ревизии создать ветку с названием, основанным на своей фамилии, сделать коммит в ветке (с какими угодно изменениями), создать вторую такую же ветку из первой, сделать коммит во второй ветке, и затем постепенно слить вторую ветку с первой, а первую - с главной. Если дерево получится не совсем таким, но тоже "разумным" и показывающим базовые навыки работы с git, то задание тоже может быть принято.
  4. Сообщить любым способом о выполнении задания.

Задание 2: cmake

Обязательно для получения положительной оценки.

Презентации: make, cmake.

Крайний срок сдачи: 24.09.2017, 23:59.

Максимальная оценка за выполнение в срок: 20 баллов.

Штраф за невыполнение в срок: -2 балла за каждый день сверх крайнего срока, но не ниже ноля баллов за задание.

Собственно задание:

  1. Заглянуть в репозиторий prac-318-cmake.
  2. Посмотреть свой номер варианта в файле tasks.xlsx .
  3. Скачать все файлы из папки с названием - номером варианта.
  4. Не изменяя скачанных файлов, дополнить их файлами сборки cmake, позволяющими собрать цели, описанные в скачанном файле task.txt .
  5. Сообщить решение любым способом, например,
    • прислать архив со всеми файлами ему на почту, или
    • выложить решение в новый репозиторий в gitlab-мк и сообщить об этом.

Задание 3: catch

ВНИМАНИЕ!!! В варианте номер 2 обнаружена ошибка: функция show_min должна возвращать значение минимального элемента кучи, т.е. h[0]. Исправление загружено в репозиторий.
ВНИМАНИЕ!!! В варианте номер 2 обнаружена еще одна ошибка: единственный рекурсивный вызов в функции checkdown должен быть таким: checkdown(c). Репозиторий обновлен.

Обязательно для получения положительной оценки.

Презентация: тестирование ПО.

Крайний срок сдачи: 13.10.2017, 10:00 15.10.2017, 23:59.

Максимальная оценка за выполнение в срок: 20 баллов.

Штраф за невыполнение в срок: -2 балла за каждый день сверх крайнего срока, но не ниже ноля баллов за задание.

Собственно задание:

  1. Заглянуть в репозиторий prac-318-tests.
  2. Посмотреть свой номер варианта в файле tasks.xls .
  3. Скачать все файлы из папки с названием - номером варианта.
  4. Не изменяя скачанных файлов, дополнить их файлом main.cpp, в котором должны присутствовать тест-кейсы, тестирующие функционирование класса из варианта задания.
  5. Использование библиотеки Catch является необходимым условием для сдачи задания.
  6. Тесты для класса должны быть разнообразными. Необходимо иметь несколько видов тестовых данных:
    • первый тест должен быть максимально прост, его цель - проверить, работает ли компонент вообще,
    • вторая группа тестов должна проверять граничные/вырожденные случаи (здесь находится, в том числе, и проверка правильности выброса соответствующих исключений),
    • в следующую группу необходимо включить тесты, проверяющие правильность работы компонента в целом, при этом здесь должны присутствовать 1) специальные тесты, проверяющие работоспособность компонента в случае специальной организации входных данных (например, входные данные могут быть отсортированы в порядке возрастания, в порядке убывания, или значения всех параметров могут быть равны между собой) и 2) общие тесты, проверяющие, по возможности, все ветви логической схемы программы.
    • в последнюю группу тестов надо включить тесты, которые должны в полном объеме отражать реальную нагрузку на соответствующие компоненты - здесь, в частности, тестируются такая работа, при которой происходит многократное заполнение и опустошение соответствующих структур данных.
  7. Разные виды тестов надо оформлять в виде отдельных тест-кейсов.
  8. Сообщить решение любым способом, например,
    • прислать архив со всеми файлами ему на почту, или
    • выложить решение в новый репозиторий в gitlab-мк и сообщить об этом.

Оценка задания будет производиться путём подмены правильной реализации рассматриваемых классов их ошибочными реализациями. Любое поведение, отличающееся от эталонного (представленного в реализации из варианта задания), надо считать ошибочным. В ошибочных реализациях гарантируется лишь совпадение сигнатур public членов классов - private члены, реализация конструктора, а также тел inline-функций и значений параметров функций по умолчанию могут быть произвольными. При выполнении необходимых условий балл за задание будет равен взятой от максимального балла доле обнаруженных тестами ошибочных реализаций (разумеется, на эталонной реализации все написанные тесты обязаны проходить успешно).

Задание 4: Doxygen

Обязательно для получения положительной оценки.

Презентация: Styleguide. Презентация: Документирование ПО. Крайний срок сдачи: 22.10.2017, 23:59.

Максимальная оценка за выполнение в срок: 20 баллов.

Штраф за невыполнение в срок: -2 балла за каждый день сверх крайнего срока, но не ниже ноля баллов за задание.

Собственно задание:

  1. Восстановить, если требуется репозиторий, использованный для выполнения предыдущего задания.
  2. Отредактировать оформление файлов в соответствии со Styleguide, если это требуется.
  3. Задокументировать файлы, находящиеся в репозитории, в формате Javadoc.
  4. При помощи Doxygen автоматически создать документацию в формате .html и в формате .pdf.
  5. Сообщить решение любым способом, например,
    • прислать архив со всеми файлами ответственному на почту, или
    • выложить решение в репозиторий, который использовался для предыдущего задания, и сообщить об этом.

При определении оценки за задание будут использоваться следующие критерии:

  • полнота документации;
  • использование возможностей Javadoc;
  • наличие автоматически созданной документации в формате .html и в формате .doc.

Второй блок: практические задания

Задание 1: робот в изменяющемся лабиринте

Крайний срок сдачи: 12.11.2017, 23:59.

Штрафы: 4 балла за день просрочки, плюс штрафы за ошибки в реализации.

Готовое решение следует донести любым способом до него. Рекомендуемый способ - создать репозиторий с названием "Фамилия-Prac318-Labyrinth" в Gitlab сервера mks1.cs.msu.ru, выложить решение в этот репозиторий и пригласить его.

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

Условие задания.

Пример использования библиотеки работы с булевыми функциями BuDDy (bdd-реализация булевых функций).

Презентация по разбору командной строки в C/C++ при помощи getopt и Boost.Program_options

Задание 2: двоичные решающие диаграммы

Крайний срок сдачи: 03.12.2017, 23:59.

Штрафы: 4 балла за день просрочки, плюс штрафы за ошибки в реализации.

Условие задания.

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

Презентация про хэш-таблицы и основы построения библиотеки для работы с BDD.

Пояснения к заданию:

1. Булева разность относительно выбранной переменной - это булева функция,

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

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

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

Третий блок: теоретические задания

Если всё пройдёт по плану, то на последнем занятии (18 декабря) пройдёт контрольная работа по двум темам, освещаемых в рамках блока.

Максимальная оценка за работу: 100 баллов

Тема 1: знакомство со структурами данных, алгоритмами и сложностью.

Тема 2: знакомство со стандартом 11 языка C++.

Критерии выставления оценки

В курсе предполагаются:

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

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

  • 320 для получения оценки "Отлично";
  • 240 для получения оценки "Хорошо";
  • 160 для получения оценки "Удовлетворительно".

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