СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ




СОДЕРЖАНИЕ

ВВЕДЕНИЕ

Структурные части:

А. Про что тема?

Б. Кому-нибудь это надо? Актуальность, где используется.

В. Аналоги. Какие продукты существуют сейчас, какой функционал в них.

Описание аналогов с точки зрения функционала, предоставляемого пользователю. Берете несколько (2-3) приложений-аналогов и описываете функционал, который в них есть. Про каждый по чуть-чуть.

Г. Что планируется сделать? Постановка задачи идет последним абзацем. Что вы планируете сделать в этой работе и с каким функционалом с точки зрения пользователя.

СПИСОК ИСПОЛЬЗУЕМЫХ СОКРАЩЕНИЙ (опционально)

Если у вас есть сокращения необщепринятые (которые выходят за рамки обучения первым трем курсам университета), их надо отсортировать по алфавиту и дать определения. Аналогично определения. Если есть такие термины и их много – то нужно меняем название раздела на СПИСОК ИСПОЛЬЗУЕМЫХ ОПРЕДЕЛЕНИЙ И СОКРАЩЕНИЙ - и где-то в начале группой определения, потом сокращения, отсортированные по алфавиту.

ОБЗОР ЛИТЕРАТУРЫ(3 стр курсач, диплом – 11 стр.)

Для чего это делается:

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

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

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

 

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

Проводят анализ/обоснование – вот для вашей постановки задачи – что лучше подходит из всего этого или не подходит.

В конце выбирают путь - как приблизительно делать.

 

 

Структурные части.

А. Программы-аналоги с точки зрения реализации высокоуровневой (2-3)

Б. Выбор пути (например, если вы используете БД, то надо рассказать какие есть кратко, какие достоинства и недостатки, а потом сказать, что выбрали. Аналогично GUI-шная часть)

1. Если получилось много и про разное, то можно сгруппировать по смыслу в подразделы.

2. Помимо того, что я упоминал – в анализе еще можно сформулировать

a. основные требования (если есть) к вашему ПС/программам, решающим этот класс задач, где-нибудь в конце анализа рядом с упоминанием пути

b. тенденции развития систем.

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

 

Примеры:

(1)

 

(2)

 

Поскольку цель анализа – выбрать путь, то крупные структурные части можно так и назвать «Выбор … …»

(3)

 

СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ

Цель: высокоуровневая декомпозиция.

Для проектов на ООП обязательны минимум 2 диаграммы: диаграмма компонентов и диаграмма классов (в дипломе + еще 2 UML диаграммы).

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

 

Что выбрать в качестве компонентов? Зависит от уровня абстрации выбранного:

– файлы: dll / exe / файлы БД;

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

 

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



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-08-08 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: