Содержание к диссертации
Введение
1 Управление знаниями и корпоративная память 10
1.1. Сложность программного обеспечения и пути ее преодоления 10
1.2 Основные понятая об управлении знаниями 29
1.3 Извлечение знаний 37
1.4 Формализация знаний 40
1.4.1 Продукционные правила .40
1.4.2 Фреймы 41
1.4.3. Семантические сети .41
1.4.4 Исчисление предикатов 42
1.4.5 Системы, основанные на прецедентах 42
1.5 Теория CBR-систем 45
1.5.1 Технология CBR-систем 45
1.5.2 CBR и поисковые системы 53
1.5.3 CBR и продукционные системы 54
1.5.4 CBRH машинное обучение 55
1.5.5 CBR и нейронные сети 56
1.5.6 CBR и статистический анализ 51
1.6. Применение CBR метода в проектировании систем 59
1.7. Выводы 61
2 Концептуальные модели представления знаний 62
2.1. Основные понятия 62
2.2 Повторное использование концептуальных моделей 64
2.3. Расчет меры сходства для концептуальных моделей 66
2.4. Онтологии 68
2.5. Поиск моделей с использованием онтологии 76
2.6. Образцы проектирования 77
2.7. Архитектура СГШР 83
2.8. Выводы 94
3 Автоматизированный процесс извлечения образцов проектирования 95
3.1. Образцы проектирования и повторное использование кода 95
3.2 Выделение образцов проектирования 99
3.3 Выводы 118
4. Разработка и анализ эффективности СППР 120
4.1. Этапы разработки 120
4.2. Оценка эффективности работы СППР 125
4.3 Выводы 132
Заключение 134
Список литературы 136
Приложение 143
- Сложность программного обеспечения и пути ее преодоления
- CBR и статистический анализ
- Повторное использование концептуальных моделей
- Образцы проектирования и повторное использование кода
Введение к работе
Актуальность проблемы. В настоящее время для различных предметных областей разрабатывается большое количество информационных и автоматизированных систем управления. Каждая такая система требует, как правило, больших затрат времени и ресурсов на создание программных объектов из которых она состоит. Поэтому организации и предприятия стараются привлечь к работе над проектами программных систем разработчиков с высокой квалификацией и большим опытом работы. Тем не менее, не всегда удается найти специалистов необходимой квалификации, а это, в свою очередь, увеличивает время разработки программы, которая в конечном итоге может оказаться неадекватной требованиям. Различные софтверные фирмы выпускают на рынок программного обеспечения средства автоматизированного проектирования программ (CASE-средства), которые предлагают разработчику средства для построения моделей программных систем в рамках различных методологий проектирования. Это позволяет сделать сам процесс разработки более определенным и контролируемым на различных этапах проектирования. Однако это не является панацеей или по меткому выражению Ф. Брукса [10]"серебряной пулей" и все равно требует от разработчика необходимого опыта работы. В данной диссертационной работе показана необходимость соединения интеллектуальных средств поддержки принятия решений с CASE-средствами, что позволит значительно повысить производительность труда разработчика автоматизированных систем управления. Такие системы позволят использовать формализованный опыт разработок в предметных областях на основе корпоративных хранилищ знаний [68].
Целью работы является создание архитектуры СППР разработчика автоматизированных систем с применением метода, основанного на прецедентах (CBR-метод) и вопросы ее реализации на основе современных программных средств. А также рассматриваются вопросы повышения труда разработчика
систем и применения различных алгоритмов поиска информационных моделей для систем управления.
Задачи исследования:
Разработать архитектуру интеллектуальной системы поддержки принятия решений.
Рассмотреть основные элементы системы и методы их функционирования-
Создать алгоритмы поиска адекватных информационных моделей.
Разработать алгоритм выделения образцов проектирования
Провести экспериментальное исследование работы СППР при решении прикладной задачи проектирования.
Методы исследования. Задачи исследования решены при помощи использования так называемого CBR метода использования формализованных знаний и технологии нейронных сетей, а также с использованием концептуальных моделей представления информации.
Научная новизна выполненных в диссертации исследований состоит в следующем:
Определена архитектура системы поддержки принятия решений разработчика информационных систем-
Разработан способ хранения корпоративной информации на основе метода, основанного на прецедентах.
Представлен алгоритм расчета меры сходства моделей при их поиске в базе данных.
Предложен метод изнлечения образцов проектирования на основе классификации моделей систем с использованием нейро-сетевой парадигмы.
5. Использована технология построения Ончологий для создания
і.
информационной базы данных СППР.
Практическая ценность. Реализация СППР разработчика ИС и АСУ позво
лила снизить затраты труда на разработку систем в связи с возможностью ав
томатизированного выбора наиболее релевантных информационных моде-
* лей. Разработчик вправе в соответствии с требованиями либо принять пред-
ложенную системой поиска модель, так как она есть, либо создать новую путем незначительных модификаций выбранной модели. СППР реализована на платформе Windows ХР с использованием реляционной СУБД Access и процедурного языка программирования C++. Механизм извлечения образцов проектирования из базы данных моделей ИС позволил разработчику проводить работу по поиску и документированию новых образцов проектирования.
Реализация результатов работы, СППР проектировщика информационных
систем была внедрена на предприятиях и организациях ОАО Кубаньэнерго и
( ОАО Роснефть-Краснодарнефтегаз, таких как ООО "Краснодарнефтегаз-
Энергия" и филиал Нсфтемашсервис.
Публикации по теме диссертации. Основной материал работы опубликован в 7 научных статьях.
Основные положения, выносимые на зашиту:
1. Архитектура СППР разработчика ИС и АСУ,
2, Методика формализации корпоративных знаний.
3- Алгоритмы расчета меры сходства моделей ИС.
4, Метод извлечения образцов проектирования.
5. Методология разработки ИС на базе интеллектуальных CASE-средств.
Структура н объем работы. Диссертационная работа состоит из введения, четырех разделов с выводами но каждому из них, заключения, списка ис-
пользованных источников, включающего 105 наименований. Материал работы изложен на 146 страницах машинописного текста и включает 8 таблиц и 35 рисунков.
В введении рассматриваются характеристики наиболее популярных CASE-программ, а также их возможности в плане предоставления разработчику ИС эффективных средств автоматизированного проектирования, генерации отчетов и исходного кода- Здесь же показывается необходимость создания интеллектуальных средсів Clll IP в дополнение к CASF--nporpaMMa\i, что позволит повысить качество создаваемых проектов ИС.
В первой части рассматривается понягие корпоративной памяти и способов формализации знаний. Анализируются преимущества и недостатки каждого из способов, после чего выбирается наилучший из них для представления знаний в СППР. Метод рассуждения на основе прецедентов (CBR-метод) выбирается за основу, и далее рассматриваются его теоретические и практические аспекты, В этой части также показан метод решения задачи принятия решений человеком, из которого следует, что представление знаний в виде прецедентов является наиболее естественным и очевидным при рассмотрении такого типа задач.
Показано, CBR-мстод в построении корпоративных хранилищ знаний, имеет преимущества перед другими известными методами, например, такими как продукционные системы. Тут же представлен алгоритм выбора релевантных прецедентов из базы данных прецедентов и вводится формула для расчета меры сходства двух прецедентов.
Во второй части показано представление моделей ИС и образцов проектирования и виде концептов и отношений между ними. Такой способ представления информации является довольно распространенным в программной ин-
дустрии и на его основе построены все известные нотации, используемые CASE-средствами.
Вводится формула расчета меры сходства двух концептуальных моделей, на основе которой функционирует алгоритм поиска моделей ИС. Далее рассматривается усложненный вариант формулы меры сходства, который учитывает использование онтологической таксономии концептов.
Рассматривается архитектура СППР разработчика ИС и назначение каждого ее элемента. Описывается назначение образцов проектирования, и показываются возможные выгоды от их использования при разработке ИС, а также представлена архитектура гипертекстовой базы знаний.
В третьей части диссертационной работы рассматривается алгоритм выделения образцов проектирования из базы данных информационных моделей. Дня этого используется неиросетевая модель Кохонена, позволяющая проводить классификацию исходных данных, представленных в виде бинарного вектора. Каждой модели ИС соответствует свой бинарный вектор, каждый элемент которого содержит наличие или отсутствие определенной характеристики модели. Здесь же представлена архитектура нейросети и ее возможная реализация на C++.
В четвертой части рассматриваются вопросы повышения эффективности труда разработчика ИС с использованием системы поддержки принятия решений (СППР). Приводятся формулы для оценки степени гслияния па производительность использования средств СППР, а так же указывается на необходимость увеличения объема базы данных проектов ИС с целью более результативного использования системы.
В заключении обобщаются основные теоретические и практические результаты диссертационной работы, формулируются основные направления дальнейших исследований в рассматриваемой области.
Основные теоретические и практические результаты заключаются в следующем:
-использована технология хранения и извлечения корпоративных знаний на
основе CBR-метода для СГТПР разработчика ИС и АСУ
-предложена формула и алгоритм расчета меры сходства двух моделей ИС.
-предложен алгоритм извлечения моделей образцов проектирования
-рассмотрена архитектура СШ IP.
-предложен вариант реализации СПТТР на основе указанной архитектуры.
-доказана необходимость соединения CASE-систем с системой поддержки
принятия решений.
-проведено экспериментальное исследование модели знаний ПрО.
Сложность программного обеспечения и пути ее преодоления
Почему программному обеспечению присуща сложность? Как говорит Брукс, «сложность программного обеспечения — отнюдь не случайное его свойство» [10]. Сложность вызывается четырьмя основными причинами: сложностью реальной предметной области, из которой исходит заказ на разработку; трудностью управления процессом разработки; необходимостью обеспечить достаточную гибкость программы; неудовлетворительными способами описания поведения больших дискретных систем.
Проблемы, которые мы пытаемся решить с помощью программного обеспечения, часто неизбежно содержат сложные элементы, а к соответствующим программам предъявляется множество различных, порой взаимоисключающих требований. Рассмотрим необходимые характеристики электронной системы многомоторного самолета, сотовой телефонной коммутаторной системы и робота. Достаточно трудно понять, даже в общих чертах, как работает каждая такая система. Теперь прибавьте к этому дополнительные требования (часто не формулируемые явно), такие как удобство, производительность, стоимость, выживаемость и надежность! Сложность задачи и порождает чу сложность проіраммного продукта, о которой пишет Брукс [10].
Эта внешняя сложность обычно возникает из-за «нестыковки» между пользователями системы и ее разработчиками: пользователи с трудом могут объяснить в форме, попятной разработчикам, что на самом деле нужно сделать. Бывают случаи, когда пользователь лишь смутно представляет, что ему нужно от будущей программной системы. Это в основном происходит не из-за ошибок с той или иной стороны; просто каждая из групп специализируется в своей области, и ей недостает знаний партнера. У пользователей и разработчиков разные взтляды на сущность проблемы, и они делают различные выводы о возможных путях ее решения. На самом деле, даже если пользователь точно знает, что ему нужно, мы с трудом можем однозначно зафиксировать все его требования- Обычно они отражены на многих страницах текста, «разбавленных» немногими рисунками- Такие документы трудно поддаются пониманию, они открыты для различных интерпретаций и часто содержат элементы, относящиеся скорее к дизайну, чем к необходимым требованиям разработки.
Дополнительные сложности возникают в результате изменений требований к программной системе уже в процессе разработки [43]. В основном требования корректируются из-за того, что само осуществление программного проекта часто изменяет проблему. Рассмотрение первых результатов — схем, прототипов, — и использование системы после того, как она разработана и установлена, заставляют пользователей лучше понять и отчетливей сформулировать то, что им действительно нужно. В то же время этот процесс повышает квалификацию разработчиков в предметной области и позволяет им задавать более осмысленные вопросы, которые проясняют темные места в проектируемой системе [43].
Большая программная система — это крупное капиталовложение, и мы не можем позволить себе выкидывать сделанное при каждом изменении внешних требований. Тем не менее, даже большие системы имеют тенденцию к эволюции в процессе их использования: следовательно, встает задача о том, что часто неправильно называют сопровождением программного обеспечения. Чтобы быть более точными, введем несколько терминов: под сопровождением понимается устранение ошибок; под эволюцией — внесение изменений в систему в ответ на изменившиеся требования к ней; под сохранением — использование всех возможных и невозможных способов для поддержания жизни в дряхлой и распадающейся на части системе. К сожалению, опыт показывает, что существенный процент затрат на разработку программных систем тратится именно на сохранение.
Наше неумение создавать сложные программные системы проявляется в проектах, которые выходят за рамки установленных сроков и бюджетов и к тому же не соответствуют начальным требованиям. Мы часто называем это кризисом программного обеспечения, но, честно говоря, недомогание, которое тянется так долго, становится нормой. К сожалению, этот кризис приводит к разбазариванию человеческих ресурсов — самого драгоценного товара — и к существенному шраничению возможное гей создания новых продуктов. Сейчас просто не хватает хороших программистов, чтобы обеспечить всех пользователей нужными программами. Более того, существенный процент персонала, занятого разработками, в любой организации часто должен заниматься сопровождением и сохранением устаревших программ. С учетом прямого и косвенного вклада индустрии программного обеспечения в развитие экономики большинства ведущих стран, нельзя позволить, чтобы существующая ситуация осталась без изменений [7].
Процесс разработки ПО определяет действия л организационные процедуры, направленные на усиление совместной работы в бригаде разработчиков с целью поставки заказчикам высококачественных программных продуктов. На модель процесса возлагаются следующие функции [43J.
CBR и статистический анализ
Наиболее продуктивным мне видится использование методики синтеза для решения задач, возникающих в проектировании различных систем, особенно информационных [30,49J. Используя опыт ведущих проектировщиков, новичок может использовать его в построении собственных информационных систем. Известные CASH средства позволяют на основе определенной методологии проектировать программные и информационные системы с нуля, т.е. не предлагая проектировщику никаких средств для интеллектуальной поддержки процесса принятия решений. Таким образом, часто приходится просто "изобретать велосипед", т. е. проектировать систему, которая ранее была создана, протестирована и хорошо себя зарекомендовала. Вся нелогичность данной ситуации в том, что одни проектировщики, замкнувшись в своей производственной среде, зачастую лишены доступа к проектам, созданным другими проектировишками для решения аналогичных задач. Было бы просто замечательно создать базу данных разработок информационных и про-іраммньїх систем и использовать ее в разработке собственных проектов. Например, определив и формализовав требования к информационной системе, проектировщик вводит их программу, которая просматривает базу данных и находит в ней, по возможности, проект с наиболее близкими к исходному проекту требованиями. После этого разработчику предъявляется уже готовое решение, и он либо отвергает его, либо полностью или частично его использует. Если решение частично удовлетворяет требованиям к решаемой задаче, то проектировщик может адаптировать готовое решение на основе различающихся требований, В любом случае, с использованием базы данных готовых проектов, процесс разработки информационной системы пройдет более быстро и эффективно. Если адаптация слишком сложна, то можно попробо вать синтезировать проект на основе выбора частичных или локальных решений на базе нескольких разных проектов. Для этого можно использовать технологию так называемых паттернов или образцов, т.е. некоторых стереотипных шаблонных ситуаций проектирования, возникающих в определенных ситуациях. Они предоставляют проектировщику возможность работать на более высоком уровне абстракции. Используя вместе с базой данных проектов и базу данных образцов проектирования, разработчик программных и информационных систем получает в свои руки очень мощный инструмент проектирования, способный повысить производительность труда в несколько раз. Даже если готового решения не будет существовать, проектировщик, пользуясь базой данных образцов, сможет довольно быстро синтезировать готовый проект, применяя образцы проектирования. Встраивая такую возможность, предоставляемую CBR технологиями в CASE системы, мы получим идеальный инструмент разработки программных систем.
Теперь рассмотрим основные достоинства и недостатки CBR-технологии в сравнении с другими вычислительными технологиями, включая такие как поисковые системы, статистический анализ, продукционные системы, машинное обучение и нейронные сети [102].
CBR-системы и поисковые системы имеют много общего. Поисковые системы используют технику отличную от той- которая используется в стандартных запросах к базам данных тем, что использует выбор из больших объемов текстовой информации, находящейся на компакт-дисках ли в сети Internet. Здесь используется такая популярная техника выбора информации как концептуальный поиск. Он использует тезаурус для нахождения подобия между словами в запросе. В данном контексте, CBR и поисковые системы поддерживают удобные средства запросов и выбирают множество потенциально релевантной, возможно даже неопределенной, информации. Однако между этими двумя техниками существуют и различия: Поисковые системы используются для поиска текста в больших документных источниках, в то время как CBR методы могут поддерживать работу с различными типами данных. Поисковые системы не предназначены для использования знаний об извлеченной информации, а CBR-системы могут их использовать, например, назначением весам атрибутов некоторых значений. Таким образом, CBR-системы отличаются от поисковых систем тем, что в отличие от последних, они могут работать с большим количеством источников информации. Известно, что продукционные системы описывают предметную область в виде множества индивидуальных правил, каждое из которых решает определенную часть проблемы. Правила комбинируются вместе для решения всей проблемы. Для создания таких правил вручную, необходимы знания о том, как решается такая проблема, и эта задача может быть очень сложной и отнимать много времени на ее решение. В случае использования CBR-систем, нам нет необходимости знать, как решается проблема. Всего лишь необходимо вспомнить, как уже была решена похожая проблема в прошлом. Преимущества CBR технологии над продукционными системами заключается в следующем: Уменьшением времени на процесс извлечения знаний, поскольку CBR-системы не требуют понимания процесса решения проблемы. То есть, для создания CBR-систем, вам необходимо только создать набор прецедентов и их решений; вам нет необходимости извлекать правила из экспертных знаний. Способностью к обучению посредством добавления новых прецедентов без необходимости добавлять новые правила или модифицировать уже существующие. Способностью проводить оценку решения посредством набора прецедентов, а не трассировкой правил. В таблице 1-1 приведены сравнительные характеристики используемых двух техник, применяемых для представлення знаний из различных областей. Таким образом, в случае существования узкой, хорошо формализованной предметной области, применение продукционных правил может оказаться более предпочтительным, чем использование CBR технологии. И, наоборот, в случае слабо формализованной проблемной области с широкими границами применения, лучшим способом представления знаний окажется применение CBR- систем.
Повторное использование концептуальных моделей
Онтология (от др.-греческого онтос-сущее, логос учение, ионятие)-термин, определяющий учение о бытии, сущем. В философском смысле на онтологию можно ссылаться как на определенную систему категорий, являющиеся следствием определенного взгляда на мир. Сама же система категорий не должна зависеть от языка, который используется для ее описания. Понятие онтологии нашло свое применение и в искусственном интеллекте [13,21,93,94]. Здесь онтология рассматривается как формальная конпептуали зация знаний о предметной области. Концептуализация может иметь различные формы: логические теории первого порядка, где терминам словаря соответствуют унарные и бинарные предикаты, называемые соответственно концептами и отношениями, лингвистические описання. Сама концептуализация предполагает описание множества концептов, знаний о них и связей между ними. Таким образом, Онтологией [Gmber,1993] называется эксплицитная спецификация концептуализации. Формально онтология состоит из терминов, организованных в таксономию, их определений и атрибутов, а также связанных с ними аксиом и правил вывода.
Люди, организации и проіраммньїе системы взаимосвязаны между собой. Способ выражения знаний даже об одних и тех же вещах и на одном и том же языке может быть столь различным, что это приводит к непониманию между людьми даже при разговоре об одном и том же предмете. Об этом много написано, в том числе в литературе, не имеющей прямого отношения к искусственному интеллекту. Непонимание становится еще более значительным в случае обмена информацией между людьми, организациями и программами. Возможности взаимодействия программных моделей, созданных в различных организациях, возможности повторного использования и распространения этих моделей весьма ограничены. Это в свою очередь приводит к повторным усилиям по созданию программных моделей, мало отличающихся от уже созданных. Такая ситуация напоминает повторное изобретение велосипеда.
Спрашивается, как можно избежать такого рода изобретений? Естественный ответ — это устранить или свести к минимуму концептуальную и терминологическую путаницу и установить однозначное понимание языка, используемого для формирования требований и спецификаций сложных систем. Такой язык должен, прежде всего, служить средством коммуникации между людьми, имеющими различный взгляд на одни и те же вещи, взаимодействия между программными системами путем трансляции в него и из него, инстру ментальной поддержки для повторного использования благодаря формальной спецификации, унификации представления различных моделей, автоматизации проверки корректности, переводимости различных методов моделирования в унифицированное представление.
Онтологией называют представленные на некотором языке, обладающем перечисленными ранее свойствами, знания о некоторой области интересов (среде, мире). Онтологии непременно сопутствует некоторая концепция этой области интересов. Чаще всего эта концепция выражается посредством определения базовых объектов (индивидуумов, атрибутов, процессов) и отношений между ними. Определение этих объектов и отношений между ними обычно называют концептуализацией. На определенном этапе концептуализация может быть неявной (или ментальной, т.е. существующей только в чьей-то голове). Онтология является явным представлением некоторой концептуализации и может иметь несколько форм представления: неформальную на каком-либо естественном языке; полуформальную на каком-либо структурированном подмножестве естественного языка; слабоформализованную на каком-либо языке из области искусственного интеллекта с формальным синтаксисом; формализованную на каком-либо языке из области искусственного интеллекта с формальным синтаксисом, семантикой, значимым и полным механизмом вывода, Следующее определение онтологии, обобщает различные определения онтологии: онтологией является общепринятая и общедоступная концептуализация определенной области знаний (мира, среды), содержащая базис для моделирования этой области знаний и определяющая протоколы для взаимодействия между агентами, которые используют знания из этой области, и наконец, включающая соглашения о представлении теоретических основ дан ной области знаний. Литературные источники богаты описанием различных онтологии и ожидаемых от их использования перспектив. Эти перспективы можно подразделить на следующие категории: улучшение взаимодействия; унификация обмена данными; формализация процессов спецификации, повышения надежности и обеспечения многократности использования. Улучшение взаимодействия связывают с уже упомянутыми надеждами на уменьшение терминологической и концептуальной путаницы и неоднозначности понимания па основе осуществления следующих мероприятий, 1. Создание в конкретной области человеческой деятельности (среде) унифицирующего нормативного ядра понятий, которое позволило бы достичь однозначного семантического толкования основных объектов и процессов этой области. Предполагается, что это нормативное ядро является семантической основой для порождения, переопределения и интерпретации новых понятий. 2. Создание однозначно понимаемого множества отношений между понятиями нормативного ядра, допускающего исследование динамических и статических аспектов среды, влияния на нее различных факторов, вывод и планирование ситуаций.
Образцы проектирования и повторное использование кода
При создании любого программного обеспечения важное место занимает вопрос повторного использования уже существующего кода [L7,1S]. Каждая новая программа создается для решения определенного набора задач. Если программа удовлетворяет требования пользователя, то она используется в готовом виде без дополнительных подключаемых модулей. В противном случае она подвергается процессу модификации и доработки. Процесс модификации может включать в себя как исправление уже существующего программного кода, так и разработку новых модулей для решения специфических задач. К счастью, существует большое количество повторно используемого программного фонда в виде библиотек процедур, функций, классов которые решают наиболее общие задачи программирования, такие как сортировка, поиск, организация данных, графика, работа с базами данных и т. д. Однако при решении конкретных задач приходится учитывать большое количество факторов, которые могут свести на нет повторное использование программного кода. К таким факторам относятся: различные и несовместимые между собой среды разработки, требования к памяти компьютера, быстродействие алгоритмов реализации функций и другие.
Возьмем, к примеру, программу сортировки массива [33]. Существуют различные алгоритмы решения этой задачи, различающиеся быстродействием и требованием к ресурсам памяти [35]. Выбор того или иного алгоритма остается за программистом. Один и тот же алгоритм решения определенной задачи может устраивать одного программиста и не устраивать другого. И дело тут не в субъективных причинах, а в требованиях накладываемых иа программную систему. Если на первое место выступает быстродействие, то используются более сложные и быстродействующие алгоритмы, а если нет - то можно обойтись и более простым и менее ресурсоемким алгоритмом. В случае с сортировкой массива, если размер его довольно велик, необходимо использовать алгоритм бысфой сортировки Хоара. При небольшом размере массива достаточно будет использовать более простой алгоритм сортировки вставками.
Этот пример показывает, что не существует готового рецепта решения проблемы на все случаи жизни и программирование остается довольно трудной задачей поиска компромисса между требованиями и реализаций на компьютере этих требований. В требовании заключается вопрос: Что должна делать система, а в реализации - Как она должна это делать. Эти два вопроса тесно связаны между собой как спецификация и решение задачи. Хорошо продуманная спецификация может существенно упростить процесс программирования, акцентируя внимание на действительно важных вопросах и оставляя в стороне несущественные. Из всего этого можно сделать простой вывод: повторное использование проіраммного кода не является панацеей. Теперь представим на минуту, что нам предстоит перевести исходный текст алгоритма из одного языка программирования на другой. Если повезет - это можно сделать относительно легко, а в противном случае придется повозиться. И все дело тут не в самом алгоритме как таковом, а в его реализации, которая может отличаться в различных языках программирования. Структуры данных, поддерживаемые в одном языке, могут отсутствовать в другом. Например Pascal и С+-Ї- поддерживают работу с указателями, a Visual Basic нет. Это касается так же и динамического распределения памяти, множественного наследования и т. д. И в этом случае возникают трудности повторного использования кода. Надо заметить, что, в конечном счете, все программы транслируются в машинный код, который может отличаться в различных аппаратных платформах, да и языки программирования для того и создавались, чтобы программист мог работать па более высоком уровне абстракции. Использование машинного кода должно использоваться только в исключитель ных случаях, когда необходимо напрямую использовать возможности аппаратных средств и поэтому этот случай мы не будем рассматривать, а сосредоточимся на программных конструкциях более высокого уровня абстракции.
Попытаемся теперь определить чем хорошая информационная система отличается от плохой. Ответ прост - в архитектуре. Выбор удачного архитектурного решения для проектируемой информационной системы позволит уже на начальном этапе ее реализации существенно снизить трудоемкость ее программной реализации и делает систему более простой для сопровождения и возможных последующих модификации. Также упрощено взаимодействие между различными частями информационной системы, реализующими определенные функциональные задачи. Во многих предметных областях уже существуют довольно удачные архитектурные решения стереотипных проблем, которые возникают в проектировании. Использование таких готовых решений может сильно повысить производительность труда проектировщика информационных систем и оказать определенное воздействие на выбор архитектуры такой системы. Конечно, это не означает, что нужно слепо и без учета специфических требований при реализации некоторой задачи копировать чужой программный фонд, но изучать опыт проектирования просто необходимо. Это3 по крайней мере, позволит уже на этапе знакомства с требованиями к информационной системе определить для себя, что можно использовать из существующего программного фонда, а что нельзя. Если мы найдем какое-то свое хорошее решение существующей проблемы, то оно вполне может стать отправной точкой для работы других проектировщиков и таким образом за счет этого решения увеличится фонд накопленных знаний в области моделирования информационных систем.
