Методы и модели проектирования распределенных подсистем обучения автоматизированному проектированию Текст научной статьи по специальности «Компьютерные и информационные науки»

Королев Е.Н., Львович Я.Е. МЕТОДЫ И МОДЕЛИ ПРОЕКТИРОВАНИЯ РАСПРЕДЕЛЕННЫХ ПОДСИСТЕМ ОБУЧЕНИЯ АВТОМАТИЗИРОВАННОМУ ПРОЕКТИРОВАНИЮ

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

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

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

Важной задачей является разработка CASE-средств автоматизации проектирования процесса обучения и построения функциональных моделей обучения САПР с использованием методологии SADT {Structured Analysis and Design Technique), которая отображает функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями. Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Одной из наиболее важных используемых особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель.

Архитектура построения подсистем обучения должна: обеспечить возможность построения функциональ-

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

При реализации распределенных последовательных подсистем обучения автоматизированному проектированию предлагается применять следующие технологии:

технологию создания распределенных информационных систем с использованием структурнокомпонентного подхода на основе технологии Java2 Platform Enterprise Edition (J2EE); аспектно-ориентированную технологию (АОТ) построения последовательных систем.

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

диаграммы вариантов использования САПР (use case diagram);

диаграммы классов, содержащих проектные процедуры, операции и решения (class diagram); диаграммы поведения (behavior diagrams):

диаграммы последовательности обучения (sequence diagram); диаграммы сценариев обучения (activity diagram).

Интегрированная модель системы обучения в нотации UML представляется в виде совокупности казанных диаграмм (рис. 1).

Диаграмма R Диаграмма fe

вариантов Ц последователь- К

использования К ности обучения к

Интегрированная модель системы обучения

Диаграмма Диаграмма и

классов сценариев К

обучения К

Рис. 1. Интегрированная модель системы обучения в нотации

Набор этих диаграмм будет представлять основу универсальной нотации для моделирования системы (процесса) обучения (UML PT).

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

Построение различного рода диаграмм и моделей, реализация средств управления проектом, разработка документации, генерация программного кода проекта обучения являются основой синтез-методологии объектно-ориентированного анализа и проектирования, как систем обучения, так и самого процесса обучения.

Общая схема предлагаемой методологии проектирования систем и процесса обучения автоматизированному проектированию представлена на рис. 2.

Рис. 2. Этапы проектирования систем (процесса) обучения автоматизированному проектированию

В предлагаемой схеме отражены пять этапов проектирования.

Проектирование системы обучения проектировщиком с использованием языка UML PT. Результатом этого этапа будет сформированная функциональная модель, представляющая собой набор следующих диаграмм: диаграммы вариантов использования; диаграммы классов; диаграммы последовательности обучения; диаграммы сценариев обучения.

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

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

Размещение разработанных компонентов и моделей в контейнере Enterprise-компонентов обучения с расстановкой атрибутов транзакций для разработанных Enterprise -компонентов.

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

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

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

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

1. Для каждогоi -го метода имя метода M•реализующего обучение определенному правилу выполнения

проектной операции, должно включать в себя имя поля P , содержащего результат выполнения проектной операции, например, если имя поля createCIass, то имя метода, может быть createClassLernin: l

Z{KMj - KPj) = 0

j =0

где l - длина поля P ; KM и

кр - код символа с порядковым номером ] в имени метода и поля соот-

ветственно.

2. Длина метода M должна быть больше, чем длина поля P ;:

LMj - LP > 0 ,

где LM - длина метода Mi ; LP - длина поля Pi

Основными методами жизненного цикла (рис. 3) являются: trainingOnModel(Object methodsOfTraining) — обучение по указанной модели; check ValidityRule(Method[] rules, Field[] data, int i) — автоматически

запускается перед выполнением любого метода обучения; invokeRules(Method method, Object methodsOfTrain-ing) — запуск метода обучения.

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

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

Кроме того, важной функцией контейнера является реализация сервиса транзакций. При размещении компонентов обучения имеется возможность для каждого из методов определить атрибут транзакции: Re-

quired; RequiresNew; Mandatory; NotSuported; Supports; Never. Контейнер начинает транзакцию непосредственно перед началом метода компонента обучения.

Рис. 3. Модель жизненного цикла функционально-инвариантной модели

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

Дескрипторы размещения компонентов представляют собой XML-конфигурационные файлы, содержащие некоторые параметры размещения. Дескриптор содержит определенное количество тегов. В XML-файле указывается тип компонента, его методы, атрибуты транзакций. Дескриптор делится на две части: <enterprise-beans>, содержащая описание всех компонентов <assembly-descriptor>, которая содержит атрибуты транзакций для методов компонента. Например, XML-файл, указывающий тип транзакции Required для метода training2, относящегося к компоненту PathSecond, будет содержать следующий тег <assembly-descriptor>:

<assembly-descriptor>

<container-transaction>

<method>

<ejb-name> PathSecondBean </ejb-name> <method-intf>Remote</method-intf>

<method-name> training2 </method-name>

<method-params>

<method-param>String</method-param>

</method-params>

</method>

<trans-attribute>Required</trans-attribute>

</container-transaction>

</assembly-descriptor>

Аспектно-ориентированные модели представляют собой модели, отражающие последовательность выполнения тех или иных методов, связанных с обучением. Технология аспектно-ориентированного проектирования (АОП) ставит своей целью разработать механизм реализации сквозной функциональности в объектноориентированных системах. АОП не заменяет собой объектно-ориентированное проектирование (ООП), а всего лишь достраивает его концепции. Эта новая технология, позволяет компоновать сложные системы из взаимно пересекающихся блоков (crosscutting concerns). АОП вводит в действие аспекты (aspects). Они инкапсулируют особенности поведения взаимно влияющих друг на друга этапов обучения, представленных в виде классов, в составе повторно используемых обучающих модулей. Аспектно-ориентированные модели формируются на основе диаграмм последовательности обучения, которые проходят верификацию, выполняющуюся как редукцию графа распределения зависимости обучения этапам проектирования друг от друга. При использовании AspectJ большое число вызовов может быть заменено одним аспектом, который автоматически регистрирует и параметры, и возвращаемые значения наряду с входами и выходами метода. Модель обучения, отвечающую этим требованиям, можно представить в виде следующего аспекта: public aspect AutoTest{

pointcut publicMethods() : execution(public * org.sapr.test.*(.)); pointcut trainingCallsO : execution(*TrainingLession.*(.)); pointcut allCalls() : publicMethods() && trainingCallsO;

beforeO : allCalls(){

AutoPassword.entryPassword(thisJoinPoint.getSignatureQ.toString());

}

after() : allCalls(){

AutoPassword.statistic(thisJoinPoint.getSignature().toString());

}}

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

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

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

сделать простым расширение и изменение функциональных требований за счет функциональноинвариантных моделей;

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

упростить код системы с помощью локализации кода, не относящегося к основной функциональности;

упростить тестирование (можно тестировать различные аспекты обучения отдельно, а только потом вплетенные в систему); улучшить управляемость кода и как следствие — упростить эволюцию и сопровождение;

увеличить число повторно используемых модулей благодаря слабой связности подсистем.

ЛИТЕРАТУРА

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. М.: ДМК Пресс, 2000. 432 с.

2. Aldawud О., Elrad Т., Bader A. A UML Profile for Aspect-Oriented Modeling // Proc. of Aspect-

Oriented Programming Workshop at OOPSLA, 2001.

3. Stein D., Hanenberg S., Unland R. Designing Aspect-Oriented Crosscutting in UML // Proc. of

Workshop on Aspect-Oriented Modeling with UML at AOSD, 2002.