Концепция построения CASE-системы разработки информационных управляющих систем

Размещено на http://www.allbest.ru/

Концепция построения CASE-системы разработки информационных управляющих систем

В.М. Левыкин

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

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

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

Рассмотрим основные особенности такой CASE-системы на примере процессов построения РБД ИУС. С точки зрения теории категорий данные процессы можно описать моделью следующего вида [3]

. (1)

где - категория параметров предметной области;

- категория локальных концептуальных описаний информационных потоков ИУС;

- функтор отображения категории параметров предметной области в категорию локальных концептуальных описаний информационных потоков ИУС;

- категория локальных логических описаний базы данных ИУС;

- функтор отображения категории локальных концептуальных описаний информационных потоков ИУС в категорию локальных логических описаний РБД ИУС;

- категория моделей данных, применяемых для логического проектирования РБД ИУС в целом;

- функтор отображения категории локальных логических описаний РБД ИУС в категорию моделей данных, применяемых для логического проектирования РБД ИУС в целом;

- категория моделей данных, применяемых для физического проектирования РБД ИУС;

- функтор отображения категории моделей данных, применяемых для логического проектирования РБД ИУС в целом в категорию моделей данных, применяемых для физического проектирования РБД ИУС.

Как показано в [3], рассматриваемые категории являются категориями структурированных множеств.

Использование предлагаемой CASE-системы позволяет представить процессы проектирования РБД ИУС в соответствии с моделью (1) в виде схемы, представленной на рис. 1.

На рис. 1 приняты следующие обозначения:

- категория требований пользователей к ИУС;

- функтор отображения категории параметров предметной области в категорию требований пользователей к ИУС;

- функтор отображения категории требований пользователей к ИУС в категорию моделей данных, применяемых для логического проектирования РБД ИУС в целом;

- категория логических моделей РБД ИУС;

- функтор отображения категории параметров предметной области в категорию логических моделей РБД ИУС;

Рис. 1. Процесс проектирования РБД ИУС.

- функтор отображения категории логических моделей РБД в категорию моделей данных, применяемых для логического проектирования РБД ИУС в целом;

- категория физических моделей РБД ИУС;

- функтор отображения категории логических моделей РБД ИУС в категорию физических моделей РБД ИУС;

- функтор отображения категории физических моделей РБД ИУС в категорию моделей данных, применяемых для физического проектирования РБД ИУС.

case управляющий информационный

На рис. 1 сплошными линиями показаны процессы прямого проектирования РБД ИУС, основанные на исследовании предметной области и формировании общесистемной логической и физической модели РБД из локальных концептуальных моделей РБД. Пунктирными линиями на рис. 1 показаны другие возможные варианты реализации проектирования РБД, а именно: "сверху вниз" (проектирование осуществляется на общесистемном уровне в виде создания и корректировки категорных моделей , , и с последующей детализацией) и "напрямую" (проектирование осуществляется на общесистемном уровне путем прямой реализации категорных моделей , и ). Выбор конкретного варианта в общем случае является прерогативой проектировщика, который принимает решение на основании результатов исследования объекта автоматизации.

Исходя из данного представления становится возможным разделить процессы проектирования РБД ИУС на процессы синтеза (корректировки) категорных моделей и процессы реализации функторов, обеспечивающих преобразование категорных моделей друг в друга и поддерживающих сохранность структуры создаваемой ИУС. Анализируя функторы , обуславливающие сохранность структуры проектируемой системы в процессе разработке РБД ИУС, можно сделать следующие выводы.

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

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

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

Шаг.1. Определение режима реализации проекта разработки структуры информационного обеспечения. Если выбран ручной режим, то перейти к шагу 3. В противном случае перейти к шагу 2.

Шаг.2. Определение первого нереализованного функтора из последовательности . Затем перейти к шагу 4.

Шаг.3. Определение проектировщиком реализуемого функтора из последовательности .

Шаг.4. Установка взаимно-однозначных соответствий между типовыми категориями , и категориями, участвующими в реализации заданного функтора.

Шаг.5. Установка соответствия между типовым функтором и реализуемым функтором.

Шаг.6. Определение уровня представления категорий и . Если выбран уровень объектов, то перейти к шагу 7. Если выбран уровень подобъектов, то перейти к шагу 13. Если выбран уровень элементов, то перейти к шагу 20.

Шаг.7. Вводятся элементы множества категории и множества категории .

Шаг.8. Вводятся элементы множества категории и множества категории .

Шаг.9.Для введенных элементов множеств и категории определяется отображение .

Шаг.10. Для введенных элементов множеств и категории определяется отображение .

Шаг.11. Для элементов множества категории вводится морфизм.

Шаг.12. Для элементов множества категории вводится морфизм . Затем перейти к шагу 15.

Шаг.13. Выполняются процедуры, аналогичные процедурам шага 8 для элемента множества категории .

Шаг.14. Выполняются процедуры, аналогичные процедурам шага 8 для элемента множества категории .

Шаг.15. Вводятся элементы множества категории и множества категории .

Шаг.16. По аналогии с шагом 9 определяется отображение .

Шаг.17. По аналогии с шагом 10 определяется отображение .

Шаг.18. Для элементов множества вводится морфизм .

Шаг.19. Для элементов множества вводится морфизм . Затем перейти к шагу 22.

Шаг.20. Выполняются процедуры, аналогичные процедурам шага 8 для множества категории .

Шаг.21. Выполняются процедуры, аналогичные процедурам шага 8 для множества категории .

Шаг.22. Для элементов множества вводится морфизм .

Шаг.23. Для элементов множества вводится морфизм .

Шаг.24. По аналогии с шагом 6 определяется соответствующий уровень объектов. Если выбран уровень объектов, то переходим к шагу 25. Если выбран уровень подобъектов, то переходим к шагу 27. Если выбран уровень элементов, то перейти к шагу 29.

Шаг.25. Устанавливается соответствие верхней части коммутативных диаграмм и равенств категорий и . Если эти условия выполняются, то перейти к шагу 27.

Шаг.26. Устанавливаются и корректируются нарушения отображений ,.

Шаг.27. По аналогии с шагом 25 устанавливается соответствие нижней части коммутативных диаграмм и равенств категорий и . Если эти условия выполняются, то перейти к шагу 29.

Шаг.28. Устанавливаются и корректируются нарушения отображений ,.

Шаг.29. Корректировка элементов категорий и .

Шаг.30. Наполнение типового функтора .

Шаг.31. Копирование полученных категорий и в соответствующие категории, определенные на шаге 4.

Шаг.32. Копирование полученного функтора в соответствующий функтор, определенный на шаге 5.

Шаг.33. Определить режим реализации проекта. Если установлен автоматизированный режим и не все функторы реализованы, то перейти к шагу 2. Если выбран ручной режим и выражено желание продолжить работу, то перейти к шагу 3. В противном случае завершить выполнение алгоритма.

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

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

1. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. -М.: Финансы и статистика, 1998. - 176 с.

2. Маклаков С.В. BPWin и ERWin. CASE-средства разработки информационных систем. - М.: ДИАЛОГ-МИФИ, 1999. - 256 с.

3. Мухайрат Мохаммад, Левыкин В.М., Борисенко В.П., Борисенко Т.И. Теоретико-категорное моделирование процессов автоматизированного проектирования распределенных баз данных корпоративных информационных управляющих систем // АСУ и приборы автоматики, 2000. Вып. 111. С. 156-162.

4. Цаленко М.Ш., Шульгейфер Е.Г. Основы теории категорий. - М.: Наука, 1974. - 256 с.

5. Левыкин В.М., Скляров А.Я., Евланов М.В. Генный подход к проектированию сложных информационных систем / Тезисы докладов Международной конференции "Теория и техника передачи, приема и обработки информации". - Харьков: ХТУРЭ, 2000. - С. 12-14.

Размещено на Allbest.ru