Артефакты анализа и проектирования

На этапе анализа и проектирования могут использоваться различные виды деятельности и артефакты, а также принципы и рекомендации.

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

С понятием «компонент» часто ассоциируют компонентное или сборочного программирование, однако это не верно с точки зрения UML. В терминах UML компонентное или сборочное программирование манипулирует артефактами!

Компонент (в UML) — это частью модели, описывающая логическую сущность, которая существует только во время проектирования (design time), хотя в дальнейшем ее можно связать с физической реализацией (артефактом) времени исполнения (run time).

При проектировании компьютерных обучающих систем на основе RUP с использованием универсального языка моделирования (Unified Modeling Language - UML) и CASE-средства Rational Rose предлагается разрабатывать следующие артефакты:

1. документ-концепция проекта, представляющий высокоуровневое определение системы и отражающий основные требования к ней;
2. модель предметной области в виде UML-диаграммы классов, отражающая формализацию концептуальных объектов, выявленных по документу-концепции компьютерной обучающей системы;
3. модель прецедентов (вариантов использования системы) в виде UML-диаграммы Use Case, отражающая функциональные требования к системе;
4. документ развернутого описания функций системы в виде сценариев как совокупности прецедентов;
5. расширенная модель предметной области с атрибутами в виде UML-диаграммы классов сущностей с атрибутами;
6. модель взаимодействия в виде UML-диаграмм последовательности и кооперации, описывающая динамику всех прецедентов системы;
7. модель проектирования в виде развернутой UML-диаграммы классов, описывающую реализацию прецедентов системы и служащую в качестве абстрактного представления исходного программного кода компьютерной обучающей системы;
8. модель базы данных: UML-диаграмма показывающая взаимодействие таблиц входящих в базу данных, а так же подробное описание атрибутов операций и связей между этими таблицами.

Этапы анализа и проектирования и взаимосвязь артефактов разработки компьютерной обучающей системы показаны на рис. 1.

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

Рис. 1. Взаимосвязь артефактов проектирования компьютерных обучающих систем

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

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

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

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

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

Выявленные и отраженные в модели предметной области классы используются в процессе дальнейшей разработки компьютерной

Рис. 2. Краткая схема документа-концепции для программного продукта

Рис. 3. Пример модели предметной области для компьютерной обучающей системы

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

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

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

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

На основе анализа модели прецедентов осуществляется дальнейшее уточнение модели предметной области: выявляются и добавляются ранее пропущенные концептуальные классы, удаляются избыточные классы. Из подробного описания прецедентов выявляются и добавляются в модель предметной области атрибуты классов.

Рис. 4. Диаграмма прецедентов компьютерной обучающей системы

Модифицированная таким образом модель предметной области - диаграмма классов сущностей с атрибутами (рис. 5) - является основой для модели проектирования компьютерной обучающей системы.

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

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

Основными элементами динамической части являются UML- диаграммы взаимодействия (последовательности и кооперации), которые создаются для каждого прецедента. Моделирование взаимодействия направлено на решение трех основных задач:

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

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

• закончить распределение операций по классам.

Рис. 5. Фрагмент диаграммы классов сущностей с атрибутами для компьютерной обучающей системы

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

На UML-диаграммах последовательности отражаются как основные, так и альтернативные потоки событий для каждого прецедента (рис. 6).

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

Диаграммы кооперации для компьютерной обучающей системы, полученные в Rational Rose автоматическим преобразованием из диаграмм последовательности, позволяют подробно проанализировать взаимодействие объектов системы при описании каждого прецедента. На рис. 4.23 представлена диаграмма кооперации для прецедента «Работа с тренажером».

Рис. 6. Диаграмма последовательности для прецедента «Работа с тренажером»

Рис. 7. Диаграмма кооперации для прецедента «Работа с тренажером»

Анализ диаграмм кооперации помогает выявить «узкие» места (избыточную загруженность) динамической модели проектируемой системы. Проверка следования определенным правилам взаимодействия объектов системы друг с другом даст возможность проверить наличие ошибок в диаграммах последовательности.

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

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

Рис. 8. Фрагмент модели проектирования компьютерной обучающей системы

Эта модель проектирования представляет основу для получения каркаса базы данных компьютерной обучающей системы, диаграмма которой может быть получена в Rational Rose.

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

Взяв за основу модель проектирования, с помощью инструмента Rational Rose Data Modeler можно автоматически сгенерировать модель базы данных для компьютерной обучающей системы. На рис. 4.25 представлен фрагмент модели базы данных, отображающей взаимосвязь всех ее элементов. Дополнительно инструмент Data Modeler дает возможнос ть сформировать описание каркаса базы данных на языках программирования (SQL, Oracle8, Ada83, Ada95 и т. д.).

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

Важно подчеркнуть, что переходу к этапу кодирования должен предшествовать анализ качества проекта, в том числе модульности, плотности классов, степени связанности объектов и других метрик.

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