1.4. Особенности объектно-ориентированного анализа и проектирования систем искусственного интеллекта

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

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

• уменьшить время разработки и отладки базы знаний;

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

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

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

1.5. Описание программных средств, реализующих нотацию Unified Modeling Language

Для реализации RUP в настоящее время разработчики широко используют программные продукты компании Rational: Rational Rose, SoDA,

ROSE является CASE средством, чьи графические возможности, основанные на UML, способны решить задачи, связанные с объектным моделированием и проектированием: от общей модели процессов (абстрактной) предприятия до конкретной (физической) модели класса в создаваемом программном обеспечении. Работа в Rational Rose заключается в проектировании определенного вида диаграмм. Разработчик может задавать при этом все свойства объектов, отношения и взаимодействие друг с другом.

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

Необычайно богатый набор средств Rose предоставляет разработчикам:

1. Проектирование систем – кодогенерация. Позволяет нарисованную модель преобразовать в описание на конкретном языке программирования. Поддерживается: С++, Ada, Java, Basic, Xml, Oracle. Также к Rose сторонними компаниями разрабатываются специальные мосты к не входящим в стандартную поставку языкам, например, к Delphi.

2. Возможности обратного проектирования – реинжениринга, когда готовую информационную систему (например, на С++) или базу данных (на Oracle) “закачивают” в Rose с целью получения наглядной визуальной (структурной) модели.

3. Round-trip engineering – сочетает возможности первых двух подходов, когда создается система, а по прохождении некоторого времени эволюционного периода (доработок) подвергаетсявновь реинженирингу и вновь кодогенерации.

SoDA является инструментом автоматизации документооборота моделирования и проектрования.

Его основная обязанность - подготовить отчет по заранее установленному шаблону. Данные для отчета берутся из любой программы Rational. Отчет представляется в виде обычного документа в формате MS Word, включая спецификации и комментарии моделей. Система вызовов и меню интегрирована в Word и позволяет генерировать шаблоны на базе имеющихся файлов. SoDA допускает к использованию как стандартных шаблонов, так и созданных пользователем при помощи специального Wizard, также встроенного в систему меню Word.

Продукт обязателен для использования в составе любого проекта. Также особенную направленность продукт имеет на разработчиков и постановщиков задач.

Описанные выше три программных продукта полностью покрывают потребности аналитиков, проектировщиков и разработчиков. Вот список программ, позиционированных как Unified: RUP, SoDA, Requisite PRO, ClearQuest.

Requisite PRO

Управлением требованиями занимается продукт Requisite PRO.

Информационную систему любых размеров невозможно строить в отрыве от консультаций с заказчиком. Естественно, подобные консультации ведут к постоянному уточнению функций системы (выяснение требований). Подобное перекраивание строящейся системы редко ведет к ее улучшению, поскольку стороны изначально не договаривались о том, что система меняется (уточняется) в процессе разработки. Стало быть, все изменения носят шоковый характер, нанося немалый ущерб - как моральный, так и материальный. С точки зрения компании Rational, если на первом этапе выяснения функций планируемой системы у заказчика использовался инструмент Rational Rose, то 90% функций будет оговорено на самом начале пути разработки. И все же… требования будут вноситься, так пусть это будет обыденный безболезненный процесс!

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

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

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

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

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

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

Продукт также направлен на всех участников проекта.

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

ClearQuest помогает в решении данной задачи:

ClearQuest

ClearQuest является мощным средством управления запросами на изменение (change request management – CRM), специально разработанным с учетом динамической и сложной структуры процесса разработки ПО. ClearQuest отслеживает и управляет любым типом действий, приводящих к изменениям в течение всего жизненного цикла продукта, помогая, тем самым, организациям более предсказуемым (правильным) образом создавать качественное ПО.

Основные задачи, решаемые посредством ClearQuest:

• Управлять изменениями, возникающими в ходе процесса разработки ПО.

• Оптимизировать путь прохождения запросов на изменения, а также связанные с ним формы и процедуры.

• Через World Wide Web поддерживать связь внутри команд, разделенных территориально.

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

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

• Интегрироваться со средствами конфигурационного управления, такими как Rational’s ClearCase, позволяя создавать связи между запросами на изменение и развитие кода.

В качестве положительных черт данного продукта можно отметить его адаптивность (то есть продукт можно на месте доработать с учетом конкретной функциональности), масштабируемость, простоту в администрировании и использовании.

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

Запросы на изменения проходят цикл из нескольких состояний (states), начиная с подачи и заканчивая их разрешением. Например, только что поданный запрос находится в состоянии “Подан” (Submitted). После передачи запроса сотруднику он переходит в состояние “Назначен” (Assigned). Начало работы над запросом переводит его в “Открытое” состояние (Open), и вся команда может видеть, что кто-то обрабатывает запрос. Наконец, когда запрос проверен и закрыт, он проходит соответственно стадии “Проверка” (Verify) и “Закрыт” (Resolved).

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

Итак, мы рассмотрели пять программных продуктов, четыре из которых необходимы на протяжении всего цикла разработки ПО (RUP, ClearQuest, RequisitePRO, SoDA) и один, необходимый на самых ответственных этапах проектирования и кодогенерации (Rose, Rose RealTime).

Методы визуального моделирования

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

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

Модель, правильно разработанная с использованием объектной технологии:

• Проста для понимания. Она ясно отражает действительность.

• Проста для изменения. Изменение в конкретном явлении касается только объекта, который представляет это явление.