Методические указания по выполнению дипломного проекта

5.1 Реферат

Реферат в соответствии с ГОСТ 7.32 должен содержать следующие элементы:

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

– сведения о количестве слайдов иллюстративной части;

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

Текст реферата должен отражать:

– объект исследования или разработки;

– цель работы;

– метод или методологию проведения работы;

– результаты работы и их новизну;

– основные конструктивные, технологические и технико-эксплуатационные характеристики;

– степень внедрения;

– рекомендации по внедрению или итоги внедрения результатов;

– область применения;

– экономическую эффективность или значимость работы;

– прогнозные предположения о развитии объекта исследования.

Объем реферата должен составлять от 0,5 до 0,75 страницы.

5.2 Содержание

Раздел «Содержание» помещают в пояснительной записке на странице, следующей за рефератом. Содержание включает введение, наименования всех разделов, подразделов, пунктов (если они имеют наименование), заключение, список использованных источников и литературы и наименования приложений с указанием номеров страниц, с которых начинаются эти элементы отчета.

5.3 Введение

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

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

5.4 Исследование предметной области

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

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

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

Общая схема исследования предметной области может быть представлена в виде:

– Получение общего представления.

– Проведение интервью с ключевыми лицами по проблемам предметной области и текущих решений по управлению данной предметной областью.

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

– Анализ стратегий (концепций, политик) и других нормативных документов предметной области.

– Ранжирование списка проблем (решение которых требует минимальных усилий; решение которых дает максимальный эффект и т.п.), выявление первоочередных проблем, выявление системных проблем, выявление обусловленности проблем.

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

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

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

Пример. Специальные требования к варианту использования «Оплата счета».

Требования по производительности. Когда покупатель подает счет к оплате, система должна выдать результат проверки запроса не медленнее чем за 1,0 секунду в 90 % случаев. Время проверки никогда не должно превышать 10,0 секунд.

5.5 Модель предметной области

Цель моделирования предметной области состоит в том, чтобы понять и описать наиболее важные классы контекста предметной области. Небольшие предметные области обычно содержат от 10 до 50 основных классов. В более обширной предметной области классов может быть гораздо больше. Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств. Например, если в качестве предметной области рассмотреть вуз, то в ней можно выделить следующие классы объектов: учащиеся, преподаватели, аудитории и т. д.

Модель предметной области определяет наиболее важные типы объектов контекста системы. Объекты предметной области представляют собой «предметы», которые существуют, или события, происходящие в среде, где работает система.

Многие из объектов предметной области или классов предметной области можно определить в ходе опроса специалистов исследуемой организации.

Классы предметной области разбивают на три типовых категории:

– бизнес-объекты, описывающие сущности, используемые в бизнесе, например, заявки, счета, контракты;

– объекты и понятия реального мира, которые система должна отслеживать, такие как вражеские самолеты, ракеты и траектории;

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

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

Например, классы предметной области: Заказ, Счет, Предмет и Банковский счет. Система будет использовать Интернет для пересылки заказов, счетов и платежей между покупателями и продавцами. Система должна помогать покупателю готовить заказы, продавцу рассчитывать стоимость заказов и рассылать счета и покупателю проверять правильность выписанных счетов и совершать платеж продавцу со своего банковского. Отметим, что Заказ— это запрос покупателя продавцу на поставку изделий. Каждое изделие занимает «одну строку» в заказе. Заказ имеет такие атрибуты, как дата выписки и адрес поставки.

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

Банковский счет имеет такие атрибуты, как баланс и владелец. Атрибут владелец идентифицирует лицо, которому принадлежит банковский счет

Диаграмма классов изображена на рисунке 5.1.

Рисунок 5.1 - Диаграмма классов в модели предметной области

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

5.6 Анализ требований к программному обеспечению

«На этапе анализа требований проходит структуризация уже собранных ранее требований. Цель этапа — предоставить четкий список не дублируемых требований к системе, которые должны быть выделены из избыточных и частично дублирующихся сценариев и пользовательских историй, которые были полученных на предыдущем этапе. Правильно сгруппированные требования помогут обойтись минимальным количеством функционала для удовлетворения максимально большего количества целей» [1].

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

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

Для приоритезации рекомендуется использовать метод MoSCoW [2].

В нем четыре оценки — Must, Should, Could и Won’t.

Элементы Must обязаны быть включенными в продукт.

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

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

Элементы Won’t являются наименее критичными для продукта. Они могут считаться интересными и перспективными для будущих версий продукта, но точно не будут реализованы в текущей версии.

5.7 Выбор метода разработки программного обеспечения

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

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

– модульные программы легко составлять и отлаживать. Функциональные компоненты такой программы могут быть написаны и отлажены порознь;

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

Недостатки модульности:

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

– В модульном подходе может потребоваться несколько больший объем памяти. Если каждой подпрограмме отводится отдельная часть рабочей памяти, то всей программе может потребоваться несколько больший объем памяти [3].

Объектно-ориентированное программирование (ООП) позволяет моделировать объекты определённой предметной области путем программирования их содержания и поведения в пределах класса. Конструкция «класс» обеспечивает механизм инкапсуляции для реализации абстрактных типов данных. Инкапсуляция как бы скрывает и подробности внутренней реализации типов, и внешние операции и функции, допустимые для выполнения над объектами этого типа. Разработка объектно-ориентированных программ состоит из следующих последовательных работ:– определение основных объектов, необходимых для решения данной задачи;– определение закрытых данных (данных состояния) для выбранных объектов;– определение второстепенных объектов и их закрытых данных;– определение иерархической системы классов, представляющих выбранные объекты;– определение ключевых сообщений, которые должны обрабатывать объекты каждого класса;– разработка последовательности выражений, которые позволяют решить поставленную задачу;– разработка методов, обрабатывающих каждое сообщение;– очистка проекта, то есть устранение всех вспомогательных промежуточных материалов, использовавшихся при проектировании;– кодирование, отладка, компоновка и тестирование.

Компонентно-ориентированное программирование (КОП) можно описать примерно такой формулой: КОП = ООП+ модульность (включая сокрытие информации и позднее связывание модулей, то есть возможность подгружать необходимые модули в процессе выполнения программы, а не заранее, как в старых системах программирования). В КОП запрещено наследование от типов, реализованных в других модулях; наследовать можно только абстрактным, чисто интерфейсным типам.[4].

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

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

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

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

– определение параллелизма: анализ задачи с целью выделить подзадачи, которые могут выполняться одновременно;

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

– реализация параллельного алгоритма в исходном коде с помощью системы обозначений параллельного программирования [6].

5.8 Техническое задание на разработку

Техническое задание на разработку программного обеспечения составляют в соответствии с требованиями ГОСТ 19.201-78 (Приложение Ж). Оно содержит разделы:

– введение;

– назначение разработки;

– требования к программе или программному изделию;

– требования к программной документации;

– технико-экономические показатели;

– порядок контроля и приемки;

Например, техническое задание на программный продукт «Деятельность библиотеки» содержит следующие разделы:

– цель проекта;

– рамки проекта;

– цель работы системы;

– структура автоматизируемого объекта;

– описание подразделений;

– описание ролей;

– макеты документов;

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

– описание основных решаемых задач;

– описание структуры данных для создания одноименных форм;

– нефункциональные требования (практичность, надежность, производительность, возможность сопровождения);

– требования к интерактивной пользовательской документации и системе подсказок (руководство администратора системы, руководство пользователя системы);

– ограничения проектирования (требования к системному программному обеспечению, требования к языкам программирования, требования к информационному обеспечению (клиентские операционные системы, серверные операционные системы, системы управления базами данных));

– требования к техническому обеспечению;

– интерфейсы (требования к элементам пользовательского интерфейса, общие требования к пользовательским интерфейсам);

– применяемые стандарты;

– основная часть.