Статьи
21 декабря 2010
—

Концепция создания системного и прикладного программного обеспечения задач математического моделирования

 

Электронное издание AtomInfo.Ru публикует статью "Концепция создания системного и прикладного программного обеспечения задач математического моделирования". Автор статьи - главный научный сотрудник РНЦ КИ Михаил Николаевич ЗИЗИН.

1. Введение

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

Американский философский фольклор
(Цитируется по книге В.Ф. Турчина "Феномен науки")
 

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

ALAN PERLIS. Epigrams on Programming
 

Главное - это величие замысла.

Иосиф Бродский
 

Известное известно немногим.

Аристотель "Поэтика"
 

Если начинают с неправильного,
то мало надежды на правильное завершение.

Конфуций

Бурно развивающаяся область компьютерной программной технологии (software engineering) - инженерия знаний (knowledge engineering) - вместе с ещё более бурным развитием вычислительной техники - требует периодического пересмотра подходов к решению традиционных задач математического моделирования таких сложных установок как ядерные реакторы.

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

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

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

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

Сформулированная в следующем разделе концепция разработки системного и прикладного программного обеспечения реакторных расчётов первоначально выросла из попыток обобщить на современном уровне опыт создания программных комплексов и модульных систем для расчёта реакторов [1, 2, 3, 4, 5, 6].

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

Концепция формулировалась, использовалась и совершенствовалась при создании открытой интеллектуальной программной системы среднего класса ShIPR [7, 8, 9]. (Shell of Integrated Package for Reactors) для математического моделирования ядерных реакторов.

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

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

Брукс [10, с. 191] рассматривает всякую творческую деятельность, как состоящую из:

      1. формулирования концептуальной конструкции,

      2. воплощения в реальном материале,

      3. диалога с пользователями в реальном мире.

Концепция так же нужна при экспертной оценке программных продуктов и проектов.

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

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

Следует понимать, что многие концепции, понятия и утверждения не всегда переносимы из области больших проектов в малые. Достаточно большая корректировка связана с размышлениями при чтении второго издания классической работы Ф. Брукса "Мифический человеко-месяц"[10]. Мелкие коррективы вносятся постоянно, в соответствии с принципом непрерывного совершенствования.

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

2. Знания и информация

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

Д.С. Черешкин, Вице-президент РАЕН
 

Сумма разума на Земле постоянна, а население растёт.

Закон Мэрфи
 

Чем больше знаем, тем меньше понимаем.

Павел Гавел

Формальное определение знаний (изложение части этого раздела основано на выдержках из работы [11]) и чем они отличаются от информации - вопрос во многом философский. Знания, как и другие философские категории, можно определить только через их свойства и методы обработки (информация также относится к аксиоматическим понятиям).

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

      1. Информация становится знаниями только когда используется при решении задач.

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

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

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

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

Возможно два класса задач управления знаниями:

      1. Поддержка механизмов обмена опытом между людьми (в том числе через создание единых хранилищ данных).

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

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

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

Вот ещё несколько подходов к определению взаимосвязей знаний, данных и информации (два последних определения списаны из работы [12]).

      1. Логической закономерностью является высказывание, обладающее значительным прогнозирующим свойством. Набор таких логических закономерностей (знаний), представленных на языке, близком к естественному языку логических суждений, является логико-вероятностной моделью изучаемого сложного объекта. Такой подход позволяет при разработке экспертных систем наряду с экспертными знаниями пополнять базу знаний вероятностными логическими закономерностями [13].

      2. Знания представляют собой краткое обобщённое описание основного содержания информации, представленной в данных. Одной из наиболее распространённых форм при работе с большими объёмами данных являются логические правила в виде логических правил типа "если…то…" [14].

      3. Знания - это факты, совмещённые с правилами их обработки.

      4. Под управлением знаниями в общем случае понимается дисциплина, которая обеспечивает интегрированный подход к созданию, сбору, организации, доступу и использованию информационных ресурсов организации . Эти ресурсы включают в себя корпоративные базы данных, текстовую информацию, такую как документы, описывающие правила и процедуры, и, что наиболее важно, неявные знания и опыт сотрудников организации. [15]

      5. Знания - это информация, материализованная в процессе решения конкретной задачи в виде каких-то конкретных действий людей, стремящихся достичь своих конкретных целей" [16].

3. Принципы

Модулярность, адаптируемость,
модифицируемость, расширяемость,
универсальность
- эти слова произносятся всеми разработчиками
математического обеспечения.

А.П. Ершов, 1972 г.
 

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

Проф. А. А. Шалыто

По мнению группы макроэкономических исследований "Deutsche Bank Research" (www.dbresearch.de), проведённом в 2005 году, в ближайшем будущем особо привлекательными станут приложения, в которых объединены прикладная и системная функциональность.

Чистый и элегантный программный продукт должен представить своим пользователям согласованную идеальную модель приложения, стратегий осуществления приложения и тактики пользовательских интерфейсов, используемой при задании действий и параметров. Необходимо помнить, что системы составляются из концептуальных блоков, таких, как подпрограммы, модули и классы [10, сс. 235, 250].

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

      1. Стремление к простоте.

      2. Баланс простоты и гибкости.

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

      4. Многоступенчатый контроль.

      5. Унификация интерфейсов.

      6. Возможность автономной работы подсистем.

      7. Баланс распределённости и централизации.

      8. Распределение интеллекта по всем уровням системы.

      9. Следование принципу (бритвы) Оккама - не вводить новых сущностей без крайней необходимости.

      10. Сохранение - при всех переменах! - разработок прикладных программистов - процедурных знаний.

Программисты должны стремиться к простоте создаваемых приложений и встраивать в них только те средства, которые потребуются не менее 80% пользователей [17].

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

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

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

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

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

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

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

При создании любого программного продукта нужно задаваться не только вопросом КАК, но и вопросами ЗАЧЕМ и ДЛЯ КОГО. Хорошая программа интуитивно понятна и хорошо документирована. Она должна отвечать высказанным и невысказанным требованиям пользователя. Цель заключается в получении лояльного, восхищённого пользователя. Только "восхищённый" пользователь рекомендует продукт другим. А всего лишь "удовлетворённый" пользователь будет воспринимать своё удовлетворённое состояние как нормальное явление.

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

Основная философия разработчиков - решение реальных проблем пользователей. Но часто требования заказчика бывают из области фантастики. Он хочет сразу всего: самой широкой функциональности, очень низкой стоимости приобретения и владения, высокой производительности и простоты использования, быстрого и лёгкого внедрения, минимальных усилий по освоению системы всеми сотрудниками (Излагал С. Рамишвили).

И не забывайте отслеживать технологический ландшафт!

4. Миссия и стратегия

Можно ли управлять автомобилем,
смотря только в зеркало заднего вида?

Роберт Каплан и Дэвид Нортон

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

Vision - looking a head - видение - взгляд вперёд на десять лет. Длительная стратегическая концепция конечной цели. Vision - это не только умение заглянуть в будущее, но смелость самим формировать его.

Mission - миссия - формулировки задач на пять лет.

Стратегия - планы на три года.

Тактика - задачи на один год, с последующим пересмотром стратегии.

Есть ещё и такие термины.

Девиз (он же слоган) - это, по видимому краткая формулировка Vision.

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

Концепция проекта - Vision Document - результат фазы "Анализ"; документ, определяющий цели и задачи текущей версии продукта.

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

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

Основное отличие стратегического планирования от целевого состоит в том, что оно направлено на выполнение ориентированной на человека миссии, а не на достижение цели. Оно предполагает постоянную корректировку в ответ на слабые воздействия в процессе реализации стратегии и оперирует в основном качественными показателями [18]. Жить становиться легче, когда осознаешь, что ты не просто работаешь, а облагодетельствуешь значительную часть человечества (шутка).

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

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

Ещё один важный вопрос - когда и на чём остановиться (доводить всё до конца - не лучшая идея. Л. де Брабандер [19]). Необязательная или излишне сложная функциональность (gold plating) - слабая сторона многих продуктов. Российские разработчики "зацикливаются" на технологии и у них слабо развито ощущение "достаточности" продукта (time-to-match).

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

В процессе создания программного продукта нужно постоянно ранжировать решаемые задачи следующим образом [20]:

      1. Что необходимо сделать.

      2. Что следует сделать.

      3. Что можно сделать.

5. Жизненный цикл программ

Уже на ранних стадиях разработки надо иметь в виду и проблему поддержки (сопровождения) программ.

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

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

6. Технологические аспекты реализации концепции

      1. Максимально используйте языки высокого уровня.

      2. По возможности применяйте объектно-ориентированную технологию.

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

      4. Двигайтесь вперёд по мере конкретизации стоящих перед вами задач - не тратьте время на создание чего-то грандиозного и всеобъемлющего.

      5. Вносите изменения квантами в хорошо определённые документированные версии [10, с. 223].

      6. Стимулируйте постоянную переработку кода (то есть переписывание и совершенствование программ).

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

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

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

      2. Используйте и модифицируйте уже существующие программы. Неэффективно каждый раз начинать всё с нуля.

      3. Создавайте собственные инструменты (tools - программы с широким спектром применения).

      4. Сохраняйте состояние отдельных окон и/или приложений так, чтобы при возврате пользователя эти состояния восстанавливались.

      5. Используйте масштабирование шрифтов и в формах устанавливайте их размеры по умолчанию (свойство AutoSize = True).

      6. Присваивайте значение True свойству Transparent, что сделает фон надписи прозрачным.

Характеристики хорошего алгоритма - простота, понятность, соответствие ожидаемым входным данным, эффективность.

Методы получения эффективных алгоритмов:

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

      2. Динамическое программирование

      3. Жадные методы (поиск локальных оптимумов)

      4. Поиск с возвратом и локальный поиск.

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

      6. Приближённое решение вместо точного.

7. Проект

Вскарабкавшись
по служебной лестнице,
Вы можете обнаружить,
что она была приставлена
не к той стене

Вот список противоречий, которые, по мнению А.П. Ершова, надо разрешать при реализации проекта:

      1. между сложностью и объёмом,

      2. между универсализмом и специализацией,

      3. между многообразием целей и ограниченностью средств,

      4. между стремлением к совершенству и факторами времени.

Правильный ответ на большинство вопросов проектного управления должен начинаться словами: "Это зависит от…". Но многие полагают, что есть единственно верное решение, пытаются найти его и насильственно внедрить, а в результате оно оказывается неправильным.

8. Проект и команда

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

В. Верма
 

Успех Команды - успех каждого из её членов,
успех члена команды - успех всей Команды.

Мотт

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

      2. Не допускайте, чтобы тот или иной специалист становился единственным экспертом в какой-то определённой части проекта.

      3. Сильные коллективы потому и сильные, что над идеей каждого думают все [21].

      4. Число специалистов в команде разработчиков должно быть невелико. Чем меньше программистов, тем более сконцентрированным и тщательнее будет планирование приложений и тем меньшее число "самых современных возможностей" разработчики захотят в них добавить [17].

      5. Разработчикам трудно выполнять функции других членов команды. Мастерство специфично, и оно растёт по мере того, как люди применяют его. Аплодировать ногами трудно [22, с.39].

      6. Необходимо критическое отношение к себе. Разработчики должны понимать, что они будут делать ошибки и им придётся искать их. Нельзя безрассудно верить в безошибочность своего кода [17].

      7. Существует три способа сделать хороший проект - communicate, communicate, communicate. Фред Майлз, консультант из Price Waterhouse-Coopers.

      8. Самое трудное в разработке ПО - заставить людей думать. Джим М Маккарти [22, с. 30]

9. Системное наполнение

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

      1. обеспечение качества,

      2. степень документированности (для пользователей, ИТ-специалистов и разработчиков),

      3. лёгкость сопровождения,

      4. возможность расширения функциональности по запросам пользователей.

9.1. Цели

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

      2. Создание комфортной среды для расчётчиков и разработчиков программ. Максимальное облегчение подготовки исходных данных для расчёта.

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

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

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

9.2. Способы и средства достижения цели

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

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

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

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

      5. Создание сценариев событий и/или последовательностей расчётов. Генерация входных данных на основе сценариев.

      6. Возможность организации вычислительного процесса из уже готовых программ с использованием сценариев на основе языка скриптов (последовательность команд и/или действий; сценарий), что позволяет организовывать вычислительный процесс с использованием exe-программ.

      7. Средства для работы с графическими объектами.

      8. Использование парадигмы заранее подготовленных наборов данных с целью максимального облегчения подготовки исходных данных для конкретного расчёта.

      9. Использование правил для формирования некоторых исходных данных.

      10. Реализация способов фильтрации всех типов информации, хранящейся в базе знаний. Использование цепочек фильтров.

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

      12. Наличие средств для статистического анализа функционального наполнения. Существует специализированный набор инструментов SLOCCount (www.dwheeler.com/sloccount/) для подсчёта строк кода в приложении, который корректно выявляет комментарии и вычленяет сложные конструкции.

      13. Возможность фиксации частоты использования объектов и профилирования объектов по этой информации.

      14. Разработка средств очистки базы знаний от мусора на основе соответствующих правил и/или в режиме диалога с пользователем.

      15. Наличие инструмента для возможности следить за процессом расчёта при больших временах счёта.

9.3. Дружественность интерфейса

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

Достоинства системы сильно зависят от качества пользовательского интерфейса. Ошибки в интерфейсе наиболее критичны для производительности пользователей системы, количества человеческих ошибок, скорости обучения работе с системой и субъективного удовлетворения пользователей. Экспертная оценка позволяет быстро локализовать и исправить наиболее серьёзные недостатки.

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

      2. Однотипность работы с объектами.

      3. Контекстная справка в стандартном для Windows виде - HTML формате, вызываемая нажатием клавиши F1.

      4. Всплывающие подсказки, появляющиеся при наведении на объект курсора мыши.

      5. Аппарат быстрой справки (Quick Help). Вызывается нажатием правой кнопки мыши.

      6. Выдача отчётов по любому виду объектов (выдача отчётов в файл по выбранной группе экземпляров объектов или для одного экземпляра объекта).

      7. Быстрый поиск нужных объектов при помощи фильтров.

      8. Цвет при работе с объектами. 9. Многоязыковость (Русский, English) для систем с потенциальным выходом на зарубежные рынки. В систему лучше сразу зашить English, а Русский реализовать с помощью обращения к созданному ini-файлу.

10 эвристических правил Якоба Нильсена

Эвристические принципы здесь сформулированы с помощью работы [23]. Их формулировку в оригинале можно найти в Интернете: www.useit.com/papers/heuristic/heuristic_list/html.

1. Видимость состояния системы (правило обратной связи)

      Информированность пользователя о состоянии системы, времени - оценка времени или % выполнения длительного процесса.

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

2. Равенство между системой и реальным миром

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

3. Свобода действий пользователя

      Возможность отмены последнего действия - кнопка Cancel (отмена) и/или Escape.

4. Последовательность и стандарты

      Последовательность в выборе одинаковых способов оповещения о событиях, использовании терминов, в оформлении элементов интерфейса (кнопки и т.д.).

5. Предупреждение ошибок

      Дизайн, предупреждающий возникновение ошибки, лучше всякого оповещения об ошибке.

6. Понимание лучше, чем запоминание

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

7. Гибкость и эффективность использования

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

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

8. Эстетичный и минималистский дизайн (ничего лишнего)

9. Распознавание и исправление ошибок

      Описание ошибки должно быть чётким, ясным и понятным.

      В окне сообщения об ошибке должны присутствовать кнопки Справка и Подробнее.

      Необходимо описание решения возникшей проблемы.

10. Справка и документация

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

9.4. Объектно-ориентированные методы

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

С прагматической точки зрения, наверное, всё же самое большое достоинство ООП кроется в возможности безболезненного для программ изменения данных, на что сейчас, по утверждению автора книги [24], расходуется до 16% средств в области ИТ.

Главное преимущество ООП - не повторное использование компонентов, а облегчение сопровождения разработанного ПО. Почти половина всех запросов на внесение изменений в систему связана со сменой требований. Верно и то, что нисходящая декомпозиция задачи приводит к тому, что и модули, и объекты становятся зависимыми от приложения (из рецензии Э. Пройдакова на книгу [24]).

9.5. База знаний и вычислительная среда

Я говорю про всю среду…

Б. Пастернак "Высокая болезнь"

      1. Накопление знаний о предметной области в виде процедурных знаний (программ), описаний программ, их интерфейсов, типовых и повторно используемых наборов исходных данных, правил для коррекции и контроля интерфейсов, инициализации данных и правил использования и связывания объектов базы знаний. Наследование связей объектов. Знания должны накапливаться как в структурированном, так и неструктурированном виде.

      2. Фиксация знаний о программной среде и тестовых задачах.

      3. Высокое качество данных (data quality) в базе знаний, которое определяется уровнем соответствия между математическими моделями и моделируемыми установками. Данные должны быть достаточно точными и полными. Везде, где можно, за полнотой данных должна следить система.

      4. Планирование распараллеленного на вычислительного процесса с возможностью его выполнения в многопроцессорной и/или распределённой среде. Автоматизация генерации распараллеливаемой на уровне модулей программы.

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

      6. Возможность работы с разными версиями Фортрана - ФОРТРАН 77, Фортран 90 и т.д., а также с несколькими основными трансляторами для Фортрана, в том числе с обеспечивающими многопроцессорную работу.

      7. Профилирование информации в соответствии с решаемой задачей и/или требованиями пользователя - повсеместное применение фильтров.

      8. Предоставление пользователю возможности работы на основе примеров - широкое использование прототипов при создании новых объектов практически всех типов (классов) объектов.

      9. Реализация сценариев работы с разной степенью подробности в зависимости от уровня подготовки пользователя и/или степени отлаженности решаемой задачи.

      10. Максимальная машинная независимость создаваемых вычислительных программ.

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

9.6. Подсистемы

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

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

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

      4. Справочная подсистема, работающая в онлайновом и контекстно-зависимом режимах.

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

      6. Использование готовых программных пакетов типа Simulink или MathCad 2000 (инструмент для математических и научных расчётов с модулями для двумерной САПР и создания готовых к публикации 2D-графиков).

9.7. Требования к системному наполнению

Общие

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

      1. Удобство пользования системой и устойчивость её функционирования.

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

      3. Надёжность программы - устойчивость её работы в условиях модификации кода, смены компилятора и аппаратной платформы.

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

      5. Широкое применение правил использования системных и функциональных объектов.

      6. Использование базы знаний при генерации входной информации для расчётов.

      7. Автоматическое накопление количественных, частотных и временных данных о работе прикладного и системного программного обеспечения.

      8. Лексический анализ словесных определений объектов для:

      - определения принадлежности объекта к соответствующему разделу предметной области;

      - образования новых стандартных величин по определённым правилам;

      - выделения ключевых слов и поиск объектов по ним.

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

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

      11. Пошаговое наращивание интерфейсов и функциональности системы, что обеспечивает её постоянную работоспособность [10, с. 194].

      12. Эволюционное наследование баз знаний, свойств и компонентов системы при переходе на новые средства реализации.

      13. Средства для хранения семантических (неформализованных) знаний - смысловых описаний объектов и др.

      14. Потенциальная эмерджентность. Эмерджентность (от англ. Emergence) означает свойство самопроизвольного возникновения у системы качества, которым она первоначально не обладала.

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

С точки зрения пользователя

Чаще всего при работе с системой
проблемы сидят перед клавиатурой.

Хассо Платтнер, исполнительный директор SAP AG

      1. Ориентированность системы на пользователя. Сформулируйте, какие потребности пользователя удовлетворяет система.

      2. Участие заказчика (потребителя) в формировании требований к программному продукту с начала разработки системы.

      3. Максимально возможная простота использования системы. Сейчас в США разрабатывается новый стандарт Common Industry Format (CIF) for Usability Test Reports (общий отраслевой формат отчётов о тестировании применимости), который устанавливает формат представления условий и результатов тестирования, определяя всю информацию, достаточную для того, чтобы организации-пользователи могли повторить тестирование.

      4. Быстрота освоения системы пользователем. Простые правила применения функциональности для конечного пользователя. Сложность системы уменьшается, если модули или объекты располагаются иерархически, по уровням [10, с. 194].

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

      6. Система должна спасать пользователей от последствий трудно предсказуемых действий.

      7. Хранение в базе знаний наборов повторно используемых данных - как для использования в формате NameList, так и в виде любых готовых исходных данных для отдельных программ, или их генерация на основе хранящейся информации.

Требования к интерфейсу

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

      2. Интуитивная понятность пользовательского интерфейса с возможностью его настройки.

      3. Интеллектуальная контекстно-зависимая помощь для ускорения работы и уменьшения числа ошибок пользователя.

      4. Однотипность приёмов работы в различных частях системы.

С точки зрения администратора

      1. Возможность работы как в сети, так и на отдельном компьютере.

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

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

      4. Защита от несанкционированного исправления критически важной информации.

      5. Обеспечение средств обязательного донесения до пользователя важной информации

      6. Отчуждаемость системы от разработчиков с возможностью её освоения квалифицированными пользователями.

      7. Возможность (наличие средств) аккумуляции пожеланий пользователей. Использование опыта эксплуатации для постепенного наращивания и улучшения системы.

9.8. Интеллектуальность системы

В условиях поголовной неграмотности…

В.И.Ленин

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

      1. Запросы по требованию (ad-hoc query)

      2. Накопление процедурных знаний и открытый доступ к ним.

      3. Широкое применение правил для коррекции, контроля, дозадания и инициализации данных, для связывания объектов и контроля областей их применимости.

      4. Возможность автоматического планирования вычислительного процесса.

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

      6. Проверка правильности следования вычислительных модулей в стандартных путях расчёта и супермодулях.

      7. Проверка самосогласованности информации, использующейся для подготовки данных для расчёта, в том числе и длин массивов (аналог контроля задания данных в NAMELIST'е, делаемой некоторыми трансляторами без указания места ошибки).

      8. Проверка взаимно-однозначного соответствия фактических параметров вычислительных модулей с их описаниями в системе.

      9. Пополнение базы знаний на основе автоматизированного анализа текстов программ и наборов данных.

      10. Овеществление знаний экспертов в систематизированном виде:

      - Правила - корректирующие, контролирующие, исключающие и связующие.

      - Группы фильтров.

      - Наборы данных.

      - Тестовые задачи.

      - Супермодули.

      - Стандартные пути расчёта.

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

10. Функциональное наполнение

Функциональное программное обеспечение часто называют прикладным (applications software).

10.1. Цели

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

Отчуждение знаний и как частный случай - отчуждение программ от разработчика.

Система должна быть ориентирована на возможность использования открытого пользовательского кода (free user's software) - в нашем случае - программ на Фортране. Доступ к коду даёт возможность проанализировать программы и выявить ошибки. Стандарты достоверности, применяемые для научных экспериментов, должны распространяться и на тестирование программного обеспечения.

10.2. Способы достижения цели

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

Э. Дейкстра

      1. Накопление процедурных знаний. К ним относятся:

      - объектные библиотеки с процедурами,

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

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

      - inline-модули - встраиваемые в текст головной программы куски текста на Фортране.

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

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

      4. Создание предметно-ориентированных подсистем - например, визуализации входной и выходной информации.

      5. Наличие альтернативных программ для критически важных участков расчёта.

      6. Оценка разработчиками качества и производительности создаваемых модулей. Точность таких оценок - показатель квалификации разработчиков.

      7. Возможность работы с графическими объектами.

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

Отладка и сопровождение хорошо написанной и структурированной программы требуется намного меньше времени и сил. Такая программа более надёжна в работе по сравнению с той, в которой стилю не уделяется соответствующего внимания [25]. Соблюдение правил и стандартов при написании прикладных программ жизненно необходимо [26].

10.3. Требования к функциональному наполнению

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

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

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

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

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

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

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

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

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

11. Документация

"Здравствуй, брат! Писать очень трудно!"

Приветствие членов группы "Серапионовы братья"
 

При изложении на бумаге
требуется принятие сотен мини-решений,
и их наличие отличает
чёткую и точную политику от расплывчатой.

Ф. Брукс [10, с. 221]
 

Good documentation promotes understanding,
reduces duplication of effort,
eases conversion to different computer environments,
and facilitates extension to other applications.

Хорошая документация способствует пониманию,
уменьшает дублирование,
облегчает переход в другую компьютерную среду
и облегчает расширение на другие предметные области.[27]

Крайне важно всегда…
всё документировать,
как будто ожидая,
что на следующей неделе
у вас случится приступ амнезии.

Браун, 1976. Цит. по [28].
 

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

Катцнельсон, 1971. Цит. по [28].
 

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

Э. Иордан [29]

11.1. Общие принципы

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

Ценность документации, к которой описаны алгоритмы, архитектура и интерфейсы, может превышать ценность текстов программы.

Вот некоторые принципы, о которых нужно помнить создателям программных систем.

      1. Документирование системы на всех этапах жизненного цикла.

      2. Наличие высококачественной документации для системных и прикладных подсистем. Излишний объём документации предпочтительнее её недостаточности. Чем сложнее проект, тем полнее должна быть документация.

      3. Доступность электронных версий документации. Это требование сейчас является обязательным для всех наукоемких продуктов.

      4. Максимальное использование самодокументирования.

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

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

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

      8. Хорошая документация содержит детальное описание установок, тонких моментов, допущений, фиксаций "как есть".

      9. Документация всегда должна полностью соответствовать программе.

      10. Использование в документации единой терминологии.

11.2. Проектная документация

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

Э. Дейкстра

Недавно организованное проф. Шалыто A.A.(www.is.ifmo.ru), движение "За открытую проектную документацию", достойно самого пристального внимания.

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

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

Проектная документация не сводится к эксплуатационной документации.

Документация, необходимая при модификации программ, должна объяснять не только 'как', но и 'почему' программа делает то, что она делает. Желательно описывать отвергнутые алгоритмы с объяснением, почему они не приняты. Нужно документировать принятые решения и фиксировать, каким путём развивалась программа.

Хорошая проектная документация очень облегчает рефакторинг программы (изменение структуры программы без изменения её функциональности).

11.3. Пользовательская документация

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

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

12. Тестирование

Мы недавно проводили
Испытанья нашей силы.
Всё на славу удалось -
Там, где нужно, взорвалось.

С. Михалков "Про советский атом"
 

Повышенное использование
компьютерных моделей
призывает к разделению тех,
кто создаёт модели
и тех, кто проверяет их достоверность.

Майкл Крайтон
 

Мир без ошибок - опасная,
как всякая утопия,
тоталитарная фантазия.
Исправляя, мы улучшаем,
улучшая - разрушаем.

А. Генис
 

Ошибки - это постыдно. Это как клоп на манишке.

Фаина Раневская

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

      2. Особое внимание - тестированию отдельных модулей и средств их взаимодействия.

      3. Уделяйте внимание тестированию эксплуатационной пригодности программного продукта.

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

      5. Усилия на тестирование программ должно составлять не менее 2/3 от общих усилий на разработку

Четыре стадии тестирования:

      - инженер-разработчик,

      - специалист в области проектирования,

      - инженер отдела технического контроля,

      - апробация бета-версии.

Ошибки проявляются, если инструмент используется в несвойственной для него манере или же возникает строго определённая непроверенная последовательность действий. Ошибки появляются, когда пользователи выполняют трудно предсказуемые на момент разработки программы действия.

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

Цели программистов и тестировщиков разнонаправлены. Программист созидает, а тестировщик - разрушает. Чем более разрушителен тест, тем лучше. Каждый тест призван находить какой-то существенный прокол.

В технологических тестах нужно обращать внимание на следующие особые точки:

      1. Достаточность и правильность диагностики.

      2. Точность вычислений.

      3. Отклонения от стандарта.

      4. Тонкие и запутанные места в языке.

      5. Неоправданное и/или непроверенное использование оптимизации.

И надо помнить, что тестирование пронизывает всю жизнь программы.

13. Отладка

Для многих программ наиболее вероятная участь - программа умрёт с ненайденными ошибками, или (не дай Бог) кто-то умрёт от ненайденных ошибок - и об этом нельзя забывать при создании ответственных систем.

Из рецензии на книгу [30]. Андрей Колесов. PC Week/RE № 9, 2004

Ещё лет тридцать назад было признано, что отладка занимает в среднем около половины трудозатрат в общем процессе разработки ПО. Есть основания полагать, что за прошедшее время эта доля не снизилась, может быть, даже возросла.

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

Однако прежде всего нужно разобраться с самим понятием "отладка", которое мы обычно используем либо в широком, либо в узком смысле. В широком смысле отладка - это процесс доводки ПО после его написания, но до эксплуатационного состояния. Он состоит из двух основных элементов:

      1. тестирования обнаружения ошибок (точнее, несоответствий исходным требованиям);

      2. отладки (в узком смысле) - поиска причин ошибки и их устранения .

Разделение жизненного цикла создания ПО на различные этапы и виды работ является весьма условным. Обычно системы создаются в итерационном режиме, когда на каждом шаге выполняется цикл "написание кода - тестирование - отладка". Это же относится и к сочетанию "тестирование - отладка": например, для выявления причин ошибки нужно выполнять дополнительно специальные тестовые исследования.

В английском языке отладке в узком понимании соответствует более точный термин debugging (устранение жучков-ошибок). Именно этому виду программистской деятельности и посвящена книга Джона Роббинса.

Актуальность данной работы можно проиллюстрировать на простом примере. Как уже отмечалось выше, отладка и тестирование занимают до половины времени разработчика. Но сравните: сколько литературы (книг, статей) посвящено проектированию и кодированию и сколько - отладке!? А сколько времени отводится этой теме в общей программе подготовки разработчика?

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

Книга посвящена отладке приложений, создаваемых для Windows и .NET, в первую очередь с использованием языка C++ и в меньшей степени - C#, при этом особое внимание уделяется вопросам низкоуровневого программирования с применением неуправляемого кода. Это уже само по себе предполагает, что читатели имеют достаточно хорошую подготовку и ориентированы на создание сложных эффективных приложений. Однако первые две части книги (восемь глав) я бы посоветовал прочесть всем программистам независимо от их квалификации, используемого языка и платформы.

В части I обсуждаются общеметодические вопросы процесса коллективной отладки. Позволю себе привести некоторые полезные сведения из первой главы "Откуда берутся ошибки".

Основные категории ошибок:

      1. нелогичный пользовательский интерфейс;

      2. неудовлетворенные ожидания;

      3. низкая производительность;

      4. аварийные завершения или разрушения данных.

Причины ошибок:

      1. недостаточные сроки для выполнения проекта;

      2. подход "сначала кодируй, а потом думай";

      3. непонимание требований;

      4. низкая квалификация разработчика;

      5. недооценка важности качества конечного продукта.

А вот как выглядит общая последовательность правильно организованного процесса отладки:

      1. воспроизведи ошибку;

      2. опиши ошибку;

      3. всегда предполагай, что ошибку сделал ты;

      4. разделяй и властвуй;

      5. мысли творчески;

      6. усиль инструментарий;

      7. начни интенсивную отладку;

      8. проверь, что ошибка устранена;

      9. научись и поделись.

Стоит особо сказать о том, что автор думает по поводу извечных дискуссий о необходимости комментариев в программе: "Комментировать, комментировать и еще раз комментировать!".

Завершая рецензию книги, хотел бы привести еще пару ключевых идей Джона Роббинса. Первая: "Моя цель в первую очередь - научить вас избегать ошибок, а не находить их". И вторая: "Отладчик - это только инструмент, вроде отвертки. Настоящий отладчик находится в вашей черепной коробке".

14. Типичные ошибки

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

      1. Недостаточно анализируется существующая ситуация.

      2. Неясно сформулированы цели.

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

      4. Ответственные за проект окончательно не назначены и не согласованы.

      5. Отсутствует достаточно персонала нужной квалификации.

      6. Проблемы игнорируются, риски недооцениваются, ошибки повторяются.

      7. Отдаётся предпочтение импровизации, а не системному подходу.

15. Качество программного обеспечения

Этот раздел почти целиком основан на работе [31].

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

Подходы к качеству программного обеспечения

Для классификации подходов к качеству программного обеспечения возможны два измерения [32].

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

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

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

Два важнейших утверждения лежат в основе достижения качества.

      1. Качество начинается с удовлетворения потребностей разработчиков.

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

Подходы к достижению качества таковы:

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

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

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

      4. достижение качества должно планироваться;

      5. достижение качества - обязанность каждого разработчика.

Характеристики качества программного обеспечения

В настоящее время не существует
общепринятых критериев
качества программного обеспечения.

Стандарт 1S0 9000-3, п.6.4.1

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

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

Перечислим ряд таких характеристик [33].

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

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

      3. Эффективность (по времени и ресурсам ). Эффективность - это отношение уровня ycлуг, предоставляемых программным продуктом пользователя при заданных условиях, к объёму использованных ресурсов.

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

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

      6. Добротность (рациональная организация, продуманность, непереусложнённость)

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

Существуют следующие подходы по обеспечению надёжности:

      1. предупреждение ошибок;

      2. самообнаружение ошибок;

      3. самоисправление ошибок;

      4. обеспечение устойчивости к ошибкам.

"Достаточно хорошее" программное обеспечение

Пропагандистом "достаточно хорошего" программного обеспечения является Эдвард Йордон [20]. К "достаточно хорошему" программному обеспечению можно отнести такое, когда заказчик может быть удовлетворён системой, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями , достаточно устойчива и будет готова достаточно скоро. Однако даже "достаточно хорошее" программное обеспечение создать сложно.

К сожалению, "достаточно хорошее" программное обеспечение редко бывает действительно достаточно хорошим. Никлаус Вирт отмечает, что это "следствие грустного проявления духа нашего времени, в котором исчезает личная гордость за свою работу". По его мнению, "нельзя ожидать качественно выполненной работы, если не отдавать ей себя полностью, если нет личного удовлетворения, более того - удовольствия от неё".

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

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

16. Последние тенденции

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

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

16.1. Высокоскоростные вычисления - High Performance Computing (HPC)

Неприятности в экономике (и не только)
можно объяснить тем,
что все наши математические модели,
как бы сложны они ни были,
слишком просты.

Мысль Алана Гринспена
 

Жизнь - это земледелие.
Надо найти хороший кусок плодородной земли,
распахать почву и запастись терпением.
Урожай приходит позже,
а главное дело делается тогда,
когда ни малейших результатов еще не видно.

Герберт Кауфман

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

Нужно всерьёз осваивать инструменты для распараллеливания программ MPI [35] и/или OpenMP [36] или их аналоги. Утверждается, что молодые мозги осваивают эти инструменты на лету. Но для их эффективного применения невозможно обойтись без существенной модернизации алгоритмов (по крайней мере для MPI), что молодым делать значительно труднее. Выход - в объединении усилий.

В области нейтроники нужно внедрять расчёты по подобластям. И здесь стоят проблемы, как делить на подобласти, ноды или домены, как и по каким критериям автоматизировать этот процесс. Например, в статье [37] описывается красно-чёрное упорядочение вычислительных нод, что помогает оптимизировать обработку перетекающих токов, улучшить эффективность итераций и позволяет распараллелить процесс внутренних итераций с помощью OpenMP. Подобный процесс раскрашивания реализован, например, и у Серёгина А.С. в последних версиях программы TRIGEX.

Следует отметить, что процесс деления на подобласти существенно проще реализуется в XY-геометрии, которая хорошо подходит для западных тепловых реакторов. В XY-геометрии широко используются итерации на перекрывающихся подобластях [38]. Подробные формулы для разных вариантов декомпозиции приведены в работах [39, 40, 41]. Структура решений уравнения переноса такова, что одному процессору удобно отдавать внутренние итерации в одной подобласти. И снова встаёт вопрос об оптимальном соотношении точностей внешних и внутренних итераций с учётом скоростей обмена информацией между процессорами. Можно защитить еще много диссертаций.

Однако XY-геометрия плохо приспособлена для моделирования реакторов с гексагональной структурой топливных сборок (ВВЭРы, БНы), хотя примеры наложения мелкой квадратной сетки га гексагональную структуру есть. И это открывает простор нашим математикам для ухищрений в декомпозиции таких структур и построении соответствующих схем вычислений.

Почему-то в публикациях мне не попадалось использование ромбических структур (если не считать очень старые работы Z. Woznicki: HEXAGA II - A Twodimensional Multigroup Neutron Diffusion Program for a Uniform Triangular Mesh, KfK 2293, 1976.), которые хорошо подходят для дробления гексагонов.

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

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

Важным является и организация обмена данными. Для повышения эффективности этого процесса разрабатываются специальные форматы, например HDF5 [42], где данные организованы иерархически.

Необходима и оптимизация загрузки процессоров. Один из подходов к этой проблеме описан в работе [43]. Там предлагается использовать предварительные расчёты в диффузионном приближении для оценки весов каждого домена, которые затем используются при ребалансе загрузки процессоров при транспортных расчётах.

Есть одно достаточно новое направление гигантского ускорения вычислений с распараллеливанием их на графических процессорах (GPU). До недавнего времени это требовало программирования на Си, однако сейчас уже появилась возможность программировать для GPU и на Фортране, используя среду CUDA.

Описание из Википедии (слегка отредактировано):

CUDA (англ. Compute Unified Device Architecture) - технология GPGPU (General-Purpose Computing on Graphics Processing Units), позволяющая программистам реализовывать алгоритмы, выполнимые на графических процессорах ускорителей GeForce восьмого поколения и старше (GeForce 8 Series, GeForce 9 Series, GeForce 200 Series), Nvidia Quadro и Tesla компании Nvidia. Технология CUDA разработана компанией nVidia.

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

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

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

CUDA использует grid-модель памяти, кластерное моделирование потоков и SIMD (Single instruction/Multiple data) инструкции. Включена возможность подключения к приложениям, использующим Microsoft Direct3D 9 и OpenGL. Создана в версиях для Linux и Windows.

Перечень устройств от производителя оборудования Nvidia с заявленной полной поддержкой технологии CUDA приведён на официальном сайте Nvidia.

Сегодня есть возможность программировать на языках C, Java, Fortran, Python (для последнего взаимодействие идёт с использованием PyCUDA).

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

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

16.2. Системы программ

Мы строим здания, а потом они строят нас.

У. Черчилль.

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

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

Развиваются специализированные инструменты и для пре- и постобработки. Например Graphical User Interface Silene [44] может быть полезна как образец таких систем. Silene используется в CEA для генерации входных данных, описывающих 2D*3D неструктурированные конфигурации для нейтронных транспортных кодов. Silene может обрабатывать и правильные структуры.

Но есть и общие инструменты. В Европе создана платформа SALOME - The Open Source Integration Platform for Numerical Simulation (www.salome-platform.org), которая должна облегчить интеграцию программ для научных, исследовательских и промышленных расчётов, в том числе для полномасштабного моделирования реакторных установок.

SALOME решает проблему системного программного обеспечения, а работы по созданию функционального программного обеспечения решаются внутри проекта NURESIM - A European Platform for NUclearREactor SIMulation [45, 46] - www.nuresim.com, www.nuresim.org (requires password).

На PHYSOR'08 ссылки на NURESIM есть в десятке статей, и в шести на M&C+SNA 2007. Полный список публикаций по NURESIM можно найти в Интернете: NURESIM_List_of_publications(February272009).pdf. И даже заголовки этих публикаций дают очень хорошую картину того, что делается в Европе (нейтроника, бенчмаркинг, мультифизика и т.д.).

В США чуть раньше, в 2003 году, был открыт проект Numerical Nuclear Reactor (NNR) [47], рассчитанный на использование высокоскоростных компьютеров с параллелизмом и ориентированный на транспортные нейтронно-физические расчёты активной зоны, CFD (computational fluid dynamics) для теплогидравлических расчётов и на структурные термомеханические расчёты [48, 49, 50, 51, 52, 53]. Изначально рассчитанный на реакторы PWR, проект NNR теперь приспособлен и для расчётов BWR [54].

Вот еще несколько ссылок на описание систем, ориентированных на расчёт либо одного, либо нескольких типов реакторов: Osiris reactor analysis code [55], UNIC [56, 57], AEGIS [58], MARBLE [59], SHARP (Simulation-based High-efficiency Advanced Reactor Prototyping) [60]. Эти системы не связаны с проектом NURESIM. А система DESCARTES [61, 62, 63, 64] входит в проект NURESIM и ориентирована на нейтронные расчёты реакторов различных типов.

И в качестве примера, несколько ссылок на математические инструменты:

1. PETSc (Portable, Extensible Toolkit for Scientific Computation), разработанный в ANL [65]. Содержит решатели для уравнений в частных производных с параллельными вычислениями.

2. S. Balay, W. D. Gropp, L. C. McInnes, B. F. Smith, "Efficient Management of Parallelism in Object Oriented Numerical Software Libraries, Modern Software Tools in Scientific Computing", E. Arge and A.M. Bruaset and H.P. Langtangen, 163-202, Nirkhauser Press, (1997)

3. LAPACK - Linear Algebra Package, www.netlib.org/lapack/

16.3. Pre & post processing, graphical user interface (GUI), расчётные сетки

Одна из основных проблем - выбор расчётных сеток, особенно при мультифизических расчётах.

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

Поскольку надежда на гибкость в задании сеток в теплогидравлических программах невелика (м.б. я ошибаюсь?), то если вы хотите быть конкурентоспособными на рынке программ, вы должны обеспечить максимальную гибкость расчётных сеток в нейтронных кодах. Пример - работа [66], где за основу была взята сетка из STAR CD [67] и гибкость была обеспечена за счёт MCNP [68].

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

Если раньше такие подходы могли себе позволить только наши коллеги из Арзамаса и Снежинска, то сейчас возможности стремительно расширяются. Компьютеры уже есть или вот-вот будут, но где программы, или люди, способные создавать такие программы?

Для детерминированных программ переноса получает всё большее распространение использование общей комбинаторной геометрии, разработанной для методов Монте-Карло [69, 70, 71, 72].

Еще два очень общих подхода - в работе [73]. Очень интересен вариант с произвольной треугольной сеткой, сделанный с помощью графической системы SILENE. В статье[74] подробна описана схема расчёта, в которой есть все основные этапы - разбиение на физические домены, покрытие треугольной сеткой и т.д. Есть хорошая обзорная статья [75].

Статьи о Graphical User Interface SILENE [76, 77] могут быть полезны не только описанием общего полхода к генерации сеток для транспортных расчётов, но и образцами используемых геометрических компонентов.

К сожалению, треугольную геометрию нельзя использовать при расчётах методом дискретных ординат. Как следствие, следует отметить возросший интерес к различным модификациям метода сферических гармоник, позволяющих использовать треугольную сетку и/или методы конечных элементов [78].

Будущее за адаптивными [79, 80, 81,82, 83, 84, 85, 86], автоматически выбираемыми сетками.

17. Список литературы

1 Автоматизация реакторных расчётов. Зизин М.Н., Загацкий Б.А., Темноева Т.А., Ярославцева Л.Н. М.: Атомиздат, 1974.

2 Зизин М.Н. Концепция создания системного и прикладного программного обеспечения реакторных расчётов. Атомная энергия, т.75 вып. 5, май 1995 с.299-305.

3 Зизин М.Н. Интеллектуальное программное обеспечение задач математического моделирования. Препринт РНЦ-КИ, ИАЭ 6108/5, М.: 1999.

4 Зизин М.Н. Расчёт нейтронно-физических характеристик реакторов на быстрых нейтронах. М.: Атомиздат, 1978.

5 Зизин М.Н. Нужен ли Российский Проект по реакторному моделированию? Препринт РНЦ КИ ИАЭ 6447/5, 2007.

6 Зизин М.Н. Нужен ли Российский Проект по реакторному моделированию? Атомная Энергия, 2007, т. 103, вып.4, с. 232.

7 Зизин М.Н. Системное и прикладное программное обеспечение задач математического моделирования ядерных реакторов. Докторская диссертация, РНЦ-КИ, 1995.

8 Зизин М.Н., Сушнова Н.Б. ShIPRW - Windows-версия интеллектуальной программной оболочки ShIPR для математического моделирования ядерных реакторов. Нейтроника-98, с.218-226, 1999.

9 Зизин М.Н. Интеллектуальная программная система ShIPR для математического моделирования ядерных реакторов. Препринт ИАЭ-6354/5, 2005.

10 Брукс Ф. Мифический человеко-месяц. 2-е издание. 'Символ'. Санкт-Петербург, 2000.

11 Колесов А. А управлять - так знаниями! Byte Россия № 3 (42), с. 7.

12 Рыков В.В. Парадигма трёх миров и управление знаниями. Труды XLVII научной конференции МФТИ 'СИСТЕМНАЯ ИНТЕГРАЦИЯ И МЕНЕДЖМЕНТ', М.: 2004, с. 105-108.

13 Лбов Г.С., Старцева Н.Г. Логические решающие функции и вопросы статистической устойчивости решений. Новосибирск. Издательство Института математики. Тираж 200 экз., 1999.

14 Загоруйко Н.Г. Прикладные методы анализа данных и знаний. Издательство Института математики, Новосибирск, 1999.

15 Технологии IBM для электронного бизнеса. - М.: 2004. - www.ibm.com/developerworks/patterns/ru_ru.

16 Простаков И.Е. Технологии управления корпоративными знаниями //Всероссийская научно-техническая конференция "Наука и образование" - 2002. - М.. 2002.

17 Ванс, Эшли. Залог безопасности. Computerworld Россия, 10.09.2002, № 33(338) с. 29.

18 Бугроменко В. Экспертные системы в стратегическом планировании: пример транспорта. PC Week/RE #29, 2000.

19 Л. де Брабандер. Забытая сторона перемен. М.: Претекст, 2006.

20 Йордон, Эдвард. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. М.: 'ЛОРИ', 2000

21 Гейтс, Билл. Бизнес со скоростью мысли. М.:ЭКСМО-ПРЕСС, 2001, с. 15

22 Маккарти Д., Маккарти М. Правила разработки программного обеспечения. М.: ПИТЕР, 2007

23 Жарков С. Shareware: профессиональная разработка и продвижение программ. Bhv, Санкт-Петербург, 2002.

24 Иан Грэхем. Объектно-ориентированные методы. Принципы и практика. - М.: ИД "Вильяме", 2004.

25 Керниган Б.У., Пайк Р. Практика программирования. Пер. с англ. М.: Издательский дом 'Вильямс', 2004.

26 Зизин М.Н. Стандарт написания и документирования программ на Фортране 90. ВЕРСИЯ 1.0 Препринт РНЦ-КИ, ИАЭ-6355/5, М.: 2005.

27 American National Standard Documentation of Computer Software, ANSI/ANS-10.3-1995.

28 Турский А. Методология программирования. М.: МИР, 1981.

29 Йордан Э. Структурное проектирование и конструирование программ. М.: МИР, 1979.

30 Роббинс Дж. Отладка приложений для Microsoft .NET и Microsoft. Пер. с англ. М.: ИТД "Русская Редакция", 2004. - 736 с., компакт-диск.

31 Одинцов Игорь О. Профессиональное программирование. Системный подход. С.-П. bhv 2002 г., сс.191-199.

32 Vliet H.V. Software Engineering: Principles and Practice. John Wiley and Sons, 2000.

33 Жоголев Е.А. Лекции по технологии программирования. М.: МГУ, факультет ВМиК, рукопись, 1996.

34 Khalil H.S.. Modeling and Simulation Needs for Future Generation Reactors M&C+SNA 2007.

35 "Message Passing Interface Forum", visit the website at: http://www.mpi-forum.org/

36 "OpenMP: Simple, Portable, Scalable SMP Programming", visit the website at: http://www.openmp.org

37 Pautz A., Curca-Tivig F. et al. The ARTEMIS Core Simulator: A Central Component of AREVA NP's Code Convergence Project. M&C+SNA 2007.

38 Pautz A., Curca-Tivig F. et al. The ARTEMIS Core Simulator: A Central Component of AREVA NP's Code Convergence Project. M&C+SNA 2007.

39 Herrero J.J., Ahnert C. and Aragonns J.M. Whole Core Fine Mesh Multigroup Diffusion Calculations by Domain Decomposition thought Alternate Dissections. M&C+SNA 2007.

40 Van Criekingen S., Nataf F., Have P. Neutron Transport Solver Parallelization Using A Domain Decomposition Method. PHYSOR'08.

41 Guerin P., Baudron A., Lautard J. Domain Decomposition Methods for Core Calculations Using the Minos Solver. M&C+SNA 2007.

42 "What is HDF5", visit the website at: http://hdf.ncsa.uiuc.edu/whatishdf5.html

43 Aliva Pattnaik, Cassiano R. E. de Oliveira. Load Balancing Strategy for Radiation Transport Code EVENT. M&C+SNA 2007.

44 Z. Stankovski. Implementation of the Component Concept in SILENE 2D/3D Pre & Post Processing GUI. M&C+SNA 2007.

45 M. Hugon, V. Bhatnagar, M. Deffrennes, P. Manolatos and G. Van Goethem. Research and Training Supporting Reactor Systems in the Euratom Framework Programmes. PHYSOR'08.

46 O. Zerkak, P. Coddington N. Crouzet, E. Royer J. Jimenez, D. Cuervo. LWR Multi-Physics Developments and Applications Within the Framework of the Nuresim European Project. M&C+SNA 2007.

47 Weber D.P., Joo H. G., Downar T.J. and Kim C. H. Integrated 3-D Simulation of Neutronic, Thermal-Hydraulic and Thermo-Mechanical Phenomena. presented at the 10th International Topical Meeting on Nuclear Reactor Thermal Hydraulics (NURETH-10), Seoul, Korea 2003.

48 The Numerical Nuclear Reactor for High Fidelity Integrated Simulation of Neutronic, Thermal-Hydraulic and Thermo Mechanical Phenomena - Project Overview D. P. Weber, T. Sofu1, P. A. Pfeiffer et al. PHYSOR'04.

49 Coupled Calculations Using the Numerical Nuclear Reactor for Integrated Simulation of Neutronic and Thermal-Hydraulic Phenomena D.P. Weber, T. Sofu, W.S. Yang et al. Joo. PHYSOR'04.

50 Weber D.P. et.al. The Numerical Nuclear Reactor - A High Fidelity Integrated Neutronic, Thermal-Hydraulic and Thermo-Mechanical Code, M&C 2005.

51 The Numerical Nuclear Reactor - A High Fidelity, Integrated Neutronic, Thermal-Hydraulic, and Thermo- Mechanical Code. Weber D.P., Sofu T., Yang W.S. et al. Nuclear Science and Engineering, 155, 395-408, 2007.

52 Coupled BWR Calculations with the Numerical Nuclear Reactor Software System. T. Sofu, J. W. Thomas, D. P. Weber, and W.D. Po. PHYSOR'08.

53 Hursin M., Downar T.J. PWR Control Rod Ejection Analysis with the Method of Characteristic Code DeCART. PHYSOR'08.

54 Extension of Integrated Neutronic and Thermal-Hydraulic Analysis Capabilities of the "Numerical Nuclear Reactor" Software System for BWR Applications. D. Weber, T. Sofu, D. Pointer et al. PHYSOR'06.

55 Procassini, Chand, Clouse, et al. Osiris: A Modern, High-Performance Code for Nuclear Reactor Core Analysis. M&C+SNA 2007.

56 G. Palmiotti, et al., "UNIC: Ultimate Neutronic Investigation Code", M&C+SNA 2007.

57 M.A. Smith, G. Palmiotti, C. Rabiti, et. al. PNFE Component of the UNIC code, M&C+SNA 2007

58 N. Sugimura, T. Ushio, A. Yamamoto, et al. Development of Advanced Neutronics Design System Of Next Generation, AEGIS. PHYSOR'08.

59 MARBLE: a next generation neutronics analysis code system for fast reactors K. Yokoyama, Y. Hirai, M. Tatsumi, H. Hyoudou et al. PHYSOR'08.

60 A. Siegel et al. Ragusa. Software Design of SHARP. M&C+SNA 2007.

61 Calvin C. DESCARTES: A New Generation System for Neutronic Calculations. M&C 2005.

62 A.M. Baudron, J.J. Lautard. MINOS: A SPN Solver for Core Calculations in the DESCARTES System, M&C 2005.

63 C. Calvin, C. Fedon-Magnaud "DESCARTES: An Advanced Code System for Neutronics Calculations", in Advanced Methods, Codes and Benchmarking of the NURESIM Core Physics European Simulation Platform, American Nuclear Society and the European Nuclear Society International Conference on Making the Nuclear Renaissance Real, Washington D.C., Nov. 2007, Trans. TANSAO 97, 691-693, ISSN: 0003-018X (2007),

64 A.M. Baudron, C. Doderlein, P. Guerin, J.J. Lautard, F. Moreau. Unstructured 3d Core Calculations with the Descartes System Application to the JHR Research Reactor. M&C+SNA 2007.

65 S. Balay et al. PETSc home page, (2002). http://www.mcs.anl.gov/petsc.

66 Reactor Simulation with Coupled Monte Carlo and Computational Fluid Dynamics. Volkan Seker, Justin W. Thomas and Thomas J. Downar. M&C+SNA 2007.

67 CD-adapco Group, STAR-CD, Version 3.26, Melville, NY

68 X-5 Monte Carlo Team, "MCNP - A General Monte Carlo N-Particle Transport Code, Version 5", LANL, 2003.

69 M.D. DeHart, I.C. Gauld, and M.L. Williams. High-Fidelity Lattice Physics Capabilities of the Scale Code System Using Triton. M&C+SNA 2007.

70 M.D. DeHart, R.E. Pevey, and T.A Parish, "An Extended Step Characteristic Method for Solving the Transport Equation in General Geometries," Nucl. Sci. Eng., 118, 79 (1994).

71 DeHart M.D., Pevey R.E. and Parish T. A. "An Extended Step Characteristic Method for Solving the Transport Equation in General Geometries," Nucl. Sci. Eng., 118, 79 (1994)

72 DeHart M.D., "Advancements in Generalized-Geometry Discrete Ordinates Transport for Lattice Physics Calculations," A154.pdf in Proc. of PHYSOR'06.

73 A.M. Baudron, C. Doderlein, P. Guerin, J.J. Lautard, F. Moreau. Unstructured 3d Core Calculations with the Descartes System Application to the JHR Research Reactor. M&C+SNA 2007.

74 Z. Stankovski. Implementation of the Component Concept in SILENE 2D/3D Pre & Post Processing GUI. M&C+SNA 2007.

75 Hansen G. An Overview of Mesh Generation Technology Applied to Reactor Core Analysis. M&C+SNA 2007

76 Z. Stankovski. Implementation of Component Concept in Silene 2D/3D Pre & Post Processing GUI. M&C+SNA 2007.

77 Z. Stankovski. Mutant Components and Scripting in Silene 2D/3D Pre & Post Processing GUI. PHYSOR'08

78 M.A. Smith, G. Palmiotti, C. Rabiti, et. al. PNFE Component of the UNIC code, M&C+SNA 2007

79 J. Warsa et al, "p-Adaptive Numerical Methods for Particle Transport", Trans. Theo. Stat. Phys., 28, pp 229-270 (1999).

80 J.C. Ragusa, "3-D Adaptative Solution of the Multigroup Diffusion Equation on Irregular Structured Grids Using a Non Conforming Finite Element Method Formulation", PHYSOR'04

81 E. Lewis et al., "Spatial Adaptivity Applied to the Variational Nodal Pn Equations," Nucl. Sci. & Eng. 142, 1-7 (2002).

82 L. Demkowicz, W. Rachowicz, Ph. Devloo, "A Fully Automatic hp-adaptivity," TICAM Report 01-28, Texas Institute for Computational and Applied Mathematics, The University of Texas at Austin (2001).

83 Y. Wang and J.C. Ragusa. GOAL-ORIENTED hp-MESH ADAPTATION FOR 1-D MULTIGROUP DIFFUSION EQUATIONS, M&C+SNA 2007.

84 Yaqi Wang and Jean Ragusa. MULTI-DIMENSIONAL AUTOMATIC MESH REFINEMENT FOR THE MULTIGROUP SPN EQUATIONS, M&C+SNA 2007.

85 G. Palmiotti et al. UNIC: Ultimate Neutronic Investigation Code, M&C+SNA 2007.

86 J.D. Densmore, T.M. Evans, and M.W. Buksas. A HYBRID MONTE CARLO-DIFFUSION METHOD FOR RADIATION TRANSPORT ON ADAPTIVE MESH REFINEMENT-TYPE MESHES. M&C+SNA 2007.

Источник: 
atominfo.ru