Семейство продуктов 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 -Свойство содержит количество нейронов в первом слое нейронной сети.

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