`

Schneider Electric - Узнайте все про энергоэффективность ЦОД


СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Что такое CASE?

+22
голоса

Для разработок программного обеспечения характерны в настоящее время высокая степень автоматизации всех работ и массовый переход к индустриализации этого процесса. Это выражается прежде всего во внедрении CASE-систем (Computer-Aided Software Engineering) не только в организациях, занятых производством ПО для последующей продажи, но и в тех, которые разрабатывают его для собственных потребностей и используют эти системы как мощное средство развития (сопровождения) имеющегося ПО.

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

Основные этапы развития методологий разработки ПО

Любая CASE-система реализует некоторую методологию разработки ПО, охватывающую весь жизненный цикл программного обеспечения (ЖЦ ПО). Жизненный цикл - это тот путь, который проходит ПО от зарождения идеи его создания до изъятия из эксплуатации. ЖЦ, таким образом - это модель процесса разработки и сопровождения ПО. Одной из первых таких моделей стала модель, согласно которой процессы кодирования и разработки ПО начинаются почти одновременно. В основе такого подхода лежит представление о том, что написание программы, ее отладку и последующую аппроксимацию к фактическим требованиям пользователя необходимо осуществлять на как можно более ранней стадии. В результате отсутствия предварительных этапов анализа и проектирования ПО как продукт имеет низкие характеристики качества, а последующая модификация его крайне затруднена. Оптимальным вариантом является разработка подобных программ силами одного специалиста, поскольку проблемы управления программным проектом фактически не поддаются решению. Управление прежде всего подразумевает контроль. А что, собственно, можно контролировать? Процесс написания оператора условного перехода или подсчет begin и end? Разработка ПО для нас, в основном, это некоторый вид искусства, а программисты - свободные художники. Управлять такими «художниками» - дело почти безнадежное. Очень сложно что-либо сказать о сроках и стоимости разработки и практически ничего - о качестве. Такой подход теперь часто называют кустарным, иногда - традиционным. К сожалению, именно он превалирует в отечественных разработках.

Что такое CASE?

Рис 1. Жизненный цикл программного обеспечения


В конце 60-х появилась так называемая каскадная модель ЖЦ (рис. 1). Она предполагает наличие последовательных этапов: анализа, проектирования и реализации (значительно позже был добавлен еще один этап - стратегического планирования). Впоследствии и она претерпела изменения.

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

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

  • читаемость и понятность;
  • контроль сложности программы при увеличении ее размеров;
  • контроль связи статистической структуры программы с динамической структурой программы времени выполнения.

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

Что такое CASE?

Рис. 2. Графическое представление моделей и архитектуры ПО


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

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

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

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

Разработка ПО в рамках современных методологий

Рассмотрим более подробно вопрос о том, как собственно работать в соответствии с современными методологиями разработки ПО (в том числе и с CASE-системами, реализующими их). Как уже отмечалось, все начинается с этапа стратегического планирования (в некоторых методологиях этот этап отсутствует, и в CASE, соответственно). Разрабатывается обобщенная модель данной организации, описывающая либо ее информационные потребности, либо процессы, протекающие в ней. Есть сторонники обоих подходов: например, в методологии Информационной инженерии (Information Engineering - IE) Джеймса Мартина (James Martin) во главу угла ставятся информационные потребности, а в методологии STRADIS фирмы McDonnell Douglas - процессы. Разработанная модель становится основой, на которой проводится процесс автоматизации данной организации, и источником планирования этого процесса. Планируется распределение всех видов ресурсов, определяются последовательности работ и их приоритеты. Термин «стратегический» свидетельствует о том, что речь идет о стратегии автоматизации, а не о разработке какого-то конкретного ПО. Необходимость данного этапа обусловлена следующей идеей. В конце концов, утверждают сторонники такого подхода, вы придете к глобальной автоматизации вашей организации, так не лучше ли с этого и начинать, во избежание сложностей, с которыми столкнетесь в противном случае. А сложности могут стать и непреодолимыми, если этот этап проигнорировать.

Исторически процесс автоматизации начинался с разработки небольших программ для отдельных видов работ и подразделений. Со временем появилась необходимость в объединении отдельных программ и систем в рамках единой системы Такой процесс интеграции породил проблему, похожую на ту, что в свое время была в программах языка Фортран с печально известной общей (common) областью этого языка. Бесконтрольное использование этой возможности Фортрана и оператора безусловного перехода (go to) привели к тому, что программы стали напоминать блюдо спагетти: множество программных модулей каким-то образом связаны между собой, но практически невозможно проследить эти связи. В результате, невозможно было предсказать, к каким последствиям для всей программы приведут изменения в одном программном модуле. К тому же и поведение самой программы было, в общем-то, непредсказуемым. Теперь все это повторяется уже на уровне интегрированной системы. Отдельные программы каким-то образом взаимосвязаны, ведь они функционируют в одной организации, но невероятно сложно определить эти связи. Процесс интеграции отдельных программ в единую систему может, таким образом, привести к необходимости повторной разработки уже имеющегося ПО. Далее рассмотрим решение этой проблемы средствами реинжиниринга (reengineering). Итак, в результате работ на этом этапе мы получаем концептуальную модель и план разработки. Концептуальная модель будет основой для следующего этапа - анализа.

Этап анализа начинается с детализации концептуальной модели. Мы уже говорили, что на этом этапе определяется, что собственно подлежит разработке. В современных методологиях анализа для этого предусматривается разработка совокупности моделей, отражающих различные аспекты проблемы. Процессы и потоки информации, протекающие между ними, отображаются диаграммами потоков данных (Data Flow Diagram - DFD), информационные потребности разрабатываемой системы - диаграммами сущность-связь (EntityRelationship Diagram - ERD), временные аспекты функционирования - диаграммами состояний-переходов (State Transition Diagram - STD) (рис. 2). Все три типа диаграмм применяются и на этапе стратегического планирования, но на более обобщенном уровне. На DFD отображаются потоки данных, процессы, преобразующие входные потоки в выходные, хранилища информации, источники и потребители информации, внешние по отношению к системе. Каждый из процессов может быть представлен диаграммой более низкого уровня. В дальнейшем эти диаграммы служат основой для формирования структуры (называемой чаще архитектурой) разрабатываемого ПО. На ERD показываются так называемые сущности (информация, представляющая интерес с точки зрения последующего хранения) и связи между сущностями (с отображением характера связей). Эта диаграмма является основой для проектирования баз данных. На STD отображаются состояния, в которых может находиться система, и возможные переходы из одного состояния в другое. На основе диаграммы затем проектируется интерфейс пользователя. Данный этап заканчивается извлечением предварительной архитектуры системы из совокупности моделей, и эта информация передается на следующий этап. Формируется так называемый словарь данных (Data Dictionary) - перечень описаний всех элементов моделей. В результате мы получаем:

  • модель ПО, представляющую собой совокупность моделей DFD, ERD и STD;
  • словарь данных с описанием всех элементов моделей: потоков данных, хранилищ данных, процессов (в виде так называемых мини-спецификаций), сущностей и их атрибутов, а также связей между сущностями (с описанием характера этих связей), состояний и переходов;
  • план тестирования;
  • предварительную архитектуру системы.


Полученная информация называется структурной спецификацией на разрабатываемое ПО и отражает требования на его разработку.

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

  • архитектуру системы в виде так называемой структурной схемы (Structure Chart - SC), на которой отображены программные модули и связи между ними, а также данные, передаваемые от одного модуля к другому;
  • проект БД и интерфейса пользователя;
  • словарь данных, содержащий описание этих данных и их структуры;
  • спецификации модулей с описанием их назначения и особенностей;
  • проект архитектурных тестов (при которых модули рассматриваются как «черные ящики» без учета их внутренней структуры). Вся эта информация передается на этап детального проектирования. Здесь разрабатываются алгоритмы программных модулей на основе их спецификаций, полученных на предыдущем этапе, а также проекты модульных тестов с учетом их структуры (часто говорят - по методу «белого ящика»), и все это затем переходит на этап реализации.


На этапе реализации программные модули кодируются на выбранном языке программирования в соответствии с разработанными алгоритмами и отлаживаются. Далее, исходя из проектов тестов (архитектурных и модульных), кодируются тесты, и по плану тестирования проводится тестирование программной системы. После этого разработанное ПО передается на сопровождение. Жизненный цикл разработки на этом заканчивается и начинается жизненный цикл ПО.

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

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

Вся информация, получаемая в рамках программного проекта, представляется разумным сочетанием графики и текста, что, конечно, значительно облегчает ее восприятие.

И наконец, интересующий нас объект (ПО) представляется на различных уровнях абстракции: модель-архитектура-алгоритмы-программный код. Некоторые другие преимущества современных методологий мы еще обсудим.

Деятельность (activity)
• составной элемент процесса
Задача (task)
• составной элемент деятельности
Инженерия (engineering)
• систематическое и дисциплинированное применение знаний, методов и средств для производства сложного продукта
Метод (method)
• реализация конкретной методологии; например SSADM
Методология (methodology)
• организованная совокупность процедур, нотации способов; например, структурный анализ, структурное проектирование
Методология разработки (development methodology)
• систематический подход к созданию информационной системы, который определяет этапы разработки и устанавливает виды деятельности, продукты, процедуры верификации, а также критерий полноты каждого этапа
Модель (model)
• представление некоторого фактического или воображаемого объекта с релевантными по отношению к моделируемому объекту характеристиками. Какие особенности являются релевантными, зависит от обстоятельств и подразумеваемого использования модели. Они могут быть внешним проявлением или внутренней структурой, статическими или динамическими, идеальными или аппроксимированными
Программное обеспечение (средство - software)
• комбинация связанных между собой компьютерных инструкций, определений данных и документации, необходимая для выполнения вычислительным устройством вычислительных или управляющих функций;
• программы, процедуры, правила и любая связанная с ними документация, имеющая отношение к эксплуатации компьютерных систем
Процесс (process)
• множество видов деятельности, реализуемых (с процедурами инициализации, выполнения и завершения, определенных для каждого вида деятельности) для достижения конкретной цели или намерения
Процесс разработки (development process)
• процесс, посредством которого потребности пользователя преобразуются в системные требования, требования - в проект, проект реализуется в коде, который затем тестируется, документируется и сертифицируется для последующего использования
Система (system)
• множество компонентов, их взаимосвязи и организация, которая имеется внутри рассматриваемой сферы;
• совокупность людей, машин и методов, организованных для совершения множества конкретных функций;
• интегрированное целое, которое составлено из разных, взаимодействующих, специализированных структур и подфункций
Способ (technique)
• формальная стратегия для выполнения идентифицированной деятельности или задачи

Состав и структура CASE-систем

Мы кратко рассмотрели историю формирования современных методологий разработки ПО и их практическое применение. По мере развития этих методологий осуществлялась и их автоматизация. В промышленности уже существовали такие системы, как CAD (ComputerAided Design - автоматизация проектирования) и САМ (Computer-Aided Manufacturing - автоматизация производства). В сфере разработки ПО аналогичные системы появились значительно позже, и им соответствовали CASA (Computer-Aided Systems Analysis - автоматизация анализа систем) и CAP (ComputerAided Programming - автоматизация программирования). Их объединение и породило CASE (ComputerAided Software Engineering). Причем букву S в аббревиатуре иногда трактуют как слово «system» (система) - в этом случае подразумевается разработка не только программного, а программно-аппаратного обеспечения. Годом рождения CASE считается 1984 г., когда на рынке ПО появились первые графические средства анализа. В отечественной литературе так до сих пор и не пришли к какому-то одному варианту перевода этого термина. Вы можете встретить следующие: система автоматизации проектирования программного обеспечения (САПР ПО); автоматизация инженерии программных средств; автоматизация разработки ПО; автоматизация программирования.

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

Итак, CASE обеспечили автоматизацию на протяжении всего ЖЦ ПО равномерной поддержкой всех его этапов. Это является главным аспектом CASE, но не единственным. Современные разработки требуют усилий десятков и сотен специалистов. Следовательно, каким-то образом должна решаться проблема координации их работ. Роль дирижеров взяли на себя менеджеры программных проектов, деятельность которых также необходимо было автоматизировать. Другой проблемой, требующей решения, стало качество ПО, от которого зависит функционирование всей организации. Причем чем выше уровень ее автоматизации, тем выше риск от применения ПО. Очередной задачей является выполнение требований на разработку ПО. Несмотря на эффективные методологии анализа, по окончании разработки обнаруживается масса неучтенных требований (соответственно и нереализованных). Возникла необходимость в макетировании (прототипировании) разрабатываемого ПО с тем, чтобы заказчик мог как можно раньше получить представление о том, что он будет иметь в конечном итоге. При этом желательно максимально довести полученный прототип до действующего ПО. И наконец, проблема, относящаяся к внедрению CASE в организациях, заключается в самом ПО, уже находящемся в эксплуатации. Оно было разработано задолго до того, как появились первые CASE, и не очень-то вписывается в них. Создавать ПО заново, но уже в соответствии с современными методологиями на современных инструментальных средствах - CASE? Но речь может идти о сотнях тысяч и даже миллионах строк исходного текста. Не делать этого, но тогда как провести интеграцию старого ПО с новым, если последнее разрабатывать на CASE? Таким образом, потребовались способы препарирования старого ПО с последующим приведением его в соответствие с требованиями современных методологий разработки и конкретной CASE-системой.

Рассмотрим кратко все эти проблемы и варианты их решения в рамках CASE, поскольку от этого во многом зависит состав этих систем. Начнем с аспектов прототипирования и частичной или полной генерации готового к эксплуатации ПО. Для этого опять проведем небольшой экскурс в прошлое, а именно в историю языков программирования.

В далекие времена рождения первых компьютеров единственным способом общения с ними был машинный язык. Он состоял из нулей и единиц, посредством которых писались программы. Это было первое поколение языков программирования, работа на которых характеризовалась огромной трудоемкостью. Поэтому написать что-то более или менее серьезное было практически невыполнимой задачей. Единственным их преимуществом была возможность писать очень эффективные по памяти и быстродействию программы. Частичным решением проблемы высокой трудоемкости стало появление языков ассемблера. Машинным командам были поставлены в соответствие более пригодные для восприятия символьные аналога. Кроме того, в таких языках были введены обобщенные команды, так называемые макрокоманды - совокупности команд, выполняющих определенные функции. Производительность труда программистов несколько повысилась, но снизилась (за счет макрокоманд) эффективность программ. Теперь языки ассемблера принято называть языками второго поколения. Несмотря на некоторое продвижение вперед, они были языками все еще очень низкого уровня, не позволяя значительному увеличению объемов и сложности программ. Следующий шаг в этом направлении был сделан языками третьего поколения, такими как Фортран, Кобол и др. Продолжилось обобщение конструкций языков более низкого уровня, появилось такое понятие, как «подпрограммы». Стала возможной разработка относительно серьезных программ. К тому же, начали формироваться современные методологии разработки. Особенностью всех трех поколений языков программирования является их процедурный характер, который заключался втом,что необходимо было точно описать, как должен работать компьютер для выполнения требуемой задачи. Разница между этими языками заключалась в степени детализации такого описания. Дальнейшее развитие языков программирования, с одной стороны, пошло по прежнему пути обобщения конструкций языков предыдущих поколений, с другой - ознаменовалось переходом от процедурного характера описания к декларативному, т. е. описывается не то, как надо что-то делать, а то, что, собственно, надо делать. Так появились языки четвертого поколения - 4GL (4 Generation Language). Они построены на принципе таких обобщенных функций, как создание экранных форм, баз данных и документов. По описанию таких функций генерируется программа либо на одном из известных языков программирования, либо на специфичном для этого 4GL языке третьего поколения. Как правило, в интерактивном режиме вы можете описать нужные экранные формы - меню и подменю, поля ввода/вывода, контекстно-зависимые подсказки. Точно так же можно описать структуры ваших баз данных, ключевые и неключевые поля, пароли доступа разного уровня. Аналогично в интерактивном режиме можно определить структуру выходных документов, предназначенных для печати. Дальнейшим развитием таких 4GL стали генераторы программ (приложений), частью которых они теперь являются. Дело в том, что 4GL чаще всего не реализуют сложной программной логики и вычислений. Кроме того, они не всегда (или ограниченно) позволяют подключать программные модули, написанные на традиционных языках программирования третьего поколения. Генераторы компенсируют эти недостатки. Принцип их действия таков: что можно, то генерируется (средствами 4GL). Для фрагментов программы, не поддающихся генерации, подключаются уже готовые к использованию программные модули (offthe-shelf) либо генерируется некоторый шаблон, в который надо вписать программный код вручную. Как правило, фирмы -поставщики СУБД в большинстве своем довели свои продукты до уровня 4GL. Некоторое время 4GL предлагались как альтернатива CASE. В самом деле, зачем «городить огород» из моделей, общего и детального проектирования, когда можно взять такой язык и сделать все, что нужно. Однако практика показала, что такой подход срабатывает до определенного уровня сложности ПО, после превышения которого программы начинают вести себя самым непредсказуемым образом. И значит, по-прежнему необходимо тщательно проектировать ПО, а уж потом переходить к его реализации, даже если оно полностью базируется на 4GL. Таким образом, 4GL стали составной частью современных CASE. Информация, полученная на этапах анализа и проектирования, подается на 4GL, который и генерирует все иди часть (как правило, основную) ПО. После этапа анализа можно быстро разработать прототип, демонстрирующий основные функции и внешнее представление разрабатываемого ПО, на его основе уточнить окончательные требования и далее довести его до действующего ПО. При необходимости можно дописать вручную отдельные его части.

Что такое CASE?

Рис. 3. Реинжиниринг ПО

Проблема приведения уже имеющегося ПО в соответствие с выбранной методологией разработки (соответственно, с CASE, которая ее реализует) решается в рамках так называемого реинжиниринга ПО. Как правило, в нем выделяют три аспекта: передокументирование (redocumentation), переструктурирование (restructuring) и обратный инжиниринг (inverse, иногда - reverse, engineering). Инструментальные средства передокументирования берут на вход существующий исходный текст программы и проводят его анализ с целью получения перекрестных ссылок и потоков управления в программе. При этом генерируются блок-схемы (или иная графическая форма представления) программы, описание данных и места их использования, а также другие особенности. Функции средств переструктурирования программы предусматривают анализ исходного текста на предмет приведения кода к некоторому стандартному виду и устранения избыточности. Кроме того, часть кода может быть создана заново. Наиболее важной частью реинжиниринга являются средства обратного инжиниринга. Когда мы говорили о методологиях разработки ПО, имелся в виду прямой инжиниринг: мы шли от требований через проектирование (общее и детальное) к исходному тексту программ. Теперь весь путь проходится в обратном порядке. На вход средств обратного инжиниринга подается исходный текст программы. После соответствующего анализа создаются алгоритмы (например, в виде блок-схем). Далее реконструируется архитектура программы (в виде структурных схем). И наконец, создается совокупность моделей рассматриваемого ПО (диаграммами DFD, ERD и STD). Нужно учесть, что на этом пути есть определенные сложности, требующие вмешательства экспертов. Дело в том, что любое ПО, как известно, имеет «две стороны медали» - данные и процедуры их обработки. Существующие методологии разработки предоставляют однозначное соответствие по данным: ERD - проект БД (например, реляционные таблицы) - программный код. Все это можно проделать и в обратном порядке при реинжиниринге. Другое дело с процедурами обработки. Здесь такой однозначности нет. Из одной совокупности DFD можно создать несколько архитектур ПО, и все они будут соответствовать сформулированным требованиям. Кроме того, для полученного алгоритма необходимо словесное описание. Тем не менее, при определенных усилиях проведение обратного инжиниринга возможно. Стоимость этих усилий, по данным зарубежной печати, может составлять от 20 тысяч до нескольких сотен тысяч долларов. Но, судя по расширению рынка услуг и инструментальных средств реинжиниринга, эти затраты себя окупают. После всех работ наступает самый ответственный этап, ради чего все это и делается, а именно анализ на предмет улучшения и развития рассматриваемого ПО (рис. 3). Но это уже аспекты прямого инжиниринга, который мы рассматривали. К наиболее важным результатам данного процесса следует отнести возможность согласования старого и вновь разрабатываемого ПО. После проведения этой работы появляется возможность использования CASE как инструмента сопровождения ПО, прошедшего реинжиниринг. О некоторых других существенных возможностях рассмотренных средств упомянем позже.Главное, что средства реинжиниринга стали составной частью CASE.

Теперь обсудим такие аспекты, как качество ПО и его связь с CASE. При традиционной разработке мы получаем в результате исходные тексты, документацию по эксплуатации и неформальные (написанные на естественном языке) требования к ПО. Каким-то образом оценить качество этой информации очень сложно. В те далекие времена, когда информатика только зарождалась, такие попытки предпринимались и сводились к определению сложности программ и отдельных программных модулей, степени их комментируемости и полноты реализации требований в разработанном ПО. О таких характеристиках качества, как надежность, возможность расширения и адаптации ПО к изменяющейся среде функционирования, мобильность и другие, можно было только гадать. В самом деле, сложность и комментируемость не так много говорят об эксплуатационных свойствах. А соответствие ПО требованиям на него вообще нельзя оценить в полной мере. Требования на разработку составлялись на естественном языке, который изобилует массой неоднозначностей, вследствие чего они могут интерпретироваться разными людьми самым различным образом (вплоть до прямо противоположных). Кроме того, нет связи этих требований с кодом программ. В современных методологиях такая связь устанавливается посредством этапов общего и детального проектирования, которые являются как бы мостом между требованиями (совокупностью моделей этапа анализа) и кодом. Но главное даже не в этом. При традиционной разработке мы получаем уже готовую программу и поставлены перед фактом ее существования. Допустим, мы каким-то образом пришли к выводу о ее низком качестве. Что делать в этом случае? Оставить все как есть и с замечаниям! I передать на эксплуатацию? Или попытаться откорректировать и потом вновь провести оценку качества? Но программы, написанные таким образом, подобны карточному домику-тронь их, и они рассыплются. Эти проблемы и были решены (относительно полно) современной дисциплиной качества ПО, основанной на современных методологиях разработки. Эта дисциплина состоит из двух взаимосвязанных частей: инженерии качества ПО (Software Quality Engineering - SQE) и обеспечении качества ПО (Software Quality Assurance — SQA). SQE занимается вопросами оценки качества как промежуточных (этапов анализа и проектирования) продуктов программного проекта, так и конечного (этапа реализации), т. е. собственно ПО. Требования на качество поступают на этап анализа вместе с функциональными требованиями на ПО. Это устраняет один из недостатков традиционной разработки, при которой требования на качество не предъявлялись. Выполнение этих требований отслеживается на протяжении всего программного проекта. SQA занимается организационными вопросами оценки и управления качеством на протяжении всего проекта для каждого этапа ЖЦ. Итак, мы рассмотрели еще одну составную часть современных CASE.

Теперь, завершая обсуждение состава современных CASE, перейдем к интеграции информации и инструментальных средств в этих системах, а также к связанным с ними аспектами управления программным проектом.

Как правило, выделяют следующие формы интеграции:

  • интеграция данных;
  • интеграция контроля;
  • интеграция представления.


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

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

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

Что такое CASE?

Рис. 4. Каркас для CASE

К сожалению, нет какой-нибудь согласованной стратегии для построения и использования интегрированных CASE. Наиболее серьезной попыткой в этом плане можно считать стандарт на так называемый каркас (framework) для интеграции инструментальных средств CASE. Он разработан в рамках Европейской ассоциации производителей компьютеров (European Computer Manufacturers Association - ЕСМА). Смысл предлагаемого подхода в том, что такой каркас для CASE должен служить объединению множества методологий и инструментальных средств «под одной крышей» (рис. 4).

Все виды интеграции способствуют эффективности управления программным проектом, осуществляемого средствами IPSE и ICASE. Надо отметить, что существует некоторая путаница в понятиях IPSE (Integrated Project Support Environment - интегрированная среда поддержки проекта) и ICASE (Integrated CASE - интегрированная CASE). Разница между ними в том, что ICASE разрабатывается, как правило, одним поставщиком и предназначается для обслуживания одного программного проекта. При этом ICASE орие1ггирована на конкретную методологию разработки, опять же реализованную данным поставщиком (исключения составляют совместные разработки нескольких фирм, являющихся стратегическими партнерами на рынке CASE-средств). IPSE же предназначена для коллективов, работающих одновременно над разными проектами и даже в разных методологиях разработки. Причем конкретная IPSE не привязана к поставщику CASE-средств. Возможности работы одновременно над разными проектами важны не только сами по себе, но и как средство избежания дублирования (вряд ли в рамках одной организации будет слишком большой разброс разрабатываемого ПО). Каркасы, подобные описанному, реальны благодаря высокому уровню стандартизации как на национальном уровне, так и в рамках европейского (стандарты ЕСМА) или международного сообщества (стандарты ISO — Международной организации по стандартам).

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

  • средства поддержки всех этапов жизненного цикла ПО;
  • язык четвертого поколения;
  • средства сбора статистики и оценки качества;
  • средства реинжиниринга;
  • средства управления программным проектом.


Как правило, обеспечивается широкая поддержка этапов жизненного цикла - этапов анализа и общего проектирования, реже - этапов детального проектирования и реализации. Такую позицию поставщики аргументируют наличием 4GL, когда необходимость кодирования вручную якобы отсутствует, что достаточно спорно. Чаще всего большинство поставщиков CASE комплектует их 4GL или другими вариантами генерации ПО, причем либо собственного производства, либо других фирм (возможны оба варианта). Не часто предоставляются возможности управления проектом, да и то в самом ограниченном виде (вы можете, к примеру, закрепить конкретных участников проекта за определенными видами работ, но контроль их деятельности не автоматизируется). Еще реже получает пользователь средства оценки качества. Вместо них - возможности сбора статистики, которую вы вольны интерпретировать тем или иным образом. В последнее время стали поставляться средства реинжиниринга, но ориентированные на продукты конкретной фирмы. Тем не менее, намечается тенденция реализации всех перечисленных возможностей либо конкретными поставщиками CASE, либо совместными усилиями в рамках кооперации.

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

Теперь, когда общая картина нарисована, можно перейти к вопросам необходимости внедрения CASE-систем и проблемам, связанным с этим.

Внедрение CASE-систем

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

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

Повышение производительности достигается двумя путями. Так, применение языков четвертого поколения 4GL может увеличить этот показатель в 10-20 раз. Другой путь - возможность повторного использования компонентов программных проектов, а именно: моделей и архитектуры (или их частей), алгоритмов и исходных текстов. В силу того, что для разработки всех программных проектов применяется одна методология, упрощаются создание и поиск таких компонентов. Средства CASE-систем позволяют сделать вырезку по необходимым компонентам. Поскольку существует полная навигация по проекту сверху вниз, можно, отметив, какая часть старой модели необходима, «вытянуть» все, что с нею связано, - соответствующие ей части архитектуры, алгоритмы и исходные тексты - и затем вставить все это в новый проект.

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

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

Будучи продуктом производственной деятельности, ПО теперь, как и любой другой продукт, обладает таким ценным качеством, как максимальная отчужденность от производителя. Этот вопрос может стать для отечественных пользователей ПО очень актуальным и сейчас практически никак не решается. Известно, что ПО, построенное традиционным способом, может изменить только тот программист, который его разрабатывал (да и то не всегда). Предложите любому программисту модифицировать чужую программу, и он вам резонно заметит, что ему проще и быстрее разработать ее заново. В рамках CASE все специалисты на протяжении ЖЦ ПО работают с одними и теми же инструментальными средствами в соответствии с одной и той же методологией и по одним стандартам. Поэтому проблем манипуляций с ПО на этапе сопровождения не возникает, поскольку имеется не допускающая различных интерпретаций полная и согласованная информация о конкретном ПО. Независимость программного продукта от разработчика - производителя этого продукта важна и по другой причине. Приводятся в соответствие роли людей и их значимость в данной организации. Роли определяются штатным расписанием. Значимость зависит, конечно, от конкретного индивидуума, но остается в рамках отведенной ему роли. Такое положение характеризует разумно построенные организационные структуры. А теперь посмотрим, что происходит у нас. Роль программиста, по идее, очень невысока - низший исполнительский уровень организационной структуры. А вот значимость может перерасти даже таковую руководителя организации, в которой он работает. Это произойдет, если разработанное им ПО критично по отношению к функционированию данной организации. Ведь только он является единовластным «хозяином» этого ПО. То, что наших руководителей это пока не волнует объясняется очень просто - крайне низкой степенью автоматизации организаций. Это не «дикий Запад», где разрабатываются и внедряются так называемые стратегические информационные системы. Такие системы призваны служить главным стратегическим оружием в конкурентной борьбе и охватывают деятельность всей организации. Наши успехи в этом направлении ограничиваются, как правило, небольшими, мало связанными между собой островками автоматизации, беспорядочно разбросанными по организации. В силу этого зависимость от ПО, соответственно и от программистов, его разработавших, пока не ощутима. Но это уже скорее культурные, чем технические аспекты. И еще ддин аргумент в пользу необходимости внедрения CASE. По сути, вы внедряете не просто новые технические приемы, а иную, более высокую культуру разработки ПО. Апологеты современных методологий разработки ПО любят приводить следующий довод: «Если единственным инструментом в руках человека является молоток, то весь мир, во всем его многообразии, естественно, представляется ему местом для забивания гвоздя». Иными словами, примитивные орудия труда неминуемо формируют примитивность мышления и соответствующие представления о сути автоматизации. Наши разработчики традиционно имели в руках именно молоток-компилятор, а если повезет, то хорошее зубило-отладчик. Таким образом, с внедрением CASE-систем появляется возможность изменить нынешнюю ситуацию в лучшую сторону.

Проблемы внедрения CASE-систем

Переход к CASE означает, как мы отметили, кроме всего прочего, более высокую культуру разработки ПО. Но, купив CASE, вы приобретаете лишь инструментальные средства и методологию для такого перехода. Культуру как таковую придется «выращивать» на своем, отдельно взятом «огородике», и в этом, наверное, главная проблема. К сожалению, мощная западная инфраструктура информатики нам не поможет, поскольку мало доступна, а своя только формируется. В начале этой статьи шла речь об этапах развития методологий разработки ПО. С развитием методологий появлялись инструментальные средства их поддержки. Как вы помните, в каскадной модели ЖЦ ПО в виде лестницы нижняя ступенька отведена структурному программированию, следующая - структурному проектированию, еще выше - структурному анализу, и наконец, самая высокая - стратегическому планированию. Так, шаг за шагом, развивалась методология, и ступенька за ступенькой, карабкались вверх и разработчики (западные), осваивая не только новые методы, но и профессии. Подобного эволюционирования отечественные разработчики были лишены. На это нужно определенное время.

От внедрения таких систем часто ждут мгновенных результатов. Грешат этим, как правило, руководители различного уровня. Не дождавшись их, начинают относиться ко всем нововведениям с изрядной долей скепсиса. Нередко в оппозицию становятся и ведущие программисты. Сознательно или нет, но они понимают, что их статус со временем резко изменится. В настоящий момент они «надежда и опора» в области автоматизации своих организаций. С переходом к CASE-системам им, возможно, придется довольствоваться скромной ролью «винтиков» в большом и сложном механизме. Но ведь в настоящий момент это наиболее авторитетные и влиятельные группы - и они становятся в оппозицию по отношению к CASE-системам. Как результат - сильно тормозится процесс внедрения. Даже будучи купленными (и такие случаи есть), эти системы складываются в ящик и убираются подальше. Беда здесь в том, что дискредитируется сама идея, вернуться к ней позже будет намного сложнее.

Допустим, однако, что CASE-система выбрана, приобретена и установлена. Все прониклись важностью исторического момента, отведено достаточно времени на освоение, созданы необходимые условия. А кто на ней будет работать? Типичное подразделение по разработке ПО состоит из программистов и одного-двух администраторов. Но уже говорилось, что придется осваивать новые профессии. А профессия - это не только сумма знаний и опыт практической работы, но и склонность к тому или иному виду деятельности. Как такую склонность определить, да еще и не ошибиться? Здесь уместно уделить немного внимания проблемам освоения методологий отдельных этапов ЖЦ ПО.

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

С другой стороны, для программиста все сложности концентрируются в языках программирования, компиляции, компоновки, сетевых протоколов и т. д. Языки используются и в процессе моделирования, но они просты. В DFD, например, всего четыре языковые конструкции: источники и потребители информации, потоки данных, процессы и хранилища. Простота языков создает иллюзию простоты процесса - моделирования. Как следствие, вся работа сводится к рисованию кружков, квадратиков и линий связи между ними. Такие рисунки, конечно, будут слишком хрупким фундаментом для ПО, поскольку игнорируются главные принципы (философия), лежащие в основе этого процесса. Вот почему на этом этапе рекомендуется забыть программирование как кошмарный сон. Чем прочнее забудете, тем лучше будете моделировать. Это полезно еще и потому, что в этой работе не применимо^блок-схемное мышление (потоками управления), свойственное программистам.

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

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

Что такое CASE?


Вы можете подписаться на наш Telegram-канал для получения наиболее интересной информации

+22
голоса

Напечатать Отправить другу

Читайте также

 
 
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT