Software & Systems

Что такое CASE-система?

В последние годы на мировом рынке программных продуктов появилось много программных средств, называемых CASE-cucme-мами, CASE-инструментами или CASE-средст-вами (CASE-tools). Слово CASE является сокращением от Computer Aided Software Engineering. В русскоязычной литературе нет общепринятого соответствующего термина. Мы предлагаем русский термин, который является достаточно разумной и благозвучной калькой английского: "Программная Инженерия, Поддерживаемая Компьютерами" (или "с Помощью Компьютеров"), сокращенно — ПИПК.

CASE-Системы и соответствующий термин появились не в научных, а в производственно-коммерческих кругах. Теоретическое осмысление этого явления и его места в методологии и технологии программирования (программной инженерии) только начинается [1]. На русском языке имеются довольно поверхностные обзоры коммерческих CASE-систем [2, 15], в которых кратко перечисляются средства, включенные в ряд конкретных систем, и упор делается на внешние характеристики интерфейса.

Рассмотрим сначала спектр значений, фактически покрываемых термином CASE-система, а также соотношение этого спектра с давно используемыми в методологии программирования понятиями среды программирования (programming environment) и среды разработки программ (software development environment -кстати, букву Е в CASE расшифровывают и как Environment).

Если термин CASE понимать буквально, то CASE-системой можно считать всякую программную систему, помогающую в разработке программ, включая любой транслятор или систему программирования. Но CASE-системы, первоначально появившиеся на рынке программных продуктов под этим названием (такие как Exelerator [2]), — это системы, поддерживающие.этап анализа проектируемой системы и фиксацию результатов этой работы в виде соответствующих спецификаций. По мере того как слово CASE входило в моду, им стали называть самые разные инструментальные программные средства, относящиеся к автоматизации проектирования и разработкам программ. Поэтому имеет смысл ввести' некоторую классификацию CASE-систем.

Прежде всего CASE-системы классифицируются по уровням (или этапам) разработки программ, которые они охватывают, т.е. содержат средства, помогающие в работах, относящихся к этим уровням или этапам. Различают верхние (upper) и нижние (lower) системы [7].

Верхние CASE-системы поддерживают работы по уточнению постановки задачи и анализу проектируемых систем, в ходе которых составляются, корректируются и анализируются спецификации систем. Так как верхние CASE-системы поддерживают те же виды работ, что и упомянутые выше первоначальные CASE-системы, их называют еще нормальными [10].

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

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

По степени интегрированности и полноте охвата работ различают менее полные и слабо интегрированные CASE-инструментарии (toolkit) и более полные и интегрированные CASE-АРМы (workbench) [7]. Сопоставим интегрированные CASE-системы со средами программирования и средами разработки программ. Интеграция, обеспечиваемая типичной средой рограммирования, касается средств более низкого уровня (этапа) разработки программ, чем'в CASE-системах (компилятор с языка программирования, текстовой редактор, отладчик). В типичных интегрированных средах разработки программ интеграция охватывает, кроме указанных средств среды программирования, еще и средства, поддерживающие коллективную работу над большими и сложными проектами (соответствующим образом организованную библиотеку программной документации, средства связи между разработчиками и отслеживания версий).

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

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

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

Методы спецификации программ в CASE-системах

Методологической основой нормальных (верхни-х) CASE-систем являются методы спецификации программ. Спецификацией программы (program specification) называют описание задачи, которую должна решать программа. Задача может быть как простой функцией, так и сложной системой. В последнем случае постановка задачи становится анализом проектируемой системы, а постановщика задач называют системным аналитиком. Результатом постановки задачи или системного анализа является спецификация, в которой фиксируется понимание задачи или проектируемой системы. Спецификация большой н сложной системы включает в себя много подспецификаций, так же как большая программа включает много подпрограмм (модулей). Людей, составляющих спецификации, называют еще спецификаторами (specifier), а спецификацией называют и деятельность по разработке спецификаций.

Для поддержки спецификации программ как деятельности, отличающейся от разработки собственно программ, создано большое количество разнообразных языков спецификации (см. [13, 16]). Они отличаются от языков программирования более высоким уровнем и выразительностью, ориентацией на удобство, естественность и наглядность описания задач и систем. В коммерческих CASE-системах используются графические языки спецификации, позволяющие применять в спецификациях наглядные графические средства описания - диаграммы того или иного типа, сети, деревья и т.д. Такие языки появились в 70-х годах задолго до появления коммерческих CASE-систем и использовались как вручную, так и с компьютерной поддержкой на больших ЭВМ [14]. Однако только благодаря развитию и широкому распространению относительно дешевых графических средств на микроЭВМ и рабочих станциях стало рентабельным создание коммерческих CASE-систем, использующих графические языки спецификации.

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

1) диаграммах потоков данных (data flow digram),

2)      диаграммах объектов - связей (entity — relationship diagram),

3)      диаграммах переходов состояний (state- transition diagram).

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

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

цию, в которой "Заказчик" является внешним узлом, "Продукция" и "Заказчики" - это узлы хранения данных о продукции и заказчиках, а занумерованные узлы - это узлы обработки данных.

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

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

Диаграмма объектов-связей (или сущностей-связей) содержит узлы двух типов: для объектов (сущностей) и для связей (отношений). Дуги соединяют узел-отношение (связь) с его аргументами (объектами). На рисунке 3 показан фрагмент диаграммы объектов-связей, в которой объектами являются "врач", "пациент", "диагноз" и "анализ". Диаграммы объектов-связей часто используются для описания концептуальных схем баз данных (информационных систем).

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

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

Что касается диаграмм переходов состояний, то для применения к описанию достаточно сложных систем реального времени их обобщают и расширяют дополнительными средствами. В CASE-системе STATEMATE [4] введено обобщение диаграммы состояний, позволяющее "укрупнять" состояния и дополнять тем самым диаграмму структурой, упрощающей ее понимание. На рисунке 5,а показана обобщенная диаграмма состояний, полученная из обычной диаграммы (рис. 5,6 объединением состояний S и Т в новое укрупненное состояние V, явно демонстрирующее общность поведения состояний S и Т для входного сигнала f. В ряде методологий спецификации программ, ориентированных на описание систем реального времени, обобщения н модификации диаграмм переходов комбинируются с диаграммами потоков данных и другими средствами описания (например средствами контроля времени) [5, II, 12].

Создатели первых коммерческих CASE-сис-тем воспользовались лежавшими на поверхности, не слишком изощренными методами спецификации программ. Вместе со своим программным инструментом они навязывают пользователям включенную в него методологию в той специфической форме, в которой она там представлена. Это явление выразительно названо "инструментальным империализмом" [7].

Для более современных интегрированных CASE-систем характерно использование более разнообразных и изощренных методов спецификации. Например в системе IEF, основанной на методологии IEM (Information Engineering Methodology) используется несколько типов диаграмм на разных уровнях анализа и проектирования систем [6]. Упомянутая выше система STATEMATE является ярким примером реализации в коммерческой производственной CASE-системе оригинальных научных разработок в области языков спецификации и тщательно продуманной методологии, комбинирующей разные языковые средства.

Развитие интегрированных CASE-систем приведет к большему языковому плюрализму и обеспечению пользователям большей свободы выбора из уже наработанного многообразия средств описания. На преодоление "инструментального империализма" (не только программного, но н языкового) направлена и разрабатываемая автором система ПТО [13] — база знаний по спецификации программ, которая помогает подобрать подходящие понятия для описания задач и систем, найти или создать приемлемый язык спецификации, а также найти подходящую систему поддержки спецификации программ.

В развитых CASE-системах, таких как STATEMATE и IEF, выразительные графические средства описания систем дополняются средствами прототипирования, позволяющими демонстрировать выполнение (интерпретацию) спецификаций на вычислительной машине. Методы построения прототипов как выполнимых спецификаций (в отличие от прототипов на языках программирования) образуют перспективный класс методов спецификации программ, применение которых в CASE-системах будет расширяться. Это относится как к прототипиро-ванию на основе графических языков спецификации (диаграмм потоков данных [3, 8], диаграмм переходов состояний [4, 12], сетей Петри и др.), так и к неграфическим языкам - функциональным, реляционным, логическим.

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

Список литературы

1. Bjorner D. Formal methods in software development: Requirements for a CASE. - Lecture Notes in Computer Science, 1991, voL 509, p. 178-210..

2.        CASE-средства для ПЭВМ. - Программные продукты и системы, 1991, N1, с.39-43, N2, с.56-57.

3.        Docker T.W.G., France R.B. Flexibility and rigour in structured analysis. - Information Processing 89, 1989, p.89- .94.

4.        Harel D., Lahover H. et al. STATEMATE: A working environment for the development of complex reactive systems. - IEEE Transactions on Software Engineering, 1990, 16, N4, p.403 -414.

5.        Hatley D.J., Pirbhai l.A. Strategies for real-time system specification. - New York: Dorset House Publishing, 1987.

6.        MacDonald I.G. Automating the Information Engineering Methodology with the Information Engineering Facility. - Computerized Assistance During the Information Systems Life Cycle, 1988, p.337-373.

7.        Nilsson E.G. CASE tools and software factories. - Lecture Notes in Computer Science, 1990, 436, p.42-60.

8.        Olson C, Webb W., Wieland R. Code generation from data flow diagrams. - Third International Workshop on Software Specification and Design, 1985, p.172-176.

9.        Parkinson J. Making CASE work. - Lecture Notes in Computer Science, 1990, 436, p.21-41.

10.       Suomi R. Selecting system development tools: some experiences. - Lecture Notes in Computer Science, 1990, 436, p.61-78.

11.       Ward P.T., Mellor S.J. Structured development for real time systems. - Prentice-Hall, 1985.

12.       Zave P., Jackson D. Practical specification techniques for control-oriented systems. - Information Processing 89, 1989, p.83-88.

13.       Агафонов Я.Н. Спецификация программ: понятийные средства н их организация. - Новосибирск: Наука, 1990, - 224 с.

14.       Белл Т., Бккслер Л., Дайер М. Расширяемая система автоматизированной разработки требований к программ ному обеспечению. - В кн. Требования и спецификации в разработке программ. - М.: Мир, 1984, С. 47-76.

15.       Маклауд Дж. Инструментапьные средства автоматиза ции проектирования программного обеспечения встроен ных систем. - Электроника. - 1988. - N24 (803), С. 46-S1.