Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Основные структуры алгоритмов: сравнительный анализ и примеры их использования (Типы моделей и основные их классификации)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

  • Раскрыть теоретические основы понятия алгоритмов;
  • Провести оценку различных видов алгоритмизации;
  • Определить практическое применение данных алгоритмов.

Объектом исследования в данной работе является формирование представление об основных структурах алгоритмов: сравнительный анализ и примеры их использования.

Предметом исследования являются методы описания система алгоритмизации.

1. Теоретические основы основных структур алгоритмов

1.1. Типы моделей и основные их классификации

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

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

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

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

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

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

3. набор допустимых операций, которые применимы к объекту описываемого типа.

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

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

Абстрактный тип данных (АТД) – это математическая модель с совокупностью операторов или операций определенных в рамках данной модели. Операции АТД реализуют функциональное назначения математической модели.

Абстрактному типу данных соответствует понятие класса в объектно-ориентированном программирование (ООП). Как известно, класс состоит свойств и методов класса. Свойства представляют собой совокупность переменных для описания объекта предметной области, а методы – набор допустимых операций над ним, реализованных в рамках данного класса.

К АТД применимы понятия инкапсуляции, абстрагирования (обобщение) и наследования парадигмы ООП:

1. Абстракция или обобщение в том смысле, что АТД можно рассматривать как обобщение понятия типа данных.

2. Наследование применимо в том смысле, что одни абстрактные типы данных могут быть описаны на основе АТД, реализация которых уже осуществлена в базовых АТД.

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

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

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

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

Модель — упрощенное представление о реальном объекте, процессе или явлении.

Моделирование — построение моделей для исследования и изучения объектов, процессов или явлений.

Для чего создавать модель, а не исследовать сам оригинал?

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

1. Типы моделей

Рассмотрим наиболее распространенные признаки, по которым классифицируют модели:

• область использования;

• учет в модели временного фактора (динамики);

• отрасль знаний;

• способ представления моделей.

Классификация по области использования:

• учебные модели — наглядные пособия, различные тренажеры, обучающие программы:

• научно-технические модели — создают для исследования процессов и явлений:

• игровые модели — это военные, экономические, спортивные, деловые игры;

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

Классификация с учетом фактора времени. Модели можно разделить на статические (это как бы одномоментный срез информации по объекту) и динамические. Динамическая модель позволяет увидеть изменения объекта во времени.

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

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

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

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

Знаковая модель — информационная модель, выраженная специальными знаками, т.е. средствами любого формального языка (это рисунки, тексты, графики, схемы).

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

• геометрические — графические формы и объемные конструкции:

• словесные — устные и письменные описания с использованием иллюстраций;

• математические — математические формулы, отображающие связь различных параметров объекта или процесса;

• структурные — схемы, графики, таблицы и т. п.;

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

• специальные — ноты, химические формулы и т. и.;

• компьютерные и некомпьютерные.

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

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

Свойства, которыми должен обладать алгоритм:

1. Конечность (финишность) алгоритма. Алгоритм должен приводить к решению задачи обязательно за конечное время. Последовательность правил, приведшая к бесконечному циклу, алгоритмом не является.

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

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

4. Массовость алгоритма. Это означает, если правильный результат по алгоритму получен ятя одних исходных данных, то правильный результат по этому же алгоритму должен быть получен и ятя других исходных данных, допустимых в данной задаче.

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

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

• механические, или детерминированные (жесткие);

• гибкие, или стохастические (вероятностные и эвристические).

1.2. Основные этапы алгоритмов

Все этапы определяются поставленной задачей и целями моделирования. Рассмотрим основные этапы моделирования подробнее.

I этап. Постановка задачи: Описание задачи. Определение цели моделирования. Анализ объекта моделирования.

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

III этап. Компьютерный эксперимент. Тестирование — процесс проверки правильности модели.

IV этап. Анализ результатов моделирования. Конечная цель моделирования (V этап) — принятие решения, которое должно быть выработано на основе всестороннего анализа полученных результатов.

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

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

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

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

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

1.3. Виды алгоритмов и средства их реализации

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

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

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

В программировании алгоритмы подразделяются на три типа:

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

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

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

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

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

• словесный;

• формульно-словесный;

• блок-схемный;

• псевдокод;

• структурные диаграммы;

• языки программирования.

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

Пример. Пусть задан массив чисел. Требуется проверить, все ли числа принадлежат заданному интервалу. Интервал задастся границами А и В.

п. 1. Выбираем первый элемент массива. Переходим к п. 2.

п. 2. Сравниваем: выбранный элемент массива принадлежит интервалу? Если да. то переходим к п. 3, если нет — к п. 6.

п. 3. Все элементы массива просмотрены? Если да. то переходим к п. 5. если нет — к п. 4.

п. 4. Выбираем следующий элемент. Далее переходим к п. 2.

п. 5. Печать сообщения: все элементы принадлежат интервалу. Переходим к п. 7.

п. 6. Печать сообщения: нс все элементы принадлежат интервалу. Переходим к п. 7.

п. 7. Конец.

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

Формульно-словесный — задание инструкций с использованием математических символов и выражений в сочетании со словесными пояснениями.

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

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

2. Анализ разработки системы алгоритмизации на примере предприятия

2.1. Анализ предметной области

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

На сегодняшний день компания «Свод Интернешнл» известна в Краснодарском крае как лидер по продаже автомобилей российского и зарубежного производства, среди которых такие известные марки как ВАЗ, ГАЗ, УАЗ, FORD, MITSUBISHI, WOLKSWAGEN, HYUNDAI, CHEVROLET, CHERY, FIAT, SSANG YONG.

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

Рисунок 1 – Структура компании

Классическая структура автосалонов представлена на примере автосалона FORD и приведена на рисунке 2.

Рисунок 2 – Структура автосалона FORD

Работа станции технического обслуживания (СТО) и отдела гарантии автосалона строится по специальной программе, разработанной вышестоящей компанией «FORD MOTOR COMPANY», на основе многолетнего опыта эксплуатации и ремонта автомобилей FORD во всем мире. СТО оснащена новейшим технологическим оборудованием и программным обеспечением.

Работа магазина и склада запасных частей автосалона строится на основе специальной программы ЕСАТ, также разработанной «FORD MOTOR COMPANY» с учетом особенностей наименований и комплектаций фирменных запасных частей и аксессуаров марки FORD /1/.

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

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

а) консультации клиентов;

б) подбор автомобиля по заявке клиента;

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

г) формирование заказа мастеру предпродажной подготовки (ПП) на подготовку конкретного автомобиля;

д) заключение договоров заказа автомобиля;

е) формирование общего списка заказов поставщику на автомобили для передачи его начальнику отдела продаж;

ж) регистрация всех изменений состояния склада после продажи или резервирования автомобиля;

з) регистрация новых автомобилей, поступивших на склад от поставщика;

и) присвоение салонного номера каждому из новых автомобилей и регистрация этого акта в базе данных автомобилей;

к) ведение клиентской базы данных;

л) формирование общего списка автомобилей для свободной продажи, находящихся на складе по состоянию на конкретную дату;

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

н) формирование общего списка заказанных автомобилей по состоянию на конкретную дату;

о) формирование отчетов по проделанной работе каждым из менеджеров за определенный промежуток времени.

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

Схема движения информации в системе автосалона представлена на рисунке 3.

Рисунок 3 - Схема движения информации в системе автосалона

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

Договор купли-продажи представляет собой документ, который является доказательством серьезного намерения клиента приобрести данный автомобиль. Здесь прописываются такие пункты как предмет договора (марка и модель приобретаемого автомобиля, VIN (от англ. « vehicle individual number» - индивидуальный номер автотранспорта), комплектация, тип кузова, силовые агрегаты, дополнительные опции и окраска кузова), права и обязанности сторон, цена договора и порядок расчета (здесь указывается полная стоимость автомобиля), условия расторжения договора, ответственность сторон и порядок разрешения споров, заключительное положение, а также реквизиты и подписи сторон. Далее менеджер присваивает документу имя по фамилии покупателя и сохраняет его на своем компьютере в папке «Договора купли-продажи», затем выводит на печать две его копии, заверяет их у сотрудника торгового отдела, оставляет ему одну из копий для дальнейшего оформления сделки купли-продажи в присутствии клиента. Вторая копия заносится в бумажный архив договоров купли-продажи.

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

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

Договор купли-продажи представляет собой документ, который является доказательством серьезного намерения клиента приобрести данный автомобиль. Здесь прописываются такие пункты как предмет договора (марка и модель приобретаемого автомобиля, VIN (от англ. « vehicle individual number» - индивидуальный номер автотранспорта), комплектация, тип кузова, силовые агрегаты, дополнительные опции и окраска кузова), права и обязанности сторон, цена договора и порядок расчета (здесь указывается полная стоимость автомобиля), условия расторжения договора, ответственность сторон и порядок разрешения споров, заключительное положение, а также реквизиты и подписи сторон. Далее менеджер присваивает документу имя по фамилии покупателя и сохраняет его на своем компьютере в папке «Договора купли-продажи», затем выводит на печать две его копии, заверяет их у сотрудника торгового отдела, оставляет ему одну из копий для дальнейшего оформления сделки купли-продажи в присутствии клиента. Вторая копия заносится в бумажный архив договоров купли-продажи /1/.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2. Техническое задание

Основанием для разработки является задание, выданное директором автосалона FORD ОАО «Свод Интернешнл» Калтахчян М.Ю. и утвержденное кафедрой «Информационно-вычислительные системы» Пензенского Государственного Университета.

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

Разрабатываемая система автоматизации управления продажами автосалона должна позволять:

а) вести справочники «Марки автомобилей», «Модели», «Автомобили», «Сотрудники», «Контрагенты - Физические лица», «Контрагенты - Юридические лица», «Склады»;

б) учитывать поступление новых автомобилей на склад автосалона (на основании транспортной накладной и инвойса);

в) учитывать резервирование автомобиля на складе и снятие резерва;

г) учитывать продажу автомобиля со склада;

д) учитывать перемещение автомобиля с одного склада на другой;

е) формировать договор купли-продажи автомобиля;

ж) формировать договор заказа автомобиля;

з) формировать заказ на предпродажную подготовку;

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

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

л) формировать отчеты по критерию и за период;

м) вести общий журнал документов;

н) осуществлять поиск и просмотр данных в справочниках.

Входными данными должны быть:

а) по маркам - код, наименование, описание;

б) по моделям - код, наименование, марка, описание;

в) по автомобилям - салонный номер, марка, модель, VIN, тип кузова, тип коробки переключения передач (КПП), объем двигателя, комплектация, дополнительные опции, цвет, цена, состояние, дополнительная информация;

г) по покупателям - ФИО клиента, вид документа, удостоверяющего личность, номер документа, адрес, контактная информация;

д) по поставщикам - код, наименование организации, индивидуальный налоговый номер (ИHH), юридический адрес, контактный телефон, номер расчетного счета, банк, корреспондирующий счет, примечание;

е) по сотрудникам - код, фамилия, инициалы, должность;

ж) по складам - код, наименование;

з) по поступлению автомобилей - номер товарно-транспортной накладной, дата поступления, наименование организации-поставщика, тип цены, менеджер, склад, автомобиль, VIN, стоимость;

и) по резервированию автомобиля – марка, модель, VIN, ФИО клиента, длительность резерва, фамилия менеджера, стоимость, сумма задатка;

к) по продаже автомобиля – марка, модель, VIN, тип кузова, тип КПП, объём двигателя, комплектация, дополнительные опции, цвет, цена, ФИО покупателя, дата покупки, фамилия менеджера, склад, стоимость, количество;

л) по заказу автомобиля - марка, модель, тип кузова, тип КПП, объем двигателя, комплектация, дополнительные опции, цвет, ФИО покупателя, цена, сумма предоплаты, фамилия менеджера, сопровождающего сделку.

Выходными данными должны быть:

а) договор купли-продажи;

б) заказ мастеру предпродажной подготовки;

в) договор заказа автомобиля;

г) заказ поставщику;

д) отчет по остаткам автомобилей на складах;

е) отчет по зарезервированным автомобилям;

ж) отчет по состоянию автомобилей;

з) отчет по продажам (общий за период и по каждому из менеджеров отдела продаж);

и) отчет по рекламе;

к) отчет по клиентам;

л) лист отказа.

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

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

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

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

Программа должна реализовать контроль над корректностью и полнотой вводимой информации.

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

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

Условия эксплуатации должны соответствовать требованиям по безопасности работы оператора ПК.

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

- процессор не ниже Pentium IV 3,2 ГГц;

- оперативная память не менее 1 Гб;

- свободное дисковое пространство 2,5 Гб, для установки клиентской части приложения и возможности работы с системой;

- наличие сетевой карты для осуществления обмена информацией с серверами.

Требования к компьютеру, на котором исполняется сервер 1 С:Предприятие 8.0, можно сформулировать следующим образом:

- процессор не ниже Pentium IV 3,2 ГГц;

- оперативная память не менее 2Гб (рекомендуется 1024 Мбайт и выше). И хотя сервер 1С:Предприятие 8.0 может исполняться в достаточно небольших объёмах памяти, в пиковых ситуациях его потребности могут быть весьма значительными;

- особых требований к дисковой подсистеме со стороны сервера 1 С:Предприятие 8.0 нет, так как он сам не ведет интенсивной работы с дисковыми файлами;

- требуется наличие USB-порта для подключения ключа аппаратной защиты сервера 1С:Предприятие 8.0.

Требования к серверу баз данных главным образом определяются требованиями Microsoft SQL Server 2010. В качестве сервера баз данных может использоваться любой компьютер, на котором может работать Microsoft SQL Server 2010. Формально требования могут быть сформулированы следующим образом:

- аппаратура: в соответствии с требованиями Microsoft SQL Server 2010.

3. Разработка системы алгоритмизации

3.1. Требование к программе

Для разработки функциональной модели использовалось САSЕ-средство верхнего уровня - BPWin. BPWin — это модель, поддерживающая следующие методологии:

- IDEFO (функциональная модель);

- IDEF3 (WorkFlow Diagram);

- DFD (DataFlow Diagram).

Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО - ВЕ). Методология IDEFO предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEFO) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.

В результате анализа предметной области была разработана функциональная модель системы автоматизации рабочего места менеджера продаж автосалона. Осуществилось на основе использования методологий IDЕF0 И DFD .

Работа осуществляется на основе устава автосалона «Стандарты продаж» («управление») менеджером продаж («механизм»).

Входными данными для системы является:

- товарно-транспортная накладная;

- инвойс на автомобиль;

- заявка на автомобиль;

- запрос на формирование отчета;

- отказ клиента от заказа.

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

Выходные данные системы:

- договор купли-продажи;

- договор заказа;

- заказ мастеру предпродажной подготовки;

- заказ поставщику;

- отчет по продажам;

- отчет по остаткам на складах;

- отчет по зарезервированным автомобилям;

- отчет по состоянию автомобилей;

- отчет по клиентам;

- отчет по рекламе.

Функциональная декомпозиция системы проводится на основе методологии DFD и приведена на рисунке А.2.

Диаграмма верхнего уровня иерархии (контекстная диаграмма) определяет основные процессы или подсистемы с внешними входами и выходами. Она детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором детализировать процессы далее не имеет смысла /2/.

В проектируемой системе используется три хранилища (накопителя) данных:

- «Сведения об автомобилях». Накопитель содержит: марка, модель, VIN, тип кузова, тип коробки переключения передач (КПП), объем двигателя, комплектация, дополнительные опции, цвет, цена, состояние, дополнительная информация, наименование поставщика.

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

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

Диаграмма декомпозиции контекстной диаграммы включает пять

процессов:

- регистрация новых автомобилей;

- обработка заявки клиента;

- формирование отчетов;

- формирование заказа поставщику;

- формирование заказа мастеру предпродажной подготовки.

Данные товарно-транспортной накладной и инвойса на автомобиль поступают на вход процесса «Регистрация новых автомобилей». В рамках данного процесса происходит занесение сведений из накладной и инвойса в хранилища данных «Сведения об автомобилях» и «Сведения о контрагентах».

Входными потоками для процесса «Обработка заявки клиента» являются заявка на автомобиль и отказ клиента от заказа. В результате выполнения процесса формируются выходные потоки - данные о заказанном автомобиле и данные о купленном автомобиле, а также документы - договор заказа, договор купли-продажи, лист отказа. Декомпозиция данного процесса представлена на рисунке А.3 и описана в пункте 3.3.1.

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

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

В процессе «Формирование отчетов» анализируется входной поток «Запрос на формирование отчета». В результате выполнения процесса формируются необходимые отчеты.

Диаграмма содержит четыре процесса: «Подбор автомобиля», «Оформление договора купли-продажи», «Оформление договора заказа», «Расторжение договора заказа».

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

Входными потоками для процесса «Расторжение договора заказа» является отказ клиента от заказа и данные о клиенте. Здесь выполняется расторжение договора заказа путем формирования листа отказа.

3.2. Функциональное проектирование системы

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

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

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

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

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

атомарное (или единственное) значение, находится в 1НФ. При этом необходимо, чтобы отношение имело первичный ключ.

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

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

Разработанная модель находится в третьей нормальной форме т.к.:

- атрибуты сущностей являются атомарными;

- каждый неключевой атрибут функционально полно зависит от первичного ключа;

- в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.

Выбор третьей нормальной формы обусловлен достаточной для данной модели данных защищённостью от избыточности и аномалий.

Первый шаг нормализации - выделение первичных ключевых атрибутов сущностей. В качестве первичного ключа в отношении «Автомобиль» включен атрибут «Код_ Автомобиль», в отношении «Марка» - атрибут «Код_Марка», в отношении «Модель» - атрибут «Код_Модель», в отношении «Доступность_опции» - атрибут «Код_Доступность», в отношении «Состояние» - атрибут «Код_Состояние», в отношении «Сотрудник» - атрибут «Код_Сотрудник», в отношении «Контрагент» - атрибут «Код_Контрагент», в отношении «Покупатель» - атрибут «Код_Покупатель», в отношении «Склад» - атрибут «Код_Склад», в отношении «Тип_Цены» - атрибут «Код_Тип_цены», в отношении «Приходная_накладная» - атрибут «Номер приходного документа», в отношении «Расходная_накладная» - атрибут «Номер расходного документа», в отношении «Перемещение» - атрибут «Номер документа перемещения», в отношении «Оприходование» - атрибут «Номер оприходования», в отношении «Резервирование» - атрибут «Номер документа», в отношении «Снятие_резерва» - атрибут «Номер документа», в отношении « Заказ_покупателя» - атрибут «Номер документа», в отношении «Опросник» - атрибут «Номер документа». В отношении «Список_опций» первичный ключ является составным и включает два атрибута: «Код_Опции», «Код_Автомобиль». Отношение «Цена» также имеет составной первичный ключ, включающий атрибуты «Код_Цена» и «Код_Автомобиль». Первичный ключ отношения «Строка_приходного_документа» включает два атрибута: «Номер приходного документа» и «Номер строки документа». В отношении «Строка_расходного_документа» первичный ключ также является составным и включает атрибуты: «Номер расходного документа» и «Номер строки документа». Первичный ключ отношения «Перемещаемый_автомобиль» включает два атрибута: «Номер документа перемещения» и «Номер строки документа». В отношении «Приходуемый_автомобиль» первичный ключ также является составным и включает атрибуты: «Номер оприходования» и «Номер строки документа». Первичный ключ отношения «Строка_резервирования» включает два атрибута: «Номер документа» и «Номер строки документа». В отношении «Строка_снятия_резерва» первичный ключ также является составным и включает атрибуты: «Номер документа» и «Номер строки документа». Первичный ключ отношения «Строка_заказа_покупателя» включает два атрибута: «Номер документа» и «Номер строки документа».

На данном этапе логическая модель удовлетворяет 1НФ. То есть в отношениях, на пересечении каждой строки и каждого столбца содержится атомарное (или единственное) значение. Теперь можно связать сущности с помощью добавления внешних ключей. После этого для некоторых сущностей первичный ключ стал составным. Сущности такого типа удовлетворяют 2НФ, так как ни один атрибут таких сущностей не зависит от части ключа. То есть неключевые атрибуты функционально полно зависят от всего составного ключа. Модель базы данных удовлетворяет так же и 3НФ, так как в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.

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

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

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

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

ЗАКЛЮЧЕНИЕ

В процессе выполнения проекта была изучена предметная область - процесс управления продажами автосалона. По результатам анализа было разработано техническое задание, построена функциональная и инфологическая модели системы. На основе инфологической модели была разработана физическая модель базы данных. Далее была разработана конфигурация на базе платформы 1 С:Предприятие 8.0, предназначенная для менеджера продаж автосалона.

По результатам тестирования был сделан вывод о том, что разработанная система работает верно.

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

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

На сегодняшний день система автоматизации управления продажами автосалона прошла тестирования на реальные данных заказчика в компании ОАО «Свод Интернешнл» г. Сочи и находится на стадии опытной эксплуатации.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Агафонов, В.Н. Логическое программирование / В.Н. Агафонов. - М.: [не указано], 2016. - 471 c.

2. Алгоритмизация и программирование (+ CD-ROM) / И.Н. Фалина и др. - М.: КУДИЦ-Пресс, 2012. - 280 c.

3. Ашманов, С.А. Линейное программирование / С.А. Ашманов. - М.: [не указано], 2015. - 537 c.

4. Бартеньев, О. 1С: Предприятие. Программирование для всех / О. Бартеньев. - М.: Диалог МИФИ, 2012. - 464 c.

5. Валеева-Сулейманова, Г.Ф. Декоративно-прикладное искусство казанских татар / Г.Ф. Валеева-Сулейманова, Р.Г. Шагеева. - М.: Советский художник, 2016. - 216 c.

6. Голуб, А.И. Веревка достаточной длины, чтобы... выстрелить себе в ногу. Правила программирования на Си и Си++ / А.И. Голуб. - М.: [не указано], 2017. - 309 c.

7. Де Моран История декоративно-прикладного искусства / Де Моран, Анри. - М.: Искусство, 2016. - 578 c.

8. Долгов, А. И. Алгоритмизация прикладных задач / А.И. Долгов. - М.: Флинта, 2013. - 136 c.

9. Заковряшин, А. И. Алгоритмизация и программирование вычислительных задач / А.И. Заковряшин. - М.: Science Press, 2013. - 164 c.

10. Информатика и программирование. Алгоритмизация и программирование / Н.И. Парфилова и др. - М.: Academia, 2012. - 336 c.

11. Канцедал, С. А. Алгоритмизация и программирование / С.А. Канцедал. - М.: Инфра-М, Форум, 2012. - 352 c.

12. Канцедал, С. А. Алгоритмизация и программирование / С.А. Канцедал. - М.: Форум, Инфра-М, 2014. - 352 c.

13. Карманов, В.Г. Математическое программирование / В.Г. Карманов. - М.: [не указано], 2017. - 832 c.

14. Кнут, Д.Э. Искусство программирования (Том 1. Основные алгоритмы) / Д.Э. Кнут. - М.: [не указано], 2017. - 855 c.

15. Кнут, Д.Э. Искусство программирования (Том 2. Получисленные алгоритмы) / Д.Э. Кнут. - М.: [не указано], 2016. - 147 c.

16. Кнут, Д.Э. Искусство программирования (том 3) / Д.Э. Кнут. - М.: [не указано], 2013. - 407 c.

17. Кофман, А. Методы и модели исследования операций. (том 3) Целочисленное программирование. / А. Кофман, А. Анри-Лабордер. - М.: [не указано], 2015. - 369 c.

18. Левенталь, Л. Введение в микропроцессоры: Программное обеспечение, аппаратные средства, программирование / Л. Левенталь. - М.: Энергоатомиздат, 2012. - 464 c.

19. Мартынов, Н. Н. Алгоритмизация и основы объектно-ориентированного программирования на JavaScript. Информатика и ИКТ. Профильный уровень. 10 класс / Н.Н. Мартынов. - Москва: ИЛ, 2013. - 272 c.

20. Ощенко Азбука программирования в 1С: Предприятие 7.7.: моногр. / Ощенко, Игорь. - М.: БХВ-Петербург, 2016. - 520 c.

21. Пинтер Visual FoxPro: уроки программирования / Пинтер, Пинтер Лес; , Джон. - М.: Русская Редакция, 2017. - 480 c.

22. Розенталь, Р. История прикладного искусства нового времени / Р. Розенталь, Х. Ратцка. - М.: Искусство, 2017. - 240 c.

23. Романенко, А. Музей прикладного искусства и быта XVII века. 22 открытки / А. Романенко. - М.: Изобразительное искусство, 2016. - 668 c.

24. Сигал, И. Х. Введение в прикладное дискретное программирование / И.Х. Сигал, А.П. Иванова. - М.: ФИЗМАТЛИТ, 2016. - 304 c.

25. Трояновский, В.М. Информационно-управляющие системы и прикладная теория случайных процессов / В.М. Трояновский. - М.: Гелиос АРВ, 2014. - 304 c.