авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 3 | 4 || 6 |

«Введение Цели, задачи, структура курса Несколько слов о месте курса «История и методология информати- ки и вычислительной техники» в образовательной программе магистра- ...»

-- [ Страница 5 ] --

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

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

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

7.2 Парадигмы программирования Термин «парадигма программирования» впервые применил Роберт Флойд в своей лекции лауреата премии Тьюринга.

Флойд отмечает, что в программировании можно наблюдать явле ние, подобное парадигмам Куна, но, в отличие от них, парадигмы про граммирования не являются взаимоисключающими: «Если прогресс ис кусства программирования в целом требует постоянного изобретения и усовершенствования парадигм, то совершенствование искусства от дельного программиста требует, чтобы он расширял свой репертуар па радигм» [64].

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

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

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

В качестве этой единицы выступают:

инструкция (императивное программирование, FORTRAN/C/PHP), функция (функциональное программирование, Haskell/Lisp/F#/Scala), прототип (прототипное программирование, JavaScript), объект (объектно-ориентированное программирование, С++/Java), факт (логическое программирование, PROLOG) и др. сущности.

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

Приверженность определнного человека какой-то одной парадиг ме иногда носит настолько сильный характер, что споры о преимущест вах и недостатках различных парадигм относятся в околокомпьютерных кругах к разряду так называемых «религиозных» войн – холивар.

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

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

дисциплина логики управления с исключением переходов по меткам (goto_less_style);

минимизация использования глобальных переменных в пользу формальных параметров процедур (global_variable_harmful);

полнота условий в ветвлениях, отказ от отсутствия ветви else;

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

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

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

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

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

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

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

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

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

7.3 Понятие жизненного цикла ПО Одним из базовых понятий методологии проектирования ПО явля ется понятие жизненного цикла (ЖЦ). ЖЦ – это непрерывный процесс, который начинается с момента принятия решения о необходимости соз дания ПО и заканчивается в момент его изъятия из эксплуатации [61].

По международному стандарту ISO/IEC 12207 структура ЖЦ ПО базируется на трех группах процессов:

основные процессы (приобретение, поставка, разработка, экс плуатация, сопровождение);

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

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

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

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

Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО.

Верификация – процесс определения того, отвечает ли текущее со стояние разработки требованиям.

Проверка – оценка соответствия параметров разработки исходным требованиям.

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

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

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

7.3.1 Модели жизненного цикла ПО ЖЦ ПО – это непрерывный процесс, который начинается с момен та принятия решения о необходимости создания ПО и заканчивается в момент полного его изъятия из эксплуатации.

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

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

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

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

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

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

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

Преимущества каскадного способа состоят в следующем:

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

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

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

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

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

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

реализацию ПО – программирование модулей, отладка, а так же испытания и внедрение для эксплуатации созданной версии КП;

внедрение;

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

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

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

7.3.1.4 Спиральная модель ЖЦ Для преодоления перечисленных проблем была предложена спи ральная модель ЖЦ, в которой делается упор на начальные этапы ЖЦ – анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спи рали соответствует созданию фрагмента или версии ПО, на нем уточ няются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углуб ляются и последовательно конкретизируются детали проекта, и в ре зультате выбирается обоснованный вариант, который и доводится до реализации.

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

Рисунок 6.2 – Спиральная модель жизненного цикла 7.4 CASE–средства Еще в 1975 г. Фредерик Брукс, проанализировав свой уникальный по тем временам опыт руководства крупнейшим проектом разработки операционной системы OS/360, определил перечень неотъемлемых свойств ПО: сложность, согласованность, изменяемость и незримость.

Что же касается современных крупномасштабных проектов ПО, то они характеризуются, как правило, следующими особенностями [61].

Характеристики объекта внедрения:

структурная сложность и территориальная распределенность;

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

сложные взаимосвязи между ними;

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

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

Технические характеристики проектов создания ПО:

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

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

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

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

В конце 60-х годов прошлого века в США было отмечено явление под названием "software crisis" (кризис ПО). Это выражалось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал тре буемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не уст раивало потребителей.

Объективная потребность контролировать процесс разработки сложных систем ПО, прогнозировать и гарантировать стоимость разра ботки, сроки и качество результатов в конце 60-х годов прошлого века свидетельствовала о необходимости перехода от кустарных к индустри альным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием "про граммная инженерия" (software engineering).

CASE (англ. Computer-Aided Software Engineering) – набор инстру ментов и методов программной инженерии для проектирования про граммного обеспечения, который помогает обеспечить высокое качест во программ, отсутствие ошибок и простоту в обслуживании программ ных продуктов [65].

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

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

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

Графические (визуальные) модели представляют собой средства для визуализации, описания, проектирования и документирования архи тектуры системы [66]. Разработка модели системы ПО промышленного характера в такой же мере необходима, как и наличие проекта при строительстве большого здания. Это утверждение справедливо как в случае разработки новой системы, так и при адаптации типовых про дуктов класса R/3 или BAAN, в составе которых также имеются собст венные средства моделирования. Хорошие модели являются основой взаимодействия участников проекта и гарантируют корректность архи тектуры. Поскольку сложность систем повышается, важно располагать хорошими методами моделирования. Хотя имеется много других фак торов, от которых зависит успех проекта, но наличие строгого стандарта языка моделирования является весьма существенным.

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

сложности проектируемой системы;

необходимой полноты ее описания;

знаний и навыков участников проекта;

времени, отведенного на проектирование.

Визуальное моделирование оказало большое влияние на развитие CASE-средств.

7.5.2 Методы структурного анализа и проектирования ПО В структурном анализе и проектировании используются различные модели, описывающие:

функциональную структуру системы;

последовательность выполняемых действий;

передачу информации между функциональными процессами;

отношения между данными.

Наиболее распространенными моделями первых трех групп явля ются следующие.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта ка кой-либо предметной области. Функциональная модель SADT отобра жает функциональную структуру объекта, т.е. производимые им дейст вия и связи между этими действиями. Метод SADT разработан Дугла сом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности. Модели SADT (IDEF0) традиционно ис пользуются для моделирования организационных систем (бизнес процессов) [67]. Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в США в качестве типового. Достоинствами применения моделей SADT для описания бизнес-процессов являются:

полнота описания бизнес-процесса (управление, информацион ные и материальные потоки, обратные связи);

жесткие требования метода, обеспечивающих получение моде лей стандартного вида;

соответствие подхода к описанию процессов стандартам ISO 9000.

Метод моделирования IDEF3, являющийся частью семейства стандартов IDEF, был разработан в конце 1980-х годов для закрытого проекта ВВС США. Этот метод предназначен для таких моделей про цессов, в которых важно понять последовательность выполнения дейст вий и взаимозависимости между ними. IDEF3 приобрел широкое рас пространение как дополнение к методу функционального моделирова ния. Основой модели IDEF3 служит так называемый сценарий процесса, который выделяет последовательность действий и подпроцессов анали зируемой системы [68].

Диаграммы потоков данных (Data Flow Diagrams - DFD) пред ставляют собой иерархию функциональных процессов, связанных пото ками данных. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна Сэрсона. Эти нотации незначительно отличаются друг от друга графи ческим изображением символов. В соответствии с данными методами модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Практически любой класс сис тем успешно моделируется при помощи DFD-ориентированных мето дов. Они с самого начала создавались как средство проектирования ин формационных систем (тогда как SADT – как средство моделирования систем вообще) и имеют более богатый набор элементов, адекватно от ражающих специфику таких систем (например, хранилища данных яв ляются прообразами файлов или баз данных, внешние сущности отра жают взаимодействие моделируемой системы с внешним миром).

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

Наиболее распространенным средством моделирования данных (предметной области) является модель "сущность-связь" (Entity Relationship Model – ERМ) [69]. Она была впервые введена Питером Че ном в 1976 г. Эта модель традиционно используется в структурном ана лизе и проектировании, однако, по существу, представляет собой под множество объектной модели предметной области. Одна из разновид ностей модели "сущность-связь" используется в методе IDEF1Х, вхо дящем в семейство стандартов IDEF и реализованном в ряде распро страненных CASE-средств (в частности, AllFusion ERwin Data Modeler).

7.5.3 Методы объектно-ориентированного анализа и проектирования ПО.

Концептуальной основой объектно-ориентированного анализа и проектирования ПО (ООАП) является объектная модель. Ее основные принципы (абстрагирование, инкапсуляция, модульность и иерархия) и понятия (объект, класс, атрибут, операция, интерфейс и др.) наиболее четко сформулированы Гради Бучем [70].

Большинство современных методов ООП основаны на использова нии языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, пред ставления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диа грамм и нотаций самых разнообразных видов.

Главными в разработке UML были следующие цели [71]:

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

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

обеспечить независимость от конкретных языков программиро вания и процессов разработки.

обеспечить формальную основу для понимания этого языка мо делирования (язык должен быть одновременно точным и дос тупным для понимания, без лишнего формализма);

стимулировать рост рынка объектно-ориентированных инстру ментальных средств;

интегрировать лучший практический опыт.

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

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

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

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

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

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

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

Ряд современных методов моделирования бизнес-процессов осно ван на использовании языка UML [72]. Хотя UML изначально предна значался для моделирования систем ПО, его использование в другой области стало возможным благодаря наличию в UML механизмов рас ширения (стереотипов).

Среди таких методов наиболее известными являются метод Ericsson-Penker и метод, реализованный в технологии Rational Unified Process (RUP) [73].

Методика моделирования RUP предусматривает построение двух моделей:

модели бизнес-процессов (Business Use Case Model);

модели бизнес-анализа (Business Analysis Model).

Модель бизнес-процессов представляет собой расширение модели вариантов использования UML за счет введения набора стереотипов – Business Actor (стереотип действующего лица) и Business Use Case (сте реотип варианта использования). Business Actor (действующее лицо бизнес-процессов) – это некоторая роль, внешняя по отношению к биз нес-процессам организации. Business Use Case (вариант использования с точки зрения бизнес-процессов) определяется как описание последова тельности действий (потока событий) в рамках некоторого бизнес процесса, приносящей ощутимый результат конкретному действующе му лицу. Это определение подобно общему определению бизнес процесса, но имеет более точный смысл. В терминах объектной модели Business Use Case представляет собой класс, объектами которого явля ются конкретные потоки событий в рамках описываемого бизнес процесса.

В RUP рекомендовано следовать шести практикам, позволяющим успешно разрабатывать проект [74]:

итеративная разработка;

управление требованиями;

использование модульных архитектур;

визуальное моделирование;

проверка качества;

отслеживание изменений.

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

7.6 Современные тенденции в программной инженерии В начале 2001 года века ряд ведущих специалистов в области про граммной инженерии (Алистер Коберн, Мартин Фаулер, Джим Хайс мит, Кент Бек и другие) сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стремительный) отражало в це лом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Этот подход под на званием "Быстрая разработка ПО" (Agile software development) базиру ется на четырех идеях, сформулированных ими в документе "Манифест быстрой разработки ПО" (Agile Alliance's Manifesto) и заключающихся в следующем:

индивидуумы и взаимодействия между ними ценятся выше про цессов и инструментов;

работающее ПО ценится выше всеобъемлющей документации;

сотрудничество с заказчиками ценится выше формальных дого воров;

реагирование на изменения ценится выше строгого следования плану.

Методология RAD (быстрой разработки 7.6. приложений) Методология RAD включает в себя три составляющие [65]:

небольшую команду программистов (1–10 чел.) короткий, но тщательно проработанный производственный гра фик (2–6 мес.) повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реа лизуют в продукте требования, полученные через взаимодейст вия с заказчиком.

Фазы жизненного цикла ПО согласно методологии RAD:

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

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

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

После детального определения состава процессов оценивается ко личество функциональных элементов разрабатываемой системы и при нимается решение о разделении программной системы на подсистемы, пригодные для реализации одной командой разработчиков за приемле мое для RAD-проектов время (60–90 дней). С использованием CASE средств проект распределяется между командами. Результатом данной фазы должны быть :

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

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

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

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

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

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

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

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

Фаза внедрения завершает процесс.

РАД не универсальна, подходит для небольших проектов для одно го заказчика. Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является "Экстремальное программирование" (Extreme Programming – XP) 7.6.2 Экстремальное программирование Отцом-идеологом экстремального программирования считают Кента Бека (Kent Beck) [75]. XP является достаточно молодой методоло гией, оценки которой весьма противоречивы – от восторженных до рез ко негативных.

Факторы ускорения разработки.

Итеративность: разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2–3 не дели и не более 1 месяца. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать посредством активного включения в процесс разработки заказчика как полноправного члена команды и за счет наличия постоянного контакта с заказчиком.

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

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

функциональность расширяется на каждой итерации.

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

Планирование процесса (planning game). Вся команда собирается вместе, принимается коллективное решение о том, какие свойства сис темы будут реализованы в ближайшей итерации.

Тесное взаимодействие с заказчиком (feed-back, on-site customer).

Заказчик должен быть членом XP-команды (on-site customer). Заказчик должен быть экспертом в автоматизируемой предметной области. Не обходимо постоянное наличие обратной связи с заказчиком (feed-back).

Метафора системы (system metaphor). Хорошая метафора систе мы означает простоту именования классов и переменных;

команда должна иметь единые правила именования.

Простая архитектура (simple design). Любое свойство системы должно быть реализовано как можно проще. Принимается первое наи простейшее работающее решение, реализуется необходимый уровень функциональности на данный момент.

Стандарты кодирования (coding conventions). Стандарты кодиро вания нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга.

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

Парное программирование (pair programming) – одна из самых из вестных XP-практик. Все программисты должны работать в парах: один пишет код, другой смотрит.

40-часовая рабочая неделя. Программист не должен работать бо лее 8 часов в день. Необходимость сверхурочной работы (overtime) – это четкий индикатор проблемы на данном конкретном направлении разработки;

к тому же заказчик не платит за сверхурочную работу в XP.

Поиск причин сверхурочной работы и их скорейшее устранение – одно из основных правил.

Коллективное владение кодом (collective code ownership). Каждый программист в коллективе XP должен иметь доступ к коду любой части системы и вносить изменения в любой код. Обязательное правило: если программист внес изменения и система после этого работает некоррект но, то именно этот программист должен исправить ошибки. В против ном случае работа системы уподобится тотальному хаосу.

Частая смена версий (small releases). Минимальная итерация – один день, максимальная – месяц;

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

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

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

Тестирование (testing). В отличие от большинства остальных ме тодологий тестирование в XP – одно из важнейших составляющих. Экс тремальный подход заключается в том, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test – тест данного модуля;

та ким образом, в XP осуществляется regression testing (возвратное тести рование, «неухудшение качества» при добавлении функциональности).

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

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

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

8 Вычислительная техника как инструмент научной и практической деятельности. Вычислительный эксперимент В настоящее время складываются основы новой методологии науч ных исследований – математического моделирования и вычислительно го эксперимента. Сущность этой методологии состоит в замене исход ного объекта его математической моделью и исследовании современ ными вычислительными средствами математических моделей.

Понятия вычислительного эксперимента и математического моде лирования были введены в прикладную математику академиком А.А.

Самарским. В своей основополагающей статье [76] он определяет их как технологическую и научную составляющие единого подхода к ре шению сложных научно-технических проблем.

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

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

Рождение и становление методологии математического моделиро вания пришлось на конец 40-х – начало 50-х годов XX века и было обу словлено по крайней мере двумя причинами. Первым побудительным мотивом послужило появление компьютеров, которые избавили исследо вателей от огромной по объему рутинной вычислительной работы;

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

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

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

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

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

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

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


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

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

8.2 Организация и проектирование вычислительного эксперимента Процесс выполнения вычислительного эксперимента можно услов но разбить на следующие этапы [77].

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

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

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

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

4 этап: проведение расчетов на ЭВМ. Результат получается в виде некоторой цифровой информации, которую далее необходимо будет расшифровать. Точность информации при вычислительном экспери менте определяется: достоверностью модели, положенной в основу эксперимента;

правильностью алгоритмов и программ (проводятся предварительные «тестовые» испытания);

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

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

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

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

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

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

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

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

по максимальному значению относительных отклонений откли ков модели от откликов системы.

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

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

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

Каким образом может быть оценена устойчивость модели? Уни версальной процедуры проверки устойчивости модели не существует.

Разработчик вынужден прибегать к методам «для данного случая», час тичным тестам и здравому смыслу. Часто полезна апостериорная про верка. Она состоит в сравнении результатов моделирования и результа тов измерений на системе после внесения в нее изменений. Если резуль таты моделирования приемлемы, уверенность в устойчивости модели возрастает.

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

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

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

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

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

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


Особенности программного обеспечения 8. вычислительного эксперимента С точки зрения программирования, вычислительный эксперимент характерен тем, что для каждой модели необходимо решать большое число вариантов (варьируя определяющие параметры задачи) и, кроме того, изменять (уточнять) саму математическую модель. Эта особен ность – "многовариантность" и "многомодельность" – вычислительного эксперимента проявляется в многократных изменениях реализующей алгоритм программы, причем изменения касаются и структуры про граммы в целом, и отдельных ее частей [79].

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

Совершенно иначе обстоит дело в вычислительном эксперименте.

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

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

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

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

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

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

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

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

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

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

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

различные способы отражения эле ментов установки в математической модели;

методы, используемые при расчете;

геометрия (прямоугольная, сферическая), в которой выполня ется расчет;

точность вычислений;

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

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

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

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

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

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

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

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

8.6 Области применения вычислительного эксперимента Математическое моделирование традиционно развивается в недрах фундаментальных наук: механике и физике, для которых отмечается наивысший уровень теоретических исследований (другими словами, уровень математизации) [76].

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

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

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

Заключение В одной из своих статей в 2001 году Дж. Бэкус отметил, что ком пьютерная революция испытала три волны. Первая волна началась с коммерциализацией кремниевых чипов и продолжалась 10-15 лет. Вто рая волна связана с развитием технологий программного обеспечения и началась приблизительно в середине 80-х годов XX века. Третья волна началась в конце 90-х годов XX века и связана с развитием сетей и ис пользованием их для коммуникаций компьютеров. Информационные технологии и в настоящее время демонстрируют высокий потенциал развития. Однако в последнее время наметился ряд проблем, которые необходимо решить для сохранения темпов развития вычислительной техники.

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

В начале 21-го века рост производительности отдельных процессо ров замедлился. Это изменение объяснятся фундаментальными ограни чениями проектирования и изготовления интегральных схем, основан ных на технологии К-МОП, которые используются практически во всех сегодняшних процессорных кристаллах. Следствием этого стала совре менная тенденция изготовления кристаллов с несколькими процессора ми (ядрами процессоров), которые к настоящему моменту стали прак тически повсеместно распространены.

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

Если смотреть еще дальше, то оказывается, что появляющиеся тех нологии фотоники, энергонезависимой памяти, трехмерной компоновки интегральных схем (3D stacking), а также новые рабочие нагрузки, ори ентированные на обработку данных, обеспечивают новые притягатель ные возможности. Компоновка бескорпусных кристаллов на различных кремниевых подложках, по-видимому, является одним из наиболее эф фективных подходов к решению проблем проектирования высокопро изводительных вычислительных систем. Изначально технологии 3DSI применялись при проектировании реконфигурируемых компьютерных систем, но позже акцент был перенесен на традиционные высокопроиз водительные вычислительные системы. К настоящему моменту получе ны серьезные результаты в областях разводки питания и сигналов, управления температурным режимом, вертикальной интеграции моду лей и взаимосвязи модулей. На основе этих результатов появилась идея многослойных 3DSI, в которых каждый слой оптимизируется для под держки некоторой уникальной функции.

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

Появившийся сравнительно недавно термин «нанохранилище»

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

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

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

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

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

информационный поиск и создание механизмов индексирования для поисковых машин;

обеспечение мобильного мультимедиа;

построение мультиагентных интеллектуальных систем;

хранение сверхбольших массивов данных;

обработка естественных языков;

исследования в биоинформатике и др.

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

Комитет по поддержке роста производительности компьютеров (Committee on Sustaining Growth in Computing Performance) рекомендует обратить намного большее внимание на исследования и разработки, по священные совершенствованию параллельной обработки и переходу к параллельному компьютингу. Наивысшим приоритетом следует наде лить следующие направления исследований:

алгоритмы, допускающие параллельную обработку;

новые компьютерные «стеки» (приложения, языки программи рования, среды поддержки времени выполнения/виртуальные машины, операционные системы и архитектуры), которые по зволяют выполнять параллельные, а не последовательные про граммы, и которые эффективно управляют программным парал лелизмом, аппаратным параллелизмом, энергопотреблением, основной памятью и другими ресурсами;

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

параллельные компьютерные архитектуры, управляемые при ложениями, включая развитие однокристальных мультипроцес соров, традиционных архитектур с распараллеливанием по дан ным, архитектур, ориентированных на приложения, и совер шенно новых архитектур;

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

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

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

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



Pages:     | 1 |   ...   | 3 | 4 || 6 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.