С появлением персонального компьютера, как средства поддержки деятельности профессионалов, возникла идея АВТОФОРМАЛИЗАЦИИ ЗНАНИЙ (Дж.Мартин). То есть в связи с ПК и с реализованными на них интегрированными пакетами типа Framework, высказывалась надежда на то, что профессионалы-предметники займутся в конкретных предметных областях переводом накопленных знаний в ЭКСПЛИЦИТНУЮ форму программных продуктов. Но этого не произошло, надежда не сбылась.
Профессионалы, серьезно занявшиеся программированием с целью автоформализации знаний, как правило, ушли в область профессионального программирования. Это наблюдалось уже в условиях работы с языками третьего поколения.
Появились CASE-средства и CASE-технологии, вначале как инжиниринг знаний о предметной области для больших ЭВМ, а затем и для ПК. С ними связали аналогичные надежды, но "чуда" опять не произошло. Автоформализация снова не состоялась. То же наблюдается с приходом объектно-ориентированных языков программирования.
Видимо, все дело в том, что программа не может реализоваться на ЭВМ без того, чтобы предварительно не пройти через голову программиста. Прежде чем реализоваться на ЭВМ в форме приложения, или базы данных или любого другого продукта, замысел приложения должен оформиться в виде концептуальной модели в голове человека. Если же этих людей двое - профессионал в предметной области и программист за пультом ЭВМ, то и моделей две. Можно, питая те же надежды, снова пытаться сажать самого профессионала-предметника за пульт ЭВМ. Жизнь все время опровергает этот подход. Предметники не хотят работать профессионально со средствами разработанными ПРОГРАММИСТАМИ. Предметник из созданных программистами заготовок пока не может создавать адекватные своей модели деятельности программные реализации для поддержки собственной профессиональной деятельности. Персональный компьютер оказался персональным инструментом только для программистов.
|
|
Предметник, прежде чем стать профессионалом, проходит ряд стадий овладения знаниями, навыками и умениями, в ходе которых модель его профессиональной деятельности трансформируется, усложняется от технологической (А.И.Галактионов), через функциональную, алгоритмическую и информационную к наглядно-образной модели деятельности, которая часто и самим профессионалом плохо осознается, а уж тем более не вербализуется и не визуализируется. Он знает, что и когда делать. А почему и как, объяснить не может.
Он ушел уже на несколько порядков сложности от технологической, предметно-опосредованной модели, когда в качестве объектов выступали конкретные предметы и детали, с которыми надо что-то делать. Оказалось, что для визуализации знаний и последующей их передачи на ЭВМ нужен профессионал-постановщик, владеющий методами концептуального анализа, умеющий понимать предметника.
Выяснилось, что несмотря на сходство в названиях, средства концептуального анализа, к которым относится и объектно-ориентированный подход, и средства объектно-ориентированного подхода в программирования - существенно разные вещи.
Тому и другому обучают разные контингенты специалистов, как бы разбитые на два лагеря. Ими издаются терминологически обманчиво сходные, но принципиально разнопредметные монографии по "объектно-ориентированному подходу". Дело, кроме всего прочего в том, что они манипулируют разнородными оперативными единицами деятельности из разнородных предметных областей. И к сожалению, одно с другим совсем не сходится, несмотря на внешнее сходство терминологии.
|
|
Но несомненно, существуют мощные объектно-ориентированные языки программирования, манипулирующие объектами из концептуального мира ПРОГРАММИСТОВ.
То же, что специалистами лагеря непрограммистов предлагается для создания концептуальных моделей предметных областей, как правило, аппаратом назвать трудно, а использовать при программной реализации вовсе невозможно. Здесь может возникнуть естественное возражение: а как же CASE-средства? Но эти технологии - технологии визуализации с помощью потоковых диаграмм концептуальных моделей предметной области. Они не на много лучше, чем стандартная номенклатура структурных единиц для построения блок-схем. В потоковых диаграммах номенклатура поменьше, а значит проще реализация на ЭВМ средствами языков четвертого поколения. Но все равно концептуальная модель прежде всего должна сложиться в голове эксперта. А для этого его надо научить мыслить категориями во многом неестественного формализма потоковых диаграмм.
Как пишет Дж.Дантеман в предисловии к [39] известные работы в области объектно-ориентированного подхода лишь обещают разрешение всех трудностей программирования, а на самом деле на сегодняшний день реализуют крайне серьезное противоречие, заключающееся в том, что в теориях "объекты" являются содержанием, не имеющим ясной формы. Точнее: в рамках объектно-ориентированных сред программирования говорить о КОМПОНЕНТАХ, как строительных блоках для создания конкретных моделей-реалий не приходится. Они суть лишь строительные блоки программных продуктов.
|
|
В мире программирования важны не сами по себе компоненты, или объекты из объектных библиотек, а объединяющая их в единую систему среда разработки приложений. И снова: объектно-ориентированный анализ в теории - это одно, а объектно-ориентированные среды программирования совсем другое, а именно: оно суть всего лишь логическое развитие экономных (по написанию кода вручную) методов разработки больших программных проектов.
Итак, понятно, что то, что понимается под "объектами" в объектно-ориентированном программировании мало пригодно для описания тех механизмов формирования обобщений, которыми пользуется предметник.
Овладение знаниями о предметных областях сводится в плане реализации психических механизмов к овладению и фиксации механизмами памяти пар "ОБЪЕКТ-ДЕЙСТВИЕ", что и составляет суть ОЕД. И поскольку, даже говоря об аналогично понимаемых объектах предметник и программист свяжут с ними различные ДЕЙСТВИЯ, и поневоле сформируют различные концептуальные модели. То есть даже если речь идет об одном и том же объекте O, адекватность его понимания состоит в том, что с ним связывается адекватное для субъекта S1 и субъекта S2 действие D, то есть реализуется схема:
S1---- -----S1
--->O---D<---
S2----- -----S2
На практике, даже если объект один и тот же для разных субъектов, связанные с ним субъективные действия, как правило, различны:
S1---- --D1<----S1
--->O-
S2----- --D2<----S2
То есть субъекты оперируют разными ОЕД. Отсюда же может быть выведена объяснительная схема понимания того, что, например, в одном и том же тексте для разных субъектов может содержаться разная семантика (смысл) - так как у них РАЗНЫЙ ДЕЯТЕЛЬНОСТНЫЙ ОПЫТ. Приведем следующий пример [78]. Выражение "намылить шею" в русской культурно-исторической традиции понимается в смысле наказания. А японец это же выражение понимает как покаяние, признание собственной вины вплоть до расплаты собственной жизнью: харакири сопровождалось ритуальным отсечением головы, перед которым надо было намылить и помыть шею.