СОДЕРЖАНИЕ
ВВЕДЕНИЕ
Структурные части:
А. Про что тема?
Б. Кому-нибудь это надо? Актуальность, где используется.
В. Аналоги. Какие продукты существуют сейчас, какой функционал в них.
Описание аналогов с точки зрения функционала, предоставляемого пользователю. Берете несколько (2-3) приложений-аналогов и описываете функционал, который в них есть. Про каждый по чуть-чуть.
Г. Что планируется сделать? Постановка задачи идет последним абзацем. Что вы планируете сделать в этой работе и с каким функционалом с точки зрения пользователя.
СПИСОК ИСПОЛЬЗУЕМЫХ СОКРАЩЕНИЙ (опционально)
Если у вас есть сокращения необщепринятые (которые выходят за рамки обучения первым трем курсам университета), их надо отсортировать по алфавиту и дать определения. Аналогично определения. Если есть такие термины и их много – то нужно меняем название раздела на СПИСОК ИСПОЛЬЗУЕМЫХ ОПРЕДЕЛЕНИЙ И СОКРАЩЕНИЙ — и где-то в начале группой определения, потом сокращения, отсортированные по алфавиту.
ОБЗОР ЛИТЕРАТУРЫ (3 стр курсач, диплом – 11 стр.)
Для чего это делается:
1. Не изобретать колесо / сэкономить время на придумывании того, что уже давно есть.
2. Ознакомиться с тем, как сделаны компоненты в других продуктах.
3. Определиться с тем, как будете приблизительно сделать – какие технологии лучше всего подходят, какой язык, и т.д.
В анализе предметной области сжато рассказывают про существующие аналоги – как в них приблизительно это было сделано, те или иные фрагменты системы. Дают оценку – достоинства и недостатки. Классифицируют, если есть, что.
Проводят анализ/обоснование – вот для вашей постановки задачи – что лучше подходит из всего этого или не подходит.
В конце выбирают путь — как приблизительно делать.
Структурные части.
А. Программы-аналоги с точки зрения реализации высокоуровневой (2-3)
Б. Выбор пути (например, если вы используете БД, то надо рассказать какие есть кратко, какие достоинства и недостатки, а потом сказать, что выбрали. Аналогично GUI-шная часть)
1. Если получилось много и про разное, то можно сгруппировать по смыслу в подразделы.
2. Помимо того, что я упоминал – в анализе еще можно сформулировать
a. основные требования (если есть) к вашему ПС/программам, решающим этот класс задач, где-нибудь в конце анализа рядом с упоминанием пути
b. тенденции развития систем.
В. Краткое резюме последним абзацем: как с использованием чего будет делаться проектируемое программное средство (перечисляете что вы выбрали).
Примеры:
(1)
(2)
Поскольку цель анализа – выбрать путь, то крупные структурные части можно так и назвать «Выбор … …»
(3)
СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ
Цель: высокоуровневая декомпозиция.
Для проектов на ООП обязательны минимум 2 диаграммы: диаграмма компонентов и диаграмма классов (в дипломе + еще 2 UML диаграммы).
Соответственно должны рассказать про то, на какие компоненты разбили свое программное средство, сослаться на рисунок с диаграммой компонентов, к рисунку дать пояснение: рассказать общими словами про связь компонентов, потом про каждый компонент по чуть-чуть (о чем, зачем он нужен, какой функционал в нем есть).
Что выбрать в качестве компонентов? Зависит от уровня абстрации выбранного:
– файлы: dll / exe / файлы БД;
– наборы классов: группируете классы по смыслу, называете группы как-нибудь, используете эти названия как компоненты.
Потом где-нибудь здесь привести диаграмму классов, описать ее, т.е. прокомментировать аналогичным образом. Класс предназначен для этого, отвечает за это, в нем реализован такой-то функционал. Лишних деталей – имена методов – не надо. Если диаграмма классов слишком большая – либо малозначащие классы уберите, либо разбейте на несколько диаграмм классов, например, классы такого-то компонента.
