Инструментальная поддержка CASE-технологий тема диссертации и автореферата по ВАК РФ 05.13.11, кандидат физико-математических наук Чекрий, Сергей Павлович

• Чекрий, Сергей Павлович
• кандидат физико-математических наук
• 1998

Оглавление диссертации кандидат физико-математических наук Чекрий, Сергей Павлович

Содержание

Введение

Глава I Обзор существующих технологий CASE

1. Определение CASE, классификация систем CASE, требования к CASE

2. Современные методологии проектирования ПО - обзор 18 2.1 Определение методологии

2.2. Концепции моделирования

2.3. Метамодели

2.4. Нотация

2.5. Результаты разработки

2.6. Процесс

2.7. Шаблоны

2.8. Примеры методологий

3. Мета-CASE, примеры подходов

3.1. Метамоделирование

3.2. Мета-CASE

4

Глава II Архитектура системы MetaBuilder

1. Существующие системы мета-CASE

2. Постановка задачи

3. Требования и цели работы

4. Определение подсистем и их взаимосвязей

4.1. Репозиторий метамоделей

4.2. Подсистема спецификации метамоделей

4.3. Описание механизма языка спецификации (механизма сценариев)

4.4. Подсистема спецификации графических примитивов метамоделей

4.5. Подсистема спецификации сценариев поведения

4.6. Графический интерфейс пользователя

Глава III Методика применения системы MetaBuilder

1. Классы решаемых системой задач

1.1. Задачи метамоделирования

1.2. Задачи статического моделирования

1.3. Задачи динамического моделирования

2. Цикл проектирования в системе

3. Планы дальнейшего развития системы

Заключение

Библиографический список

Приложение I. Глоссарий метамоделирования

Приложение И. Краткое описание стандарта CDIF

Приложение III. Библиотека классов CDIF системы MetaBuilder

1

Введение диссертации (часть автореферата) на тему «Инструментальная поддержка CASE-технологий»

Введение

Здесь необходимо хотя бы коротко охарактеризовать понятия, о которых пойдет речь. Определение системы CASE и мета-CASE системы дается в разделе 2.1 первой главы, здесь же отметим, что система CASE (Computer Aided System/Software Engineering) - программный продукт, который характеризуется поддержкой ограниченного набора методологий проектирования, жестко закодированных в системе. Система же мета-CASE -это CASE-система, средствами которой могут быть созданы новые методологии проектирования, которые затем можно в этой же системе применять.

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

Действительно, в последнее время наблюдался некоторый "провал" интереса к системам CASE, когда даже самого термина CASE старались не употреблять, заменяя на "системы быстрой разработки приложений" - RAD и т.п. "Вторая волна" структурно характеризуется интересом именно к мета-CASE системам, как к системам наиболее интересным для корпоративного использования.

Мета-CASE применяют:

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

• Если есть необходимость модифицировать существующую методологию.

• Если есть необходимость интегрировать несколько методологий.

• Если есть необходимость применить в методологии новые технологии, такие как CORBA.

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

-f

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

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

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

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

Перейдем к обзору существующих технологий CASE, без которых не было бы и мета-CASE систем.

Заключение диссертации по теме «Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей», Чекрий, Сергей Павлович

Результаты работы используются в учебном процессе в курсе "Технология построения больших программных систем" факультета "Прикладная математика" МАИ. Система MetaBuilder используется при выполнении лабораторных работ по курсу. Работй апробирована при выступлениях на научных конференциях и на веб-сайте www.meta-case.com.

Заключение

В диссертационной работе получены следующие научные и практические результаты:

• Осуществлена классификация, сформулированы ключевые свойства и принципы построения систем мета-САБЕ. Определены области применения технологии мета-САЗЕ. Выработаны требования к системам мета-САБЕ.

• Разработана архитектура системы мета-СА8Е, основанной на метамоделировании. Обоснован выбор метаметамодели, лежащей в основе данной системы.

• Разработан механизм спецификации метамоделей, основанный на метаметамодели СОШ. Предложена структура репозитория СБН7 и методика использования репозитория для хранения метамоделей. Разработана технология хранения графической нотации метаобъектов в репозитории в виде процедур изображения.

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

• Осуществлены проектирование, программная реализация и внедрение в учебный процесс системы мета-САБЕ Ме1аВш1с1ег, использующей разработанную в диссертационной работе архитектуру системы мета-САБЕ, основанной на метамоделировании.

• Создана методика применения разработанной системы мета-САБЕ Ме1аВшМег. Определены классы задач решаемых системой и методы их решения. Описан цикл проектирования в системе.

Новизну диссертации составили:

•Разработка архитектуры системы мета-САБЕ, основанной на метамоделировании.

•Разработка механизма спецификации метамоделей.

•Создание универсального подхода к заданию динамических свойств моделей и метамоделей.

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

Результатом работы над диссертацией явилась также разработка системы мета-CASE MetaBuilder.

Список литературы диссертационного исследования кандидат физико-математических наук Чекрий, Сергей Павлович, 1998 год

Библиографический список

[1] CASE Vendor/Product Review University of California, San Diego Holly A. Cartwright, 1995

[2] Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). М., "Лори", 1996.

[3] CASE metamorphosis, (computer-aided software engineering tools are enhanced to increase MIS productivity) Author: Moriarty, Terry, 1995

[4] What Is a Method? Dr. James Rumbaugh, October 1995

[5] Требования и спецификации в разработке программ: Пер. с англ. - М.: Мир, 1984.-344 е., ил.

[6] Marca, D., McGowan, С.. SADT: Structured Analysis and Design Technique. New York, NY: McGraw-Hill Book Cpmpany, 1988.

[7] EasyCASE Version 4.0, Methodology Guide. Evegreen CASE Tools, Inc., 1993.

[8] Bailey S. CASE Method Primer. DBMS, March 1993

[9] Ken Orr, Chris Gane, Edward Yourdon, Peter P. Chen, Larry L. Constantine. Metodology: The Experts Speak. BYTE, April 1989

[lOJCattell R.G.G. (ed.): The Object Database Standard - ODMG-93. Morgan Kaufmann Publ., San Francisco, California 1994

[1 l]Chen. M., Norman R.J.: A framework for integrated CASE. In IEEE Software, March 92

[12]Kelly, S., Tahvanainen, V-P., Support for Incremental Method Engineering and MetaCASE. Proceedings of the fifth workshop on the next generation of CASE tools, Theodoulidis B. (ed.), Memoranda Informatica 94-25, University of Twente, NL, 1994

[13]Klint P.: A meta-environment for generating programming environments. ACM Trans. Software Engineering and Methodology, 2 (2) 1993, 176-201

[14]Smolander K., Martiin P., Lyytinen K., Tahvanainen V.-P.: MetaEdit - a flexible graphical environment for methodology modelling. In Advanced Information

Systems Engineering, Lecture Notes in Computer Science, Vol. 498 1991, 168193

[15][CDIF94a] CDIF - Framework for Modeling and Extensibility, Interim Standard, EIA 1994.

[16][CDIF94b] CDIF - Transfer Format - General Rules for Syntaxes, Interim Standard, EIA 1994.

[17][CDIF94c] CDIF - Transfer Format - Transfer Format Syntax - SYNTAX. 1, Interim Standard, EIA 1994.

[18][CDIF94d] CDIF - Transfer Format - Transfer Format Encoding -ENCODING. 1, Interim Standard, EIA 1994.

[19][CDIF94e] CDIF - Integrated Meta-model, Foundation Subject Area, Interim Standard, EIA 1994.

[20][CDIF96a] CDIF - Integrated Meta-model, Common Subject Area, Interim Standard, EIA 1996.

[21 j[CDIF96b] CDIF - Integrated Meta-model, Data Flow Subject Area, Interim Standard, EIA 1996.

[22]Rony G. Flatscher: An Overview of the Architecture of EIA's CASE Data Interchange Format (CDIF). "Fachtagung der Fachgruppe 5.2.1 - Modellierung betrieblicher Informationssysteme (MoblS)", 1996-10-11, BTU Cottbus, Germany.

[23]Johannes Ernst: Data Interoperability between CACSD and CASE Tools Using the CDIF Family of Standards.

[24]Чернышов JI.H., Чекрий С.П. Обзор стандарта обмена данными средств проектирования - CDIF (CASE Data Interchange Format)

[25]Буч Г. Объектно-ориентированное проектирование с примерами применения: Пер. с англ. - М.: Конкорд, 1992.

[26]Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях. Киев, "Диалектика", 1993.

[27]Кауфман В.Ш. Языки программирования. Концепции и принципы. М.; Радио и связь, 1993.

[28]Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных программных систем. М. 1996.

[29]Требования и спецификации в разработке программ: Пер. с англ. - М.: Мир, 1984.-344 е., ил.

[30]Marttiin, P., Rossi, М., Tahvanainen, V-P., Lyytinen, К., "A comparative review of CASE shells: A preliminary framework and research outcomes", Information and Management, 25 (1993) 11-31.

[31]Nuseibeh, В., "Meta-CASE Support for Method-Based Software Development", (to appear in) Proc. Of 1st Int. Congress on Meta-CASE, 5-6th January 1995, Sunderland, UK.

[32]Mehandjiska, D., Page, D., Dasari, S., "Generic Knowledge Base of a Methodology Independent Object-Oriented CASE Tool", Proceedings of the IASTED International Conference on Artificial Intelligence, August 19-21, 1996 - Honolulu, Hawaii, USA, 23-26.

[33]Kelly, S., Smolander, K., "Evolution and issues in metaCASE", Information and Software Technology, 38 (Special Issue: Method engineering and meta-modelling), 4 (April 1996), 261-266.

[34]Sommerville, I., Welland, R., Beer, S., "Describing Software Design Methodologies", The Computer Journal, 30, 2 (1987), 128-133.

[35]Alderson, A., "Meta-CASE Technology", Lecture Notes in Computer Science 509: Software Development Environments and CASE Technology, 1991, 81-91.

[36]Sorenson, P. G., Tremblay, J-P., McAllister, A. J., "The Metaview Ssytem for Many Specification Environments", IEEE Software, 5,2 (March 1988), 30-38.

[37]Information and Software Technology Special Issue on Method Engineering and Meta-Modelling, 38 (4), 1996.

[38]S. Brinkkemper, К. Lyytinen and R. Welke (eds), Method Engineering: Principles of method construction and tool support, Chapman and Hall, 1996.

[39]S. Hooker and M. A. Lockyer and P. C. Fencott, CASE Support for Methods Integration: Implementation of a Translation from a Structured to a Formal Notation Methods Integration, Electronic Workshops in Computing, SpringerVerlag, 1996.

[40]Martin, James, and James J. Odell, Object-Oriented Methods: Pragmatic Considerations, Prentice-Hall, Englewood Cliffs, NJ, 1996.

[41]Martin, James, and James J. Odell, Object-Oriented Methods: A Foundation, Prentice-Hall, Englewood Cliffs, NJ, 1996.

[42]Ramackers, Guus, Integrated Object Modelling, Thesis Publishers, Amsterdam, 1994.

[43]Попов Э.В., Евсеев O.M., Методологи и средства реинжиниринга бизнес-процессов //Банки и технологии. 1997. - №4.

[44]Попов Э.В., Шапот М.Д., Реинжиниринг бизнес-процессов и информационные технологии. //Открытые системы. - 1996. -№1.

[45]Ойхман Е.Г., Попов Э.В., "Реинжиниринг бизнеса", М., Финансы и статистика, 1997

[46]Еделыитайн Н., Интеллектуальные средства анализа, интерпретации и представления данных в информационных хранилищах. //Компьютеруик. -1996.-№16.

[47]Stan Jarzabek and Irene Woon. Towards a precise description of reverse engineering methods and tools. In Proceedings. First Euromicro Conference on Software Maintenance and Reengineering, pages 3-9, Berlin, Germany, 17-19 March 1997. IEEE.

[48]Maya Daneva and Radostina Terzieva. Assessing the potentials of CASE-tools in software process improvement: A benchmarking study. In Proceedings of the Fourth International Symposium on Assessment of Software Tools, pages 104-8, Toronto, Ontario, Canada, 22-24 May 1996.

[49]Andreas Hierholzer and Georg Herzwurm. Methodology of a CASE-tool assessment. In Proceedings of the Fourth International Symposium on Assessment of Software Tools, pages 97-8, Toronto, Ontario, Canada, 22-24 May 1996.

[50]David Redmond-Pyle. Software development methods and tools: Some trends and issues. Software Engineering Journal, 11(2):99-103, March 1996.

[51]David A. Ladd and J. Christopher Ramming. A*: A language for implementing language processors. IEEE Transactions on Software Engineering, 21(11):894-901, November 1995.

[52]Bertrand Meyer. On formalism in specifications. IEEE Software, 2(l):6-26, January 1995.

[53]CORBA: Architecture and Specification. Object Management Group, Inc., 1995.

Ill

Приложение I. Глоссарий метамоделирования

Метамодель (Meta-model)

Информационная модель для информационных объектов, которые могут применяться в процессе моделирования. Концепты, которые можно обнаружить в метамодели, это, например, «Класс», «Процесс», «Метод», также «Присваивание», «Таймер».

Модель (Model)

Коллекция объектов, полученных в результате моделирования системы, такой как программной системы. Концепты, которые можно обнаружить в модели это, например, «Покупатель», «Заказ», «Адрес», также «время по умолчанию 5 е.», «Z не может наступить, пока не наступили X и Y».

Метаметамодель (Meta-meta-model)

Для того чтобы создать метамодель, Вам требуется язык, на котором Вы будете описывать ее. Мета-мета модель определяет этот язык. Метаметамодель относится к метамодели также, как метамодель относится к модели.

Четырехуровневая архитектура (Four-layer architecture)

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

Интегрированная метамодель (Integrated metamodel) в сравнении с не интегрированной (non-integrated)

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

дисциплин. В качестве простого примера рассмотрим написание требований. Проектируете ли Вы с помощью 00, SADT или разрабатываете микросхему, концепция написания требований остается той же самой. Метакласс (metaclass)

Как Класс (Class) в моделировании, но для метамоделирования. Метаотношение (metarelationship)

Как Отношение (Relationship) в моделировании, но для метамоделирования. Метаатрибут (metaattribute)

Как Атрибут (Attribute) в моделировании, но для метамоделирования. Метаобъект (metaobject)

Обычно используется как общий термин для всех «вещей», которые формируют язык метамоделирования, таких как метаклассы, метаотношения, метаатрибуты. '

Экземпляр метаобъекта (metaobject instance)

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

Приложение II. Краткое описание стандарта CDIF

Разработка стандарта CASE Data Interchange Format (CDIF) была начата в октябре 1987. Основной идеей является определение так называемых «метамоделей» в соответствии с парадигмой «сущность-отношение».

Набор стандартов "EIA CDIF Interim Standards" 1991 г предоставил возможность интерпретировать типы сущностей как классы, от которых можно унаследовать подклассы в уточненных метамоделях. В стандарты 1994 появилась возможность наследовать подклассы от типов отношений.

Стандарт CDIF имеет формальные и неформальные связи с ANSI (X3L8, ХЗН4), ЕСМА (ТСЗЗ:РСТЕ), IEEE (PI 175), ISO (ISO IRDS, ISO/IEC JTC1/SC7/WG11) и OMG.

Метаметамоделъ CDIF

В стандарте CDIF сначала определяется «метаметамодель» [CDIF94a] , которая описывает в собственных терминах основное объектно-ориентированное дерево классификации и выразительные средства собственной методологии «сущность-отношение».

MetaObject SubjectArea CollectableMetaObject AttributableMetaObj ect MetaRelationship MetaAttribute

Рис. 22. Дерево классификации (Метаметасущности), [CDIF94a], р.31.

АипЬи1аЬ1еМе1аОЬ]ес1.На58иЫуре.АПпЬи1аЬ1еМе1аОЬ]ес1 Со11ес1аЬ1еМе1аОЬ]ес1.15и8её1п.8иЬ]ес1Агеа MetaAttribute.IsLocalMetaAttributeOf.AttributableMetaObject MetaRelationship.HasDestination.MetaEntity М^аЯекйошЫр. НазБоигсе. М^аЕпМу

Рис. 23: Метаметаотношения, [СВ1Р94а], р.31.

Рис. 24: Метаметамодель, [СВ1Р94а], р.ЗЗ.

Метамодели

С помощью метаметамодели СОШ можно определять метамодели. Метамодель образуется от метаметамодели путем ее расширения.

Метамодели - это предопределенные определения для передачи данных модели для определенной "предметной области" (методологии), такой как модели данных, модели перехода состояний, модели потока данных и т.п. Все стандарты CDIF Interim Subject Area вместе определяют "Интегрированную метамодель CDIF", каждая предметная область использует подмножества этой метамодели. Сама интегрированная метамодель CDIF определена средствами объектно-ориентированной версии методологии сущность-отношение, определенной с помощь метаметамодели CDIF (!). Возможна ситуация, когда различные предметные области перекрываются в смысле использования в них определенных метасущностей и метаотношений, что дает возможность использования предопределенных метасущностей и метаотношений при определении новой предметной области.

Поскольку механизм передачи даннйх по CDIF предназначен для переноса конкретных моделей между различными инструментами, модель должна быть описана соответствующей метамоделью (также называемой предметной областью). Поскольку метамодели - это просто представления интегрированной метамодели CDIF с точки зрения определенных предметных областей, становится возможным использовать более чем одну предметную область при переносе данных модели. Также возможно переносить информацию о тех метасущностях и метаотношениях, которые в CDIF еще не определены. Таким образом, может передаваться информация о семантике, для которой еще не существует метамоделей CDIF. Две наиболее важных метамодели - это «Foundation Subject Area» и «Common Subject Area» описаны ниже. Они необходимы для передачи информации по CDIF.

Метамодель Foundation Subject Area

Эта метамодель ([CDIF94e]) является корнем иерархии всех метамоделей в CDIF. Все метамодели CDIF должны быть наследниками (возможно не непосредственными) метасущности RootObject (абстрактный класс типа

AttributableMetaObject), от нее наследуется RootEntity, и метаотношение IsRelatedTo (полное имя RootEntity.IsRelatedTo.RootEntity)

Метамодель Common Subject Area

Common Subject Area ([CDIF96a]) детализирует Foundation Subject Area за счет определения метасущностей ToolUser, AbstractionLevel, SemanticInformationObject (предок метасущностей Derivation, DataObject и ProcessObject), TextualConstraint, PresentationlnformationObject и AlternateName. Эта метамодель описывает аспекты, которые могут быть существенны для определения инструментов, вовлеченных в передачу информации по CDIF, а также SemanticInformationObject, который является основой для всей информации, связанной с семантикой во всех последующих предметных областях, и определяет, таким образом^ семантику передаваемой модели. Все эти метасущности являются наследниками RootObject. Предок описанных ниже метаотношений - это IsRelatedTo. Метаотношения позволяют дальнейшее структурирование метасущностей, как, например,

SemanticInformationObject.IsCategorizedln.AbstractionLevel, или определяют синонимы объектов. RootEntity.Has.AlternateName.

Дополнительные предметные области

В стандарт CDIF все время добавляются предметные области. Некоторые уже закончены, другие находятся на стадии разработки, есть запланированные на будущее предметные области. Законченные предметные области:

• Foundation Subject Area, публикация 1994,

• Common Subject Area, публикация 1996,

• Data Definition Subject Area, пройдена заключительная проверка,

• Data Flow Model Subject Area, публикация 1996,

• Data Modeling Subject Area, пройдена заключительная проверка,

• Presentation Object Location & Connectivity Subject Area, пройдена заключительная проверка.

Предметные области, которые разрабатываются в настоящее время:

• Business Process Model Subject Area,

• Control Design Subject Area,

• Object-Oriented Analysis and Design Subject Area,

• Physical Relational Database Subject Area,

• Planning & Scheduling Subject Area,

• Repository Import/Export Subject Area,

• Sizing & Estimating Subject Area,

• State/Event Model Subject Area,

• Tracking Subject Area.

f

Запланированные/находящиеся на стадии исследования предметные области:

• CORBA mapping,

• Computable Constraints Subject Area,

• Computer Aided Testing,

• Expression Subject Area,

• Global Parameters for Presentation Object Behavior,

• Graphical User Interface Subject Area,

• Presentation Object Shape Subject Area,

• Repeating Structures for Presentation Objects,

• Requirements Traceability Subject Area.

Приложение III. Библиотека классов CDIF системы MetaBuilder

TDrawClass

Необходимо ввести данный класс, чтобы придать классам иерархии, наследникам СотропепЮЬ^ес!, возможность визуализации

Metaldentifier

ЗетапйсМогтайопО^ес! - при создании регистрирует себя в массиве Сй1РАггау (см. рис.20), а при разрушении сообщает об этом этому же массиву. Таким образом, массив СР1РАггау знает о всех живущих обьектах, в связи с чем на него налагается основная работа по обработке объектов.

SemanticlnformationObject

FlowPi

AttrlnformationObject - класс, имеющий несколько (ноль или более ) аттрибутов (Attribute), хранящихся i массиве

AttrlnformationObject

FlowPort - предназначен для установки связи между

двумя ComponentObject ^_

СотропепЮ^ес! - обьект, который имеет массив портов ИожРо№. Посредством этих портов СотропепЮЦеЛ - ы могут соединятся друг

FiowNode,

Flov

ConnectableObject

ComponentObject - ы делятся на два виде - ConnectableObject и Flow. С помощью Flow можно соединить два ConnectableObject.

FomnalFlowPort - особый вид Соппес1аЫеОЬ]ес1, который пользователь не может сам добавлять и удалять. Играет роль при декомпозиции Сотропеп(ОЬ)ес1, соответствуя одному из соединенных с этим СотропепЮЬ)ес1 другим СотропепЮ^ей.

lalFlowPort

Рис. 25: Иерархия классов CDIF в системе MetaBuilder

На рис. 25 приведена иерархия классов CDIF, созданная при реализации метаметамодели в системе MetaBuilder. Ниже приведены исходные тексты интерфейсных частей данных классов. TDrawClass = class(TShape) private FBkgndPen, FDataPen:TPen; FdataBrush, FBkgndBrush:TBrush; FPoints: array[0. .MaxTPoints-1 ]of TPoint; FHorzUnit, FVertUnit:Integer; protected

function GetPoint(Index:Integer):TPoint; virtual; procedure SetPoint(Index: integer; APoint:TPoint); virtual; procedure SetHorzUnit(AValue:Integer); virtual; procedure SetVertUnit(AValue:Integer); virtual; public

constructor Create(AnOwner:TComponent);override;

destructor Destroy;override;

procedure Ctrl StyleChanged(Sender: TObj ect);

function AssertValid:boolean; virtual;

property Points [Index: Integer]: TPoint read GetPoint write SetPoint; published

property DataBrush:TBrush read FDataBrush; property DataPen: TPen read FDataPen; property BackgroundBrush :TBrush read FBkgndBrush; property BackgroundPen:TPen read FBkgndPen; property UnitHorizontal: Integer

read FHorzUnit write SetHorzUnit; property UnitVertical:Integer read FVertUnit write SetVertUnit; end;

Metaldentifier = class(TDrawClass) public

CDIFMetaldentifier: Word;

constructor Create( AnOwner:TComponent);override; destructor Destroy;override; end;

//

// SemanticInformationObject - при создании регистрирует себя в массиве // CDIFArray, а при разрушении сообщает об этом этому же массиву. // Таким образом, массив CDIFArray знает о всех живущих объектах, в связи с // чем на него налагается основная работа по обработке объектов.

SemanticInformationObject = class(Metaldentifíer) public

constructor Create( AnOwner:TComponent);override; destructor Destroy;override; end;

// FlowPort - предназначен для установки связи между двумя ComponentObject // (см. ниже)

//

FlowPort = class(SemanticInformationObject) public

constructor Create( AnOwner:TComponent);override; destructor Destroy;override; public

m_CompObj : Metaldentifier; // ComponentObject, который имеет // этот порт.

m_Port: FlowPort; // порт - двойник у m_CompObj m_FFPort: Metaldentifier; // Формальный порт end;

//

// Attribute - Атрибут. Имеет имя AttrName : string и значение // Value : Variant (любого типа).

//

Attribute = class(SemanticInformationObject) public AttrName : string; Value : Variant;

constructor Create( AnOwner:TComponent);override; destructor Destroy;override; end;

//

// AttrlnformationObject - объект, имеющий несколько (ноль или более)

// атрибутов, хранящихся в массиве Attributes : TSIOArray.

// Также имеет имя класса ClassName (FName): string. Имеется в виду,

// что если мы, например, строим диаграмму в Data Flow Model, и имеется объект

// 'DFMProcess' с названием 'Обслужить', то ClassName будет равно 'DFMProcess',

// а не 'Обслужить'.

AttrlnformationObject = class(SemanticInformationObject) protected

FName : string; FCanDecomposite : boolean; FUserCanlnsertAndDelete : boolean;

XCDIFMetaldentifier : integer;

procedure SetName(xname : string);virtual; function GetName : string;

public

Attributes : TSIOArray;

procedure AddAttr(AttrName : string;AttrV&lue : Variant); property UserCanlnsert: boolean read FUserCanlnsertAndDelete; property UserCanDelete : boolean read FUserCanlnsertAndDelete;

property ClassName : string read GetName write SetName; property CanDecomposite : boolean read FCanDecomposite;

constructor Create( AnOwner:TComponent);override; destructor Destroy;override;

function AttrByName(AttrName : string): Metaldentifier; function AttrExist(AttrName : string): Metaldentifier;

end;

//

// ComponentObject - объект, который имеет массив портов FlowPorts. // Посредством этих портов ComponentObject - ы могут соединятся друг // с другом.

// Containsln - указатель на ComponentObject, в декомпозиции которого

// этот объект участвует, или nil, если находится на вершине модели.

// В каждый момент в системе существует декомпозируемый объект, и видимы

// (Visible = TRUE) только те объекты, Containsln которых указывает на

// декомпозируемый объект.

// IsActive - активен ли объект.

// только один объект активен одновременно. Активный

// элемент выделяется на экране, к нему применяются текущие операции.

// (удаление, декомпозиция и т.д.)

ComponentObject = class(AttrlnformationObject) protected procedure Paint;override; procedure SetName(xname : string);override; public '

FlowPorts : TSIOArray; // порты

DataBaseMetaldentifier : Word; // Употребляются при считывании

DataBaseContainsInldentifier : Word; // из базы

procedure Simulate;

procedure SimulatePrivate;

procedure SimulateChildren;

procedure SimulateChildrenPrivate;

procedure AddPort(FPort: Metaldentifier);

function CanContainObject(MI: Metaldentifier): Boolean;virtual;

function CanContainType(Ident: integer): Boolean;virtual; function CanConnectToObject(MI: Metaldentifier) : Boolean;virtual; function CanConnectToType(Ident: integer): Boolean;virtual;

constructor Create( AnOwner:TComponent);override;

destructor Destroy;override;

procedure GetCenter(var X,Y:integer);

procedure GetIntersection(xc,yc:integer;var X,Y:integer);

//для возможного будущего использования procedure GetConnectionlnfo;

public

Containsln : Metaldentifier; // ComponentObject

IsActive : Boolean; // только один объект активен одновременно. Активный // элемент выделяется на экране, к нему применяются текущие операции.

end;

f

FlowNode = class(ComponentObject) protected

procedure Paint;override; public

constructor Create( AnOwner:TComponent);override; destructor Destroy;override; public

m_Flow : Metaldentifier; // Flow, который имеет // этот FlowObj

end;

//

// ComponentObject - ы делятся на два вида - ConnectableObject // и Flow. С помощью Flow можно соединить два ConnectableObject. // Это совершает функция Connect.

ConnectableObject = class(ComponentObject)

public

destructor Destroy;override;

function Connect(ConObj : ConnectableObject;FlowName : string;bCreateFlowPort: boolean; Arr : TSIOArray): Metaldentifier; end;

Flow = class(ComponentObject) protected procedure Paint; override; public

Nodes : TSIOArray;

constructor Create( AnOwner:TComponent);override; destructor Destroy;override;

procedure AddNode(NewMI, ExistMI: MetaIdentifier;bAfiter : Boolean); procedure DeleteNode(MI: Metaldentifier;bShouldDelete : Boolean); procedure DeleteAllNodes;

end;

//

// FormalFlowPort - особый вид ConnectableObject, который пользователь не // может сам добавлять и удалять. Играет роль при декомпозиции // ComponentObject, соответствуя одному из соединенных с этим // ComponentObject другим ComponentObject.

//

// Если два объекта связаны потоком, то возникающую взаимосвязь отвечающих // за эту связь объектов можно описать схемой :

//

// ConnectableObject-FlowPort)-(FlowPort - Flow - FlowPort)-(FlowPort-ConnectableObject)

U Ii II

// FormalFlowPort FormalFlowPort FormalFlowPort FormalFlowPort

//

FormalFlowPort = class(ConnectableObject) protected

procedure Paint; override; public

xFlowPort: Metaldentifier; // FlowPort, которому этот FormalFlowPort // соответствует

DataBaseConnectsToIdentifier: word; *

constructor Create( AnOwner:TComponent);override; destructor Destroy;override;

procedure SetName(xname: string);override;

end;