СОДЕРЖАНИЕ
Введение1. Обзорпроцесса проектирования1.1 Характерныечерты удачных проектов2. Понятиедомена2.1 Типыдоменов2.2 Пакеты(домены) в языке UML 2.3 Управлениебольшим доменом3. Разработкадомена 4. Структураприложения 4.1.Способобработки событий4.2 Архитектурныйкласс Form4.3 Архитектурныйкласс Imitator 4.4 Архитектурныйкласс AE 5. Разработкаприкладного домена 5.1 Статическаямодель прикладного домена 5.2 Описаниесобытий 5.3 Реагированиеобъектов классов на события 5.4 Исходныетексты операций обработки событий 5.5 Диспетчервызовов операций класса 6. Организацияпроцесса проектирования
Заключение
Использованы источники
Введение
Тема курсовой работы «Основные этапыобъектно-ориентированного проектирования».
В современном мире прогресспроизводительности программиста достигается в тех случаях, когда частьинтеллектуальной нагрузки берут на себя компьютеры. Одним из способовдостигнуть максимального прогресса в этой области, является «искусственныйинтеллект», когда компьютер берет на себя не только однотипные,многократно повторяющиеся операции, но и сам сможет обучаться.
Целью работы изучение решениявопросов в области автоматизации сложноформализуемых задач. Задачей работыявляется приобретение знаний о фундаментальных алгоритмах, применяемых припостроении систем искусственного интеллекта, а также методов разработкипрограммных приложений, реализующих эти системы.
Принципиальное отличиеинтеллектуальных систем от любых других систем автоматизации заключается вналичии базы знаний о предметной среде, в которой решается задача. Неинтеллектуальнаясистема при отсутствии каких-либо входных данных прекращает решение задачи,интеллектуальная же система недостающие данные извлекает из базы знаний ирешение выполняет.
По А.Н. Колмогорову, любаяматериальная система, с которой можно достаточно долго обсуждать проблемынауки, литературы и искусства, обладает интеллектом. Такое определениепоказывает, что данная дисциплина находится во взаимосвязи практически со всемиучебными дисциплинами. Тем не менее, следует подчеркнуть связи со следующими дисциплинами:«Программирование», «Математический анализ», «Линейная алгебра и аналитическаягеометрия», «Дискретная математика», «Логическое программирование», «Экспертныесистемы», «Интерфейсы интеллектуальных систем».
Работа посвящена вопросам объектно-ориентированногопроектирования интеллектуальных систем. В качестве основного инструментаиспользуется унифицированный язык моделирования UML.
1. Обзорпроцесса проектирования
Процесс объектно-ориентированногоанализа и проектирования не сводится к сумме рецептов, однако он определендостаточно хорошо, чтобы быть предсказуемым и воспроизводимым в умелых руках.
Объектно-ориентированный анализ ипроектирование — метод, использующий объектную декомпозицию;объектно-ориентированный подход имеет свою систему условных обозначений ипредлагает богатый набор логических и физических моделей, с помощью которыхможно получить представление о различных аспектах рассматриваемой системы.1.1 Характерные черты удачных проектов
Удачным проектом называется тот,который удовлетворил ожидания заказчика, уложился во временные и финансовыерамки, легко поддается изменению и адаптации. Пользуясь этим критерием,рассматриваются следующие две черты, которые оказались общими для всехизвестных удачных проектов:
— ясное представление об архитектуресоздаваемой системы;
— хорошо организованный итеративноразвивающийся процесс работы над проектом.
Можно выделить ряд этапов, которыеприсутствуют в процессе протирования и перечень которых дан в таблице 1.
Таблица 1 -Основные этапыпроцесса проектированияЭтап Результаты этапы Пред проектное обследование, разработка технического задания Отчеты, техническая документация, техническое задание, результаты обследования, прототипы системы Разбиение большой системы на домены (пакеты)
— диаграмма доменов (пакетов);
— описание доменов (пакетов);
— описание связей (мостов) между доменами (пакетами); Разбиение большого домена (пакета) на поддомены
— диаграмма поддоменов;
— описание поддоменов; Разработка домена
— статическая модель домена — диаграмма классов;
— модели состояний (диаграммы активности, диаграммы состояний, диаграммы взаимодействия, диаграммы последовательностей);
— описания моделей;
2.Понятие домена
При создании приложения разработчик,как правило, должен рассматривать ряд насыщенных предметных областей:собственно приложение, интерфейс с внешними аппаратными средствами, интерфейспользователя, управление данными, утилиты, операционную систему, языки программированияи среду разработки. Поэтому необходима стратегия для работы с этими предметнымиобластями. Рассматриваемая стратегия опирается на понятие домена или пакета (package).
Домен (package)– это отдельный реальный,гипотетический или абстрактный мир, населенный отчетливым набором классов,которые ведут себя в соответствии с характерными для домена правилами и линиямиповедения. Например, домен «Пользовательский интерфейс», домен «Управлениелабораторией». Аналогами домена (пакета) в языках программирования могут быть:язык C# — пространство имен (namespace); язык Delphi – модуль (unit), задаваемый в предложении uses; язык C++ — файл, подключаемый с помощью #include.
При определении классов и доменовдолжны соблюдаться следующие правила:
— любой класс определяется только водном домене;
— количество классов в домене должнобыть не менее одного.2.1Типы доменов
В соответствии с той ролью, которуюкаждый домен играет в законченной системе, домены подразделяются на:
— прикладные;
— сервисные;
— архитектурные;
— реализации.
Прикладной домен – это предметнаяобласть с точки зрения конечного пользователя. Она обычно рассматривается вконтексте анализа требований: что надо делать пользователю данного приложения.Для каждого проекта существует один прикладной домен.
Сервисный домен обеспечивает общиемеханизмы и сервисные функции, необходимые для поддержки прикладного домена. Втаблице 2 приведенытипичные сервисные домены.
Таблица 2 — Типичные сервисные доменыДомен Описание Процесс ввода — вывода Обеспечивает организацию сигналов, составляющих интерфейс с оборудованием (считывает данные, управляет силовыми приводами и т.п.) Сигналы Получает сообщения о вызывающих беспокойство условиях и аномалиях. Представляет эти сообщения оператору для принятия соответствующих мер. Пользовательский интерфейс Формирует и обновляет изображение на экране. Взаимодействует с оператором. Гистограммирование Отображает данные, подготавливает отчеты. Регистрация тенденций Записывает последовательные значения выбранных атрибутов в течение определенного периода времени, отображает в виде графиков тенденции в изменении значений. История Запись и сохранение всех инцидентов с указанием времени на протяжении всего выполнения производственного процесса. Архивирование данных Создает с указанием времени долговечный снимок определенных наборов данных.
Архитектурный домен обеспечиваетобщие механизмы и структуры для управления данными и управления приложением какединым целым. Классы в архитектурном домене представляют абстрактные структурыданных и модули кода. Архитектурный домен служит ряду целей:
— обеспечение однородности структурыпрограммного обеспечения. Это достигается путем:
1) организации идоступности данных;
2) регулированияканалов управления;
3) структурыприкладного и сервисного кода;
4) взаимодействиямежду различными модулями кода.
В любом случае цель заключается втом, чтобы ограничить сложность системы использованием стандартных структур испособов выполнения многократно используемых функций;
— управление инициализацией изакрытием системы, переход к резервной при отказах;
— обеспечение мобильности – вархитектурный домен должны выноситься все процедуры и функции, зависящие отконкретной платформы. В случае переноса приложения на другую платформупеределке будет подвергаться только архитектурный домен;
— выполнение измерений в работающейсистеме – реализуется путем добавления специальных контрольных точек.
Домены реализации включают в себяязыки программирования, операционные системы и общие библиотеки объектов.Обеспечивает концептуальные сущности, в которых будет реализована вся система.2.2 Пакеты (домены) в языке UML
Пакет (package) — основной способ организацииэлементов модели в языке UML.Каждый пакет владеет всеми своими элементами, т. е. теми элементами, которыевключены в него.
Для графического изображения пакетовна диаграммах применяется специальный графический символ — большойпрямоугольник с небольшим прямоугольником, присоединенным к левой части верхнейстороны первого. Внутри большого прямоугольника может записываться информация,относящаяся к данному пакету. Если такой информации нет, то внутри большогопрямоугольника записывается имя пакета, которое должно быть уникальным впределах рассматриваемой модели (рисунок 1,а). Если же такая информация имеется, то имя пакета записывается в верхнеммаленьком прямоугольнике (рисунок 1,б).
/>
Рисунок1 -Графическое изображение пакета в языке UML
Иерархическая вложенность пакетов всреде MS Visio 2002 задается с помощью проводника модели (Model Explorer), в окне которого отображаетсядерево всех элементов, создаваемой модели приложения (рисунок 2).
/>
Рисунок2 -Общий вид окна проводника модели в MS Visio 20022.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(Form1main_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(Form1main_prog)
{
this.vyx = 1;
main_prog.Porojdaet(taker,«vx0_1»,0,null);
// здесь taker– адрес объекта Not, связанного с данным объектом And
// время задержки задано = 0
}
Аналогичным образом составляютсяисходные тексты других обработчиков событий.
5.5 Диспетчер вызовов операций класса
Данная операция, вводимая во всеактивные классы, предназначена для унификации вызова различных операций сразличным количеством аргументов различных объектов. Основой для реализацииэтой операции является оператор выбора (switch). Выбор необходимой для запускаоперации выполняется по имени операции, которое передается через аргументдиспетчера. Пример исходного текста диспетчера вызовов операций класса приведенниже.
publicoverridevoiddo_it(stringname_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) приступить к разработке следующего эволюционного релиза программы. Список новых заданий: обнаруженные дефекты и новые требования.
Функциональные точки обозначаютвидимые извне и проверяемые элементы поведения системы. С точки зренияконечного пользователя, функциональная точка представляет некоторое простейшеедействие системы в ответ на некоторое событие.
Для анализа рекомендуетсяиспользовать технологию 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 neuralnetworks in pattern recognition // Adv. Modelling & Analysis, A. AMSEPress. – 1992. – Vol.12, N4. – P.29-53
5. С. Короткий. Нейронныесети: алгоритм обратного распространения.
6. С. Короткий, Нейронные сети: обучение без учителя. Artificial NeuralNetworks: 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. Буч Г. Объектно-ориентированный анализ ипроектирование с примерами приложений на С++. — www.nexus.odessa.ua/files/books/booch.
13. Аджиев В. MS: корпоративная культура разработки ПО – http:// www.osp.ru
14. Трофимов С.А. Case-технологии. Практическая работа в Rational Rose. – М.: ЗАО «Издательство БИНОМ», 2001.
15. Новичков А. Эффективная разработка программногообеспечения с использованием технологий и инструментов компании RATIONAL. – www.interface.ru
16. Selic B., Rumbaugh J. Использование UML при моделировании сложных систем реального времени. — www.interface.ru.