CC BY
51
этой задачи лежит метод предикатно-логического синтеза, суть которого заключается в следующем.
Представим отношения Ri; i = \m в виде
Ri = Hi0 < • < и0п)}- (14)
Здесь ii,...,in есть i-яперестановка целых чисел от 1 до n. Для i-й ситуации (14) выписываются все 0,5n(n+1) бинарных отношений порядка
и(й) <и(п)’...’и(ч-0 <и(ч)
Каждому неравенству u(i)<u(j) ставят в соответствие двоичный предикат (7). Затем вычисляют многоместные РП по алгоритму (11).
Каждому многоместному РП (11) ставят в соответствие предметную переменную и в результате получается математическая модель (13).
По математической модели (13) строится ее топологическая модель — электрическая схема НС с КНКР, поскольку в ИАРП между этими моделями существует прямая однозначная связь, а синтез осуществляется в элементном базисе (рангерах), адекватном теории синтеза НС [2].
Заключение
Многоместные ПФ (13) при заданных отношениях (14) воспроизводят правило (алгоритм) идентификации предметных переменных:
z(i)
y(i)| r(i) = k;
0 r(i) Ф k.
(15)
Здесь ke{1,2,...,n| есть заданная пороговая константа. Мощность правила (15) равна единице, так как вероятность ошибки второго рода
P=p{z(i) ф y(i) | r(i) = k] =0.
Вероятность ошибки первого рода определяется, согласно [2], как
а = P{z(i) = y(i)|r(i) Ф kj = (m +1) п.
Полученные результаты подтверждают эффективность применения ИАРП: алгоритм (15) стабилизируют параметры а и р независимо от вида и параметров распределений предикатных переменных.
Литература: 1. Брюс Р. Матричные методы цифровой обработки случайных сигналов. М.: Мир, 1980. 648 с. 2. Устройства ранговой обработки информации / В. Ю. Лапий, А Я. Калюжный, Л. Г. Красный. Киев: Техніка, 1986. 120 с.
Поступила в редколлегию 24.07.2001
Рецензент: д-р физ.-мат. наук, проф. Проценко И.Е.
Полонский Александр Дмитриевич, канд. техн. наук, доцент Сумского государственного университета. Научные интересы: инвариантные системы. Адрес: Украина, 40007, Сумы, ул. Римского-Корсакова, 2, тел. 27-79-75.
УДК 519.7;681.3
ИДЕНТИФИКАЦИЯ КЛАССОВ -ПОИСК ГРААЛЯ?
КОВАЛЕВ С.А._____________________________
Описывается принцип разделения обязанностей. Обсуждается необходимость построения изначально качественных систем, а также обсуждаются принципы платонизма, классификации, применяемые для моделирования предметной области. Рассматриваются направления исследования.
На одной из конференций программистам был задан вопрос: “Какими правилами вы руководствуетесь при определении классов и объектов?”
Страуструп, разработчик языка C++, ответил: “Это как поиск святого Грааля. Не существует панацеи”.
Габриель, один из разработчиков CLOS, сказал “Это вопрос, на который нет простого ответа. Я просто пробую” [1, с.147].
Основным подходом в бизнесе к решению любой поставленной задачи является создание организационно-технической системы. Важная часть этой системы — программное обеспечение (ПО). На современном этапе ПО характеризуется высокой степенью трудоемкости. Часто оказывается, что ПО является самым сложным и самым дорогосто-
ящим компонентом всей организационно-технической системы. Более того, сохраняется тенденция роста размера ПО в пропорции относительно технической части (в 1955 году соотношение составляло 15:85, а в 1985 - 85:15 [2,с.19]).
Чтобы выяснить источники связанных с разработкой ПО проблем, проследим историю развития философии1 программирования до появления объектно-ориентированной парадигмы [3,4 ].
1 Слово “философия” (впрочем, как и использование термина “парадигма”) по отношению к программированию многим может показаться неуместным и даже вульгарным. Тем не менее, к программированию как к особой ветви производства и науки, стоящей между точной технологией и творческим искусством, эти термины применяются. Так же широко употребляются и в той же мере правомерны понятия “стиля программирования”, “собственный подход к решению технических задач”, “хорошая” или “плохая” программа. К этому же подходит англоязычный термин “best practices” (“лучшие практики” — в авторском переводе), описывающий накопленный опыт работы с конкретными технологическими решениями, эмпирические находки и открытия ведущих (и, соответственно, успешных) практиков этой отрасли. Все это, а также само умонастроение и многие невербализуемые знания и навыки обобщаются в понятии “философия программирования”. Набор методов, методик, теорий и отдельных теоретических постулатов, а также выражение всего этого в промышленных и международных стандартах автор предлагает называть “парадигмой программирования”. (Авторское понимание объектно-ориентированной парадигмы программирования смотри в [3]).
РИ, 2002, № 1
119
В самом начале развития вычислительной техники программы разрабатывались специально для конкретного задания — ad hoc — специально для данного случая. При таком подходе (назовем его парадигмой “ad hoc”) каждая программная система была “уникальным, индивидуальным продуктом, требующим для своего создания и сопровождения существенных интеллектуальных усилий” [4, с.2]. Тогда еще даже не существовало понятий повторного использования и взаимозаменяемости отдельных частей или, например, формального подхода к проектированию. Процессы управления такими системами, их модификации, расширения, обобщаемые понятием эволюции программной системы, представляли определенные трудности (которые, тем не менее, периодически возникают для каждой парадигмы программирования и обобщаются в концепции “software crisis” — кризис программного обеспечения). При каждом изменении получается новая система, еще более сложная, чем исходная. При этом проблема остается актуальной даже в системах следующего поколения — системах, ориентированных на данные (так называемые “data-driven”). Смотри, например [5, с.7]: “Любые изменения требуют значительных затрат, причем, что самое печальное, именно перспектива подобных затрат во многих случаях полностью блокирует возможность каких-либо изменений!”
В 60-х годах усилия по созданию более простого в управлении ПО привели к первому существенному пересмотру “философии” его развития. Метод ad hoc уступил место другому подходу, получившему название каскадного. Другое название этого подхода — последовательный или следующий “модели водопада” (“waterfall model”) отражает последовательность процесса создания ПО через несколько формально полностью законченных фаз. Например, фаза анализа требований должна быть завершена до начала фазы конструирования. Последовательный подход к развитию ПО часто ассоциируется с многочисленными томами документации. Связано это с неоправдавшим себя мнением о возможности полностью завершить каждый этап и, соответственно, зафиксировать его результаты в итоговых для этапа документах. Однако, несмотря на такую формализацию, большие, сложные системы по-прежнему не укладывались в сроки (on time), в бюджеты (on budget), страдало их качество (quality) и не удовлетворяли все запросы пользователей (requirements).
Другое коренное изменение “философии” развития ПО приходится на 70-е годы. Том ДеМарко в своей книге “Structured Analysis and System Specification” ввел понятие построения ПО на основе модели. Этот ученый утверждал, что подход, позволяющий добиться успеха при построении больших и сложных технических систем, подходит и для программной индустрии. Вместо чертежей предлагалось использовать модели. Вначале это были построения на бумаге, далее пришли к необходимости автоматизировать процесс — так возникла идея CASE-средств. В 70-х такой “отказ от
простого “разбиения кода” и провозглашения успеха в момент, когда программа уже создавала иллюзию корректной работы” [4, с.2], был решительным шагом вперед. Влияние этой плодотворной идеи заметно до сих пор практически в любой методологии создания программных систем, которые даже можно классифицировать по способу и виду построения этих моделей.
Другая эвристика, нашедшая применение в большинстве основанных на моделях методологий построения ПО, — принцип разделения обязанностей[4]. Основная идея заключается в разделении всех строящихся моделей на два больших типа: модель анализа и модель разработчика (таблица).
Модель анализа Модель проектирования
Выражает существенные или «логические» требования к ПО Выражает основанные на реализации или «физические» требования
Описывает, что именно система будет делать Определяет, как отдельная система будет построена
Не зависит от конкретных подходов и технологий реализации Зависит от контекста реализации (платформа, сеть, операционная система, база данных, пользовательский интерфейс и т.д.)
Создают те, кто обладает глубокими знаниями в предметной области (эксперты) Строят те, кто обладает глубокими знаниями среды реализации
Служит средством общения между покупателями, пользователями и разработчиками Выступает средством коммуникации между разработчиками, программистами, экспертами и пр.
Необходимо вспомнить о стандарте и языке проектирования, моделирования, используемом для взаимодействия между участниками процесса разработки, заказчиками и др. — о UML [6]. На сегодняшний день практически все модели строятся на его основе.
Отчего же возникают описанные выше трудности? Почему постоянно приходится придумывать новые, усовершенствовать существующие методы и методики построения программных систем, которые и выражаются в сменяющих друг друга парадигмах программирования?
Одним из ключевых моментов является сложность. Она присуща как внешнему, по отношению к системе, миру, так и самому программному продукту [1]. Не менее сложно, а на практике даже более трудоемко создать такую систему. При этом во всем итеративном процессе создания ПО (анализ, проектирование, реализация, тестирование, развертывание, эксплуатация и сопровождение) именно на первые два этапа ОО процесса приходится большая часть описываемой сложности и громаднейшей ответственности. По данным Software Project Management Network (подразделение Пентагона [7 ]) исправление ошибки на этапе формирования
120
РИ, 2002, № 1
требований к проекту обходится в 138 долларов, в процессе кодирования — 1000, на этапе тестирования — 7 тысяч, на этапе внедрения — 14 тысяч. Статистика убедительно показывает критически важную необходимость изначально создавать более качественный продукт. Г. Буч утверждает: “Очень важно с самого начала по возможности приблизиться к правильным решениям, чтобы сократить число последующих шагов приближения к истине” [1,с.138].
Широко популярная (вследствие колоссальной отдачи) тема повторного использования (reuse) также обращается к проблеме качества: “ Ничто так не мешает работе, как плохо выполненная абстракция, впоследствии инкапсулированная. Если разработчики инкапсулируют плохо выполненную абстракцию, то пользователи постоянно будут нарушать барьеры, установленные абстракцией. Хорошая абстракция — ключ к повторному использованию программы. Вы просто не захотите еще раз использовать то, что плохо сделано” [8 , с.47]. И даже более категорично: “Чтобы компоненты и использующее их программное обеспечение имели хоть какой-то шанс на корректную совместную работу, их интерфейсы сразу должны быть корректно спроектированы” [8, с.30].
Основная сложность построения качественных систем, как мы показали ранее, приходится на начальные этапы: “Определение классов и объектов — одна из самых сложных задач объектно-ориентированного проектирования” [1,с.147]. Там же: “Опыт показывает, что процесс выделения классов и объектов является последовательным, итеративным. За исключением самых простых задач с первого раза не удается окончательно выделить, описать классы” [1,с. 138].
Выше описана необходимость построения различных моделей для успеха усилий, направленных на создание качественного программного продукта. “Создавая диаграмму классов, вы просто моделируете часть сущностей и отношений, описываемых в представлении системы с точки зрения проектирования” [6,с. 112]. По сути, большинство исследователей и практиков все более склоняются к мысли, что успешное, качественное программирование и есть моделирование. Или иначе, качество модели является определяющим для качества программной системы. Об этом упоминает Айра Пол: “ООП рассматривает вычисления как моделирование поведения. То, что моделируется, является объектами, представленными вычислительной абстракцией” [9, с.18]. Моделирование реального мира А. Пол осуществляет с использованием идей платонизма: “Платоническая парадигма является моделированием или симуляцией конкретного мира” [9, с.339]. При этом: “Любой проект всегда должен быть тесно привязан к предметной области и отражать ее абстракции. Раскрыть эти абстракции позволяет философия проектирования, которую мы называем платонизмом (Platonism)” [9, с.338].
В кратком изложении идеи платонизма можно понять из следующей цитаты: “В соответствии с платонической парадигмой существует идеальный объект. Например, представьте идеальный стул и попытайтесь описать его характеристики. Это должны быть свойства, разделяемые всеми стульями Вселенной. Такой стул может быть подкатегорией другого идеала — мебели. Стул может иметь подкатегории, такие как вращающийся стул, шезлонг, стул с подлокотниками, кресло-качалка и тому подобное. Для толкового описания стула, возможно, потребуется устроить экспертизу по стульям, с привлечением производителей и пользователей стульев с целью придти к соглашению о сути и природе “огульности”. Платонический стул должен легко модифицироваться для описания наиболее часто встречающихся стульев. Платонический стул следует описывать в терминах, согласовывающихся с существующей “стульной” терминологией” [9, с.339].
О необходимости моделирования предметной области постоянно упоминает Г.Буч, но он идет еще дальше, у него объектная модель пересекается с классификацией понятий проблемной области: “Классификация—средство упорядочения знаний. В объектно-ориентированном анализе определение общих свойств объектов помогает найти общие ключевые абстракции и механизмы, что в свою очередь приводит нас к более простой архитектуре системы” [1, с. 147]. Это средство не только анализа: “ Классификация затрагивает многие аспекты объектно-ориентированного проектирования. Она помогает определить иерархии обобщения, специализации и агрегации” [ 1, с. 148]. А. Пол также отмечает важность классификации, но придает ей меньшее значение: “Наследование выгодно тем, что позволяет получать производные типы из уже определенных пользователем типов данных. Этот механизм сродни биологической таксономии” [9, с.18]. Или: “Иерархия — это метод, позволяющий копировать элементы во всем их многообразии и сложности. Она вводит классификацию объектов” [9, с.30].
В изложении А. Пола подход к построению объектно-ориентированных программных систем выглядит достаточно просто: “Концепции ООП:
— моделирование действий из реального мира;
— наличие типов данных, опред еляемых пользователем;
— сокрытие деталей реализации;
— возможность многократного использования кода благодаря наследованию;
— интерпретация вызовов функций на этапе выполнения” [9, с. 19].
“ Методология объектно-ориентированного проектирования:
1. Выбери надлежащую совокупность типов.
2. Спроектируй взаимосвязи типов в коде, используя наследование” [9, с.30].
РИ, 2002, № 1
121
Но остаются “за кадром” вопросы: Как выделить типы (классы)? Как определить надлежащую их совокупность? Каковы критерии? Какова процедура проектирования взаимосвязей, использующая наследование?
Средство решения проблем, как процитировано выше, Г. Буч видит в классификации, Мартин Фаулер — в концептуальной модели: “ Этот абзац содержит слова “заказчик”, “пункт” и “услуга”. Что они означают и как связаны друг с другом? Концептуальная модель проблемной области кладет начало ответам на эти вопросы и в то же время закладывает основы модели объектов, которая будет позднее использоваться в процессе разработки для представления объектов системы” [10, с.34].
Но и здесь разработчика подстерегают нерешенные вопросы: “ Какой детализации достаточно для того, чтобы сделать сущность пригодной в качестве класса?” [9, с.341].
Для построения концептуальной модели необходимо построить классификацию, но - “к сожалению пока не разработаны строгие методы классификации и нет правила, позволяющего выделять классы и объекты. Нет таких понятий, как “совершенная структура классов”, “правильный выбор объектов” . Как и во многих технических дисциплинах, выбор классов является компромиссным решением” [1,с.147].
Для получения качественной системы мы пытаемся построить качественную модель сразу, которая невозможна без качественной классификации, но нам препятствует “ отсутствие “совершенной” классификации, хотя, естественно, одни классификации лучше других” [1,с.150].
Как же можно построить какую-нибудь классификацию? “Любая классификация зависит от точки зрения субъекта ” [1,с. 150]. “Разумная классификация требует изрядной доли творческого озарения” [1,с.150].
И даже более: “ Разумная классификация — работа интеллектуальная и лучший способ её ведения — последовательный, итеративный процесс. На практике обычно за основу берется какая-то определенная структура классов, которую постепенно совершенствуют. И только на поздней стадии разработки, когда уже получен некоторый опыт использования такой структуры, мы можем критически оценить качество получившейся классификации” [1,с.150].
Резюмируя приведенные выше цитаты, можно сказать, что Г. Буч не знает, как строить хорошие классификации (и вообще, что есть хорошая классификация?). И это в порядке вещей, так как: “Со времени Платона проблема классификации занимала умы бесчисленных философов, лингвистов, когнитивистов, математиков. Поэтому было бы разумно изучить накопленный опыт и применить его в объектно-ориентированном проектировании. Исторически известны только три подхода:
— классическая категоризация;
— концептуальная кластеризация;
— теория прототипов” [ 1, с. 152].
Проблема еще серьезнее, авторы классического учебника по созданию объектно-ориентированных программ утверждают: “ Мы описали предварительные результаты идентификации объектов или, скорее, их классов. Мы не можем даже утверждать, что существует процедура, которой можно слепо следовать” (“ we describe some preliminary issues in the identification of objects, or rather, their classes. We cannot claim that a procedure exists that can be followed blindfolded”) [11 ].
Исследователь объектно-ориентированной парадигмы Шаян Миа (Shajan Miah) приводит такие сведения: как новички, так и опытные разработчики объектно-ориентированных программ испытывают затруднения в создании подходящей структуры классов. Ключевыми затруднениями являются:
— Идентификация классов.
— Структурирование решения (формирование иерархий и т.д.).
— Определение ISA и PART-OF отношений.
— Установление соответствия между методами (функциями-членами) и подходящими классами [12].
В настоящее время в рамках работ по созданию интеллектуальной технологии поддержки решения задач оптимизации деловой активности в научноучебной лаборатории приобретения знаний ХНУ-РЭ разработан метод системного анализа, впервые согласующийся с требованиями OOD — объектноориентированный метод системологического анализа и проектирования (OMSAD) [13 ]. В рамках данного метода используется базовая иерархия классов [14 ], значительно упрощающая процедуру выявления “подходящих” для моделирования разрабатываемой системы классов. Названный эффект достигается рассмотрением требований к системе и ее свойств “сквозь призму” специализированной с учетом конкретной предметной области иерархии, которая как структурированная по определенным правилам система специальных категорий соответствует категориальному по своей природе строю понятийного (логического) мышления. Данная иерархия представляет собой классификацию связей и элементов систем как функциональных объектов, построенную методом системологического классификационного анализа с учетом закономерностей естественной классификации [ 15 ].
Упомянутая методология обладает универсальностью из-за присущего ей свойства адаптивности, однако ее применение (как и любой системной методологии) в определенной степени все же зависит от искусства интерпретации требований в практической ситуации. Творческие и эвристические моменты анализа системы или предметной области, ввиду их сложности и, зачастую, слабо-формализованности, остаются, но все же осуществляются в рамках формальной процедуры. Это подчеркивает важность и актуальность поддержки аналитических этапов метода OMSAD при проектировании ПО.
Таким образом, жизненно важно создание методики перехода от модели анализа к модели проектирова-
122
РИ, 2002, № 1
ния с возможностью последующей реализации в конкретном языке программирования (как важен и сам процесс построения и модели анализа, и модели проектирования).
Следовательно, основным направлением данной работы автор считает модификацию объектно-ориентированного процесса идентификации классов и механизмов, что по характеру проблемы очень близко к пониманию задачи моделирования предметной области такой дисциплиной как искусственный интеллект. К этому, на сегодняшний день приходят даже специалисты-практики из области разработки программного обеспечения. Тезис “программирование есть моделирование” [16,17], возникнув, интенсивно набирает своих приверженцев. Как для качественного анализа и проектирования проблемной области, определенной для программной разработки задачи, так и для программирования на высоком уровне абстракции (повторное использование программных компонент, визуальные средства быстрой разработки приложений, генерация исходных кодов программ с помощью CASE средств) одинаково чрезвычайно важно определить более строгие критерии качества анализа (и проектирования) и разработать, по возможности, более формализованную процедуру решения таких задач.
Проведенный анализ литературных источников подтверждает мнение Г. Буча [ 1], что идентификация классов является очень сложной проблемой. Но актуальность ее такова, что даже минимальные результаты, достигнутые в этом направлении, могут принести очень большой выигрыш в области написания качественных программ и программирования в целом, включая анализ и проектирование как этапы.
Предметом данного исследования является объектно-ориентированный процесс разработки качественного программного обеспечения.
Объектом — процесс и методы проектирования объектно-ориентированного программного обеспечения на основе моделей анализа, построенных на основе базовой иерархии классов, учитывающей критерии естественной классификации.
Целью данной работы ставится модификация и усовершенствование методов преобразования модели анализа в модель проектирования для повышения изначального качества ПО на основе метода OMSAD [13].
Опираясь на системологическое понимание реальности и процессов моделирования, необходимо:
— разработать библиотеку базовых классов для конкретной предметной области путем специализации базовой иерархии классов;
— разработать шаблонные структуры и взаимодействия в модели проектирования в предлагаемой библиотеке базовых классов;
— построить формальную модель иерархии абстракций, которая может быть удобно преобразована в модель проектирования;
— формализовать метод преобразования модели анализа в модель проектирования.
Для этого нужно выполнить следующие этапы:
— добавить в ОО процесс “Анализ требований” понятие детерминантного целеполагания из аппарата системологии;
— модифицировать процедуру проведения “Анализа требований”;
— внедрить новый механизм наследования [18].
Литература: 1.Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд. М.: Бином, 1999. 560 с. 2.Royce, Walker Software project management: a unified framework ISBN 0-201-30958-0. 1998 by Addison Wesley 3.Ковалев С.А. Основные черты объектно-ориентированной парадигмы программирования //Проблемы бионики. 2000. Вып. 52. С. 104-109. 4.Йордон Э, Аргилла К. Структурные модели в объектно-ориентированном анализе и проектировании. М.: ЛОРИ, 1999. 264с. 5.ЭббиМ, Кори М. Oracle8: Первое знакомство. М.: ЛОРИ, 1998. 470с.
6.Буч Г., Рамбо Д, Джекобсон А. Язык UML. Руководство пользователя. М.: ДМК, 2000. 432 с. 7. Software Project Manager Network. http:// www.spmn.org/ 8. Ро-фэйл Э, Шохауд Я. COM и COM+: полное руководство. К.: “Век+”, 2000. 560 с. 9. Пол А. Объектноориентированное программирование на C++. С.-Пб., М.: Невский Диалект-Издательство БИНОМ, 1999. 462 с. 10. Фаулер М, Скотт К UML в кратком изложении. Применение стандартного языка объектного моделирования. М.: Мир, 1999. 199 с. 11.Dennis de Champeaux, Douglas Lea. Penelope Faure Object-oriented System Development ISBN 0-201-56355-X by Hewlett-Packard Company. 12. Shajan Miah “ Critique of the Object Oriented Paradigm: Beyond Object-Orientation”/ mem-bers.aol.com/shaz7862/critique.htm, 1997 13.Маторин С.И. О новом методе системного анализа, согласованном с процедурой объектно-ориентированного проектирования. 4.1 //Кибернетика и системный анализ. 2001. №4. С. 119-132. 14.Маторин С.И. Определение и системологическое обоснование базовой иерархии классов для создания нормативной системы объектно-ориентированного анализа и проектирования // Вестник ХГПУ. Новые решения в современных технологиях. 2000. №79. С. 22-25. 15. Соловьева Е.А. Естественная классификация: системологические основания. Харьков: ХТУРЭ, 1999. 222 с. 16. Object Management Group. http:// www.omg.org/. 17.Бадд T. Объектно-ориентированное программирование в действии. С.-Пб.: Питер, 1997. 464 с. 18. Соловьева Е.А., Маторин С.И. Методы моделирования и модели понятийных знаний / / НТИ. Сер. 2. 1989. №4. С. 2-8
Поступила в редколлегию 09.10.2001
Рецензент: д-р техн. наук, проф. Шабанов-Кушнаренко С.Ю.
Ковалев Сергей Александрович, аспирант, ассистент кафедры ПОЭВМ ХНУРЭ. Научные интересы: системология, объектно-ориентированная парадигма. Увлечения и хобби: киберкультура и смысл жизни. Адрес: Украина, 61166, Харьков, пр. Ленина, 14, тел. +38(057)7137765. E-mail: [email protected]
РИ, 2002, № 1
123
