Основные этапы объектно-ориентированного проектирования

СОДЕРЖАНИЕ

Введение

1. Обзор процесса проектирования

1.1 Характерные черты удачных проектов

2. Понятие домена

2.1 Типы доменов

2.2 Пакеты (домены) в языке UML

2.3 Управление большим доменом

3. Разработка домена

4. Структура приложения

4.1.Способ обработки событий

4.2 Архитектурный класс Form

4.3 Архитектурный класс Imitator

4.4 Архитектурный класс AE

5. Разработка прикладного домена

5.1 Статическая модель прикладного домена

5.2 Описание событий

5.3 Реагирование объектов классов на события

5.4 Исходные тексты операций обработки событий

5.5 Диспетчер вызовов операций класса

6. Организация процесса проектирования

Заключение

Использованы источники

Введение

Тема курсовой работы «Основные этапы объектно-ориентированного проектирования».

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

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

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

По А.Н. Колмогорову, любая материальная система, с которой можно достаточно долго обсуждать проблемы науки, литературы и искусства, обладает интеллектом. Такое определение показывает, что данная дисциплина находится во взаимосвязи практически со всеми учебными дисциплинами. Тем не менее, следует подчеркнуть связи со следующими дисциплинами: «Программирование», «Математический анализ», «Линейная алгебра и аналитическая геометрия», «Дискретная математика», «Логическое программирование», «Экспертные системы», «Интерфейсы интеллектуальных систем».

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

Обзор процесса проектирования

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

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

1.1 Характерные черты удачных проектов

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

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

- хорошо организованный итеративно развивающийся процесс работы над проектом.

Можно выделить ряд этапов, которые присутствуют в процессе протирования и перечень которых дан в таблице 1.

Таблица 1 -Основные этапы процесса проектирования

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

2. Понятие домена

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

Домен (package) – это отдельный реальный, гипотетический или абстрактный мир, населенный отчетливым набором классов, которые ведут себя в соответствии с характерными для домена правилами и линиями поведения. Например, домен «Пользовательский интерфейс», домен «Управление лабораторией». Аналогами домена (пакета) в языках программирования могут быть: язык C# - пространство имен (namespace); язык Delphi – модуль (unit), задаваемый в предложении uses; язык C++ - файл, подключаемый с помощью #include.

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

- любой класс определяется только в одном домене;

- количество классов в домене должно быть не менее одного.

2.1 Типы доменов

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

- прикладные;

- сервисные;

- архитектурные;

- реализации.

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

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

Таблица 2 - Типичные сервисные домены

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

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

- обеспечение однородности структуры программного обеспечения. Это достигается путем:

организации и доступности данных;

регулирования каналов управления;

структуры прикладного и сервисного кода;

взаимодействия между различными модулями кода.

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

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

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

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

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

2.2 Пакеты (домены) в языке UML

Пакет (package) — основной способ организации элементов модели в языке UML. Каждый пакет владеет всеми своими элементами, т. е. теми элементами, которые включены в него.

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

Рисунок 1 -Графическое изображение пакета в языке UML

Иерархическая вложенность пакетов в среде MS Visio 2002 задается с помощью проводника модели (Model Explorer), в окне которого отображается дерево всех элементов, создаваемой модели приложения (рисунок 2).

Рисунок 2 -Общий вид окна проводника модели в MS Visio 2002

2.3Управление большим доменом

В [7] маленьким считается домен, состоящий из 50 или менее классов. В этом случае он может анализироваться как единичный модуль. Домены с большим количеством объектов должны быть расчленены, для того, чтобы можно было успешно выполнить анализ.

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

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

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

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

3. Разработка домена

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

Рисунок 3 - Итеративный процесс проектирования

Цель выяснения семантики классов и объектов - определить поведение и атрибуты каждой абстракции.

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

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

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

4. Структура приложения

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

Основная программа выполняет следующие три функции:

- создание и инициализацию всех предварительно существующих экземпляров классов;

- ввод или имитацию внешних событий;

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

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

4.1 Способ обработки событий

Все классы приложения подразделяются на активные и пассивные. Активные классы реагируют на события, внешние или возникающие внутри приложения. Кратким и емким определением события, известным в литературе, является следующее: «Событие – это нарушенное однообразие». В аппаратуре события представляются сигналами прерываний. В ОС Windows для представления событий используются сообщения (message). Результатом реагирования на событие является вызов процедуры обработки прерывания. Поэтому в приложении реагирование на события можно реализовать как вызов соответствующего обработчика события. При моделировании динамики поведения реальных объектов необходимо учитывать конечную скорость протекания процессов в этих объектах. Вследствие этого моменты возникновения события и реакции на него разделены во времени. Реализация задержек реакции на некоторое событие требует введение специальных структур данных для задания и хранения информации о событии, обработчик которого необходимо вызвать по истечении времени задержки.

Ниже рассматривается вариант реализации механизма управления событиями для языка реализации C#, входящий в состав Visual Studio.Net. На рисунке 4 приведена структура данных, для задания информации об обработчике некоторого события.

Рисунок 4 - Структура данных описателя события

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

В основной цикл главной части программы должны быть введены операторы просмотра списка описателей события, обнаружения тех, у которых истекло время задержки, и запуск заданного обработчика события. Естественно, что обработчики различных событий будут отличаться именами и составом параметров. Чтобы обеспечить единообразный вызов обработчиков событий объектов различных классов, возможен следующий прием. В состав операций активных классов включается операция диспетчер вызовов (do_it) всех других операций класса. Диспетчер вызовов получает в качестве аргументов имя операции и данные. С помощью оператора выбора по имени выбирается и запускается соответствующая операция. Такой прием позволяет организовать циклическую обработку списка описателей событий.

На рисунке 5 отображается схема вызовов операций.

Рисунок 5 - Схема вызовов при работе основного цикла главной программы

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

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

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

- Imitator - класс, задающий необходимые методы имитации внешних событий с помощью клавиатуры;

- AE - родительский класс для всех активных классов приложения. Данный класс обеспечивает полиморфный вызов методов активных классов.

4.2 Архитектурный класс Form1

Имя класса обусловлено тем, что компилятор проектов UML в MS Visio 2002 автоматически присваивает классу главной программы приложения это имя. На рисунке 6 приведена диаграмма класса. Назначение атрибутов и операций класса дано в таблице 3.

Рисунок 6 - Диаграмма класса Form1

Таблица 3 - Назначение атрибутов и операций класса Form1

Имя атрибута, операции	Назначение
textBox1	Компонента для ввода/вывода текстовых сообщений
button1, button2	Кнопки управления
mainMenu1, menuItem1, menuItem2	Главное меню приложения, два пункта меню
timer1	Экземпляр таймера для отслеживания времен задержек событий
components, label1	Служебные компоненты приложения
imitator	Экземпляр класса Imitator для имитации внешних событий
list_message	Список описателей событий
Archive	Список всех экземпляров всех классов приложения
t	Текущее время модели
Form1()	Конструктор класса
Dispose(), InitializeComponent()	Служебные операции класса
Main()	Операция, реализующая основной цикл главной программы
menuItem2_Click(…)	Операция, вызываемая при активизации пункта меню
Form1_KeyPress(…)	Операция, вызываемая при активизации клавиш на клавиатуре
timer1_Elapsed(…)	Операция, вызываемая по сигналам таймера
Porojdaet(…)	Операция занесения описателя события в список
InitializeObject(…)	Операция создания и инициализации предварительно существующих (объектов) экземпляров классов

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

4.3 Архитектурный класс Imitator

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

Рисунок 7 - Диаграмма класса Imitator

При инициализации объектов выполняется заполнение списка имитируемых событий с помощью операции Add_event(…) класса Imitator.

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

4.4 Архитектурный класс AE

Диаграмма класса приведена на рисунке 8. В состав атрибутов данного класса включаются общие атрибуты для всех активных классов приложения. Атрибут id предназначен для хранения строки с именем объекта, которое может быть выведено на экран. Атрибут extern_event является списком, который создается при инициализации объекта (экземпляра) класса и содержит имена внешних событий связанных с данным классом. Используется при инициализации объектов класса для занесения внешних событий, связанных с объектом, в список имитатора.

Рисунок 8 - Диаграмма класса AE

Все операции данного класса объявлены как виртуальные. В классах наследниках эти операции могут перекрываться. Обязательно в классах наследниках должна быть определена операция диспетчера вызовов (do_it) других операций класса. Виртуальная операция Out_param(…) предназначена для задания операции вывода текстовых сообщений о значениях атрибутов объекта.

5. Разработка прикладного домена

Рассмотрение данного вопроса целесообразно вести на примере разработки домена. В качестве предметной среды выбрана область цифровых логических схем. На рисунке 9 приведен фрагмент цифровой логической схемы. Необходимо для заданного фрагмента разработать статическую модель прикладной области, определить состав событий и операций обработки событий, для языка C# разработать исходные тексты операций классов и сгенерировать проект для MS Visual Studio.Net.

Рисунок 9 - Фрагмент цифровой логической схемы

5.1 Статическая модель прикладного домена

Разработка статической (информационной) модели прикладной области базируется на результатах объектно-ориентированного анализа (ООА). ООА может быть проведен различными способами, например, с помощью классической категоризации [7]. Должны быть выполнены следующие работы: выделены и описаны классы и их атрибуты; определены и описаны связи между классами; построена диаграмма статической модели. Описание выделенных классов оформляется в виде таблицы 4.

Таблица 4 - Описание классов

Имя класса	Представители класса	Описание
And	Элементы D1, D3	Логический элемент, выполняющий логическую операцию «И» (конъюнкцию). Значения входных сигналов изменяются асинхронно. Имеет два устойчивых состояния: высокий уровень выходного напряжения – 1 и низкий - 0
Not	Элементы D2, D4	Логический элемент, выполняющий логическую операцию «НЕ» (инверсия, отрицание). Значения входных сигналов изменяются асинхронно. Имеет два устойчивых состояния: высокий уровень выходного напряжения – 1 и низкий – 0

Классы And и Not являются активными классами.

Для каждого класса выделяются и описываются его атрибуты (таблица 5).

Таблица 5 - Описание атрибутов класса And

Имя атрибута	Содержательное описание	Доп. значения
vx1	Значение сигнала на первом входе	[0; 1]
vx2	Значение сигнала на втором входе	[0; 1]
vyx	Значение сигнала на выходе	[0; 1]
tz	Время задержки логического элемента	1 – 20 нс

Таблица 6 - Описание атрибутов класса Not

Имя атрибута	Содержательное описание	Доп. значения
vx	Значение сигнала на входе	[0; 1]
vyx	Значение сигнала на выходе	[0; 1]
tz	Время задержки логического элемента	1 – 20 нс

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

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

Рисунок 10 - Предварительная статическая модель

Следует иметь в виду, что при генерации кода в состав атрибутов класса And будет введен еще один: имя – taker; тип – Not. То есть, имя помеченного стрелкой конца связи добавляется в качестве атрибута к классу от которого исходит стрелка.

5.2 Описание событий

Событие – это нарушенное однообразие. Однообразие в схеме нарушается, если происходит изменение какого-либо сигнала. В цифровых схемах возможны два изменение сигнала: из 0 в 1 и обратно. То есть, с каждым входом и выходом элемента схемы связаны два события. Каждому событию необходимо присвоить имя и определить другие данные. Описание событий для объекта and класса And и объекта not класса Not приведены в таблицах 7,8.

Таблица 7 -Описание событий объекта and класса And

Имя события	Описание	Источник	Приемник	Данные
vx10_1	Изменение сигнала на входе 1 из 0 в 1	Внеш. схема	Объект and	нет
vx11_0	Изменение сигнала на входе 1 из 1 в 0	Внеш. схема	Объект and	нет
vx20_1	Изменение сигнала на входе 2 из 0 в 1	Внеш. схема	Объект and	нет
vx21_0	Изменение сигнала на входе 2 из 1 в 0	Внеш. схема	Объект and	нет
vyx0_1	Изменение сигнала на выходе из 0 в 1	Объект and	Объект and	нет
vyx1_0	Изменение сигнала на выходе из 1 в 0	Объект and	Объект and	нет

Таблица 8 - Описание событий объекта not класса Not

Имя события	Описание	Источник	Приемник	Данные
vx0_1	Изменение сигнала на входе из 0 в 1	Объект and	Объект not	нет
vx1_0	Изменение сигнала на входе из 1 в 0	Объект and	Объект not	нет
vyx0_1	Изменение сигнала на выходе из 0 в 1	Объект not	Объект not	нет
vyx1_0	Изменение сигнала на выходе из 1 в 0	Объект not	Объект not	нет

5.3 Реагирование объектов классов на события

Простейший способ реагирования на события сопоставить каждому событию операцию класса, причем в качестве имен операций использовать имена событий. Для задания взаимодействия объектов по событиям можно использовать диаграмму последовательностей языка UML. На диаграмме последовательностей изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательностей ключевым моментом является динамика взаимодействия объектов во времени. При этом диаграмма последовательностей имеет как бы два измерения. Одно — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записывается имя объекта. На рисунке 11 приведена диаграмма последовательностей для описанных событий и объектов. В качестве источника внешних событий на диаграмме приведен объект класса Imitator. Аргумент main_prog задает ссылку на объект главной программы, с помощью которого можно обращаться к операциям, определенным в главной программе.

Рисунок 11 - Диаграмма последовательностей

На диаграмме отражается также взаимосвязь событий – изменение выходного сигнала какого-либо объекта класса And приведет к возникновению события, связанного с изменением входного сигнала соответствующего объекта класса Not (связки событий vyx0_1(объект and) + vx0_1(объект not) и vyx1_0(объект and) + vx1_0(объект not)).

Помощь в выявлении событий предметной среды может оказать анализ состояний активных классов. Для представления активного класса используется модель конечного автомата Мура [7]. В языке UML для анализа и задания конечных автоматов используются диаграммы состояний (Statechart diagram) и диаграммы активности (Activity diagram). Например, модель активности класса Not может иметь вид, представленный на рисунке 12.

Рисунок 12 - Модель активности класса Not

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

Рисунок 13 - Уточненная статическая модель

5.4 Исходные тексты операций обработки событий

Для рассматриваемого примера семантика операций обработки событий определяется тем, что сигнал об изменении значения сигнала должен привести к изменению значения соответствующего атрибута объекта. При этом должны выявляться сочетания входных сигналов, требующих изменения значения выходного сигнала. В этом случае необходимо обеспечить задержку события изменения выходного сигнала на время задержки логического элемента. Для этого предназначена операция главной программы Porojdaet(…) (порождения нового события). Ниже приводятся исходные тесты некоторых операций класса And на языке C#.

// Изменение сигнала на входе 1 And из 0 в 1----------------------------

public void vx10_1(Form1 main_prog)

{

this.vx1 = 1;

if((this.vx2==1)&&( this.vyx==0))

{

main_prog.Porojdaet(this,"vyx0_1", this.tz, null);

}

// Изменение сигнала на выходе And из 0 в 1----------------------------

public void vyx0_1(Form1 main_prog)

{

this.vyx = 1;

main_prog.Porojdaet(taker,"vx0_1",0,null);

// здесь taker – адрес объекта Not, связанного с данным объектом And

// время задержки задано = 0

}

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

5.5 Диспетчер вызовов операций класса

Данная операция, вводимая во все активные классы, предназначена для унификации вызова различных операций с различным количеством аргументов различных объектов. Основой для реализации этой операции является оператор выбора (switch). Выбор необходимой для запуска операции выполняется по имени операции, которое передается через аргумент диспетчера. Пример исходного текста диспетчера вызовов операций класса приведен ниже.

public override void do_it(string name_process,

ArrayList data,

Form1 main_prog)

{

switch(name_process)

{

case "vx11_0": vx11_0(main_prog);

break;

case "vx10_1": vx10_1(main_prog);

break;

case "vx21_0": vx21_0(main_prog);

break;

case "vx20_1": vx20_1(main_prog);

break;

case "vyx1_0": vyx1_0(main_prog);

break;

case "vyx0_1": vyx0_1(main_prog);

break;

}

6. Организация процесса проектирования

Г. Буч [12] выделяет в процессе проектирования программного приложения микро и макропроцессы.

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

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

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

Макропроцесс обычно включает следующие действия:

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

- разработка модели требуемого поведения системы (анализ);

- создание архитектуры для реализации (проектирование);

- итеративное выполнение реализации (эволюция);

- управление эволюцией продукта в ходе эксплуатации (сопровождение).

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

Описание основных этапов разработки приложения дано в таблице 9.

Таблица 9 - Основные этапы разработки приложения

Наименование этапа	Основные действия	Результаты
Выявление сущности требований к программному продукту (концептуализация)	1) определить цели апробации концепции и критерии того, что считать благополучным исходом; 2) собрать подходящую команду для разработки прототипа; 3) оценить готовый прототип и принять ясное решение о проектировании конечного продукта или о дальнейшем исследовании. Решение о начале разработки конечного продукта нужно принимать с разумным учетом потенциального риска, выявленного при апробации концепции.	Первичными продуктами концептуализации являются прототипы системы.
Разработка модели требуемого поведения системы (анализ)	1) идентифицировать основные функциональные точки системы и, если возможно, сгруппировать функционально связанные виды поведения. Рассмотреть возможность создания иерархии функций, в которой высшие функции вытекают из низших. 2) для каждого представляющего интерес набора функциональных точек сделать раскадровку сценария, используя технику анализа поведения. Когда прояснится семантика сценариев, следует документировать их, используя диаграммы объектов, которые иллюстрируют объекты. Приложить описание событий, происходящих при выполнении сценария, и порядок выполняемых в результате действий. Кроме того, необходимо перечислить все предположения, ограничения и показатели эффективности для каждого сценария; 3) если необходимо, сделать описания поведения системы в исключительных ситуациях; 4) для объектов с особо важным жизненным циклом описать диаграммы состояний (построить конечный автомат); 5) найти в сценариях повторяющиеся шаблоны и выразить их в терминах более абстрактных обобщенных сценариев или в терминах диаграмм классов, показывающих связи между ключевыми абстракциями. 6) внести изменения в словарь данных; включить в него новые классы и объекты, выявленные для каждого сценария, вместе с описанием их ролей и обязанностей.	Результатом анализа должно быть описание назначения системы, сопровождаемое характеристиками производительности и перечислением требуемых ресурсов Побочным результатом анализа будет оценка риска: выявление опасных мест, которые могут повлиять на процесс проектирования.
Создание архитектуры для реализации (проектирование). Архитектурное планирование - охватывает логическую декомпозицию, состоящую в группировании классов, и физическую декомпозицию, состоящую в разбиении на модули и назначении заданий процессорам	1) рассмотреть группирование функциональных точек (найденных в анализе) и распределить их по слоям и разделам архитектуры. Функции, базирующиеся одна на другой должны попасть в разные слои; функции, сотрудничающие между собой для обеспечения требуемого поведения системы на данном уровне абстракции должны попасть в разделы системы, представляющие услуги на этом уровне; 2) проверить архитектуру созданием действующих релизов, которые частично удовлетворяют семантике нескольких важнейших сценариев, предоставленных анализом; 3) оценить достоинства и недостатки архитектуры. Определить риск изменения каждого ключевого архитектурного интерфейса, чтобы можно было заранее распределить ресурсы при эволюции системы.	Диаграммы классов и объектов.
Создание архитектуры для реализации (проектирование). Тактическое проектирование состоит в принятии решений о множестве общих приемов	1) перечислить все случаи, когда нужно следовать единым общим приемам. Некоторые из них окажутся фундаментальными, независимыми от предметной области, например, управление памятью, обработка ошибок и т.д. Другие будут специфичны для данной области и будут содержать свойственные этой области идиомы и механизмы, такие, как принципы управления системами реального времени или транзакциями и базами данных в информационных системах; 2) для каждого приема составить сценарий, описывающий его семантику. Затем выразить ее в виде исполнимого прототипа, который может быть уточнен и представлен инструментально; 3) документировать каждый принцип и распространить полученные документы, чтобы обеспечить единое архитектурное видение.	Диаграммы классов и объектов Описания семантики. Сценарии
Создание архитектуры для реализации (проектирование). Программные релизы закладывают основы архитектурной эволюции системы.	1) полученные в результате анализа сценарии упорядочить от основных к второстепенным. Приоритетность сценариев лучше выяснить вместе с экспертом в предметной области, аналитиком, архитектором и контролером качества; 2) распределить функциональные точки по релизам так, чтобы последний релиз в серии представлял результирующую систему; 3) определить цели и расписание релизов так, чтобы дать время на разработку и синхронизировать релизы с другими действиями, например, с разработкой документации и полевыми испытаниями; 4) начать планирование задач, учитывая критические места проекта и ресурсы, отведенные на выпуск каждого релиза.	Программные релизы. План, в котором определены расписание работ, задачи коллектива и оценка риска.
Итеративное выполнение реализации (эволюция);	1) определить функциональные точки, которые попадут в новый релиз, и области наивысшего риска, особенно те, которые были выявлены еще при эволюции предыдущего релиза; 2) распределить задачи по релизам среди членов команды и начать новый микропроцесс. Контролировать микропроцесс, просматривая проект, и проверять состояние дел в важных промежуточных этапах с интервалами от нескольких дней до двух недель; 3) когда потребуется понять семантику требуемого поведения системы, поручить разработчикам сделать прототип поведения. Четко установить назначение каждого прототипа и определить критерии готовности. После завершения решить, как включить результаты прототипирования в этот или последующие релизы; 4) завершить микропроцесс интеграцией и очередным действующим релизом.	Серия исполняемых релизов, представляющих итеративные усовершенствования изначальной архитектурной модели. Описание поведения, которое используется для исследования альтернативных подходов и дальнейшего анализа системы
Управление эволюцией продукта в ходе эксплуатации (сопровождение).	1) упорядочить по приоритетам предложения о крупных изменениях и сообщения об ошибках, связанных с системными проблемами, и оценить стоимость переработки; 2) составить список этих изменений и принять их за функциональные точки в дальнейшей эволюции; 3) если позволяют ресурсы, запланировать в следующем релизе менее интенсивные, более локализованные улучшения; 4) приступить к разработке следующего эволюционного релиза программы.	Список новых заданий: обнаруженные дефекты и новые требования.

Наименование этапа

Основные действия

Результаты

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

1) определить цели апробации концепции и критерии того, что считать благополучным исходом;

2) собрать подходящую команду для разработки прототипа;

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

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

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

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

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

3) если необходимо, сделать описания поведения системы в исключительных ситуациях;

4) для объектов с особо важным жизненным циклом описать диаграммы состояний (построить конечный автомат);

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

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

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

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

Создание архитектуры для реализации (проектирование).

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

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

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

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

Диаграммы классов и объектов.

Создание архитектуры для реализации (проектирование).

Тактическое проектирование состоит в принятии решений о множестве общих приемов

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

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

3) документировать каждый принцип и распространить полученные документы, чтобы обеспечить единое архитектурное видение.

Диаграммы классов и объектов

Описания семантики. Сценарии

Создание архитектуры для реализации (проектирование).

Программные релизы закладывают основы архитектурной эволюции системы.

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

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

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

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

Программные релизы.

План, в котором определены расписание работ, задачи коллектива и оценка риска.

Итеративное выполнение реализации (эволюция);

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

2) распределить задачи по релизам среди членов команды и начать новый микропроцесс. Контролировать микропроцесс, просматривая проект, и проверять состояние дел в важных промежуточных этапах с интервалами от нескольких дней до двух недель;

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

4) завершить микропроцесс интеграцией и очередным действующим релизом.

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

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

Управление эволюцией продукта в ходе эксплуатации (сопровождение).

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

2) составить список этих изменений и принять их за функциональные точки в дальнейшей эволюции;

3) если позволяют ресурсы, запланировать в следующем релизе менее интенсивные, более локализованные улучшения;

4) приступить к разработке следующего эволюционного релиза программы.

Список новых заданий: обнаруженные дефекты и новые требования.

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

Для анализа рекомендуется использовать технологию CRC – карточек. CRC обозначает Class – Responsibilities - Collaborators (Класс/ Ответственности/ Участники). Это простой и замечательно эффективный способ анализа сценариев. Карты CRC впервые предложили Бек и Каннингхэм для обучения объектно-ориентированному программированию, но такие карточки оказались отличным инструментом для общения разработчиков между собой.

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

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

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

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

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

Заключение

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

Использованы источники

1. Уоссермен Ф., Нейрокомпьютерная техника, - М.,Мир, 1992.

2. Горбань А.Н. Обучение нейронных сетей. - М.: ПараГраф, 1990

3. Горбань А.Н., Россиев Д.А. Нейронные сети на персональном компьютере. - Новосибирск: Наука, 1996

4. Gilev S.E., Gorban A.N., Mirkes E.M. Several methods for accelerating the training process of neural networks in pattern recognition // Adv. Modelling & Analysis, A. AMSE Press. – 1992. – Vol.12, N4. – P.29-53

5. С. Короткий. Нейронные сети: алгоритм обратного распространения.

6. С. Короткий, Нейронные сети: обучение без учителя. Artificial Neural Networks: Concepts and Theory, IEEE Computer Society Press, 1992.

7. Заенцев И. В. Нейронные сети: основные модели./Учебное пособие к курсу "Нейронные сети" для студентов 5 курса магистратуры к. электроники физического ф-та Воронежского Государственного университета – e-mail: ivz@ivz.vrn.ru

8. Лорьер Ж.Л. Системы искусственного интеллекта. – М.: Мир, 1991. – 568 с.

9. Искусственный интеллект. – В 3-х кн. Кн. 2. Модели и методы: Справочник/ Под ред. Поспелова Д.А. – М.: Радио и связь, 1990. – 304 с.

10. Бек Л. Введение в системное программирование.- М.: Мир, 1988.

11. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. – К.: Диалектика, 1993. – 240 с.

12. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. - http://www.nexus.odessa.ua/files/books/booch.

13. Аджиев В. MS: корпоративная культура разработки ПО – http:// www.osp.ru

14. Трофимов С.А. Case-технологии. Практическая работа в Rational Rose. – М.: ЗАО «Издательство БИНОМ», 2001.

15. Новичков А. Эффективная разработка программного обеспечения с использованием технологий и инструментов компании RATIONAL. – http://www.interface.ru

16. Selic B., Rumbaugh J. Использование UML при моделировании сложных систем реального времени. - http://www.interface.ru.