IV конференция «ТРИЗ. Практика применения методических инструментов»

О классификации систем автоматизированного проектирования

и создания программ (CASE)

Бердоносов Виктор Дмитриевич – к.т.н., доцент, профессор кафедры «Информационные системы» ФГБОУВПО «КнАГТУ» (г. Комсомольск-на-Амуре); e-mail: ktriz@knastu.ru

Редколис Елена Валерьевна – аспирант кафедры «Информационные системы» ФГБОУВПО «КнАГТУ» (г. Комсомольск-на-Амуре); e-mail: Lulumzja@mail.ru

 

Аннотация: При помощи методики оценки идеальности и определения направлений совершенствования программного обеспечения были выделены линии эволюции CASE-систем, проанализировано назначение и тенденции развития каждой линии, построены ТРИЗ-эволюционные карты. Была систематизирована эволюция нескольких сотен CASE-систем, движущей силой которой явилось разрешение противоречий инструментами ТРИЗ. В качестве критериев, в соответствии с которыми происходило и происходит развитие CASE-систем, были определены «полезность» и «затратность». Использование такого подхода для целей обучения позволяет значительно сократить время на освоение большого количества CASE-систем за счёт систематизации знаний, которая позволяет: 1) выявить приоритетные направления дальнейшего развития CASE-систем; 2) упростить подбор подходящей для целей использования CASE-системы на предприятии; 3) апробировать применение инструментов ТРИЗ для разрешения противоречий, возникающих в CASE-системах.

Ключевые слова: CASE, вектор идеальности, разрешение противоречий, систематизация знаний, ТРИЗ-эволюционная карта.

Введение

В работах [1-3] предлагается использовать ТРИЗ для систематизации знаний исследуемой предметной области. Для относительно простой, с точки зрения эволюции, развитие предметной области (или её фрагмента) можно представить вектором. В этом векторе объекты исследуемой предметной области выстраиваются по степени увеличения идеальности в ТРИЗовском смысле, а переход от объекта к объекту реализуется как последовательное преодоление противоречий инструментами ТРИЗ. Для более сложных предметных областей, рассматривается не вектор, а карта (матрица), в которой представлен вектор групп объектов, и каждая группа тоже в свою очередь представлена векторами. Таким образом, для построения ТРИЗ-эволюционной карты необходимо:

• собрать сведения об объектах исследуемой предметной области;
• выявить группы объектов и оценить  идеальность каждой группы;
• расположить группы объектов по степени увеличения идеальности;
• выявить определяющее противоречие для каждого группы;
• определить инструмент ТРИЗ, разрешивший противоречие;
• проделать приведённые выше шаги для объектов каждой группы.

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

Оценка идеальности CASE-систем

Рассмотрим Методику оценки идеальности и определения направлений совершенствования программного обеспечения [5] (далее – методика), в основе которой лежит применение инструментов ТРИЗ [3]. Назначение методики: 1) Систематизация информации о каком-либо классе программного обеспечения (ПО); 2) Оценка идеальности программных продуктов, входящих в исследуемый класс ПО; 3) Определение направлений совершенствования всего класса ПО и отдельных программных продуктов. Оценим идеальность и определим направления совершенствования CASE-систем на основе разработанной методики:

1. Определимся с терминологией, применительно к рассматриваемой предметной области.

CASE (от англ. «computer-aided software engineering») – инструменты автоматизированного проектирования и создания ПО и организационно-управляющих систем.

2. Составим перечень программных продуктов, попадающих под определение CASE-систем. Используем классификацию  А. Фуггетта [4], пересмотренную и адаптированную под современное состояние [5]. CASE-системы разделены на 3 класса (рис. 1):

• «Tools» – инструменты, поддерживающие только определенные задачи;
• «Workbenches» – рабочие приложения, поддерживающие определенный вид деятельности;
• «Environments» – программные среды, поддерживающие большую часть процессов.

Рис. 1 – Классификация CASE-систем

 

3. Для каждого из классов (п. 2) составим перечень реальных программных продуктов. В ходе выполнения методики были рассмотрены 222 CASE-системы.

4.   Реальные системы (п. 3) оценим по 60 сформулированным критериям, отражающим «полезность» (количество функциональных возможностей) и «затратность» (стоимость использования).

4.1.   Заполним вектора оценок значимости критериев, отражающие полезность и затратность, для рассматриваемых систем;

4.2.   Вычислим вектора весов критериев, отражающих полезность (Wu) и затратность (Wc);

4.3.   Получим значения матрицы оценок систем по n-критериям, отражающим полезность (Eu) и затратность (Ec).

5.   Вычислим скалярные произведения векторов (Wu, Eu_p), (Wc, Ec_p), где Eu_p – вектор-столбец Eu , Eс_р– вектор-столбец Ec_.

6. Вычислим компоненты вектора идеальности (I) CASE-систем (частные от деления (Wu, Eu_p) и (Wc, Ec_p)). Произведем коррекцию значений компонент вектора путем умножения компонента вектора на отношение количества фаз жизненного цикла (ЖЦ), поддерживаемых соответствующей системой, к количеству фаз ЖЦ в целом охватываемых CASE-системами

7. Отсортируем полученные для каждого программного продукта значения идеальности (п. 2).

8. Проанализируем изменение идеальности в каждом классе; выделим несколько «лидеров». Сделаем выводы о функциональных возможностях, реализуемых «лидерами» классов.

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

10. Проведем вычисления (п. 9) для каждого класса CASE-систем.

Рис. 2 – ТРИЗ-эволюционная карта CASE-систем

Противоречия в процессе эволюции CASE-систем

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

1. Выделить и разрешить противоречия в основной линии развития классов CASE-систем;
2. Выделить и разрешить противоречия в каждом классе CASE-систем.

Рассмотрим пример:

1. Изобразим отдельно линию эволюции классов CASE-систем (рис. 3).

Рис. 3 – Выявление противоречий в основной линии развития CASE-систем

1. Выше и ниже относительно названий классов отметим положительные и отрицательные стороны в функционировании CASE-систем. Формулировки могут быть взяты из обзоров производителей систем, тематической учебной и практической литературы, или составлены самостоятельно исходя из опыта работы с  конкретными системами.
2. Выявим проблемы (предварительный набросок формулировки противоречия) – как их видят производители или пользователи каждого из классов систем (рис. 3).
3. На основе п. 2 сформулируем противоречие. Так, в основной линии развития CASE-систем были выделено два противоречия на этапах появления классов CASE-систем:

• на этапе появления «Workbenches»: при увеличении количества выполняемых функций недопустимо растет требуемый уровень интеграции системы с другими платформами и программными продуктами;
• на этапе появления «Environments»: при увеличении количества охватываемых этапов ЖЦ проектируемых систем недопустимо увеличиваются затраты на получение результатов.

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

• на этапе появления «Workbenches»: используя «Принцип объединения», системы класса «Workbenches» были созданы путем объединения нескольких интегрируемых систем класса «Tools»;
• на этапе появления «Environments»: используя «Принцип дробления» системы класса «Environments» были созданы путем распределения баз данных, составляющих их систем классов «Tools» и «Workbenches», а также путем распараллеливания работ между ними.

Аналогично эволюции в основной линии развития представлялась эволюция для каждого класса CASE. Приведем пример выявления противоречий в классе «Environments» (третий вектор карты, рис. 2).

Определим параметры CASE-систем:

• П₁: фазы ЖЦ, требующие «поддержки» («1» – формирование требований, «2» – проектирование, «3» – реализация, «4» – тестирование и отладка, «5» – внедрение, «6» – сопровождение и эксплуатация);
• П₂: тип системы («1» – ПО, «2» – организационно-управляющая).

Представление CASE-систем как «систем» (в трактовке закона полноты частей системы) с учетом их параметров наглядно демонстрирует рост идеальности при разрешении противоречий и движении по вектору идеальности в классе «Environments».

«Инструментальные программные среды» [П₁: 3, 5. П₂: 1, 2]. Поддержка в системах ограничена функциями программирования, управления конфигурацией и управления проектами. Возникает противоречие: при увеличении количества выполняемых функций недопустимо растет требуемый уровень интеграции системы с другими платформами и программными продуктами. Противоречие разрешается при помощи использования принципов «дробления» и «однородности»: осуществляется переход к «Языко-ориентированным программным средам» системам, обеспечивающим легкое расширение среды посредством написания дополнительных модулей на «заданном» языке.

Переход к « Языко-ориентированным программным средам» [П₁: 3, 4, 5. П₂: 1, 2] порождает новые проблемы. Код, написанный на другом языке программирования в такой системе, не может быть выполнен. Возникает противоречие: при увеличении уровня интеграции недопустимо сокращается количество доступных языков программирования. Противоречие разрешается при помощи использования принципов «универсальности» и «замены механической схемы»: осуществляется переход к «Процессо-ориентированным программным средам», поддерживающим крупномасштабную разработку без привязки к конкретному языку. В свою очередь, использование «Процессо-ориентированных программных сред» [П₁: 1, 2, 3, 4, 5, 6. П₂: 1, 2] сталкивается с проблемой обязательной графической формализации бизнес-процессов и т.д.

Заключение

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

В представленной классификации по одной координате располагаются классы CASE-систем («Tools» – инструменты, «Workbenches» – рабочие приложения, «Environments» – программные среды), а по другой – линии эволюции систем каждого класса. CASE-системы в рамках одной линии выстроены по степени увеличения их идеальности.

Наиболее эволюционированными системами в классе «Environments» являются интегрированные CASE-системы: DEC Cohesion, IBM AD/Cycle; в классе «Workbenches» – системы бизнес планирования и моделирования: ARIS (Business Performance Edition), CA ERwin Modeling Suite, Rational Rose, Oracle Designer, Borland Together, Power Designer Process Modeler, Simprocess и др.

Дальнейшая разработка ТРИЗ-эволюционной карты путём достройки позволит предсказать направления развития как классов систем, так и линий эволюции в рамках каждого класса.

Литература

1. Berdonosov V. «Fractality of knowledge and TRIZ», Proceedings of the ETRIA TRIZ Future  Conference, Kortrijk, 9-11 October 2006, published by CREAX Press, ISBN 90-77071-05-9. – pp. 31-36.

2. Redkolis, E.V. TRIZ-fractality of mathematics / E.V. Redkolis, V.D. Berdonosov // Procedia Engineering (Scopus): Elsevier, 2011. – Vol. 09. – P. 461–472.
3. Redkolis, E.V. TRIZ-fractality of Computer-Aided Software Engineering systems / E.V. Redkolis, V.D. Berdonosov // Procedia Engineering (Scopus): Elsevier, 2011. – Vol. 09. – P. 199-213.
4. Fuggetta A. A Classification of CASE Technology. Dipartimento di Elettronica ed Inf., Politecnico di Milano: Computer, vol. 26, no. 12, Dec. 1993, doi:10.1109/2.247645. – pp. 25-38.
5. Редколис, Е.В. Разработка методик и алгоритмов функционирования CASE-системы формирования оптимальных административных регламентов и диаграмм бизнес-процессов оказания электронных муниципальных услуг: дис. на соискание степени к. т. н.: 05.13.10. – 145 c.