Благоприятность каждого фактора возрастает в таблицах при движении слева направо.

В первом случае мы видим, что день может обладать несколькими свойствами одновременно. В таком случае нам необходимо использовать такое кодирование, при котором отсутствует ситуация, когда разным комбинациям факторов соответствует одно и то же значение. Наиболее распространен способ кодирования, когда каждому фактору ставится в соответствие разряд двоичного числа. 1 в этом разряде говорит о наличии фактора, а 0 о его отсутствии. Параметру «Обычный» можно поставить в соответствии число 0. Таким образом, для представления всех факторов достаточно 4-х разрядного двоичного числа. Получается, что число 10102 = 1010 означает, что у покупателя день выдачи зарплаты, да к тому же и праздничный день, а числу 00002 соответствует обычный день. Таким образом, факторы дня будут представлены числами в диапазоне [0..15].

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

В принципе аналогично можно поступать и для неупорядоченных данных, поставив в соответствие каждому значению какое-либо число. Однако это вводит нежелательную упорядоченность, которая может исказить данные, и сильно затруднить процесс обучения. В качестве одного из способов решения этой проблемы можно предложить поставить в соответствие каждому значению одного из входов НС. В этом случае при наличии этого значения соответствующий ему вход устанавливается в 1 или в 0 при противном случае. К сожалению данный способ не является панацеей, ибо при большом количестве вариантов входного значения число входов НС разрастается до огромного количества. Это резко увеличит затраты времени на обучение. В качестве варианта обхода этой проблемы можно использовать несколько другое решение. В соответствие каждому значению входного параметра ставится бинарный вектор, каждый разряд которого соответствует отдельному входу НС. Например если число возможных значений параметра 128, то можно использовать 7 разрядный вектор. Тогда 1 значению будет соответствовать вектор 0000000 а 128 - вектор 1111111, а, например, 26 значению - 0011011. Тогда число требуемых для кодирования параметров входов можно определить как

N=log2n(15)

Где:

n- количество значений параметра

N- количество входов

Преобразование числовых входных данных

Для НС необходимо чтобы входные данные лежали в диапазоне [0..1], в то время как данные проблемной области могут лежать в любом диапазоне. Предположим что данные по одному из параметров лежат в диапазоне [Min..Max]. Тогда наиболее простым способом нормирования будет

(16)

Где: x- исходное значение параметра

-значение, подаваемое на вход НС

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

1

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

(17)

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

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

Структурная декомпозиция ЭИС на основе объектно-ориен-тированного подхода отличается от функционально-ориентиро-ванного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникающих событий. В этом плане модель проблемной области рассматривается как со-вокупность взаимодействующих во времени объектов. Тогда кон-кретный процесс обработки информации формируется в виде последовательности взаимодействий объектов. Одна операция обработки данных может рассматриваться как результат одного взаимодействия объектов.[7]

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

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

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

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

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

Прежде чем приступать к разработке, необходимо определиться с программными продуктами, которые будут использоваться в ходе построения системы. По мере повышения сложности программных проектов резко возрастают требования к эффективности их реализации. Это тем более важно сегодня, когда разработчики ПО вовлечены практически во все аспекты работы предприятий и число таких специалистов растет. В то же время данные исследований в этой области говорят о том, что результаты как минимум половины "внутренних" проектов разработки программных средств не оправдывают возложенных на них надежд. В этих условиях становится особенно актуальной задача оптимизации всего процесса создания программных средств с охватом всех его участников - проектировщиков, разработчиков, тестеров, служб сопровождения и менеджеров. Управление жизненным циклом приложений (Application Lifecycle Management, ALM) рассматривает процесс выпуска программных средств как постоянно повторяющийся цикл взаимосвязанных этапов:

· определение требований (Requirements);

· проектирование и анализ (Design & Analysis);

· разработка (Development);

· тестирование (Testing);

· развертывание и сопровождение (Deployment & Operations).

Каждый из этих этапов должен тщательно отслеживаться и контролироваться. Правильно организованная ALM-система позволяет:

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

· повысить качество, гарантируя при этом, что приложение будет соответствовать потребностям и ожиданиям пользователей;

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

· ускорить разработку благодаря интеграции инструментов;

· уменьшить затраты на сопровождение, постоянно поддерживая соответствие между приложением и его проектной документацией;

· получить максимальную отдачу от инвестиций в навыки, процессы и технологии.

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13