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

В первом случае мы видим, что день может обладать несколькими свойствами одновременно. В таком случае нам необходимо использовать такое кодирование, при котором отсутствует ситуация, когда разным комбинациям факторов соответствует одно и то же значение. Наиболее распространен способ кодирования, когда каждому фактору ставится в соответствие разряд двоичного числа. 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-система позволяет:

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

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

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

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

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

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

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

Реализация ALM-стратегии в исполнении Borland заключается в предоставлении комплекса взаимосвязанных инструментов для всех этапов жизненного цикла приложений, таких, как определение требований, анализ и проектирование, разработка, тестирование, развертывание и управление[17]. В рамках данной стратегии компания выпустила ряд продуктов, часть которых мы собираемся использовать в своей работе, главным преимуществом которых является тесная интеграция друг с другом:

· Borland CaliberRM 2006

· Borland Together Designer 2006

· Borland StartTeam 2006

· Borland Developer Studio 2006

Borland Developer Studio 2006, как и вся линейка ALM инструментов является новейшим решением Borland в своем сегменте[18].

Как известно, корпорация Borland еще в 2001 году одной из первых среди независимых поставщиков подключалась к программе Visual Studio .NET Integration Partner и, более того, первой получила лицензию на SDK .NET Framework, объявив о намерении создания собственных средств разработки для новой по тем временам платформы Microsoft .NET.

В 2003 г. Borland представила C#Builder и Delphi 8 -- первые два инструмента для создания .NET-приложений, реализованные на базе нового ядра IDE(Integrated Development Environment) для Windows, поддерживающего несколько различных систем разработки для Win32 и .NET (проект с кодовым названием Gallileo). Потом на смену им пришел новый пакет Delphi 2005, объединивший оба средства (для .NET) с возможностями Delphi 7 (Win32).

По мнению представителей Borland, нынешний вариант инструмента -- это самое значительное обновление Delphi за последние годы, выполненное в полном соответствии со стратегией оптимизации процесса создания программного обеспечения Software Delivery Optimization, разработанной корпорацией.

Среда Delphi 2006 не только поддерживает несколько языков, SDK Win32 и .NET, но и обладает целым рядом принципиально новых усовершенствований. В ее состав входит большое количество принципиально новых функциональных возможностей IDE, призванных упростить выполнение разработчиками своих повседневных задач, повысить производительность их труда и оптимизировать работу с исходными текстами программ.[19]

В числе этих возможностей:

Продуктивность работы в cреде

§ Интеллектуальный редактор кода (история изменений, свертывание кода, подсказки)

§ Шаблоны кода

§ Рефакторинг (изменение структуры кода без влияния на функциональность)

§ Отладка (в т.ч. удаленная, включая Web-приложений)

§ Модульное тестирование (Unit-testing)

Прозрачность работы с СУБД

§ Работа с базами данных через разные механизмы
(BDE, IB Express, dbExpress, ADO, ADO.NET, BDP - Borland Data Providers)

ECO: высокоуровневая прикладная разработка для .NET

§ Объектный подход при работе с СУБД (Object-Relational Mapping)

§ Модели бизнес-сущностей и состояний - первичны и обновляемы

ALM-интеграция: эффективная командная работа

§ CaliberRM: управление требованиями

§ StarTeam: управление версиями, изменениями/дефектами, задачами

§ Together: моделирование (бизнес) и проектирование (код)

Новый менеджер памяти

§ Качественно сокращено время загрузки среды, ускорена работа IDE

Новая система шаблонов кода

§ Для всех поддерживаемых языков

§ Возможна “обертка” выделенного кода через вызов меню Surround

§ Возможно редактирование шаблонов “на лету”

Block Completion

§ Автоматическое завершение блоков код (напр. begin … end)

Diff highlighting

§ Подсветка изменений в коде, сделанных после последнего сохранения в текущей сессии редактирования

Удаленная отладка для Win32-приложений

Sort by load order

CPU view

Правила визуального размещения визуальных элементов в формах

Новые компоненты и классы VCL

§ TGridPanel, TFlowPanel, TCustomTransparetControl

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

Borland Together Designer 2006 - CASE-средство, предназначенное для визуального моделирования и проектирования программных систем на основе стандарта UML, позволяющая моделировать как компоненты программного обеспечения, так и бизнес-процессы. Borland Together обладает открытой архитектурой и предоставляет уникальный уровень интеграции инструментов моделирования и анализа со средой управления требованиями Borland CaliberRM, средством конфигурационного управления Borland StarTeam, а также с такими средами разработки и проектирования приложений, как Borland JBuilder, Borland C++ BuilderX, Microsoft Visual Studio .NET и Eclipse.

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

Технологии Borland Together 2006 помогают:

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

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

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

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

Технологии Borland Together 2006 используют передовые методы проектирования с возможностью визуализации IT-архитектуры:

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

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

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

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

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

· Поддержка стандартов Компания Borland предлагает заказчикам возможность взаимодействия, а не аналитические патентованные методы, и является приверженцем указанных ниже стандартов моделирования. Эта приверженность очевидна в семействе продуктов Together, в которых обеспечивается согласование с ключевыми стандартами MDA: UML, XMI и OCL. На ранней стадии обсуждения сейчас находятся стандарты для четвертой технологии MDA - преобразование модели (QVT); Компания Borland занимает лидирующие позиции в области разработки QVT с помощью технологии преобразования моделей. На сегодняшний день эта технология позволяет разработчикам создавать сложные платформенно-зависимые коды из обычных моделей UML.

Borland укрепляет свою приверженность стандартам MDA, участвуя в разработке важных спецификаций. Сотрудничая с другими участниками и ведущими пользовательскими организациями, компания Borland играла ключевую роль в последнем успешном завершении определений стандарта UML 2.0 и стала лидером в специальной группе OMG по разработке спецификаций OCL 2. Среди сопредседателей подкомитета OMG, занятого разработкой руководства по MDA, есть представители компании Borland.

· Поддержка на протяжении жизненного цикла приложения Технологии проектирования и моделирования Together предоставляют поддержку на протяжении всего жизненного цикла приложения и обеспечивают плавный переход от одной фазы к другой. Интеграция с Borland CaliberRM обеспечивает соответствие проектных моделей требованиям, а поддержка ведущих IDE, таких как Borland JBuilder, Borland C++BuilderX, Microsoft Visual Studio for.NET и Eclipse позволяет разработчикам преобразовывать модели в конкретные платформы. Более того, технологии Together интегрированы с Borland StarTeam и другими системами управления версиями программного обеспечения, позволяя гибко управлять конфигурацией при выборе репозитария.

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

Borland Together обладает следующими ключевыми функциями:

· LiveSource (Class-диаграммы)- two-way - изменения в коде отображаются в модели и наоборот

· Базовый набор UML 1.5 и UML 2.0 диаграмм - Class, Use Case, Sequence, Collaboration, State Chars, Deployment, Activity, Component

· Design Patterns (шаблоны проектирования)

· Refactorings (рефакторинг)

· Audits & Metrics (аудит и метрики)-оценка качества кода по заданным критериям

· Генерация документации

2.3 Проектирование функциональной структуры

Визуальное моделирование в UML можно представить, как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. [7]

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

· Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.

· Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

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

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

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

1

Детализированные диаграммы использования представлены в приложении 1.

2.4 Описание и иерархия основных классов

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

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

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

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

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

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

1

Рис. 2.5.Общая диаграмма классов иерархии нейронной сети

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

· TNeuron -Базовый класс нейрона, несет основную функциональность, состоит из весов, сумматора и выхода.

- Output: double- Свойство содержит выход нейрона (результат вычисления).

- Weights[Index: integer]: double - Индексированное свойство, содержит значения весовых коэффициентов нейрона.

- Create(ALayer: TLayer) -Конструктор нейрона, в качестве параметра передается номер слоя, в котором он находится.

- ComputeOut(const AInputs: TVectorFloat) - Виртуальный метод, вычисляет выход нейрона, фактически это взвешенная сумма нейрона так как в базовом классе активационная функция не используется.

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

- WeightCount: integer - Свойство устанавливает размерность вектора весовых коэффициентов.

- ComputeOut(const AInputs: TVectorFloat) -Вычисляет выход нейрона, использует пороговую активационную функцию.

· TNeuronBP - Класс-потомок нейрона для многослойной нейронной сети, обучаемой по алгоритму обратного распространения (Back Propagation)

- OnActivationD: TSigmoid - Свойство процедурного типа, реализующее производную активационной функции.

- OnActivationF: TSigmoid - Свойство процедурного типа, реализующее активационную функцию.

- ComputeOut(const AInputs: TVectorFloat) - Вычисляет выход нейрона, используя нелинейную активационную функцию.

- Delta: double - Свойства содержит локальную ошибку при обратном распространении.

· TLayer - Базовый класс слоя нейронной сети.

- NeuronCount: integer - Свойство содержит количество нейронов в текущем слое нейронной сети.

- Neurons[Index: integer]: TNeuron - Индексированное свойство содержит нейроны слоя, индекс указывает на соответствующий нейрон в текущем слое.

Create(ALayerNumber: integer; ANeuronCount: integer) - Конструктор слоя нейронной сети. В качестве параметров, соответственно, передаются порядковый номер слоя и количестве нейронов в создаваемом слое.

Destroy - Деструктор слоя нейронной сети. При разрушении нейронной сети вызывается автоматически. Использование напрямую нежелательно.

· TLayerBP- Класс-потомок слоя для многослойной нейронной сети, содержащий нейроны класса TNeuronBP.

NeuronsBP[Index: integer]: TneuronBP - Индексированное свойство содержит нейроны слоя, индекс указывает на соответствующий нейрон в текущем слое.

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

- InputNeuronCount: integer -Свойство содержит количество нейронов в первом слое нейронной сети.

- LayerCount: integer - Свойство содержит количество слоев нейронной сети.

- Layers[Index: integer]: TLayer - Индексированное свойство, индекс указывает на соответствующий слой нейронной сети.

- OutputNeuronCount: integer - Свойство содержит количество нейронов в выходном (последнем) слое.

- AddPattern(const AInputs: TVectorFloat; const AOutputs: TVectorFloat) - Метод добавляет пример в обучающую выборку.

- DeletePattern(Index: integer) - Метод удаляет пример из обучающей выборки.

- Init(const ANeuronsInLayer: TVectorInt) - Метод инициализирует нейронную сеть, фактически это построитель заданной конфигурации сети.

- ResetPatterns - Метод удаляет все примеры из обучающей выборки.

- Input[Index: integer]: double - Индексированное свойство устанавливает выходные значения нейронной сети, индекс указывает на соответствующий вход.

· TNeuralNetBP - Класс-потомок многослойной нейронной сети, обучаемой по алгоритму обратного распространения.

Страницы: 1, 2, 3, 4