Само понятие CASE (computer-aided system engineering - проектирование систем с помощью компьютера) в среде связанных с автоматизацией людей сегодня не менее модно, чем красные пиджаки и иномарки в среде бизнесменов. В программе 7-ой Российской конференции Ассоциации пользователей Oracle, проходившей на борту плывущего из Нижнего в Москву теплохода "Николай Чернышевский", круглого стола по CASE-проблемам запланировано не было. Но, когда у сотрудников LVS и ФОРСа такая идея родилась, в музыкальном салоне теплохода (несмотря на прекрасную погоду) свободных мест не осталось.
Чем-то слово CASE народ манит, даже в жару. Может быть, элементами мифологии. И богатому заказчику, и закаленному в боях постановщику, и бедному прикладному программисту, несмотря на весь их жизненный опыт, все же верится, что есть где-то такое "секретное оружие", такая "катюша", которая повернет на 180 градусов ход битвы за создание производительных, надежных и не очень дорогих систем. И хотя абсолютное большинство собравшихся было приверженцами Oracle, разговор не свелся только к обсуждению особенностей Oracle-Case-продуктов, а стал нормальным, интересным разговором "о CASE, о времени и о себе".
ЧУТЬ-ЧУТЬ ИСТОРИИ
Примерно четверть века назад быстро возрастающий объем и сложность систем вступили в явное противоречие с отсутствием единого подхода к их анализу и проектированию, неучастием пользователя в процессе разработки, несогласованностью различных этапов разработки. Ошибок было много, и обходились они очень дорого. Модульное и структурное программирование, логическое моделирование структур баз данных, схемы потоков данных и проектирование "сверху вниз" при всей начальной эйфории, в общем-то, остались внутренним делом разработчиков.
Проблема была глубже: нужно было как-то объединить заказчиков, разработчиков, программистов, пользователей, причем в условиях постоянно меняющейся ситуации. А для того чтобы о чем-то договориться, нужен какой-то общий язык, некий "системный эсперанто".
Естественный язык в силу малой наглядности, неоднозначности, избыточности и многословия для этой роли не подходил, и в конце концов начались попытки создания четкого графического языка ("лучше один раз увидеть"). Рискну предположить, что в основе переноса центра тяжести на начальные этапы разработки систем лежала обычная житейская мудрость типа "семь раз отмерь".
SADT -С НЕБА НА ЗЕМЛЮ
SADT (Structured Analysis and Design Technique - технология структурного анализа и проектирования) появилась в конце 60-х годов, первое ее крупное приложение было реализовано в США в 1973 году при разработке аэрокосмического проекта. В отличие от ряда других структурных методов, "выросших" из проектирования программного обеспечения, SADT изначально возникла на базе проектирования систем более общего вида и потому, кроме возможности использования на самых ранних стадиях создания систем и процедур поддержки коллективной работы, отражала такие системные характеристики, как управление, обратная связь, исполнители. Проектирование телефонных коммуникаций реального времени и банковское дело, системы наведения ракет и организация материально-технического снабжения - в этих и десятках других областей методология SADT была с успехом использована.
Немаловажным свойством была и дружественность - SADT хорошо сочеталась с другими структурными методами.
Более 10 лет SADT была "бумажной" технологией, но в середине 80-х, когда на письменных столах появились персональные компьютеры с графическими возможностями, SADT пересела за компьютер. ВВС США в рамках IСАМ, программы интегрированной компьютеризации производства, разработали на базе SADT и довели до уровня стандарта методологию IDEF (IСАМ DEFinition), состоящую из трех методологий: IDEFO (функциональное моделирование), IDEFI (информационное моделирование), IDEF2 (динамическое моделирование функций, информации и ресурсов).
Первые версии простого и мощного пакета Design/IDEF появились на российском рынке три с лишним года назад, и с тех пор количество его поклонников заметно выросло.
IDEF, основанная на принципах системного анализа и предназначенная для представления функций произвольной системы (будь то управление финансами, организация работ, обучение или автоматизация), фактически стала стандартом не только в США, но и в ряде европейских стран. Я в свое время с удивлением обнаружил в Штатах, что даже описание проектов принимается к рассмотрению в формате IDEF (хотя нарисовать его можно, конечно, в любой Windows-рисовалке). Отметим, что системный анализ применяется как с целью оптимизации уже существующих технологий и операций, так и для "открытия" (изобретения) принципиально новых возможностей и подходов.
STRADIS -ДЕЛО В ШЛЯПЕ
SADT, конечно же, не единственная из используемых технологий структурного анализа. Красива и, я бы сказал, изящна методология STRADIS (STRategic Architecture for the Deployment of Information Systems), предложенная McDONNELL DOUGLAS и демонстрирующая пошаговый инженерный подход к разработке, например, информационных систем. Наряду с техническими аспектами разработки она затрагивает вопросы стратегии бизнеса, распределения ответственности, управления и контроля за разработкой. Разработка системы при этом напоминает создание промышленной конструкции от организации конструкторской деятельности до завершения строительства и передачи ее в эксплуатацию.
Распределение обязанностей в ходе разработки напоминает исполнение ролей в спектакле. Каждую роль можно представить в виде шляпы, с которой связаны определен ные обязанности. Разработчики примеряют эти роли по своим способностям и на определенных этапах их исполняют. Мне очень нравится один из принципов этой методологии: каждая роль должна иметь своего исполнителя (иначе лучше не позориться и перенести спектакль). Эта мощная методология тоже перенеслась на компьютеры - вспомним систему ProKit*WORKBENCH и среду разработки прикладных программ на языке 4-го поколения PRO-IY (приведу лишь один пример ее использования - проектирование крупного аэропорта в Германии).
ТАБЛИЦЫ МЕНДЕЛЕЕВА И ЧЕРНЫЕ ЯЩИКИ
Когда человек пытается лучше понять суть какой-то новинки или объяснить ее другим, он ищет "якори", использует образы. На "круглом столе" меня порадовало как раз обилие таких образов (как известных, так и новых).
Евгений Зиндер (LVS) попытался изложить свои CASE-представления в терминологии "черных ящиков": система - черный ящик, модификация системы - переход от старого черного ящика к почему. Рассматривалась интеграция черных ящиков по данным в изменяющейся ситуации ("пока мы строим крылья, хвост меняется"). Был затронут и очень важный вопрос живучести проектов, зависящей от живучести черных ящиков, а также громадного черного ящика, который называется "внешний мир". Если понимать эффективность как отношение возможностей и функций к произведенным затратам, то применение того или иного инструментария, в том числе CASE, должно быть экономически оправданным (естественно, стоимость преимуществ и недостатков должна оцениваться с учетом частоты их проявления).
- CASE - это помощь в создании систем и средство их сопровождения - CASE - это воспитание культуры проектирования - CASE - это способ параллельного документирования разработки, это средство обучения заказчика и оперативного решения спорных вопросов |
Олег Полукеев (LVS), сославшись на классический труд "Проектирование качественных баз данных с помощью методологии IDEFIX", раздал участникам "стола" копии таблиц Захмана. Эти таблицы (перечислю лишь заголовки столбцов: "Данные", "Функции", "Сети" и наименования строк: "Цели", "Бизнес-модель", "Модель информационной системы", "Технологическая модель", "Детальные представления", "Функционирующая система") не просто отражают архитектуру информационных систем, но и позволяют интегрировать знания о продуктах и подходах. Кто-то из участников "круглого стола" назвал эту таблицу таблицей Менделеева. Сравнение хорошее, но слишком уж много клеток в этой таблице незаполнено. Может быть, она еще ждет своего Менделеева?
Многие фирмы сегодня предлагают CASE-средства как автономные, так и входящие в состав больших программных систем. Явного лидера среди них, видимо, еще нет, потому что, как только выявляется лидер, к нему сразу начинают "шлюзоваться" (это теплоход навеял на меня такие ассоциации).
Если суммировать определения, порожденные участниками "круглого стола", то CASE - это отчуждение проектной информации от мозгов, ее породивших, это попытка "загнать" проектировщиков в одну методологию (лучше хорошую). CASE - это помощь в создании систем и средство их сопровождения. CASE - это воспитание культуры проектирования. CASE - это способ параллельного документирования разработки (документация перейдет к эксплуатационному персоналу), это средство обучения заказчика и оперативного решения спорных вопросов.
Основная проблема любой информационной системы - это проблема главного конструктора и генерального плана. Одно дело - передвигать флажки по карте на штабных учениях, и совсем другое - бросать живые дивизии в бой с настоящим противником. Можно, конечно, учиться и в бою, но это слишком дорого, да и потери необратимы. CASE дает возможность осмыслить в тонкостях различные варианты боя, которого еще не было (а может быть, по зрелом размышлении и не будет).
CASE может помочь в быстром изготовлении прототипа работающей системы, рассчитывать же, что с его помощью удастся создать произведение искусства, - наивно. Так же, как вещи ручной работы, handycraft не следует сравнивать с конвейерной, поточной продукцией. По-моему, мы все еще недооцениваем психологические основы использования CASE-технологии, возможность заказчика, разработчика, программиста и эксплуатационщика вместе заглянуть в будущее и разобраться со многими взаимными претензиями еще до того, как они возникнут.
К Игорю Альтшулеру можно обратиться по электронной почте: MAIL: IGOR@IGOR.KIS.NNOV.SU
Игорь Альтшулер, (Нижний Новгород)
