Введение
Прежде всего хотелось бы отметить, что эта статья - личное мнение авторов. Оно может совпадать, а может и не совпадать с вашим мнением, мнением авторитетных для вас лиц и мнением официальных инстанций. Почему же тем не менее вам стоит обратить на нашу статью внимание? Все очень просто - наша статья основана на нашем опыте, и у вас нет другого способа поучиться на наших ошибках, как прочитав статью, возможно, на ваш взгляд, и в корне ошибочную.
Опыт+ Мы участвовали в большом количестве программных (и не только чисто программных) проектов, с разной степенью упорядоченности, разной степенью применения CASE-средств, а один из нас является даже разработчиком CASE-средства. Мы имеем в виду более или менее сложные проекты.
Часто спорят, какой проект называть сложным. Мы вывели для себя прагматическое правило: если в проекте участвует более двух специалистов, его можно считать сложным.
Почему проект, скажем, с тремя участниками, можно считать сложным? И что это за участники проекта? Конечно же, первая (но, на наш взгляд, далеко не главная) фигура, о которой вспоминают, - это Программист. В нашей российской практике (в отличие от западных стран с развитой программной индустрией), под Программистом понимают специалиста такого широкого профиля, что дух захватывает, - от модного нынче консультанта до настройщика готовых продуктов. Кроме Программиста, в сложном проекте всегда присутствует будущий Пользователь, иногда он же Заказчик, он же Финансист, он же Постановщик задачи, он же Приемщик продукта и т. д. Как только возникает понимание того, что для получения качественного продукта необходимо привлечение специалистов, знающих ту или иную специфику предметной области или процесса разработки программного обеспечения, и/или понимание того, что проект тривиально большой, появляется как минимум третий участник и проект неизбежно, по нашему мнению, переходит в категорию сложных.
Ключевой момент, отличающий сложный проект от простого, состоит в том, что сложный проект непременно должен быть структурирован (архитектура, ресурсы и пр.) и эта структуризация в конечном итоге должна быть воплощена в готовом программном продукте. Говоря проще, с первых же дней сложной разработки необходимо распределить задачи между постановщиком (аналитиком) и программистом, документировать решения и отслеживать изменения, управлять изменениями программного кода и решать множество других, часто трудоемких и просто рутинных задач. Наибольшая сложность заключается в том, что все это нужно делать согласованным образом, на что требуются значительные усилия. И здесь не обойтись без методов и средств программной инженерии для автоматизации проектов. В этой статье мы хотели бы изложить наше представление о том, что именно нужно автоматизировать и какими средствами.
Резюмируя это небольшое введение, скажем: сложный проект требует применения методов программной инженерии, которые в свою очередь можно эффективно задействовать, используя CASE-средства. При этом мы попытаемся указать на те мифы, которые сложились вокруг CASE, и оттенить реальную пользу применения CASE-средств.
Несколько слов о терминологии. В русскоязычной литературе как-то незаметно утвердился, на наш взгляд, не совсем удачный термин - CASE-технология. Используя этот ставший уже привычным термин, мы тем не менее хотели бы уточнить, что под ним мы понимаем совокупность методов и средств, применяемых в программной инженерии. Но об этом чуть позже.
Мифы
Миф № 1: "Большая кнопка". Представление о CASE часто сводится к сокровенному вопросу: "На какую кнопку CASE нужно нажимать, чтобы получился исходный код моей системы?". Люди хотят иметь что-нибудь, что делало бы за них всю работу. Люди думают, что CASE-средство будет работать за них. Увы, это не так. CASE-средство - не более чем инструмент, помогающий, но не работающий вместо своего хозяина. CASE-средство - это инструмент, позволяющий автоматизировать те или иные методы и процессы программной инженерии.
С этим мифом связана, возможно, наибольшая проблема при внедрении CASE: часто оказывается довольно трудно убедить лиц, принимающих решение, выделить ресурсы на нечто, конечным результатом применения которого будет все что угодно (диаграммы, схемы, отчеты и др.), но только не программа (которую сгенерирует компилятор) или исходный код (который напишут программисты).
Миф № 2: "Производительность труда стремится к бесконечности". Второе наиболее частое заблуждение относительно CASE - это надежды на то, что при помощи CASE готовую систему можно получить если и не сразу, то очень быстро. Гораздо быстрее, чем без CASE. Строго говоря, это не так. Это только в известном анекдоте картошку выкапывают на следующий день после посадки. В реальности применение CASE-средств может даже затормозить первый проект. С накоплением опыта можно добиться увеличения производительности - в литературе приводятся случаи ускорения проектов до 600%. Однако, по нашему мнению, не это самое главное. Реальность заключается в том, что применение CASE привносит в проект совершенно новые свойства, не достижимые традиционными методами: это касается и качества продукта, и управляемости проектом, и в конечном счете производительности. Если подсчитать все издержки, связанные с традиционными способами разработки (необязательные итерации разработки, невысокое качество продукта, высокая стоимость сопровождения и многое другое), то окажется, что применение CASE-средств приводит в итоге к значительному сокращению затрат на разработку.
Миф № 3: "CASE - это же безумно дорого". Действительно, если просмотреть некоторые обзоры по CASE-средствам (в частности, появившиеся в российской компьютерной периодике), то неподготовленный читатель может заскучать. Часто в этих обзорах можно увидеть цены в десятки и сотни тысяч долларов США за лицензию на одно рабочее место. И все это сущая правда! Но, к счастью, не вся. Зачастую в этих обзорах намешано все, что хоть отдаленно можно отнести к CASE-средствам. В такой смеси вы можете увидеть совершенно экзотические по назначению продукты, да еще и произведенные для программно-аппаратной платформы, существующей в нескольких экземплярах, - отсюда и цена.
Кроме того, конечно же, цены значительно отличаются от платформы к платформе, и это стандартное соотношение цен на программные продукты вообще, а не только на CASE-средства. Поэтому неудивительна цена в $100 000 для мэйнфреймов - там все так стоит.
В реальности средние цены на CASE-средства для PC - от $500 - $4000; для UNIX - $5000 - $15 000, т. е. уровень цен для CASE-средств вполне соотносится с ценами на программное обеспечение для данной платформы. Здесь, конечно же, следует оговориться, что сравнивать необходимо с программными средствами разработки или специализированными пакетами. Сегодня трудно себе представить, что цена на полноценный CASE-пакет будет близка к цене на известную электронную таблицу стоимостью $49.
Но возможно, самая главная реальность заключается в том, что приобретение CASE-средств не является необходимым (хотя и желательным) условием внедрения CASE-технологии. Напомним наше разъяснение понятия CASE-технологии как совокупности методов и средств, применяемых в программной инженерии. Поэтому хорошим началом было бы применение методов программной инженерии в вашей практике, пусть в начале и не поддержанных программными CASE-средствами. Например, ознакомление и постепенное внедрение стандартов программной инженерии гарантированно облегчит вашу жизнь в будущем.
Миф № 4: "CASE - это слишком сложно". В нашей российской действительности этот миф часто объясняется недостаточной информированностью специалистов. Действительность такова, что дисциплина программной инженерии сложилась и развивается за рубежом. Соответственно вся обширнейшая литература по программной инженерии издана там и практически недоступна отечественному читателю, ее не найти ни в библиотеках, ни в магазинах или специализированных фирмах. К сожалению, почти ничего не переводится. Небольшой список (возможно, не полный) литературы, доступной на русском языке, читатель найдет в конце статьи. К счастью, с бурным развитием Internet (надеемся, не только в Москве), у нас появился доступ к самым свежим материалам, их можно заказать или скопировать с Web-серверов.
Но достаточно о мифах, перейдем к изложению реальностей, связанных с CASE.
CASE, программная инженерия и все такое...
CASE-средства - это инструменты разработки программного обеспечения. И все же точнее - для программирования? Для документирования проекта? Управления проектом? Да, в известном смысле и для всего этого, но прежде всего - для программной инженерии.
Обычно расшифровывают CASE как Computer Aided (т. е. автоматизация) Software Engineering (программной инженерии). Еще иногда букву S расшифровывают как System, т. е. CASE - автоматизация системной инженерии. Мы считаем, что это определение поглощается предыдущим, что разработка систем в целом может (и должна в CASE-технологии) вестись методами программной инженерии.
Основное отличие методов программной инженерии от, скажем так, "непосредственного" программирования, во-первых, то, что программная инженерия систематически отделяет анализ и проектирование от программирования (кодирования) как такового. Во-вторых, программная инженерия систематически выделяет в общем ходе разработки различные типы деятельности, выполняемые на различных фазах жизненного цикла (планирование, управление, обеспечение качества, конфигурирование, тестирование и др.).
И еще раз о жизненном цикле программного обеспечения
Стандартный подход выделяет в жизненном цикле программной разработки анализ, проектирование (часто этот этап разделяют на проектирование архитектуры и детальное проектирование), программирование, тестирование и сопровождение. В зависимости от модели жизненного цикла эти фазы выполняются последовательно или в произвольном порядке. Важно только, что эти фазы явно выделяются, что им соответствуют различные виды входных и выходных документов, а также применяемых методов и средств.
Первоначально, когда были введены (открыты) эти фазы жизненного цикла, считалось, что они проходятся последовательно. Потом была введена модель спирального жизненного цикла, в которой были возвраты по основной последовательности. Потом - модель быстрой прототипизации, в которой возвраты к началу основной последовательности происходят регулярно, с каждым циклом прототипизации. В общем, тенденция очевидна: одновременное выполнение всех задач всех фаз жизненного цикла. Кстати, это отнюдь не отменяет разделения действий в соответствии с фазами жизненного цикла. Конечно, такое одновременное полноценное выполнение всех фаз возможно только с использованием CASE-средств.
Анализ и проектирование
Хорошо спроектированная завершенная разработка может быть представлена в виде совокупности небольших решений - от выбора платформы и языка до деталей реализации кода. Причем вся эта совокупность может быть упорядочена как иерархия детализации. Иерархия начинается от основополагающих решений и кончается ни на что не влияющими деталями реализации.
Анализ и проектирование - это процесс принятия той меньшей части решений, которые влияют на все остальные решения. Важность выделения анализа и проектирования состоит в том, что решения, принимаемые на этих фазах, оказывают сильное влияние на весь остальной проект.
Именно поэтому исторически CASE-средства применялись и применяются прежде всего для анализа и проектирования (front end CASE). Более того, часто CASE-средства понимают в таком узком смысле - как средства анализа и проектирования.
Программирование, тестирование, сопровождение
Когда основополагающие решения приняты, остается только их запрограммировать на конкретном алгоритмическом языке или языках. Конечно, это прежде всего кодирование. Когда приложение спроектировано как следует, скажем с помощью правильно примененного CASE-средства, кодирование можно доверить такому ненадежному устройству, как человек. Все равно ему не удастся нанести большого вреда проекту.
Но если уж ошибка проскочила, нужно иметь способ нейтрализовать ее влияние. Конечно, проверки нужно делать на всех этапах разработки, но только после программирования это принимает характер окончательной проверки на соответствие исходным требованиям.
Дальше может оказаться, что требования меняются, выявляются ошибки, не охваченные первоначальным тестированием. Все это соответствует фазе сопровождения.
Применение CASE-средств для анализа и проектирования
Представление знаний. Анализ и проектирование - это принятие решений. Можно еще оговориться, что при анализе фиксируются те решения, которые уже как бы приняты в силу внешних требований, а на фазе проектирования - решения, которые являются в большей степени произволом разработчика. Программная инженерия требует, чтобы, во-первых, все эти решения были зафиксированы. Во-вторых, сформулированы соответствующим образом (однозначно, согласованно, проверяемо и др.). Существуют разные методики, возможен даже вариант, когда эти решения фиксируются посредством фраз на естественном языке. Но как бы то ни было, результат, выходные документы фаз анализа и проектирования есть представление знаний об устройстве приложения.
Методологии анализа и проектирования. Существует целый набор различных методологий. Мы можем упомянуть, что эти методологии бывают ориентированными на процесс, ориентированными на данные и ориентированными на объект. За подробностями мы отсылаем читателя к специальной литературе, например к книге Г. Н. Калянова (см. список литературы в конце статьи). Для нас существенно следующее:
- эти методологии имеют в своем составе достаточно определенно формализуемые правила;
- некоторые детали методик принципиально не формализуемы и требуют непрерывного вмешательства разработчика;
- знания представляются в виде условных диаграмм.
Все это позволило разработать специализированные редакторы диаграмм, которыми, по существу, и являются CASE-средства автоматизации анализа и проектирования.
Применение CASE для других задач автоматизации разработки
В последнее время все более широко в проектах используются CASE-средства автоматизации почти всех видов деятельности программной инженерии, такие как конфигурационное управление, управление проектом, метрики (измерения) на объектах программного проекта, контроль качества и т. д. Все эти термины достойны отдельного рассмотрения.
Единство данных. Если все проектные решения на всех фазах жизненного цикла должны быть согласованы, то это диктует необходимость общего хранилища данных проекта - репозитория. Чем большая часть данных проекта (и главное, данные об отношениях между данными - метаданных) представлена в "машинночитаемом" виде, тем большая часть действий в ходе выполнения программного проекта может быть автоматизирована.
Кодогенерация и повторное использование. Возвратимся к вопросу, можно ли автоматизировать кодогенерацию. Для некоторых случаев да, легко. Например, по диаграмме сущность - связь легко сгенерировать соответствующую ей последовательность операторов на SQL. Очевидно, что это зависит от того, насколько полно формализуется знание о предмете. Знание о реляционных базах данных формализуется полностью. Но хорошо известно также и то, что из соображений производительности полученная схема базы данных почти наверняка будет "слегка испорчена".
Для других видов реализации - кодов на алгоритмических языках - формализация более проблематична. Это связано с большей изменчивостью кода по сравнению с реляционными базами данных. Однако более формализуемо повторное использование, и, следовательно, возможна ее автоматизация. Очевидно, кодогенерацию (если бы мы могли разработать какой-то метаязык для этого) нельзя сделать намного более гибкой, чем повторное использование. Оптимальным представляется сочетание ручной разработки нового кода и повторное использование этого кода там, где возникает необходимость в выполнении сходных задач.
Заключение
Так есть ли такая вещь, как CASE-технология? Создает ли применение средств автоматизации программной инженерии новое качество, новую технологию? И да, и нет. С одной стороны, CASE-технология есть не что иное, как просто автоматизация другой технологии - программной инженерии. А с другой стороны, развитие современной программной инженерии неотделимо от средств ее автоматизации - от CASE-средств. Именно это и имеют в виду те люди, которые употребляют слово CASE в смысле "программная инженерия". Именно об этом мы и попытались рассказать в нашей статье.
Литература
Калянов Г. Н. CASE - структурный системный анализ. М., Лори, 1996.
Боэм Б. У. Инженерное проектирование программного обеспечения. М., Радио и Связь, 1985.
Буч Г. Объектно-ориентированное проектирование с примерами применения. М., Конкорд, 1992.
Гэйн К., Сарсон Т. Структурный системный анализ: средства и методы. Пер. с англ. М., Эйтэкс, 1993.
Коллинз Г., Блэй Д. Структурные методы разработки систем: от стратегического планирования до тестирования. Пер. с англ. М., Финансы и статистика, 1986.
Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. Пер. с англ. Киев, Диалектика, 1993.
Hatley D., Pirhbai I. Strategies for real-time system specification. N.Y., Porset Hause, 1987.
Ward P. T. Mellor S.J. Structured Development of real-time systems. V.1 - 3. N.Y., Yourdon Press, 1985.
Yourdon E. Modern Structured Analysis. N.Y., Yourdon Press/Prentice Hall, 1989.
А. Козлинский, Е. Серяков
Александр Козлинский - директор "МакроПроджект". К нему можно обратиться по телефону: (095) 233-5047 или E-mail: alexk@macroproject.msk.ru.
Егор Серяков - сотрудник "АргусСофт". К нему можно обратиться по телефону:
(095) 288-3603 или E-mail: george@arguss.msk.su.
CASE-технология - совокупность средств и методов для программной инженерии
