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

БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Основные этапы объектно-ориентированного проектирования

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

СОДЕРЖАНИЕ

Введение

Заключение

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- сервисные;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Простейший способ реагирования на события сопоставить каждому событию операцию класса, причем в качестве имен операций использовать имена событий. Для задания взаимодействия объектов по событиям можно использовать диаграмму последовательностей языка 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 - Уточненная статическая модель

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

}

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

Данная операция, вводимая во все активные классы, предназначена для унификации вызова различных операций с различным количеством аргументов различных объектов. Основой для реализации этой операции является оператор выбора (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;

}

}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для анализа рекомендуется использовать технологию 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.