ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 08.02.2024
Просмотров: 10
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
-
какие в данной предметной области есть термины и понятия, субъекты и объекты, способы взаимодействия субъектов, способы использования объектов, закономерности; -
что входит в словарь предметной области, отдельно выделив список существительных и список глаголов, которые могут быть связаны с существительными; -
каковы функциональные требования к разрабатываемой системе классов.
Результат должен быть оформлен в виде реферативного описания данной предметной области.
Должно быть также представлено обоснованное формулирование требований к разрабатываемому решению. Этот подраздел должен описывать требования к конечному продукту, очерчивать границы реализуемых функций, определять состав конечного продукта.
Под требованием понимается описание функций и возможностей целевой системы. Требования передают ожидания пользователей от программного продукта. Требования определяют то, что должна выполнять система, однако не то, как она должна это выполнять, то есть особое внимание уделяется самой задаче, а не способам ее решения, важно определить все ключевые требования. Выявление требований – это процесс выяснения требований к предполагаемой системе программного обеспечения путем взаимодействия с клиентом, конечными пользователями, пользователями системы и другими лицами, заинтересованными в разработке системы программного обеспечения.
С учетом объектно-ориентированного подхода требования определяются в виде вариантов использования (use case). Совокупность всех возможных вариантов использования описывает функциональные возможности системы в целом.
Проектирование архитектуры программного обеспечения
Объектно-ориентированная архитектура рассматривает систему как серию взаимодействующих объектов, а не как набор подпрограмм или процедурных инструкций. Описание объектно-ориентированной архитектуры должно включать описание объектов и способов их взаимодействия как между собой, так и с внешним миром. С помощью объектно-ориентированной декомпозиции и абстрагирования выделить существующие классы и существующие объекты, свойства и методы классов, выполнить инкапсуляцию, обосновать наследование, выявить полиморфизм, определить существующие отношения между классами.
На этом этапе нужно разработать информационную модель заданной предметной области в виде диаграмм классов и объектов. Раскрыть связи между объектами и алгоритмы их взаимодействия в процессе решения прикладной задачи в нотации UML (унифицированного языка моделирования). В разработке программного обеспечения диаграмма классов в UML – это тип статической структурной диаграммы, которая описывает структуру системы, показывая классы системы, их атрибуты, операции (или методы) и отношения между объектами.
Возможно использование диаграммы классов на разных этапах жизненного цикла разработки программного обеспечения и, как правило, путем моделирования диаграмм классов в трех разных перспективах (уровнях детализации.
Концептуальная перспектива. Диаграммы интерпретируются как описывающие вещи в реальном мире. Таким образом, если вы придерживаетесь концептуальной точки зрения, вы показываете диаграмму, которая представляет концепции в изучаемой области. Эти концепции будут естественно относиться к классам, которые их реализуют. Концептуальная перспектива считается независимой от языка.
Перспектива спецификации. Диаграммы интерпретируются как описание программных абстракций или компонентов со спецификациями и интерфейсами, но без привязки к конкретной реализации. Таким образом, с точки зрения спецификации, мы смотрим на интерфейсы программного обеспечения, а не на реализацию.
Перспектива реализации. Диаграммы интерпретируются как описание реализации программного обеспечения на определенной технологии и языке. Таким образом, с точки зрения реализации, мы смотрим именно на реализацию программного обеспечения.
Рекомендации по написанию второй главы
Вторым разделом является практическая часть работы. Практическая часть должна содержать поэтапный процесс непосредственно кодирования программного приложения. Процесс описания кодирования может включать фрагменты программного кода основных элементов программы. Полностью программный код должен быть представлен в приложении.
На основе диаграммы классов должна быть выполнена программная реализация системы классов. Все классы должны быть описаны с указанием свойств и методов, для сложных методов, если такие есть, должны быть приведены алгоритмы. Описание этапов разработки должно показывать связь между элементами проекта на языке UML и элементами программного проекта.
Обратите внимание на то, что по тексту пояснительной записки необходимо представить программный код, реализующий систему классов предметной области. Полностью программный код с определениями методов классов должен быть представлен в приложении. Программный код должен содержать комментарии.
Вторая глава может содержать экранные формы работы программы в различных режимах. Необходимо представить информацию о возможностях, достоинствах и недостатках. Изложить рекомендации по использованию программных средств. добавить руководство пользователя с подробным описанием интерфейса каждого окна и указанием его предназначения.
Рекомендации по написанию третьей главы
Разработка test-units
В ходе курсовой работы необходимо выполнить вариант модульного тестирования, сводящийся к тестированию всех методов разработанной системы классов. Перед разработкой программы тестирования системы классов предметной области, необходимо определиться с методикой тестирования.
Модульное тестирование (юнит-тестирование, англ. unit testing) – это уровень тестирования программного обеспечения, на котором тестируются отдельные модули/компоненты программного обеспечения. Цель состоит в том, чтобы подтвердить, что каждая единица программного обеспечения работает так, как задумано.
Единица – самая маленькая тестируемая часть любого программного обеспечения. В объектно-ориентированном программировании наименьшая единица – это метод, который может принадлежать базовому/суперклассу, абстрактному классу или производному/дочернему классу. Модульное тестирование обычно выполняется с использованием метода тестирования белого ящика, то есть основывается на знании внутренней структуры программы, и обычно автоматизировано.
Модульный тест может проверять различные поведенческие аспекты тестируемой системы, но, скорее всего, он попадет в одну из следующих двух категорий: на основе состояния или на основе взаимодействия. Проверка того, что тестируемая система производит правильные результаты, или что его конечное состояние является правильным, называется состоянием на основе модульного тестирования, при проверке, что он правильно вызывает определенные методы, называется взаимодействием на основе модульного тестирования.
Результаты тестирования программного обеспечения
Модульное тестирование выполняется в соответствии с разработанной методикой. Если все предыдущие этапы работы завершены успешно, то процедура тестирования в основном сводится к выполнению тестов и фиксации результатов их выполнения. Документирование может быть выполнено в таком режиме, что для каждого выполненного теста фиксируются:
1. Номер теста (по нумерации тестов в методике тестирования).
2. Входные данные.
3. Ожидаемый результат выполнения теста.
4. Результат выполнения теста.
5. Вывод – результат выполнения теста соответствует / не соответствует ожидаемому результату.
Если в ходе тестирования выявляются несоответствия, следует выполнить анализ его причин и привести результаты этого анализа, например, указать, чем вызвано несоответствие – семантическими или алгоритмическими ошибками, сформулировать рекомендации по исправлению несоответствия, и т. п.
Рекомендации по представлению результатов и выводов
В заключении должны быть изложены основные выводы по работе. В данном разделе необходимо сформулировать основные итоги работы – сопоставление полученных и желаемых результатов. Следует отметить основные преимущества и недостатки разработанного приложения, дать практические рекомендации по совершенствованию, охарактеризовать перспективы дальнейшего развития.
Выводы по главам представляют собой описание конкретных результатов, полученных при работе над конкретным материалом исследования.
Рекомендации по оформлению списка используемой литературы
В данном разделе указываются литературные источники, используемые при выполнении курсовой работы (на все источники должны быть ссылки в тексте курсовой работы). Оформление библиографического списка должно соответствовать действующему ГОСТ.
Требования к оформлению курсовой работы, ее объему
и срокам сдачи
Примерный объем курсовой работы составляет 25, но не более 30 страниц формата А4 (без учета приложений). Текст курсовой работы следует печатать, соблюдая следующие размеры полей: правое поле – 15 мм, верхнее и нижнее – 20 мм, левое – 30 мм. Печатать на одной стороне листа через полтора интервала.
Абзацы в тексте начинают отступом равным 1,25 см.
Шрифт основного текста, заголовков, подписей рисунков и таблиц должен иметь гарнитуру «Times New Roman», размер 14, обычное начертание. Цвет шрифта черный. В заголовках и подзаголовках рекомендуется полужирное начертание шрифта. В таблицах, при необходимости, разрешается понижение размера шрифта до 12 пунктов и одинарный межстрочный интервал.
Наименования глав и структурных элементов отчета «Содержание», «Введение», «Заключение», «Список используемой литературы», а также названия глав служат заголовками структурных элементов и представляют собой заголовки первого уровня.
Разделы (главы), параграфы и пункты нумеруются арабскими цифрами. Структурные элементы «Содержание», «Введение», «Заключение» не нумеруются.
Страницы следует нумеровать арабскими цифрами, соблюдая нумерацию по всему тексту. Номер страницы проставляют в центре нижней части листа без точки в конце.
Таблицы (или рисунки) следует располагать непосредственно после текста, в котором они упоминаются впервые. На все таблицы (и рисунки) должны быть ссылки по тексту. Название таблицы следует помещать над таблицей слева, без абзацного отступа в одну строку с ее номером через тире (например, Таблица 1.2 – Название таблицы). Название рисунка следует помещать под рисунком по центру, без абзацного отступа в одну строку с его номером через тире (например, Рисунок 1.2 – Название рисунка).
Приложения следуют в конце пояснительной записки и служат для размещения разработанных схем, кода и т. п. Приложения начинаются с новой страницы. Нумеруются приложения следующим образом: Приложение А, Приложение Б и т. д. Номер и название приложения располагаются по центру страницы. Номера рисунков и таблиц, приводимых в приложениях, предваряются буквой «П», например: Рисунок ПА.2 – Блок-схема алгоритма.
После написания и поступления на проверку курсовой работы, преподаватель/ассистент исследует ее научный уровень, степень раскрываемости исследуемой темы (проблемы), а также проверяет ее оформление. Если необходимые требования к содержанию и оформлению курсовой работы не были соблюдены студентом, то она возвращается к нему для доработки и устранения недостатков. Основными критериями для выставления студенту положительной оценки за курсовую работу являются: степень разработанности темы; полнота реализации требований к программе; удобство программного интерфейса; стиль написания программного кода; обоснованные и правильные выводы; стиль изложения; правильное оформление курсовой работы.