Основы проектирования программ . Этапы создания программного обеспечения

Содержание:

ВВЕДЕНИЕ

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

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

- рассмотрение основ проектирования программ;

- изучение этапов создания ПО.

Объект исследования – проектирование программ.

Предмет исследования - основы проектирования программ и этапов созданий программного обеспечения.

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

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

ГЛАВА 1. ОСНОВЫ МОДЕЛИРОВАНИЯ ПРОГРАММ

1.1 Базы данных, понятия и основы проектирования программ

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

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

На сегодняшний день существует множество технологий разработки баз данных, включая и эти [5]. Для упрощения и создания более конкретной основы предпочтительно создавать такой каркас для выполнения программы, который будет являлся каркасом для разработки будущей системы [4]. Этот каркас должен описывать общие процедуры работы с объектами в графическом интерфейсе и на уровне БД. В тоже время функции оперируют не конкретными, а абстрактными объектами, а это позволит в будущем добавлять нужные классы без особых усилий. Получается, что созданный таким образом каркас позволит уменьшить трудозатраты по разработке итоговой программы. Для реализации каркаса предлагается использование порождающих и поведенческих паттернов проектирования.

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

Применение паттернов обеспечивает следующие преимущества:

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

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

Цель - первый критерий классификации, то есть. основная функция паттерна для реализации рассматриваемой системы. Исходя из этого выделяют:

• Паттерны пораждения, применяющиеся к процессу реализации объектов;
• структурные паттерны, которые характеризуют структуру взаимодействия объектов и классов;
• паттерны поведения, описывающие взаимодействие классов или объектов между собой.

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

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

1.2 Разработка интерфейса

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

• единообразная визуализация объектов;
• однообразная работа с объектами на уровне базы данных, в том числе: создание, изменение, чтение, удаление, а также поиск по БЛ;
• аналогичная работа с объектами на уровне графического интерфейса.

Для избежания повторения, написанного ранее кода, и для уменьшения трудозатрат, при реализации классов, для взаимодействия с объектами были применениы «порождающие паттерны». Скелет создавался, для конерктного программного обесепечения, которая создаёт пользовательский интерфейс для работы с БД отчетов. База данных содержит некоторое кол-во таблиц, содержащие сведения об отчётах, форматах и шаблонах. Графический интерфейс должен обеспечивать выполнение основных функций по работе с записями таблиц.

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

Классовая система, отраженная на рисунке, реадизована с использоыванием паттренов.

Рис. 1.1 – Модель реализации с помощью патентов

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

Этот паттрен использует когда:

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

В качестве первого примера реализации паттерна «Абстрактная фабрика» можно привести класс «AEntity», являющийся абстракцией объекта в базе данных. Класс выполняет фунцию абстрактного продукта в реализации. Класс содержит атрибуты: значение идентификатора объекта и флаг необходимости сохранения объекта в БД, их методы-обозреватели, возвращающие соответствующее значение. Этот класс является родительским для всех классов, соответствующих объектам БД. Каждый объект БД должен обладать идентификатором, определенным в БД. В производных классах объектов БД – в конкретном рассматриваемом примере это классы «Шаблон» и «Отчет» - добавляются атрибуты, которые характеризуют эти объекты, а также методы- модификаторы и методы-обозреватели для работы с объектами. Методы-модификаторы изменяют значение атрибута объекта и имеют только один аргумент - новое значение атрибута. Методы-обозреватели возвращают текущее значение атрибута объекта и не имеют аргументов. Часто названия этих методов начинаются с Get и Set соответственно. Классы «Шаблон» и «Отчет» выполняют функции конкретных объектов в реализации паттерна и относятся к разным семействам продуктов.

Следующий представитель данного паттерна - класс «ADBLayer», определяющий набор базовых виртуальных функций для выполнения простых операций над объектом на уровне БД. Еще он выполняет функции абстрактного продукта в реализации паттерна. Класс содержит методы добавления, удаления, изменения записей, и выбора объектов по фильтру. При этом все функции класса являются абстрактными, т.е. их требуется определять в классах-наследниках: «TemplateDBLayer» и «PaperDBLayer», поскольку действия по отображению объектов на записи таблиц БД весьма конкретны. Классы «TemplateDBLayer» и «PaperDBLayer» играют роль конкретных объектов в реализации паттерна и относятся к разным семействам продуктов. В родительском классе «ADBLayer» в качестве входного параметра имеющихся функций выступает указатель на абстрактный объект класса «AEntity». В наследуемых классах при реализации функций уже используется конкретный объект («Шаблон» или «Отчет»), что обеспечивается приведением типов.

Последний пример реализации этого вида паттерна —класс «AFabric», являющийся абстрактной фабрикой. Класс содержит набор виртуальных функций для создания семейства абстрактных продуктов. Все функции являются абстрактными, и их требуется переопределять. Наследуемыми классами являются «TemplateFabric» и «PaperFabric», выполняющие функции конкретных фабрик. Каждый из них обеспечивает создание конкретного семейства продуктов. В нашем примере это семейства шаблонов и отчетов. Функция абстрактного класса «Создать сущность» в качестве выходного параметра возвращает указатель на абстрактный объект «AEntity», а в классах- наследниках возвращается объект конкретного класса. Аналогично реализована функция «Создать слой БД». Функция «Создать форму работы с объектом» получает в качестве параметра указатель на абстрактный объект класса «AEntity». Функция «Создать форму поиска» не использует в качестве параметров абстрактные классы, тем не менее ее надо полностью переопределять из-за того, что требуется вызывать разные формы поиска, значительно отличающиеся от объекта к объекту из-за того, что все объекты отличаются по количеству и содержанию полей данных.

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

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

В этом паттерне выполняется правило: «Создавай объекты в отдельной операции, чтобы подклассы могли подменить способ их создания» [1]. Соблюдение этого правила и обеспечивает возможность изменять классы объектов так, как необходимо.

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

Паттерн фабричный метод используется, в следущих случаях:

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

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

Кроме абстрактной фабрики фабричные методы определены в классе работы с БД «ADBLayer», где они создают и возвращают фильтр для поиска по конкретной таблице БД, и в классе «AGui», где они используются для создания объекта на основе выбранной по виджету таблицы записи. В обоих случаях базовые классы определяют интерфейс фабричных методов по созданию требуемых объектов, а производные классы реализуют их по своим потребностям.

1.3 Паттерн Стратегия

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

Паттерн стратегия применяется в случаях, когда:

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

На приведенной ниже диаграмме классов ярким представителем этого вида паттернов выступает класс «AGui». Это абстрактный класс шаблона графического интерфейса для работы с объектами. Класс содержит набор абстрактных и реальзованных функций для работы с таблицей объектов. Данный класс выполняет функцию контекста в реализации паттерна.

Атрибутами этого класса выступают виджет таблицы, указатель на объект фабрики «AFabric» и список объектов, извлеченных из БД - List<AEntity*>. Для каждого такого атрибута реализованы методы-обозреватели, а их значения устанавливаются в конструкторе класса. Объекты фабрики выполняют функции конкретных стратегий и с помощью фабричных методов позволяют создавать конкретные объекты работы с БД, использующие контекст «AGui».

Помиио приведенных функций в «AGui» реализован в том числе и полный набор операций для работы с объектами и записями объектов на форме: данные отображаются в таблице списком, либо можно посмотреть каждый объект в отдельной форме. Так были реализованы функции «Добавление сущности», «Редактирование сущности», «Просмотр сущности», «Удаление записи», «Поиск записей» и «Создание фильтра поиска». Приведенные операции реализованы в классе «AGui» так, что они оперируют абстрактными объектами ADBLayer, AFabric и AEntity.

Класс «ADBLayer» и наследуемые от него «TemplateDBLayer» и «PaperDBLayer» выполняют функции абстрактной и конкретных стратегий. Класс «ADBLayer» объявляет общий для всех поддерживаемых алгоритмов интерфейс. Заметим, что в нашем случае, данный класс определяет только набор функций, и реализация каждого алгоритма находится уже в конкретном классе. Это происходит потому, что алгоритмы значительно отличаются по используемым значениям и объектам. Класс «AGui» пользуется интерфейсом для вызова конкретного алгоритма, определенного в классе «TemplateDBLayer» или «PaperDBLayer».

Паттерн Шаблонный метод позволяет сохранять основную структуру алгоритма при переопределении некоторых функций в классах-наследниках.

Паттерн шаблонный метод используется в случаях, если:

• требуется однократно проходить симметричные части алгоритма, а отличающиеся части поведения реализованы в подклассах;
• все подклассы обладают общим поведением, только незначительно отличающимися друг от друга, т.е. необходимо выделить общее в коде и это реализовать в классе-родителе, а различия выносятся в отдельные операции, которые и будут шаблонными методами.

Шаблонные методы вызывают операции следующих видов [1]:

• конкретные операции (либо из класса ConcreteClass, либо из классов клиента);
• конкретные операции из класса AbstractClass (т.е. операции, полезные всем подклассам);
• примитивные операции (т.е. абстрактные операции);
• фабричные методы (паттерн фабричный метод);
• операции-зацепки (hook operations), реализующие поведение по умолчанию, которое может быть расширено в подклассах.

Представителем данного вида паттернов также является класс «AGui». В классе есть абстрактная функция - «Отображение в таблице», которую необходимо переопределять в классах-наследниках. Это вызвано тем, что у каждого объекта разный набор полей, следовательно нужно отображать разное количество столбцов в таблице с разными записями в ее шапке. Вызов функции происходит в шаблонных методах по работе с записями, которые определены в базовом классе.

Рассмотрим реализацию этого паттерна на примере класса «AGui» и классов-наследников «TemplateGui» и «PaperGui». AGui - абстрактный класс, определяющий операции, замещаемые в конкретных подклассах для реализации шагов алгоритма. Помимо этого, он также реализует шаблонный метод, определяющий скелет алгоритма. Шаблонный метод вызывает примитивные операции и операции, определенные в классе «AGui». В качестве примитивных операций выступают функции работы с сущностями: добавление, изменение, просмотр, поиск, которые единообразны для всех объектов.

Конкретные классы «TemplateGui» и «PaperGui» реализуют операции, коорые выполняют шаги алгоритма способом, зависящим от подкласса. В нашем примере существует лишь одна подобная операция - «Отображение в таблице» Эта операция полностью зависит от текущего объекта и реализована в конкретных классах.

Исходя из диаграммы классов, приведенной на рисунке ниже, можно выделить следующие семейства абстрактных продуктов: это классы AEntity, ADBlayer, AFabric и AGui. Данные объекты входят в иерархии связанных классов. Так, объект AEntity находится на самом нижнем уровне иерархии, но для полноценной работы программы требуется его использование во всех остальных абстрактных классах. В качестве конкретных продуктов выступают классы-наследники от каждого абстрактного продукта, а это объекты Шаблон и Отчет, TemplateDBlayer и PaperDBlayer, TemplateFabric и PaperFabric, TemplateGui и PaperGui соответственно.

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

ГЛАВА 2. ФАЗЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Циклы разработки программного обеспечения

Подход к циклу разработки определяется исходя из потребностей проекта. В процессе создания программного обеспечения применяются разные виды жизненных циклов. Типичный цикл разработки программного обеспечения называется «каскадным» и выглядит следующим образом:

Рис. 2.1 – Цикл разработки ПО

Подготовка — это сбор и обработка требований. Предварительное планирование этапов работ, сроков, ресурсов и стоимости.

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

Создание.

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

Кодирование — получение исходного кода.

Тестирование — проверка программы на соответствие всем предъявляемым требованиям.

Документирование — получение возможности передачи накопленных знаний другим разработчикам.

Поддержка.

Внедрение — установка программного обеспечения и обучение пользователей.

Сопровождение — исправление выявленных ошибок и поддержка пользователей.

Второй из наиболее распространенных — гибкий цикл разработки (Agile). Он позволяет без негативных последствий изменять направление деятельности, вносить дополнительные задания, требовать детальной проработки узких мест.

Процесс создания ПО при помощи метода Agile состоит из небольших итераций — коротких циклов — спринтов, которые предстваляют собой мелкие проекты и длятся от одной до четырех недель. При завершении отдельного продуктивного периода проводится анализ и переориентирование на новые задачи следующего цикла. Количество спринтов может быть любым. Этапы приведены на рисунке ниже.

Рис. 2.2 – Планирование разработки ПО

Планирование — постановка целей и выбор действий для их реализации, распределение имеющихся ресурсов.

Разработка — практическое решение задач для создания приложения.

Тестирование — подготовка итоговой информации в целях контроля выполнения задач спринта. Анализ ошибок и причин отклонений от плана. Поиск путей исправления оплошностей.

Демонстрация — представление заказчику готовой части ПО.

Внедрение — по требованию возможно использование ПО в качестве самостоятельного продукта.

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

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

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

2.2 Этапы создания программ

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

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

2. Прикладное ПО предназначено для непосредственного взаимодействия с пользователем и решает конкретно поставленные задачи.

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

Системное и прикладное программное обеспечение создают компании по разработке ПО. Работа с операционной системой, системой управления базами данных, утилитами и системой программирования, входят в услуги программиста, который занимаюется широким классом связующего программного обеспечения. Отсюда слеюует вывод, что для этой деятельности необходим системный программист. Для работы с программами, направленными на выполнение конкретных задач, поставленных самим пользователем, требуются прикладные программисты. Каждый вид деятельности требует уверенных знаний и большой практики, потому не стоит смешивать воедино все познания, пытаясь найти универсального специалиста. Не случайно создание программного обеспечения в ответственных организациях строго структурно распределено между специалистами, каждый из которых отвечает за конкретный участок работы и точно знает все нюансы и особенности своей деятельности. Именно поэтому не только удобно, но и целесообразно обращаться к зарекомендовавшим себя на рынке разработки ПО компаниям. Качественная разработка программного обеспечения может не только сберечь бизнес, но и значительно повысить его производительность. В то же время слабое ПО будет создавать сложности и со временем может отказать вовсе, что приведет к потере архивов с важными данными типа клиентской базы, аналитическими сведениями и так далее.

Безусловно, любое программное обеспечение строится на основе потребностей пользователя. Каждая компания имеет свою специфику работы и требует индивидуального подхода. Произведенная под конкретные требования разработка программ позволит значительно сэкономить время сотрудникам компании на обработке отдельной информации и внесении дополнительных данных. Это могут быть складские программы, программы для произведения сложных вычислений или элементарной записи телефонов клиентов для регулярной рассылки рекламной информации. Воспользовавшись услугами хорошего ПО, можно не только сэкономить время, но и деньги с заработной платы и налогов уже не требующегося сотрудника. ПО, в таком случае, оказывает услугу не только по экономии, но и избавляет работодателя от возможности ошибок от такого понятия как «человеческий фактор». Система не спит, не ест, не курит, не требует отпуск и не пьет чай — она всегда на месте и готова трудиться на благо компании. Если она вышла из строя, достаточно пригласить к ней программиста, и спустя пару часов система снова готова к усердной работе. Чтобы воспользоваться услугами этого чуда техники, достаточно найти сайт программного обеспечения и набрать номер телефона. Работники данной сферы точно знают потребность клиенту и пути удовлетворения этой потребности. Вам детально расскажут обо всех возможностях и наверняка поведают много нового о современном ПО, ведь новшества внедряются ежесекундно [6;15].

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

Проектирование ПО

На этой стадии разработки автоматизированной системы составляются технические задания и создаются спецификации, а планы по проведению работ закрепляются в документальном виде. Проводится анализ составленного плана работ. Определяется, какие процессы и вычисления должны быть видимыми, а какие могут производиться скрыто; к каким данным необходим доступ для внесения корректировок, а какие могут производиться только автоматически или даже нуждаются в этом. Помимо прочего, в зависимости от сложности создаваемой программы, могут использоваться различные методы проектирования. Если программа не очень сложная, для нее вполне подойдет «ручное» проектирование. Если же система является продуктом сложным, то автоматизация необходима даже на этом этапе. Как правило проектированию подвергается архитектура ПО, устройство его компонентов и пользовательские интерфейсы. Чтобы наглядно описать предполагаемую систему на этапе проектирования используются ER-диаграммы, блок-схемы, DFD-диаграммы, UML-диаграммы и макеты [7;124].

Какие компоненты входят в проектирование программного обеспечения?

1. Разработка дизайна.

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

2. Кодирование ПО.

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

3. Тестирование программного обеспечения.

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

— демонстрации программы заказчику для окончательного ее утверждения;

— проверки программы на наличие ошибок, или как это называется в обывательской речи, «багов».

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

При проверке программы на наличие ошибок нужно быть очень внимательными каждому пользователю, поскольку ошибки могут скрываться в самых неожиданных местах. Естественно, если конечный результат будет ошибочным, заметить это несложно. Гораздо сложнее найти мелкие недочеты, приводящие к эффекту «накопительного» свойства. Например, если при произведении вычисления или записывая информацию программа будет совершать регулярно одну незначительную ошибку, которая на первый взгляд не имеет значения либо вообще невидима, итогом может стать полный крах системы, либо отсутствие части ожидаемых функций по формированию отчетов и прочего. Для таких случаев и предусмотрено сопровождение разработанного ПО программистами-создателями.

4. Документирование ПО в процессе разработки.

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

4.1. Чем полезно документирование:

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

4.1.2. В случае появления ошибки на определенном участке системы, будет гораздо удобней, если данный участок имеет определенное название. Таким образом можно быстро передать информацию коллегам, и она будет мгновенно принята к сведению. В таком контексте «Раздел № 26», звучит значительно понятней, чем «недоделанная вчера Ваней часть системы».

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

4.1.4. Четко определенные границы функциональности системы при ее проектировании намного проще сохранить, документируя весь процесс разработки технологий. Уже начав работу над созданием программы, не должно быть внезапно появившихся пожеланий заказчика. Изначально заложенная основа может быть просто не рассчитана на отдельные возможности.

4.2. Рекомендации по документированию программного обеспечения:

4.2.1. Краткость — сестра таланта. В случае с документированием процесса создания ПО эта истина приходится приобретает особую актуальность. Проектные документы должны содержать сухую лаконичную информацию, а не отвлекать и раздражать своими объемами занятых работой людей. Текст должен быть понятно и доступно изложен.

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

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

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

Исходя из вышесказанного можно сделать вывод, что на пункт о документировании было потрачено столько слов не напрасно. Документирование — это не просто бюрократическая волокита, а способ передать накопленные знания коллегам-разработчикам.

2.3 Поддержка ПО

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

Разберем их в отдельности и посмотрим, что они из себя представляют.

2.3.1 Внедрение ПО.

В услуги внедрения входит исполнение договорных обязательств, завершение и вывод в продакшн финальную стабильную версию ПО. За этим следует! Запуск работы с приложением внутри организации. Для того чтобы использование приложения приносила работсь и приятные ощущения, необходимо провести обучение сотрудникам, которые будут работать в готовом приложении. Важно объянить и показать каждому, как и что нужно делать, а какие действия выполнять не следует. В первое время, разработчики сами используют свое приложение, и производят сбор данных о найденных дефектах, вопросах, возникающих в работе. За это время между компаниями выстраивается партнерское взаимодействие. Завершив этап обучения и устранив все возможные баги и дефекты разработчиком, общемение между ними в скором времени сойдет на нет. Но это не означает, что после этого можно вычеркнуть программиста из жизни компании и работы ПО. По своей природе люди часто допускают ошибки и это мождет привести к значительным проблемам в работе программного обеспечения, вызваныые механическими повреждениями или другими факторами – в таком случае потребуется помощь программиста отвественного за ващу программу. Последня часть плавно подводит нас к следующему пункту – сопровождение.

2.3.2 Сопровождение ПО.

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

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

2.1. Кого могут заинтересовать услуги по сопровождению ПО?

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

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

2.1.3. Интересно сопровождение ПО также может быть организациям, которые нуждаются в анализе работы своих систем. Если действующие программы компании нуждаются в реконструкции, развитии или переходе на другую платформу, а документы по ним утеряны — помочь смогут лишь профессионалы. Они точно определят качество имеющегося ПО и рациональность его реконструкции или переноса. Возможно создание нового программного обеспечения — решение более верное менее дорогостоящее.

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

Чем полезно сотрудничество с компанией создающей ПО

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

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

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

— профессионалы в сфере программных систем, максимально обезопасят ваши системы от рисков разного рода. Взломы и неумышленное нанесение вреда — будут маловероятными посетителями;

— все сложности станут разрешаться в считанные минуты, ведь предоставление своевременных услуг — это зачастую пункт в договоре на сопровождение ПО;

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

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

Распространенные услуги реализации проектов разработки программного обеспечения

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

1. Корпоративные веб решения, которые зачастую включают в себя:

— консалтинг и бизнес-анализ;

— разработка заказных CRM, ERP и прочих решений;

— интеграция и внедрение модулей и компонентов систем управления(планирование ресурсов, ERP-системы, CRM-системы);

— настройка и развертывание корпоративной системы;

— разработка и модернизация и нового функционала;

— перенос процессов и информации;

— интеграция корпоративной системы с другими IT системами предприятия;

— обслуживание и поддержка решения;

2. Автоматизация бизнес-процессов это:

— в банковской сфере автоматизация бизнес процессов, телекоммуникационном секторе и торговле;

— разработка корпоративных шин данных (ESB) и интеграционных решений;

— разработка ERP систем корпоративных;

— разработка порталов корпоративных, CRM;

— разработка приложений мобильных;

— разработка инструментов визуализации и анализа данных;

3. Разработка мобильных приложений включает в себя:

— работа в приложениях с банками и финансами;

— получение телекоммуникационных услуг;

— приложения по обучению и маркетингу;

— приложения для торговли и коммерции;

— автомобильные и транспортные приложения;

— приложения по здравоохранению;

— энергетика;

4. ИТ консалтинг — предоставляет возможность проанализировать имеющиеся на современном рынке технологии, инструменты и продукты. Анализ так же ведется в плане рациональности их использования в избранном проекте. То есть, данная программа существует для отбора программ и сопутствующих инструментов для их создания и использования. С целью определения«пригодности» каждой, отслеживаются следующие позиции:

— предъявленные бизнес требования к системе;

— требования к системе технические;

— архитектура самой системы;

— сроки и план реализации.

5. Услуги Research and Development.

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

6. Разработка дизайна.

Дизайн страниц сайтов и программ имеет огромное значение в сегодняшнем мире. Чтобы быстро создать наиболее удачный вариант страницы, можно использовать специальное «умное» программное обеспечение, которое справится с рядом задач вместо вас. Обычно дизайн включает в себя:

— проработку стандартных элементов на экранах приложения и их расположение;

— по приложению пути навигации;

— подготовку стартового экрана, иконок, и подбор цветовой гаммы;

— внесение персональных новых элементов управления и отображение информации;

— подготовку набора экранов приложения.

7. Чтобы ПО было абсолютно адаптированным и качественным, его разработкой занимаются команды специалистов, выделенные специально для решения этой задачи. Люди полностью интегрируются в работу компании и прекрасно осознают поставленные цели. Сотрудничая с работниками фирмы, создают неповторимый уникальный и универсальный продукт. Это называется — выделенный центр разработки ПО.

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

ГЛАВА 3. ПОСТАНОВКА ПРОБЛЕМЫ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ ИНТЕГРИРОВАННОЙ ЛОГИСТИЧЕСКОЙ ПОДДЕРЖКИ ЦЕНТРОБЕЖНЫХ КОМПРЕССОРОВ

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

Значительно упростить подготовку технической документации по динамическому оборудованию, а также повысить точность и скорость обработки результатов диагностики, при одновременном снижении затрат на эксплуатацию центробежных компрессоров можно, если в достижении цели использовать интегрированную логистическую поддержку «ИЛП». При этом для обеспечения высокого качества «ИЛП» центробежных компрессоров объем эксплуатационно-технических данных, непрерывно пополняемый по каждой единице оборудования на протяжении всего жизненного цикла оборудования, должен быть систематизирован и формализован.

Реализация ИЛП центробежных компрессоров, как сложного инженерно­технического и организационно-технологического процесса включает в себя автоматизацию решения следующих задач:

- написание и поддержки паспортно-технической документации;

- проверка технологического оборудования и устройств на соответствие требованиям нормативной документации;

- планирование ремонтных работ и оформление ремонтной документации;

- оформление актов технического обследования;

- сбор статистики отказов и прогнозирование остаточного ресурса;

- анализ результатов технической диагностики.

Анализ научно-технической литературы и существующих программных средств (ПС) не выявил моделей, алгоритмов и программного обеспечения, позволяющих осуществить комплексное автоматизированное решение, перечисленных выше задач. Поэтому указанные выше задачи решаются преимущественно с помощью универсальных и не интегрированных между собой ПС, например, таких как MathCAD, Microsoft Excel, Microsoft Visio, что приводит к существенным недостаткам осуществления ИЛП, среди которых можно отметить:

- многократное дублирование операций поиска, ввода и обработки данных;

- сложность обмена информацией между различными ПС;

- высокая вероятность появления ошибок при вводе данных;

- отсутствие специализированного графического редактора для работы с картами диагностических обследований элементов ЦК (формулярами).

При этом необходимо отметить, что в настоящее время существуют различные ПС, которые позволяют сравнивать отдельные характеристики компрессоров [2-3]. Например, ПС «APRP 4.3» и «SELECT 1.1» позволяют определить коэффициенты аналитических зависимостей кривых «напор - расход», «расход - коэффициент полезного действия», «расход - мощность»; редактировать и систематизировать их для дальнейшего использования и производить подбор насосов, но не предназначена для ведения паспортной документации. Кроме этого, ПС «OLDPUMPE» является каталогом графических характеристик насосов, но не предназначена для ведения паспортной документации и анализа результатов технической диагностики. В результате анализа функциональных возможностей, специализированных ПС, применяемых в РФ и за рубежом («ТЕХНО», «АСТОР», «TRIM- PlannedMaintenanceSystem», «Global», «Лоцман: PLM», «iMaint», «SAP R3», «AutoCAD», «AutoPlantEquipment V8i», «Компас-График», «SVM-RM»,«ВИБРОБИТ», «АРМИД», «Топаз-115», «КОМПАКС», «RecipCOM» HOERBIGER), также установлено, что они позволяют решать только очень ограниченный круг задач технического облуживания и ремонта ЦК.

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

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

- предоставление структурированных актуальных данных о ЦК в графическом и численном виде;

- автоматизированный поиск необходимых данных;

- ввод и хранение в базе данных упорядоченных актуальных паспортно­технических данных о ЦК;

- обработка и хранение эксплуатационных данных о ЦК в графическом и численном виде, включая: схемы формуляров элементов компрессора, результаты вибромониторинга, технических обследований;

- осуществление расчета технических параметров центробежного компрессора.

Всю информацию необходимо структурировать и классифицировать для более удобного использования.

Реализацию ПС по ИЛП центробежных компрессоров предлагается осуществлять с помощью следующих разработанных моделей:

- представления знаний о ЦК в виде сети фреймов [4], содержащая структурированные параметры ЦК;

- математическая для определения параметров ЦК.

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

Рис. 1. ФР: Центробежный компрессор

На рис. 1 представлена общая структура разработанной фреймовой модели ЦК. Модель состоит из пяти основных информационных блоков:

1. «Основные характеристики ЦК» (рис. 2) -блок включает общую паспортно­техническую информацию о ЦК как единице оборудования.
2. «Технологические характеристики

ЦК» (рис.3) - в блоке находится информация о технологических параметрах компрессорного агрегата, включая параметры потоков и ступеней, режимов работы ЦК и компонентов рабочей среды.

1. «Конструкционные характеристики элементов ЦК» (рис. 4) - блок содержит детальную информацию о конструкционном исполнении оборудования и параметры его элементов.
2. «Эксплуатационный журнал компрессора» (рис.1) - в блоке представлены эксплуатационные данные работы компрессора.
3. «Ремонтные данные» (рис. 1) - блок содержит данные о результатах выполнения ремонтных работ.

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

m - количество типов аппаратного оформления ЦК

Рис. 2. ФР: Основные характеристики ЦК: n – количество присоединяемых к ЦК трубопроводов; m – количество типов аппаратного оформления ЦК

Рис. 3. ФР: Технологические характеристики ЦК

Использование в модели (рис. 2 к компрессору (трубопровод стороны всасывания и нагнетания, трубопроводы смазки), а связи «1-m» - наличие у ЦК дополнительного аппаратного оформления в виде нескольких вспомогательных сосудов или агрегатов (например, емкость-ресивер и фильтр).

Связи «1-n» во фрейме «Технологические характеристики ЦК» (рис. 3) позволяют учесть наличие у ЦК нескольких изолированных друг от друга потоков рабочих сред, повышение давления в каждом из которых осуществляется поэтапно в нескольких ступенях. Также модель предусматривает работу компрессора при различных режимах.

Рис. 3. ФР: Конструкционные характеристики элементов ЦК

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

Авторы полагают, что применение специализированного «ПС», разработанного в том числе при помощи предлагаемых информационных моделей центробежных компрессоров, позволит устранить имеющиеся недочёты «ИЛП» «ЦК», а это в своб очередь позволит повысить надежность и эффективность эксплуатации промышленного предприятия в целом.

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Акулов О.А. Информатика: учебник / О.А. Акулов, Н.В. Медведев. – М.: Омега-П, 2012. – 270 с.
2. Алексеев А.П. Информатика 2014 / А.П. Алексеев. – М.: СОЛОН-ПРЕСС, 2012. – 608 с.
3. Виноградова М.В. Мазнев В. Г.. Автоматизация разработки интерфейсов взаимодействия для обмена данными с устройствами // Проблемы построения и эксплуатации систем обработки информации и управления: Сб. статей (М.) под ред. Черненького В.М. - 2014. Выпуск 5.
4. Виноградова М.В., Гжельская М.О. Технология проектирования баз данных на примере пропускной системы общежития // Проблемы построения и эксплуатации систем обработки информации и управления: Сб. статей (М.) под ред. Черненького В.М.. - 2011. Выпуск 8.
5. Вьюхин В.В. Информатика и вычислительная техника: учеб. пособие для инженерных специальностей / В.В. Вьюхин; под ред. В.Н. Ларионова. - М.: Дрофа, 2012. – 286 с.
6. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - СПб: Питер, 2015. 368 с.
7. Гейн А.Г. Основы информатики и вычислительной техники / А.Г. Гейн. - М.: Просвещение, 2012. – 245 с.
8. Дубина О. Обзор паттернов проектирования // ЦИТФорум. 2015. URL: http://citforum.ru/SE/project/pattern/index.shtml#toc (дата обращения 16.10.2017).
9. Информатика: практикум по технологии работы на компьютере / под ред. Н.В. Макаровой. - 2-е изд. - М.: Финансы и статистика, 2012. – 384 с.
10. Л.Л. Босова, Н.И. Михайлова. – М.: Бином, 2012. – 400 с.
11. Макарова Н.В. Информатика: практикум по технологии работы на компьютере / Н.В. Макарова, С.Н. Рамин. – М.: Академия, 2015. – 384 с.
12. Макарова Н.В. Информатика: учеб. пособие для вузов / Н.В. Макарова, Н.В. Бройдо. – М.: Академия, 2012. – 768 с.
13. Могилев А.В. Информатика: учеб. пособие для вузов / А.В. Могилев, Н.И. Пак, Е.К. Хеннер; под ред. Е.К. Хеннера. - М.: Академия, 2015. – 346 с.
14. Острейковский В.А. Информатика / В.А. Острейковский. М.: Высш. шк., 2015. – 235 с.
15. Угринович Н.Д. Практикум по информатике и информационным технологиям: учеб. пособие для общеобразовательных учреждений / Н.Д. Угринович,
16. Федоров О. Шаблоны проектирования: практические примеры // Программист о программировании. 2015. URL: http://glan-saratov.ru/category/шаблоны-проектирования/ (дата обращения 16.10.2017).