<< Предыдущая

стр. 13
(из 26 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

• Какие изменения ожидаются в будущем?
При поиске ответов на эти вопросы следует учитывать:
1. Человеческий фактор. Основная причина неудач ранних опытных проектов OMIS заключалась в том, что разработчики игнорировали реальные потребности, способности, и цели пользователей системы [Malsch et al., 1993; Kuehn et al., 1994].
2. Стоимостной анализ. Во-первых, ядро проекта должно ориентироваться на критические процессы, «страдающие» от недостатка информационной поддержки. Во вторых, не следует перегружать начальную систему слишком большим количеством услуг, которые могут быть желательны, но не обещают быстрое возвращение инвестиций.
3. Эволюция знаний. Электронная поддержка особенно ценна в областях, подвергающихся быстрым изменениям, так как на таких предприятиях трудно обеспечить доступ к оперативной современной информации. В системах OMIS часто используют различные новые технологии обработки знаний, не имеющие пока общепринятых русскоязычных терминов и связанные с получением нового знания из анализа данных, например «открытие или разведка знаний» (Knowledge Discovery) и «разработка данных» (Data Mining). Разведка знаний представляет собой новое и быстро развивающееся направление, занимающееся «нетривиальным извлечением точной, ранее неизвестной и потенциально полезной информации из данных» [Piatetsky-Shapiro, Frawley, 1991]. В методах разведки данных используются различные подходы к анализу текста и числовых данных, плюс специальный инструментарий статистического анализа.
4. Чувствительность к контексту для естественно-языковых запросов. Система должна «понимать» контекст поступающих запросов. К примеру, она должна различать термины «размножение животных» и «размножение документов».
5. Гибкость. Система должна иметь возможность обрабатывать знания в различной форме и по разным темам в контексте работы данного предприятия.
6. Интеллектуальность. Система должна накапливать информацию о своих пользователях и о знаниях, которые она получает во время работы. Таким образом, со временем ее возможность «продуманно» предоставлять пользователям знания должна совершенствоваться.
До последнего времени при разработке OMIS остается целый ряд исследовательских вопросов [Kuehn and Abecker,1998]:
• Проблема обобщения моделей данных, словарей понятий или тезаурусов, онтологии. Основание для объединенной эксплуатации данных, документов, и формального знания — построение объединенных мета-моделей данных и знаний. Полезны были бы процедуры автоматического порождения тезауруса из существующих массивов документов. Объединенная онтология/тезаурус может использоваться, чтобы улучшить поиск, фильтрацию и маршрутизацию документов.
• Проблема объединения логического вывода и информационного поиска. Объединенная эксплуатация формальных и неформальных представлений знаний и данных — это последовательное сближение логических методов и методов информационного поиска и индексации данных.
• Соединение деловых процессов и управления знаниями. Окончательная цель состоит в том, чтобы обнаруживать информационную потребность в течение выполнения производственного процесса и определять уместное знание в специфическом контексте задачи. Первый прагматический шаг в этом направлении описан в работе [Hinkelmann и Kieninger, 1997], где авторы предлагают использовать информацию контекста задачи для информационной фильтрации.
Корпоративная память интегрирует знания, чтобы в решении новых задач опереться на предварительно накопленный опыт. Таким образом, можно избегать повторения ошибок, опыт может расширяться систематически, и информационно-емкие процессы работы могут быть выполнены более эффективными способами. В отличие от экспертных систем первичная цель систем OMIS — не поддержка одной специфической задачи, а лучшая эксплуатация необходимого общего ресурса — знаний.
В настоящее время существует значительный интерес к КМ со стороны промышленных компаний, которые осознают высокий прикладной потенциал корпоративной памяти для решения целого ряда практических задач обработки информации. С другой стороны, не многие из проектов идут далее стадии прототипа, что очевидно показывает, что компании стараются избегать затрат и риска вложения капитала в новые технологии, которые еще не нашли широкого распространения.


5.4. Визуальное проектирование баз
знаний как инструмент познания

Визуальные методы спецификации и проектирования баз знаний и разработка концептуальных структур являются достаточно эффективным гносеологическим инструментом или инструментом познания [Jonassen, 1993]. Использование методов инженерии знаний в качестве дидактических инструментов и в качестве формализмов представления знаний способствует более быстрому и более полному пониманию структуры знаний данной предметной области, что особенно ценно для новичков на стадии изучения особенностей профессиональной деятельности.
Методы визуальной инженерии знаний можно широко использовать в различных учебных заведениях — от школ до университетов — как для углубления процесса понимания, так и для контроля знаний. Большинство учеников и студентов овладевают навыками визуального структурирования в течение нескольких часов.

5.4.1. От понятийных карт
к семантическим сетям

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


Рис. 5.9. Пример понятийной карты

Программы визуализации являются инструментом, позволяющим сделать видимыми семантические сети памяти человека. Сети состоят из узлов и упорядоченных соотношений или связей, соединяющих эти узлы. Узлы выражают понятия или предположения, а связи описывают взаимоотношения между этими узлами. Поэтому разработка семантических сетей подразумевает анализ структурных взаимодействий между отдельными понятиями предметной области.
В процессе создания семантических сетей эксперт и аналитик вынуждены анализировать структуры своих собственных знаний, что помогает им включать новые знания в структуры уже имеющихся знаний. Результатом этого является более осмысленное использование приобретенных знаний.
Визуальные спецификации в форме сетей могут использоваться новичками и экспертами в качестве инструментов для оценки изменений, произошедших в их мышлении. Если согласиться, что семантическая сеть является достаточно полным представлением памяти человека, то процесс обучения с этой точки зрения можно рассматривать как реорганизацию семантической памяти.
Kozma [Kozma, 1992], один из разработчиков программы организации семантической сети Learning Tool, считает, что эти средства являются инструментами познания, усиливающими и расширяющими познания человека. Разработка семантических сетей требует от учеников:
• реорганизации знаний;
• исчерпывающего описания понятий и связей между ними;
• глубокой обработки знаний, что способствует лучшему запоминанию и извлечению из памяти знаний, а также повышает способности применять знания в новых ситуациях;
• связывания новых понятий с существующими понятиями и представлениями, что улучшает понимание;
• пространственного изучения посредством пространственного представления понятий в изучаемой области [Fisher, Faletn, Paterson, Lipson, Thorton & Spring, 1990].
Полезность семантических сетей и карт понятий, пожалуй, лучше всего Демонстрируется их связями с другими формами мышления высшего порядка. Они тесно связаны с формальным обоснованием в химии [Schreiber & Abeg, 1991] и способностью аргументировать свои высказывания в биологии [Briscoe & LeMaster, 1991; Mikulecky, 1987]. Также было показано, что семантические сети имеют связь с выполнением исследований [Goldsmith, Johnson & Acton, 1991].

5.4.2. База знаний
как познавательный инструмент

Когда семантическая сеть создается как прообраз базы знаний, разработчик должен фактически моделировать знания эксперта. Особенно глубокого понимания требует разработка функциональной структуры.
Определение структуры ЕСЛИ-ТО области знаний вынуждает четко формулировать принципы принятия решения. Нельзя считать, что просто разработка поля знаний системы обязательно приведет к получению полных функциональных знаний в данной области.
Разработка экспертных систем стала использоваться как инструмент познания сравнительно недавно. Lippert [Lippert, 1988], который является одним из пионеров применения экспертных систем в качестве инструментов познания, утверждает, что задания по созданию небольших базисов правил являются очень полезными для решения педагогических проблем и структурирования знаний для учеников от шестого класса до взрослых. Изучение при этом становится более осмысленным, так как ученики оценивают не только сам процесс мышления, но также и результаты этого процесса, то есть полученную базу знаний. Создание базы знаний требует от учеников умения отделять друг от друга факты, переменные и правила, относящиеся к связям между составляющими области знаний.
Например, Lai [Lai, 1989] установил, что после того, как студенты-медики создадут медицинскую экспертную систему, они повышают свое умение в плане аргументации и получают более глубокие знания по изучаемому предмету. Шесть студентов-первокурсников физического факультета, которые использовали экспертные системы для составления вопросов, принятия решений, формулировки правил и объяснений относительно движения частицы в соответствии с законами классической физики, получили более глубокие знания в данной области благодаря тщательной работе, связанной с кодированием информации и обработкой большого материала для получения ясного и связного содержания, а следовательно, и большей семантической глубины [Lippert & Finley, 1988].
Таким образом, создание базы знаний экспертной системы способствует более глубокому усвоению знаний, а визуальная спецификация усиливает прозрачность и наглядность представлений.
Когда компьютеры используются в обучении как инструмент познания, а не как контрольно-обучающие системы (обучающие компьютеры), они расширяют возможности автоматизированных обучающих систем (АОС), одновременно развивая мыслительные способности и знания учеников. Результатом такого сотрудничества учащегося и компьютера является значительное повышение эффективности обучения. Компьютеры не могут и не должны управлять процессом обучения. Скорее, компьютеры должны использоваться для того, чтобы помочь ученикам приобрести знания.
В данном параграфе будет описываться автоматизированное рабочее место (АРМ) инженера по знаниям KEW (Knowledge Engineering Workbench) [Гаврилова, 1995; Гаврилова, Воинов, 1995-1997], который наряду с такими программами, как SemNet [Fisher 1990, 1992], Learning Tool [Kozma, 1987], TextVision [Kommers, 1989] или Inspiration, дает возможность ученикам, экспертам или аналитикам связать между собой изучаемые ими понятия в многомерные сети представлений и описать природу связей между всеми входящими в сеть понятиями.
Последняя версия KEW, созданная совместно с Воиновым А. В., получила первую премию на выставке программных систем IV Национальной конференции по искусственному интеллекту в 1994 г. в разделе программных инструментари-ев разработки интеллектуальных систем. KEW демонстрирует жизнеспособность технологии автоматизированного проектирования интеллектуальных систем (АПРИС) или CAKE (Computer Aided Knowledge Engineering), впервые описанной в работе [Гаврилова, 1992].
KEW предназначен для интеллектуальной поддержки деятельности инженера по знаниям на протяжении всего жизненного цикла разработки экспертной системы, включая стадии — идентификации проблемы, получения знаний, структурирования знаний, формализации, программной реализации, тестирования.
Центральным блоком KEW является графический структуризатор знаний KNOST (KNOwledge STucturer). Система KNOST поддерживает последовательную графическую реализацию ОСА (см. параграф 3.4) и автоматическую компиляцию БЗ из графической спецификации.

Рис. 5.10. Интерфейс АРМа инженера по знаниям
Интерфейс KNOST состоит из трех основных частей (рис. 5.10):
• панель концептуальной структуры;
• панель гипертекста;
• панель функциональной структуры.
Панель концептуальной структуры предназначена для графического структурирования знаний. Она позволяет определить понятия и обозначить связи между ними в форме концептуальной структуры Sk.
В панель гипертекста можно поместить любой комментарий, связанный с объектом, определенным на панели концептуальной структуры понятий.
Основное назначение панели функциональной структуры Sf — представить наглядно в форме строк таблицы причинно-следственные и другие функциональные взаимосвязи между понятиями концептуальной структуры, на основании которых эксперт принимает решения. Столбцы таблицы формируются простейшей операцией drag-and-drop из понятий на панели концептуальной структуры.
После того как модели Sk и Sf созданы, KNOST автоматически компилирует базу знаний на ПРОЛОГе из созданной графической спецификации и моделирует работу экспертной системы. Это удобно для быстрого наглядного прототипирования ЭС и для отладки БЗ совместно с экспертом.

5.5. Проектирование гипермедиа БД и
адаптивных обучающих систем

5.5.1. Гипертекстовые системы

Первые информационные системы на основе гипертекстовых (ГТ) моделей появились еще в середине 60-х [Engelbart, 1968], но подлинный расцвет наступил в 80-е годы после появления первых коммерческих ГТ систем для ПЭВМ — GUIDE (1986 г.) и HyperCard (1987 г.). В настоящее время ГТ технология является стандартом de facto в области АОС и сверхбольших документальных БД [Nielsen, 1990; Агеев, 1994].

Навигация по таким сетям осуществляется по связям между узлами. Основные функции связей [Conklin, 1987]:
• перейти к новой теме;
• присоединить комментарий к документу;
• соединить ссылки на документ с документом, показать на экране графическую информацию (рисунок, чертеж, график, фотографию и пр.);
• запустить другую программу и т. д.
Учитывая широкое использование графовых структур в моделировании, ГТ может приобретать черты более сложных моделей, например сетей Петри, диаграмм состояний и др.
В настоящее время не существует стандартизированной технологии разработки «хорошо структурированного» ГТ, хотя важность когнитивно-наглядной и «прозрачной» структуры ГТ очевидна.
В качестве рабочего упрощенного алгоритма составления ГТ можно предложить следующий (в п. 5.5.3 будет представлен более сложный вариант).


5.5.2. От мультимедиа к гипермедиа


Когда элементы ММ объединены на основе сети гипертекста, можно говорить о гипермедиа (ГМ). Основной сферой применения ГМ сегодня являются автоматизированные обучающие системы (АО С) или электронные учебники. Размещение в узлах сети не только текстовой и цифровой информации, но и графиков, видеоклипов, фото и музыки обогащает гипертекст и увеличивает занимательность и наглядность электронных учебников. В последние годы ММ активно внедряется и в интеллектуальные системы [Nielsen, 1990], особенно в системы-консультанты, как эффективное средство увеличения наглядности и понятности рекомендаций, выдаваемых системой. Использование анимации, звука и видео существенно облегчает усвоение учебного материала по структурированию знаний и снижает уровень когнитивных усилий учащихся при одновременном уменьшении времени, необходимого на изучение данной проблематики.
Основной предпосылкой интереса к гипермедиа-системам является фактически беспрецедентный успех глобальной сети Интернет и WWW-технологии.
Другим фактором появления ГМ можно считать мощный прорыв на рынке машинных носителей информации со стороны фирм, производящих компакт-аудиодиски (PHILIPS, SONY, NIMBUS) в виде CD-ROM (Compact Disc Read Only Memory), позволяющих хранить до 600 Мб информации, тем самым открывая дверь для обработки BLOB (Binary Large Objects) — больших двоичных объектов, например оцифрованных видеоизображений.
Тем не менее существует целый ряд проблем, с которыми сталкиваются разработчики ММ-систем, независимо от того, ориентированы они на Интернет-приложения или на автономные учебники на CD-ROM:
• отсутствие методологии и технологии структурирования разнородной информации;
• отсутствие единых стандартов на системы кодирования и обработки;
• сложные аппаратные и программные решения проблем аналого-цифровых преобразований и синхронизации полноэкранного видео.
Сейчас не существует единой методологии, а тем более технологии разработки ГМ систем, такое состояние характеризуется как «no science, rather art», то есть «не наука, а искусство». Однако первые подступы к созданию технологии уже сделаны [Кирмайкл, 1994; Reisman, 1991], и разработки в этой области продолжают активно развиваться.
Традиционно процесс разработки ГМ включает:
Фаза 1 — проектирование и разработка структуры и отдельных фрагментов гипермедиа-приложения, включая звуковые и видеоролики, программное окружение. 1 фаза — наиболее трудоемкий по времени и человеческим ресурсам период. Эту фазу осуществляет команда, состоящая из:
• менеджера;
• специалиста по системам обучения;
• эксперта предметной области;
• дизайнера-графика;
• системного аналитика;
• сценариста;
• программиста.
Фаза 2 зависит от того, на какой вариант приложения рассчитана система.
Для Интернет-приложений разрабатываются Web-страницы на языке HTML с включением оцифрованных в специальных форматах звука, изображений, анимации и видео. При этом могут использоваться специальные пакеты, например Dreamwever или FrontPage.
Для изготовления CD-дисков используется как HTML-формат, так и специальные программные средства (authoring languages and systems), как, например Toolbook или Macromedia Director.
Фаза 3 включает прототипирование CD-ROM на специальном устройстве WORM
(Write Once Read Many) и его тестирование либо размещение приложения на
Интернет-сайте.
Фаза 4 — это тиражирование и производство готовых CD ROM.

5.5.3. На пути к
адаптивным обучающим системам

Инструментом познания согласно концепции параграфа 5.4 можно считать и процесс проектирования структуры гипертекста. Ранее нами [Гаврилова, 1996-99] был предложен подход, трактующий структуру (граф) гипертекста (ГТ) как «скелет» поля знаний, то есть наиболее информационно-нагруженный элемент поля знаний. Именно этот граф отражает структуру знания, которую можно назвать гиперзнания. Усвоение этой структуры является важнейшим компонентом процесса обучения. Очевидно, чем более будет конкретная структура ГТ соответствовать индивидуальной когнитивной структуре, тем эффективнее будет идти процесс обучения. Фактически это означает, что обучение и тренинг будут организованы не через навязывание конкретных когнитивных структур обучаемому и ломку старых представлений, а через проекцию нового знания на каркас индивидуального опыта и наращивание уже имеющихся когнитивных структур. Такая адаптация к индивидуальным познавательным структурам может существенно повысить эффективность обучающих систем.
Предлагаемый подход позволяет представить поле знаний предметной области в виде релевантной гиперструктуры HS, узлами которой являются концепты А, выделяемые экспертами как «опорные», то есть принципиально значимые. Связи или отношения R используются для переходов между узлами. Такая трактовка является естественным развитием моделей представления знаний типа семантических сетей, которые на современном этапе считаются наиболее адекватными человеческой структуре памяти [Величковский, 1982; Шенк, Хантер, 1987]. Естественно, что такие концептуально-когнитивные структуры отличаются резкой индивидуальностью, связанной с личностными, интеллектуальными и профессиональными различиями носителей знаний. В некотором смысле такая структура является когнитивной моделью индивида.
Предлагаемый подход согласуется с концепцией мультидеревьев [Furna, Zacks, 1994], реализующей множественное представление ПО. Модель пользователя, сформированная по этому принципу, будет отражать «модель мира» данного конкретного пользователя в виде гиперграфа, узлы которого, в свою очередь, могут быть раскрыты в виде гиперструктур более низкого уровня. Фактически это соответствует субъективным концептуальным структурам в памяти. Часто в проблематике АОС используют понятие «сценария». Традиционно под сценарием понимается описание содержательного, логического и временного взаимодействия структурных единиц программы, с помощью которых реализуется авторская цель [Бойкачев, Конева, Новик, 1994].
Очевидно, что в гипермедиа учебных приложениях естественным представлением сценария является граф гипертекста. При этом важно добиваться, чтобы этот сценарий соответствовал (был релевантным) представлениям как учителей, так и учеников.

Для формирования стратифицированного множества вершин А можно использовать модификацию алгоритмов объектно-структурного анализа ОСА (параграф 3.4).


Данный алгоритм выявляет канонический или основной сценарий, альтернативные сценарии формируются на основании либо иного опыта преподавания, либо с учетом категории пользователей.
Последовательное применение данного подхода и визуальных методов проектирования позволило сформировать ГРАФИТ-технологию и реализовать ее в ряде программных продуктов ВИКОНТ (ВИзуальный Конструктор Онтологии), ПЕГАС (ПроЕктирование Гипер-Активных Схем) [Гаврилова и др., 1998-2000] (рис. 5.11).
При разработке гипермедиа-приложений необходимо также учитывать фактор сбалансированности звуковых и видеоузлов опорной ГТструктуры, то есть аудио- и видеофрагменты должны равномерно распределяться на сети. Для этого в технологию ГРАФИТ введено понятие «раскраски» узлов, что позволяет наглядно оценить сбалансированность сети по аудио- и видеонагрузке. Алгоритм «ОСА-гипер» учитывает необходимость анализа не только исходной информации, но и навигационных возможностей:
• перемещение на экран назад;
• возврат к началу;
• возврат к началу секции;
• просмотр структуры;
• озвучивание экрана;
• включение видео;
• помощь;
• перемещение на экран вперед.



Рис. 5.11. ГРАФИТ-технология визуального проектирования ГТ

Особенно ценно в реализации графической навигации то, что в произвольный момент пользователь может посмотреть структуру сценария и понять, в каком месте он сейчас находится.
Данный подход использован при создании ГТ АОС в области инженерии знаний для систем дистанционного обучения (Gavrilova, Stash, Udaltsov, 1998). Системы обучения в области ИИ имеют пока небольшую историю, хотя при отсутствии учебников по данным дисциплинам эти электронные учебники особенно необходимы. Известны лишь единичные работы в нашей стране и за рубежом — «База знаний для разработчиков ЭС» [Молокова, Уварова, 1992] и KARTT (Knowledge Acquisition Research and Teaching Tool) [Liebovitz, Bland, 1994].
При проектировании любой ГТ структуры нетривиальной задачей является выделение «опорных» концептов — вопрос, практически не освещенный в литературе. В работе [Гаврилова, Червинская, 1993] представлен обзор различных методов извлечения знаний, частично включающих и исследования по выявлению значимых концептов. Можно предложить использовать для этой цели методы многомерного шкалирования, позволяющие выявлять структуру индивидуальных ментальных пространств, анализируя попарные связи понятий предметной области (см. п. 5.1).
Эти методы использовались и ранее для изучения семантических пространств памяти [Терехина, 1988; Петренко, 1988; Cook, 1985], однако можно использовать новый подход, ориентированный на анализ не только осей ментальных пространств с выявлением соответствующих конструктов, но и точек сгущения понятий, называемых «аттракторами» для выявления метапонятий или концептов.
В дальнейшем эти концепты образуют узлы {А} релевантной ГТ структуры, которую можно фактически трактовать как модель пользователя UM (user model):
UM = {A, R}.

Более широкие исследования [Voinov, Gavrilova, 1993; Воинов, Гаврилова, 1994] показали, что психосемантические методики (см. п. 5.1), обогащенные новыми элементами (использование метафорических планов), могут способствовать выявлению имплицитных структур знаний, не поддающихся выявлению другими методами.
Использование UM как гиперструктуры в гипертекстовых АОС позволяет создавать «гибкие» релевантные сценарии, ориентированные на когнитивные особенности определенных групп пользователей. Последнее замечание можно также отнести к разработке систем гипермедиа. Очевидно, что глубокое и конструктивное изучение человеческого фактора в области computer science может существенно раздвинуть ограничения современных интеллектуальных и обучающих систем.
























Программный инструментарий
разработки систем, основанных
на знаниях

Ё Технологии разработки программного обеспечения — цели, принципы, парадигмы
Ё Методологии создания и модели жизненного цикла интеллектуальных систем
Ё Языки программирования для ИИ и языки представления знаний
Ё Инструментальные пакеты для ИИ
Ё WorkBench-системы

6.1. Технологии разработки программного
обеспечения — цели, принципы, парадигмы

6.1.1. Основные понятия процесса
разработки программного обеспечения (ПО)

Как известно, технология (от греческого технос — мастерство, логос — слово, наука) — это наука о мастерстве.

В широком смысле технология разработки ПО должна обеспечивать последовательный подход к созданию программных систем. Наиболее очевидная цель в разработке ПО состоит в соблюдении установленных заказчиком требований при реализации системы. Однако у заказчика редко имеются полные и последовательные определения требований. Обычно и заказчик и разработчик не до конца понимают проблему, и требования совершенствуются в процессе разработки, системы. Необходимо отметить и факт изменения требований в течение жизненного цикла программной системы.
Изменения являются постоянным фактором разработки ПО. Для того чтобы преодолеть их разрушающий эффект, в качестве целей технологии разработки ПО принимаются следующие четыре свойства программных систем [Ross et al., 1975]:
1. Модифицируемость. Необходимость модификации ПО обычно возникает по двум причинам: чтобы отразить в системе изменение требований или чтобы исправить ошибки, внесенные ранее в процессе разработки.
2. Эффективность системы подразумевает, что при функционировании оптимальным образом используются имеющиеся в ее распоряжении ресурсы: время и память.
3. Надежность системы ПО означает, что она должна предотвращать концептуальные ошибки, ошибки в проектировании и реализации, а также ошибки, возникающие при функционировании системы.
4. Понимаелюстъ. Последняя цель технологии ПО — понимаемость — является мостом между конкретной проблемной областью и соответствующим решением. Для того чтобы система была понимаемой, она должна быть «прозрачной».
Цели технологии разработки ПО, рассмотренные выше, не могут лишь пассивно признаваться. Наоборот, по мере выполнения работ необходимо придерживаться определенного набора принципов, которые обеспечивают достижение этих целей. В качестве таких принципов обычно выделяют [Ross et al., 1975; Буч, 1992] абстракцию, сокрытие информации, модульность, локализацию, единообразие, полноту и подтверждаемостъ.
Абстракция является одним из основных средств для управления сложными системами ПО. Суть абстракции состоит в выделении существенных свойств с игнорированием несущественных деталей. По мере декомпозиции решения на отдельные компоненты каждая из них становится частью абстракции на соответствующем уровне. Абстрагирование применяется и к данным, и к алгоритмам. На любом уровне абстракции могут фиксироваться абстрактные типы данных, каждый из которых характеризуется множеством значений и множеством операций, применимых к любому объекту данного типа.
Сокрытие или упрятывание информации имеет целью сделать недоступными детали, которые могут повлиять на остальные, более существенные части системы. Упрятывание информации обычно скрывает реализацию объекта или операции и, таким образом, позволяет фиксировать внимание на более высоком уровне абстракции. Кроме того, сокрытие проектных решений нижнего уровня оберегает стратегию принятия решений верхнего уровня от влияния деталей.
Абстракция и сокрытие информации способствуют модифицируемости и пони-маемости систем ПО. На каждом уровне абстракции допускается применение лишь определенного набора операций и делается невозможным применение любых операций, нарушающих логическую концепцию данного уровня, за счет чего повышается надежность программной системы.
Модульность является следующим фундаментальным свойством, помогающим управлять сложностью систем ПО. Она реализуется целенаправленным конструированием. В самом общем плане модули могут быть функциональными (процедурно-ориентированными) или декларативными (объектно-ориентированными). Связность модулей определяется как мера их взаимной зависимости. В идеале должны разрабатываться слабо связанные модули. Другой мерой, применимой к модульности, является прочность, которая определяет, насколько сильно связаны элементы внутри модуля.
Локализация помогает создавать слабо связанные и весьма прочные модули. По отношению к целям технологии разработки ПО принципы модульности и локализации прямо способствуют достижению модифицируемости, надежности и понимаемости.
Абстракция и модульность считаются наиболее важными принципами, используемыми для управления сложностью систем ПО. Но они не являются достаточными, потому что не гарантируют получения согласованных и правильных систем. Для обеспечения этих свойств необходимо привлекать принципы единообразия, полноты и подтверждаемости.
Принципы технологии разработки ПО не должны применяться случайно — необходимо выполнять структуризацию системы определенным образом и, что самое важное, поскольку происходит деление системы на модули, применять согласованные критерии декомпозиции. Можно выделить три основных подхода к разработке ПО, обеспечивающие такие критерии: нисходящее структурное проектирование [Йордан, 1979]; проектирование, структурированное по данным [Jackson, 1975], и объектно-ориентированное проектирование [Booch, 1986].
Нисходящее структурное проектирование определяет декомпозицию системы путем оформления каждого шага этого процесса в виде модуля. Это приводит к созданию функциональных программных модулей.
Проектирование, структурированное по данным, является альтернативой нисходящей методологии. При этом сначала определяются структуры данных, а затем на их основе определяется структура программных модулей. Таким образом, здесь делается попытка сначала четко определить реализацию объектов, а затем сделать их структуру видимой в функциональных модулях, обеспечивающих операции над объектами.
Методы нисходящего проектирования императивны по своей природе. Они заставляют концентрировать внимание на операциях, мало заботясь о проектировании структур данных. Методы проектирования, основанныена структурировании по данным, находятся как бы на другом конце спектра. Они концентрируют внимание на объектах, а операции трактуют глобальным образом.
В идеале разработчикам ПО хотелось бы использовать подход, позволяющий строить решения прямо в соответствии с имеющимся представлением проблемы. Кроме того, как и в естественном языке, желательна сбалансированность объектов и операций на уровне принимаемых решений.
Такой подход получил название объектно-ориентированного [Booch, 1986]. Здесь учитывается важность трактовки объектов ПО как активных элементов, причем каждый объект наделен своим собственным набором допустимых операций. Легко убедиться, что объектно-ориентированная парадигма поддерживает основные принципы технологии разработки ПО.

6.1.2. Модели процесса разработки ПО
В литературе существует множество нареканий на несовершенство данного разбиения [Липаев и др., 1983], но смысл его в целом достаточно ясен — борьба со сложностью процесса разработки программных продуктов за счет структуризации этапов и локализации на каждом из них только тех задач, которые могут и должны решаться именно здесь. Если перечисленные выше этапы укрупнить, останутся стадии проектирования, реализации и сопровождения.
Проектирование предполагает составление формальных и/или формализованных спецификаций.
Реализация — преобразование этих спецификаций в программный код (автоматическое и/или автоматизированное).
Сопровождение — тестирование разработанной системы, ее внедрение и последующую модификацию, которая, в свою очередь, может вернуть весь процесс к стадии проектирования .(перепроектирование).
Ключевой стадией в жизненном цикле процесса разработки ПО является проектирование. Ошибки и просчеты, допущенные здесь, — самые «дорогие». Поэтому основные усилия в области технологии программирования направлены на автоматизацию проектирования программных комплексов. При этом базисными понятиями являются модель программы и модель системы.
Существуют различные подходы к разработке таких моделей [Миллс, 1970]. Однако с точки зрения целей настоящей книги нас будут интересовать, в первую очередь, те из них, которые имеют непосредственное продолжение в инструментальных средствах и интегрированных инструментальных средах. Поэтому ниже основное внимание будет уделено моделям программ, которые используются в так называемых WorkBench-системах (наиболее близким по семантике к этому термину является словосочетание «станок для производства ПО»).
Одну из таких моделей предлагает W/0 (Warnier/Orr) методология [Orr et al., 1977]. Она объединяет методологию Warnier по использованию логических
структур данных и логических конструкции программ и систем и методологию DSSD (Data Structured System Development) Oppa, базисом которой является аксиома о логическом соответствии между эвристической структурой программ и данных, обрабатываемых этими программами. На практике такая методология предполагает, что в распоряжении проектировщика системы имеется представительный набор процедурных шаблонов для достаточно широкого класса программируемых задач.
В настоящее время DSSD-методология «переросла» из методологии разработки программ в методологию разработки систем. При этом выделены явно уровень программирования (programming level) и системный уровень (system level). Применяются в DSSD два концептуальных представления — диаграммы входов (Entity diagrams), обеспечивающие определение системного контекста, и модифицированные W/O-диаграммы (Assembly-line Diagrams), специфицирующие функциональное развитие системы [McClure, 1979].
Следующим подходом к созданию моделей программ (по идее достаточно близким к W/O-методологии) является логическое моделирование Гэйиа [Cane et al., 1979]. Сам метод ориентирован на создание систем обработки данных. Логическая модель системы проектируется в процессе последовательного применения следующих семи этапов: описание природы предметной области с помощью диаграмм потоков данных (Data Flow Diagram); выделение первичной модели данных (списка элементов данных в каждом информационном узле); проверка того, что DFD действительно отражает структуру данных, хранимых в системе; сведение полученной на предыдущем этапе информации в двумерные таблицы, которые в дальнейшем нормализуются; коррекция DFD с учетом результатов нормализации предыдущего этапа; разбиение полученной в результате выполнения предыдущих этапов модели на «процедурные единицы» (procedure units), а также определение деталей каждой процедурной единицы. После выполнения этих этапов принимается решение о необходимости прототипирования системы на целевом языке.
И наконец, третьим в ряду подходов к созданию модели проектируемой программы является метод Йордана (Yourdon) [Yourdon et al., 1979; Yourdon, 1989]. Он включает два компонента: инструментальные средства и методики. Ориентирована методология Йордана на проектирование систем обработки данных. Под инструментальными средствами здесь понимаются различные диаграммы, используемые при описании моделей требований и моделей архитектуры проектируемой информационной системы. Самые известные из таких диаграмм — диаграммы потоков данных DFD. Однако их недостатком является отсутствие средств описания отношений между данными и их «поведения» во времени. Вот почему в инструментальные средства метода Йордана на сегодняшний день кроме DFD включены ERD-диаграммы (Entity Relationship Diagrams) и STD-диа-граммы (State Transition Diagrams).
Методики в методе Йордана помогают перейти от бланка на бумаге и/или экранной формы к хорошо организованной системной модели. Первоначально эти методики базировались на традиционном top-down проектировании. В настоящее время здесь используется метод событийного разбиения (event partitioning). При этом сначала создается контекстная диаграмма верхнего уровня (top level context diagram), где определяются системные ограничения и интерфейсы с внешним «миром». Затем с помощью техники интервью формируется список событий из внешней среды, на которые система должна реагировать. Такой подход обеспечивает простой базис для формирования «сырой» DFD. Несколько DFD-реакций могут быть объединены в реакцию более высокого уровня. Критерием такого объединения является наличие узлов, связанных общими данными. По существу, событийное разбиение не что иное, как метод объектно-ориентированного проектирования.
Проблемы, возникающие при использовании метода ERD-диаграмм, связаны, прежде всего, с трудностями интеграции компонентов при разработке всей системы. Вот почему в последнее время этот метод был обобщен за счет введения интегрированной базы данных. При этом ERD-метод трансформируется в структурную методологию, основные этапы которой сводятся к разработке ERD (здесь выделяются как собственно сущности с их типами, так и связи, тоже с их типами); определению кардинальности (cardianality) — однозначности-многозначности типов связей; преобразованию ERD по определенным правилам в соответствующий файл и структуру БД. В процессе такого преобразования каждый тип сущности трансформируется в отношение, а тип связи —- в особое (stand alone) отношение или объединяется с другими отношениями в зависимости от кардинальности типа связи. Разработка прикладных программ на основе сформированного файла и структуры базы данных является заключительным этапом в этом подходе.
Последним методом, который кратко рассматривается в данном подразделе, является метод структурного проектирования (Structured Design) [Yourdon et al., 1979]. Структурное проектирование сделалось действительно мощным и активно используемым на практике подходом за счет того, что к моделям и методам были добавлены оценки результатов проектирования. Здесь предлагаются все проектные решения располагать в 3-мерном пространстве (содержание — сложность — связность). И утверждается, что хорошими проектными решениями будут лишь те, которые при заданном содержании имеют минимальную сложность и максимальную связность. По существу, этот критерий отражает уже обсуждавшиеся выше понятия абстрагируемости, модульности, сокрытия информации, связности и т. п. Конкретным примером воплощения структурного подхода является «водопадная» или «каскадная» (waterfall) модель разработки систем ПО [Balzer etal, 1983].
Технология программирования уже прошла достаточно долгий путь развития, и сейчас происходит переоценка ее фундаментальных исходных посылок. Первым кандидатом для такой переоценки стала традиционная точка зрения на процесс разработки ПО, как на процесс, основанный на понятии жизненного цикла. Растущее единодушие специалистов состоит в том, что данная точка зрения должна быть заменена такой, которая в большей степени соответствовала бы разработкам, поддерживаемым автоматизированными средами.
В качестве примера смены парадигм можно отметить спиральную модель процесса разработки МО (рис. 6.1), предложенную Боэмом [Boehm, 1986], суть которой состоит в том, что отдельные фазы процесса «прокручиваются» на постепенно повышающихся уровнях иерархии.

Рис. 6.1. Спиральная модель Боэма
Результатом разработки при этом становится не только программный код, но и его представление на более высоком уровне, что особенно важно в тех случаях, когда ПО эволюционизирует. Естественно, что такая модель предполагает наличие более гибких механизмов взаимодействия между потребителями и разработчиками и соответствующих инструментальных средств.
В Европе это направление ассоциируется, прежде всего, с проектированием ПО на основе объектно-ориентированных методологий, среди которых наиболее популярными являются технология MERISE и методология Шлайера—Мэллора (Shlaer-Mellor) [Andre et al, 1994; Shlaer et al., 1992].
В рамках данного подхода проектирование рассматривается как процесс, протекающий в пространстве трех измерений: «статика»—«динамика»—«алгоритмы» (рис. 6.2).



Рис. 6.2. Проектирование в методологии Shlaer-Mellor

Жизненный цикл при этом похож на виток в спирали Боэма, но включает другие стадии. Первая из них связана с осью «Статика» и предполагает идентификацию и описание объектов, атрибутов и отношений, которые требуются для спецификации проектируемой системы. Вторая стадия служит для описания поведения каждого объекта в ответ на внешние запросы и дает в качестве результата совокупность жизненных циклов всех введенных объектов. Затем проектируются алгоритмы реализации действий, специфицированных на предыдущей стадии, и, наконец, на четвертой стадии осуществляется валидация спроектированной системы на полноту и функциональное соответствие исходной задаче. Последняя стадия может потребовать нового витка в модели жизненного цикла.

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

6.1.3. Инструментальные средства поддержки
разработки систем ПО

Технология программирования в целом и средства поддержки разработки ПО, в частности, развиваются настолько быстро, что даже простое перечисление основных инструментальных систем заняло бы в этой книге слишком много места. Вот почему ниже мы остановимся кратко лишь на нескольких проектах в области технологии программирования, которые интересны в контексте данного издания. Любая развитая технологическая система должна поддерживать все основные этапы создания проектируемого программного комплекса. Для достижения этой цели в общей структуре типовой технологической системы поддержки разработки (рис. 6.3) обычно выделяют базу данных проекта; подсистему автоматизации проектирования и программирования; подсистемы отладки, документирования и сопровождения, а также подсистему управления ходом выполнения проекта.


Рис. 6.3. Общая структура типовой технологической
системы поддержки разработки
Развитые библиотечные системы поддержки разработки используются в настоящее время во всем мире во всех сколько-нибудь серьезных программных проектах. Но в подавляющем большинстве случаев такие системы достигли уровня удобства работы с ними квалифицированных программистов. Нас же, прежде всего, интересуют системы и проекты, в которых имеются тенденции к эксплицитному представлению технологических знаний, даже если они и не базируются на идеях и методах ИИ.
Один из таких проектов — Gandalf [Haberman et al., 1986] — ориентирован на автоматизированную генерацию систем разработки программного обеспечения. Исследования, выполняемые в рамках проекта Gandalf, касаются трех аспектов поддержки проектирования ПО: управление проектом, контроль версий и инкрементное программирование, а также интеграция их в единую среду. Управление в Gandalf-среде базируется на предположении, что разрабатываемый проект должен трактоваться как множество абстрактных типов данных, над которыми могут выполняться лишь определенные операции. Средством, реализующим данную концепцию, явилась система SDC (Software Development Control), представляющая собой набор программ, первоначально реализованных на языке Shell в системе UNIX, а позднее переведенная на язык С.
Исследования в области контроля версий были начаты еще Л. Коопридером на базе проекта FAFOS [Habermann et al., 1976], где изначально анализировались возможности создания семейства операционных систем. Была разработана нотация для описания взаимодействия между подсистемами:, для описания различных версий подсистем (исходного и объектного кода, документации и т. п.) и для описания действующих на этапе разработки механизмов (компиляция, редактирование связей и т. п.). Затем был создан специальный язык Intercol как средство описания взаимосвязи и версий модулей в системе. И наконец, в систему были встроены знания о том, как конструировать систему из частей, не заставляя заниматься этим пользователя. В развитие этих работ была создана система SUCE, в рамках которой отслеживались различия между реализациями (версиями, которые действительно дают код для ряда спецификаций) и композициями (версиями, определяющими новые подсистемы как группы существующих подсистем).
В системе LOIPE (Language-Oriented Incremental Programming Environment) инкрементная компиляция выполняется на уровне отдельной процедуры. Достоинством такого подхода является то, что при коррекции процедуры на уровне локальных объектов или типов перекомпилируется только она. Если же меняется спецификация, то перекомпилируются и все зависящие от нее процедуры. Пользовательский интерфейс с LOIPE-системой базируется на подсистеме синтаксически-ориентированного редактирования ALOE (A Language-Oriented Editor). Целью разработки этой подсистемы было исследование возможности создания и использования синтаксически-ориентированных редакторов в качестве базиса для сред программирования.
Анализ литературы последних лет по технологии программирования показывает, что новой ветвью в технологии промышленной разработки и реализации сложных и значительных по объему систем программного обеспечения является CASE-технология (Computer Aided Software Engineering) [BYTE, 1990].
Первоначально CASE-технология появилась в проектах создания промышленных систем обработки данных. Это обстоятельство наложило свой отпечаток и на инструментальные средства CASE-технологии, где самое серьезное внимание уделялось, по крайней мере в ранних CASE-системах, поддержке проектирования информационных потоков. В настоящее время наблюдается отход от ориентации на системы обработки данных, и инструментальные средства CASE-технологии становятся все более универсальными.
Все средства поддержки CASE-технологии делятся на две большие группы: САSE-ToolKits и CASE-WorkBenches. Хороших русских эквивалентов этим терминам нет. Однако первые часто называют «инструментальными сундучками» (пакетами разработчика, технологическими пакетами), а вторые — «станками для производства программ» (технологическими линиями).

Такие пакеты используют общее «хранилище» для всей технической и управляющей информации по проекту (репозиторий), снабжены общим интерфейсом с пользователем и унифицированным интерфейсом между отдельными инструментами пакета. Как правило, CASE-ToolKit концентрируются вокруг поддержки разработки одной фазы производства программ или на одном типе прикладных задач.
Все вышесказанное справедливо и по отношению к CASE-WorkBench. Но здесь, кроме того, обеспечивается автоматизированная поддержка анализа решаемых задач по производству программного обеспечения, которая базируется на общих предположениях о процессе и технологии такой деятельности; поддерживается автоматическая передача результатов работ от одного этапа к другому, начиная со стадии проектирования и кончая отчуждением созданного программного продукта и его сопровождением.

В настоящее время «типовая» система поддержки CASE-технологии имеет функциональные возможности, представленные на рис. 6.4.
Как следует из этой Н-диаграммы, в CASE-среде должны поддерживаться все основные этапы разработки и сопровождения процессов создания программных систем. Однако уровень такой поддержки существенно различен. Так, например, если говорить об этапах анализа и проектирования, большинство инструментальных пакетов поддерживает экранные и отчетные формы, создание прототинов, обнаружение ошибок. Значительная часть этих средств предназначена для ПЭВМ. Многие поддерживают такие широко используемые методологии, как структурный анализ DeMarco или Gane/Sarson, структурное проектирование Yourdan/Jackson и некоторые другие. Существуют специализированные пакеты разработчиков для создания информационных систем, например AnaTool (Advanced Logical Software) для Macintosh;-CA-Universe/Prototype (Computer Associates International) для ПЭВМ. Имеются CASE-среды и для поддержки разработки систем реального времени.



Рис. 6.4. Функциональные возможности типовой системы
поддержки CASE-технологии

В среде разработчиков ПО существуют две оценки данного подхода: часть из них считает, что CASE-технология кардинально меняет процессы разработки и эксплуатации ПО, другие отрицают это и оставляют за инструментальными средствами CASE лишь функцию автоматизации рутинных работ [BYTE, 1989]. Однако анализ литературы показывает, что CASE средства все-таки «сдвигают» технологии разработки ПО с управления выполнением проектов в сторону метода ирототипизации. И этот сдвиг, на наш взгляд, чрезвычайно важная тенденция в современной технологии программирования.

6.2. Методологии создания и модели
жизненного цикла интеллектуальных

<< Предыдущая

стр. 13
(из 26 стр.)

ОГЛАВЛЕНИЕ

Следующая >>