Валерий Аджиев

Принимаясь за статью, посвященную объектно-ориентированному подходу, чувствуешь себя ломящимся в открытую дверь. Действительно, известия о новых объектно-ориентированных (ОО) продуктах и технологиях поступают чуть ли не ежедневно; а фраза вроде "при разработке данной системы использовались передовые методы ОО-программирования" стала типовым рекламным слоганом. Скажу больше: разбудите темной ночью любого студента компьютерной специальности, и он, не протирая глаз, отрапортует, что ОО зиждется на трех китах - инкапсуляции, наследовании и полиморфизме, и что он всем этим владеет, потому как программирует на С++. А опрос руководителей программистских подразделений отечественных компаний показал, что 90% их разработчиков являются специалистами в С++ , а 60% - в других ОО-языках. Так что агитировать за объектно-ориентированное программирование вроде бы некого и незачем - все и так уже сагитированы и, надо полагать, пожинают плоды передовой технологии.

Это у нас. А на Западе? Исходя из того непреложного факта, что все, имеющее отношение к ОО, будь то концепции, технологии, операционные системы, СУБД, CASE-средства, среды и языки программирования, книги, статьи, наконец, просто новости, приходит к нам "оттуда", можно было бы ожидать, что уж там-то ничего "не ОО" просто не осталось. Однако это далеко не так. Немало есть свидетельств того, что часто от объектной технологии не в восторге программисты, ее с трудом понимают менеджеры, ее эффективность проблематична, ее внедрение требует слишком радикального изменения процесса разработки, это дорого и т.д. Наконец, уже упомянутый опрос свидетельствует также, что доля разработчиков крупнейших американских компаний, владеющих ОО-методами, составляет лишь 3% (хотя эта цифра и отражает искажающее влияние огромного на Западе контингента Cobol-программистов).

Что ж, сравнивая, как выражались раньше, "два мира - две судьбы", можно прийти к следующим выводам. Либо все дело в том, что наши программисты просто-напросто могут дать сто очков вперед западным коллегам. Либо мы как-то не так понимаем, в чем же, собственно, суть ОО-технологии, и, соответственно, опросы если о чем и говорят, то о том, что "есть ложь, большая ложь и статистика" - потому что люди на самом деле отвечают не на "те" вопросы. А вот вопрос "тот": "Существуют ли в России программистские коллективы, действительно работающие по ОО-технологии?" Попытаемся прояснить его суть, поскольку она не так проста, как кажется на первый взгляд.

Во всяком случае, на Западе некоторые крупные авторитеты сомневаются в том, что возможный массовый потребитель до конца понял суть объектной технологии. Видимо не случайно такие общепризнанные гуру объектного подхода, как Гради Буч (Grady Booch) и Бертранд Мейер (Bertrand Meyer), недавно сочли необходимым выйти к профессиональной аудитории с описанием мотивации, глубинной философии и базисных принципов, лежащих в основе ОО-подхода, а также его глобальных перспектив. Проследуем и мы вместе с ними.

Мотивация: "Software crisis"

"Софтверный кризис": это выражение стало уже идиоматическим - его вспоминают всякий раз, когда вновь и вновь констатируют: процесс создания программного обеспечения никак не укладывается в запланированные сроки и бюджет, а качество продукта практически всегда оставляет желать лучшего. Сошлемся, к примеру, на сравнительно недавнее исследование фирмы Standish Group под красноречивым названием "Хаос". В 1995 г. считалось, что только 9% проектов крупных компаний, должны завершиться в срок и без превышения запланированного бюджета; стоимость 52% проектов должна превысить первоначальную на 189%; а 31% проектов будут приостановлены или вообще свернуты, причем затраты на них оценивались ни много ни мало в 81 млрд. долл. - цифра, просто поражающая воображение.

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

ОО-концепты

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

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

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

Самодостаточность (selfishness). Как замечает Б. Мейер, это наиболее известная, но наименее понимаемая часть ОО-технологии (он полагает, что не более 10% специалистов, практикующих ОО-подход, на самом деле владеют ею). Основная идея в том, что объект-поставщик раскрывает клиентам только часть своих свойств. Принципиально, что такой механизм сокрытия информации предназначен не столько для защиты объекта-поставщика от несанкционированного клиентского доступа (как полагают многие), сколько для защиты самого клиента. Дело в том, что как автор объекта-клиента, вы, в принципе, не хотите знать ни о каких деталях, свойственных поставщику; и это не поза, а вопрос выживания в борьбе со сложностью. В этом же контексте имеет смысл рассматривать и понятие динамического связывания. Как клиент, вы отказываетесь беспокоиться о некоторых деталях (в данном случае - какой вариант операции выполнять) до самого последнего момента или до момента исполнения.

Классификация. Какие объекты (классы и их экземпляры) использовать в конкретной разработке - вот критический вопрос при применении ОО-технологии. То, что в ОО-технологии называется "создание иерархий с наследованием" и является классификацией, отображающей неупорядоченный реальный мир в упорядоченный мир объектов с попутным обнаружением общности в их ключевых абстракциях и реализующих поведение механизмов. Существует эмпирически выявленная закономерность (для опытной команды разработчиков!), что 70% классов относительно легко идентифицировать уже на стадии анализа; 25% классов возникают на стадиях проектирования и программной реализации; наконец, необходимость остающихся 5% часто выявляется только на этапе поддержки и сопровождения системы.

Бесшовность. Идея бесшовности (связности, цельности - seamlessness) относится к наиболее малопонятным аспектам ОО-технологии. Суть ее в том, что модели системы на этапах анализа, проектирования и реализации обладают такой степенью связности, что изменения в одной из них сопровождаются соответствующими изменениями в других (иногда это свойство называют трассируемостью - traceability). Очевидно, что при этом имеется четкое (прежде всего - структурное) соответствие между элементами моделей на различных фазах жизненного цикла. Из бесшовности следует обратимость (reversibility), что гарантирует согласованное изменение моделей не только в прямом (от требований к реализации), но и в обратном направлении.

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

ОО-методологии

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

Лидером американского рынка с долей в 40% является OMT (Object Modeling Technique) - метод, разработанный Джеймсом Рамбо (James Rumbaugh) в научно-исследовательском центре фирмы General Electric. Далее с 11% следует подход Booch93/94 Гради Буча. Многие видные методологи особо выделяют еще OOSE (Object-Oriented Software Engineering), также известный под названием Objectory. Разработанный Иваром Якобсоном (Ivar Jacobson), он особо подходит для проектирования больших систем, в частности телекоммуникационных. Также получили признание методологии Object-Oriented Systems Analysis and Recursive Design (Shlaer/Mellor), Object-Oriented Analysis and Design (Coad/Yordon), Responsibility-Driven Design (Wirfs-Brock), Object Behaviour Analysis (Goldberg/Rubin) и ряд других.

Сегодня наступает эра ОО-методологий нового поколения. Их основные черты - более строгое и точное определение процессов и стремление к унифицированным нотациям. В первую очередь, здесь надо назвать объединившихся под крышей фирмы Rational Software Corporation Д. Рамбо, Г. Буча и И. Якобсона. Они вознамерились создать методологию, объединяющую три подхода, названных по именам авторов. После первого этапа работы выяснилось, что единой методологии пока не получается; зато удалось выработать единую нотацию - "Унифицированный Моделирующий Язык" (Unified Modeling Language - UML). Версия 0.8 обнародована и - более того - уже поддерживается рядом CASE-средств. Вскоре ожидается версия UML 1.0, которая будет признана стандартом через консорциум Object Management Group (OMS).

Более амбициозной, призванной охватить полный жизненный цикл программного проекта, включая стратегии долгосрочного планирования, управления и оценки качества, повторного использования и др., является методология OPEN (Object-oriented Process, Environment, and Notation). Неформальный интернациональный коллектив вознамерился создать не просто новую методологию, но, скорее, "метаметодологию" в виде открытой ОО-инфраструктуры, инкорпорирующую большое количество идей, методов и приемов практически из всех существующих подходов. Подробное описание этого подхода будет опубликовано в начале 1997 г.

"ОО-философия" и человеческий фактор

Хорошо известен труд Френсиса Фукуямы "Конец Истории и Последний Человек". Отталкиваясь от выраженных в нем фундаментальных футурологических идей, Г. Буч в статье "Конец Объектов и Последний Программист" доказывает, что после серии революционных смен программистских парадигм (алгоритмическая абстракция - абстракция данных - абстракция типов данных - ОО-абстракция) ОО-парадигма обеспечивает логичный, стабильный и окончательный организующий принцип разработки программного обеспечения.

Как следствие, каждый разработчик-индивидуум должен осознать эту стабильность данной технологии и овладеть ею. В этом смысле он "последний программист", потому что ОО-идеи и принципы, лежащие в основе его работы, будут неизменными, несмотря на возможную и радикальную замену технических и инструментальных средств. Дисциплина работы "последнего программиста" предполагает, что он не "хакер" - программист-одиночка, а командный игрок. Необходима четкая сбалансированность между микропроцессом разработки, где действует "последний программист", и макропроцессом, на котором работает вся команда. При этом микропроцесс соответствует спиральной модели Боэма и служит базисом для итеративной и инкрементальной дисциплины разработки. Макропроцесс более тесно связан с традиционным каскадным (водопадным - waterfall) жизненным циклом и является контрольно-управляющей инфраструктурой, в рамках которой располагаются многочисленные микропроцессы. На макроуровне производится последовательная доработка архитектурных прототипов, каждый из которых есть последующее приближение к функциональности полностью готовой системы. При этом необходим менеджмент с ярко выраженной ОО-спецификой.

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

Наши проблемы

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

При обилии "кодировщиков" избыточно высокой квалификации наблюдается острый дефицит аналитиков, владеющих современными методами, проектировщиков и менеджеров сложных программных разработок. Небезынтересно то, что, по данным US Bureau of Labor Statistics, в 1994 году в США работало 537 тыс. программистов-разработчиков и 483 тыс. системных аналитиков, а в 2005 г. соответствующие показатели будут равны 602 тыс. и 928 тыс. человек. Тенденция возрастания значимости предреализационных этапов работы совершенно очевидна. Не имея точных цифр, можно без большого риска предположить, что у нас соотношение между аналитиками и программистами принципиально иное.

В следствие несбалансированности "кадрового состава" имеет место отождествление объектных технологий с программированием на ОО-языках. Положение усугубляется тем, что на наших просторах безоговорочно господствует язык С++, безусловно во многих отношениях замечательный, но по природе своей гибридный. В результате масса программистов умудряется программировать на нем, не понимая самой сути ОО-подхода. Точно так же, как волка, пусть и в бабушкином чепце, все равно выдают слишком большие зубы, людей с процедурным мышлением сразу выдают написанные ими на С++ процедурные, по сути, программы. В то же время, к большому сожалению, такие истинно ОО-языки, как Smalltalk или Eiffel, заставляющие программиста мыслить объектно, являются у нас чуть ли не раритетами. Впрочем, некоторый оптимизм вызывает тот факт, что популярный инструмент Borland/C++ 5.0 в версии содержит встроенное CASE-средство анализа и проектирования Together/C++ 2.0, поддерживающее как OMT, так и унифицированную UML 0.8 нотации. Может быть, имея это CASE-средство под рукой, наши программисты волей-неволей начнут переходить к реальной ОО-технологии?!

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

Период переоценки возможностей CASE-средств прошел и на Западе - нынешнее состояние рынка этих продуктов не внушает оптимизма. Как саркастически замечает обозреватель журнала Computer Тед Льюис (Ted Lewis), "CASE-средства борются с системами искусственного интеллекта за звание самой перерекламированной и не оправдавшей ожиданий софтверной технологии десятилетия". Кстати, упоминавшаяся работа по унификации методологий призвана, помимо прочего, сократить ассортимент предлагающихся на рынке CASE-средств и таким образом нивелировать нынешнюю раздробленность рынка в условиях его спада.

Если и можно в нашем высокоинтеллектуальном, но малотехнологичном программном пространстве говорить об использовании методологий, то это, конечно, структурные подходы типа SADT. У ОО-методологий положение незавидное хотя бы потому, что источники информации крайне скудны. Очевидно, что в нынешних рыночных условиях, когда предложение определяется спросом, близкий к нулевому ассортимент книг по Software Engineering вообще и по ОО-технологиям в частности отражает оставляющее желать лучшего самосознание программистского сообщества. Десятки отличных книг по разным аспектам ОО-технологий, изданные на Западе в последние годы, остаются недоступными для российских специалистов.

ОО-будущее

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

Возможно, массовые потребители ОО-технологий (работающие на вертикальном рынке фирмы) не все и не полностью осознали их перспективность, и, с исключениями для банковских и сетевых приложений, ОО-идеи еще не стали универсальной технологией для западного программистского сообщества, разрабатывающего приложения. И тем не менее, ОО технологии становятся основным течением. Об этом говорит и то, что ключевые игроки горизонтального программного рынка, все как один, декларируют проведение "тотально объектной" политики и уже сейчас готовы обеспечить всю необходимую для ОО-разработок инфраструктуру. Это означает, что в скором будущем фактически каждая прикладная структура должна будет существовать в ОО-мире. Приведем прогноз такого авторитетного специалиста, как Эд Йордон (Ed Yourdon): "При разработке приложений объектная технология будет применяться в 40% проектов в 1996 году, 60% - в 1998 и 80% - в 2000 году".

Следовательно, альтернатив внедрению ОО-технологий нет, даже если они сами (и соответствующие CASE-средства) будут радикально меняться (вектор изменений понятен - в сторону все большей "визуальности" и сборки сложных систем из повторно-используемых, иерархически организованных ОО-компонентов). Именно ОО-технологии в конечном итоге должны обеспечить значительное увеличение производительности труда и улучшение качества всего процесса программирования и самого конечного продукта, облегчая его чувствительность к будущим неизбежным изменениям, сокращая стоимость разработки и поддержки, и обещая выгоды от "повторного применения" наработанных компонентов. Перспективны ОО-технологии и в контексте реинжиниринга бизнес-процессов (Business Process Reengineering - BPR), также пока полностью отданного у нас на откуп структурным подходам.

В заключение полезно привести более развернутую формулировку вопроса, поставленного в начале статьи. Итак, существуют ли в России программистские коллективы, которые применили к реальному проекту надлежащим образом поставленную ОО-технологию, охватывающую весь жизненный цикл разрабатываемого продукта: установление требований, анализ, проектирование, реализация, тестирование и отладка, поддержка и внесение изменений? Если да - то просьба заявить о себе. Это будет означать, что вопреки имеющемуся здесь скепсису есть-таки у нас организации, процесс разработки в которых (в соответствии с известной моделью, созданной в американском Software Engineering Institute - SEI) перешел с "начального" уровня зрелости (называемого также хаотическим) на следующий - "воспроизводимый". А это немало хотя, если принять во внимание, что таких уровней всего пять, то вроде бы и немного.

Валерий Аджиев - к.т.н., доцент кафедры кибернетики МИФИ. С ним можно связаться по электронной почты: valery@gostdvor.msk.ru


"Когда я ма-а-алоденьким юнкером был..."

Сергей Кузнецов

...Я ужасно любил писать программы. Со временем любовь к непосредственному написанию программ ослабла, но осталась любовь (возможно, страсть) к программированию. И вот, свершилось. Мы, наконец, собрались. Собрались те, кому действительно дорого, интересно, существенно то, что происходит с программированием в России.

Конференция "Индустрия програмирования"96", организованная Центром Информационных Технологий при содействии Издательского дома "Открытые системы", генеральным споснором которой была Компания "Аргуссофот", состоялась.

Организаторы конференции (и по-моему, это правильно) решили провести конференцию на манер, который принят во всем мире. Было всего четыре дня, в первые два из которых предлагались короткие учебные курсы (по четыре академических часа). Как оказалось, эта форма является очень привлеккательной для участников конференции. На каждом из восьми предложенных курсов присутствовало по крайней мере по 20 человек, причем они явно были мотивированы (я не буду перечислять все темы курсов, но среди них были такие разные, как межпроцессесные взаимодействия в ОС UNIX, множественные прикладные среды Windows NT, современные аппаратные платформы, сервисы Internet и т.д.).

Первый день конференции был предложен в виде одного пленарного потока, на котором были представлены обзорные доклады ведущих софтверных аналитиков России. Их было всего шесть, но, на мой взгляд, одних из лучших. Были представлены обзорные доклады по следующим темам: "Инкрементальные системы программирования", "Средства разработки графических интерфейсов", "История и современное состояние Си++" и т.д. Прекрасные доклады, прекрасные докладчики... Временами было жалко, что наш язык не понимают в большей части мира. Эти доклады заслуживают самого широкого внимания.

Во второй день одновремено проводилось три параллельных потока: "Опыт разработки крупных программных проекктов", "Средства разработки программ" и поток, содержащий презентации софтверных компаний - Аргуссофт, Oracle и Informix. Организаторы специально выбрали эту форму проведения конференции, но публике было нелегко: все время нужно было искать наиболее интересные темы. Все-таки лучше, когда есть что искать...

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