Тема майского номера журнала Computer (IEEE Computer Society, Vol. 39, No. 5, May 2006) — будущие операционные системы и парадигмы программирования (Future Operating Systems and Programming Paradigms)
Эдвард Ли (Edward Lee) представил статью «Проблемы использования потоков управления» (The Problem with Threads). Параллельное программирование является трудным, тем не менее необходимо — технологи предсказывают, что будущее за параллельными архитектурами: многоядерными процессорами, мультипроцессами на кристалле (chip multiprocessor, CMP), поэтому, если стремиться к непрерывному наращиванию производительности, необходимо обеспечить возможность использования параллелизма в программах. Одним из возможных технических решений является автоматическое распараллеливание последовательных программ.
Почему параллельное программирование является трудным? Физический мир в высшей степени параллелен, и наша способность к выживанию зависит от способности воспринимать одновременно происходящее физические явления. Однако эта способность не распространяется на параллельные программы, поскольку абстракции, на которых основывается параллельное программирование, даже отдаленно не напоминают параллельность физического мира. Мы завязли в этих вычислительных абстракциях и забыли, что они не является непреложными.
В практике программирования общего назначения доминирует один подход к параллельному программированию — потоки управления (thread), или последовательные процессы с совместной памятью, которые составляют ключевую модель параллельности, поддерживаемую современными компьютерами, языками программирования и операционными системами. Многие используемые сегодня параллельные архитектуры общего назначения, например симметричные мультипроцессоры, являются непосредственной аппаратной реализацией абстракции потоков управления. В некоторых приложениях потоки управления можно использовать очень эффективно, например в так называемых явно (embarrassingly) параллельных приложениях, в которых, по существу, порождается несколько независимых процессов (например, PVM gmake или Web-серверы). Независимость этих процессов несколько облегчает программирование, и абстракция отображается скорее в понятие процесса, а не потока управления. Совместное использование памяти в таких приложениях основывается на абстракциях базы данных, а параллельность управляется механизмом транзакций. Однако клиентские приложения не так просты.
Потоки управления не являются единственной возможностью для параллельного программирования. В научных приложениях, в которых параллельное программирование обусловливается требованиями производительности, доминируют языковые расширения распараллеливания под управлением данных и библиотеки передачи сообщений (PVM, MPI и OpenMP). Компьютерные архитектуры, ориентированные на научные приложения, часто существенно отличаются от архитектур общего назначения. Например, в них обычно поддерживаются вектора и потоки. Однако даже в этой области написание параллельных программ остается утомительным делом. Несмотря на наличие гораздо лучших языков параллелизма по управлением данных доминируют языки Cи и Фортран.
В распределенном программировании абстракция потоков управления часто не является практичной, поскольку создание иллюзии разделяемой памяти обходится слишком дорого. Тем не менее, предприняты значительные усилия для создания механизмов распределенных вычислений, эмулирующих многопотоковое программирование. Например, технологии CORBA и .Net произрастают из объектно-ориентированных методов, при использовании которых программные компоненты взаимодействуют через прокси, ведущие себя так, как если бы они являлись локальными объектами с разделяемой памятью. Абстракция данных, присущая объектной ориентации, ограничивает пределы иллюзии разделяемой памяти, и такие методы зарекомендовали себя как достаточно целесообразные. Они делают распределенное программирование во многом похожим на многопотоковое программирование.
При программировании встроенных систем также часто используются модели распараллеливания, отличные от потоков управления. Программируемые архитектуры DSP (Digital Signal Processing — «цифровая обработка сигналов») часто являются VLIW-машинами (Very Large Instruction Word — «очень длинное командное слово»). В видеосигнальных процессорах часто комбинируются WLIW- и потоковая обработка. В сетевых процессорах обеспечивается явная аппаратная поддержка потоковых данных. Однако, несмотря на существенные инновации, на практике программные модели для этих областей остаются примитивными. Разработчики пишут низкоуровневый ассемблерный код, в котором используются конкретные аппаратные возможности, комбинируя этот код с кодом на языке Cи там, где эффективность не критична. Для многих встроенных приложений более важными являются надежность и предсказуемость, а не выразительность и эффективность. По мнению автора, для многих приложений, по существу, невозможно достичь надежности и предсказуемости при использовании потоков управления.
Однако основной проблемой параллельного программирования с использованием потоков данных является недетерминизм результирующей системы. В качестве характерного примера приводится ситуация, возникшая в системе Ptolemy II, которая разрабатывалась с 2000 года в группе автора статьи (ptolemy.eecs.berkeley.edu). Система представляет собой среду поддержки параллельных моделей вычислений. Система разрабатывалась с использованием потоков управления Java с синхронизацией на основе мониторов. Было выполнено тщательное проектирование и тестирование. Система использовалась многими исследователями и до 2004 года несколько лет в ней не наблюдалось каких-либо ошибок. Однако в 2004 году в системе возник синхронизационный тупик. Автор приходит к заключению, что с помощью тестирования никогда не удастся обнаружить все проблемы в нетривиальном многопотоковом коде.
Для достижения детерминированного выполнения параллельных программ требуются другие подходы — вместо того, чтобы рассчитывать на то, что недетерминированность будет устранена программистом, следует опираться на детерминированные, компонуемые механизмы и прибегать к недетерминизму только в случае необходимости. В статье приводится несколько механизмов, позволяющих придать детерминированность поведения программам, которые оказываются недетерминированными при использовании потоков управления. По мнению автора, эти подходы обеспечивают часть решения общей проблемы. Однако сомнительно, чтобы хотя бы один из них стал доминирующим подходом.
Синтаксически потоки управления поддерживаются либо за счет незначительных расширений этих языков (как в случае Java), либо за счет всего лишь внешней библиотеки. С точки зрения семантики такие расширения полностью подрывают детерминизм этих языков.
К сожалению, похоже, что на программистов больше влияет синтаксис, а не семантика. Укоренившимся альтернативам потоков управления (например, MPI и OpenMP) присуще то же свойство — они не привносят в языки синтаксические изменения. Альтернативы, заменяющие традиционные языки (такие, как Erlang (www.erlang.org) и Ada), не прижились. Даже языки с незначительными синтаксическими изменениями (например, Split-C (www.eecs.berkeley.edu/Research/Projects/CS/parallel/ castle/split-c/split-c.tr.html) и Cilk (supertech.csail.mit.edu/papers/cilkjpdc96.pdf)) остаются известными лишь для посвященных.
Не следует стараться заменить установившиеся языки — нужно основываться на них. Однако недостаточно использования только библиотек. Библиотеки не обеспечивают должной структурированности, навязывания паттернов и возможностей композиции. Правильный ответ состоит в использовании языков взаимодействий (coordination language), называемых также языками компоновками (composition language), которые обладают новым синтаксисом. Однако этот синтаксис служит целям, ортогональным целям установившихся языков программирования. В то время, как параллельные языки общего назначения (например, Erlang или Ada) должны включать синтаксические конструкции для выражения традиционных операций, таких как арифметические выражения, язык взаимодействий не обязан обеспечивать возможность спецификации чего-либо отличного от взаимодействий. Возможно, со временем удастся создать масштабируемый и эффективный визуальный язык, подобно тому, как некоторые части языка UML удалось использовать для объектно-ориентированного программирования. Или же можно представить масштабируемый текстуальный синтаксис, пригодный для спецификации таких же структур.
Языки взаимодействий существуют уже долгое время, но и им тоже не удалось укорениться. Одной из причин является то, что они не обеспечивали однородности. Превалирующей мнением в среде исследователей языков программирования является то, что любой достойный язык программирования должен быть языком общего назначения. Как минимум, он должен быть настолько выразительным, чтобы для него можно было сделать компилятор. Однако лед разбил UML, который запросто комбинируется с C++ и Java. Программисты начали признавать совместное использование нескольких языков, особенно если эти разъединенные языки обеспечивают взаимно дополняющие возможности.
В языках взаимодействий должны развиваться средства масштабируемости и модульности, аналогичные тем, которые имеются в традиционных языках.
Статью «Можем ли мы сделать операционные системы надежными и безопасными» («Can We Make Operating Systems Reliable and Secure?») написали Эндрю Таненбаум, Джоррит Хердер и Херберт Бос (Andrew S. Tanenbaum, Jorrit N. Herder и Herbert Bos). В современных операционных системах имеются две характеристики, делающие их ненадежными и небезопасными: они огромны и обладают очень плохой изоляцией сбоев.
Авторы статьи рассматривают четыре подхода, используемые исследователями для придания будущим операционным системам более высокого уровня надежности и безопасности. Наиболее консервативным является подход проекта Nooks (www.cs.rochester.edu/sosp2003/papers/ p116-swift.pdf), направленного на повышение надежности существующих операционных систем (таких, как Windows и Linux). В Nooks поддерживается монолитная структура ядра, но ядро защищается от содержащих ошибки драйверов устройств путем обертывания каждого драйвера уровнем защитного программного обеспечения. Оболочка драйвера тщательно отслеживает все взаимодействия между драйвером и ядром. Целями проекта Nooks являются защита ядра от сбоев драйверов, автоматическое восстановление после отказа драйвера и достижение всего этого путем небольших изменений в существующих драйверах и ядре. Первая реализация была выполнена для Linux, но идеи применимы и к другим унаследованным операционным системам.
Хотя эксперименты показали, что Nooks может перехватить 99% фатальных ошибок драйверов и 55% прочих, система не является совершенной. В драйверах могут выполняться привилегированные команды, которым в них выполняться не полагается; в них может производиться запись в неверные порты; в них могут возникать бесконечные циклы. Группе Nooks пришлось вручную написать большое число оболочек драйверов, и в них самих могут содержаться ошибки. Тем не менее, этот проект является потенциально полезным шагом к повышению надежности унаследованных операционных систем.
Второй подход произрастает из концепции виртуальной машины. В проекте, выполняемом в Университете Карлсруэ, идея виртуальных машин применяется к обеспечению защиты внутри одной операционной системы (i30www.ira.uka.de/research/documents/l4ka/2004/ LeVasseur04UnmodifiedDriverReuse.pdf). Кроме того, в операционной системе допускаются изменения, гарантирующие, что она не делает ничего, что не может быть виртуализировано. Для отличия от истинной виртуализации этот подход был назван паравиртуализацией. Идея состоит в том, чтобы на одной из виртуальных Linux-машин выполнялись прикладные программы, а на других — драйверы устройств. При крахе драйвера из строя выходит только его виртуальная машина. Дополнительным преимуществом является то, что не требуется модификации драйверов, поскольку они остаются в обычной среде ядра Linux. Конечно, для достижения паравиртуализации требуется модификация самого ядра Linux, но это делается один раз для всех виртуальных машин. Измерения производительности показывают, что накладные расходы на использование паравиртуальных машин в такой манере составляют 3-8%.
Следующие два подхода ориентированы на создание будущих надежных систем. В операционной системе Minix 3 (www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf) микроядро обрабатывает прерывания, обеспечивает основные механизмы для управления процессами, реализует межпроцессные взаимодействия и производит планирование процессов. Оно также предоставляет небольшой набор вызовов ядра для авторизованных драйверов и серверов, например для чтения части заданного пользовательского адресного пространства или записи в авторизованные порты ввода/вывода. В адресном пространстве микроядра работает драйвер таймера, но он планируется как отдельный процесс. Никакие другие драйверы в режиме ядра не работают.
Над уровнем микроядра находится уровень драйверов устройств. Для каждого устройства ввода/вывода имеется собственный драйвер, выполняемый в виде отдельного процесса в собственном адресном пространстве, защищенном аппаратурой устройства управления памятью. Драйверы работают в пользовательском режиме и не могут исполнять привилегированные команды, а также читать из портов или писать в них. Для получения последней возможности они должны производить вызовы ядра. Такая конструкция повышает надежность, хотя и порождает небольшие дополнительные расходы.
Поверх уровня драйверов устройств располагается уровень серверов. Файловый сервер является небольшой программой, которая принимает запросы от пользовательских процессов по обработке Posix-совместимых вызовов, относящихся к файлам, и выполняет их. На этом уровне находится и менеджер процессов, который поддерживает управление процессами и памятью и выполняет Posix-совместимые системные вызовы (fork, exec и brk). Сервер реинкарнации является родительским процессом всех других серверов и драйверов. Если драйвер или сервер аварийно или по собственной инициативе завершается или не отвечает на периодические запросы, то сервер реинкарнации принудительно завершает его, если это требуется, и перезапускает из копии на диске или в основной памяти. В число других серверов входит сервер сети, поддерживающий весь стек TCP/IP; простой сервер имен, используемый всеми остальными серверами; информационный сервер, способствующий отладке.
Наконец, над уровнем серверов находятся пользовательские процессы. Для пользователей единственным отличием от других Unix-систем является то, что библиотечные процедуры для системных вызовов выполняют свою работу путем посылки сообщений серверам. Во всем остальном это обычные пользовательские процессы, в которых может использоваться API Posix.
Межпроцессные взаимодействия (IPC) в MINIX 3 поддерживаются на основе передачи сообщений фиксированной длины с использованием принципа рандеву: система копирует сообщение напрямую от отправителя к получателю, когда оба они к этому готовы. Кроме того, поддерживается механизм асинхронного уведомления о событиях. События, о которых оказалось невозможно уведомить процесс, фиксируются в битовой шкале в таблице процессов. С системой передачи сообщений интегрирована обработка прерываний.
Небольшой размер ядра Minix 3 (около 4000 строк) позволяет верифицировать его код вручную или на основе формальных методов. Особенности IPC позволяют избежать управления буферами в ядре. Кроме того, для каждого процесса ограничены доступные примитивы IPC, включая адреса назначения и события, о которых происходит уведомление. Все структуры ядра являются статическими. Эти свойства значительно упрощают код и устраняют ошибки в ядре, связанные с переполнением буферов, «утечку памяти» (memory leak), несвоевременные прерывания и т.д.
В течение десятилетий мультисерверные архитектуры на основе микроядра критиковались за недостаточную эффективность. Однако различные проекты показали, что при модульной разработке можно достичь приемлемой производительности. Несмотря на то что система Minix 3 не оптимизировалась для достижения высокой производительности, она работает достаточно быстро. Вынос с ядра драйверов привел к снижению производительности на 10%, и система собирается, включая ядро, общие драйверы и все серверы (112 компиляций и 11 редактирований связей) менее чем за 6 секунд на процессоре Athlon с 2,2 ГГц. Тот факт, что мультисерверная архитектура смогла обеспечить высоконадежную Unix-подобную среду за счет небольшого снижения производительности, показывает практичность этого подхода. Minix 3 для Pentium свободно распространяется под лицензией Беркли на сайте www.minix3.org.
Наиболее радикальный подход предложен в Microsoft Research. Система, называемая Singularity (research.microsoft.com/os/singularity), пишется почти целиком на новом типизированном языке Sing#. Этот язык основан на C#, но дополнен примитивами передачи сообщений, семантика которых определяется формальными, письменными контрактами. Поскольку безопасность языка строго ограничивает поведение системы и процессов, все процессы выполняются в едином виртуальном адресном пространстве. Эта схема обеспечивает и безопасность, и эффективность. Кроме того, схема Singularity является гибкой, поскольку каждый процесс является замкнутым объектом и потому обладает собственным кодом, структурами данных, распределением памяти, подсистемой времени выполнения, библиотеками и сборщиком мусора. Устройство управления памятью используется только для отображения страниц, а не для образования отдельной защищенной области для каждого процесса. Ключевым принципом организации Singularity является запрещение динамических расширений процессов. В частности, не допускаются загружаемые драйверы и подключаемые модули браузеров. Такие расширения должны запускаться как отдельные процессы.
ОС Singularity состоит из процесса микроядра и набора пользовательских процессов, обычно исполняемых в общем виртуальном адресном пространстве. Микроядро управляет доступом к аппаратуре, выделяет и освобождает память, создает, ликвидирует и планирует потоки управления, управляет синхронизацией потоков управления, управляет межпроцессной синхронизацией с использованием каналов и управляет вводом/выводом. Каждый драйвер устройства выполняется в отдельном процессе.
Пользовательские процессы получают системные услуги путем посылки строго типизированных сообщений в микроядро через двухточечные каналы. В отличие от других систем передачи сообщений, в которых поддерживаются библиотечные функции SEND и RECEIVE, в Sing# полностью поддерживаются каналы на уровне языка, включая формальную типизацию и спецификации протокола.
В Singularity поддерживается совместно используемая процессами «куча» объектов, но в каждый момент времени каждый объект из кучи принадлежит только одному процессу. Однако владение объектом может быть передано другому процессу через канал. Например, когда драйвер диска считывает блок, он помещает этот блок в кучу. Потом система передает дескриптор (handle) этого блока процессу, запросившему данные, поддерживая принцип единственного владельца, но позволяя передавать данные без копирования.
Для каждого компонента системы имеются метаданные, описывающие его зависимости, экспортирование, ресурсы и поведение. Эти метаданные используются для верификации. Образ системы состоит из микроядра, драйверов и приложений, требуемых для выполнения системы, и их метаданных. Внешние верификаторы могут выполнить многочисленные проверки образа до запуска системы; в частности, таким образом можно убедиться в том, что драйверы не конфликтуют по ресурсам.
Статья «Обеспечение масштабируемости в системах реального времени» («Achieving Scalability in Real-Time Systems») написана Джорджио Буттаццо (Giorgio Buttazzo). Большинство встроенных компьютерных систем, включая мобильные телефоны, переносные компьютеры, сенсорные сети и т.д., питается от батарей. К сожалению, высокая производительность и долгий срок службы батарей являются конфликтующими требованиями. Для достижения высокой производительности система должна функционировать на высокой скорости, что приводит к большему энергопотреблению, а для достижения большого срока службы батарей требуется, чтобы система потребляла меньше энергии.
Хотя многие исследователи обращались к проблеме сокращения энергопотребления в системах реального времени, проблема масштабирования производительности при изменении скорости требует дальнейшего изучения. В предлагаемой автором вычислительной модели время отклика меняется непрерывно при изменении скорости процессора, что позволяет системе предсказуемым образом масштабировать свою производительность при изменении напряжения. На уровне ядра в этой модели реализуются два ключевых механизма. Наличие неблокирующих коммуникационных буферов предотвращает аномалии планирования, вызываемые изменениями скорости, и позволяет обмениваться данными периодическим задачам с негармоническими отношениями периодов. Для борьбы с долговременными перегрузками, вызываемыми уменьшением скорости, применяется гибкое планирование задач, при котором скорости задач согласовываются на основе набора коэффициентов, назначаемых разработчиков на стадии проектирования на основе важности задач. Опыт автора показывает, что оба механизма можно легко реализовать поверх любой операционной системы реального времени в качестве слоя промежуточного программного обеспечения, и их следует включить в текущие стандарты разработки встроенных систем, удовлетворяющих требованиям реального времени и энергопотребления.
Последняя статья майского номера (Andrew Rae, Colin Fidge, Luke Wildman) называется «Анализ неисправностей коммуникационных устройств, критичных для безопасности» («Fault Evaluation for Security-Critical Communications Devices»). Коммуникационные устройства, способствующие защите секретной информации в правительственных и военных сетях, должны обладать высокой безопасностью. Обеспечение приемлемого уровня надежности является очень трудной задачей, для решения которой требуется анализ всех последствий каждого сбоя. В свою очередь, для этого нужен детальный анализ схемы и конструкции устройства, являющийся трудоемким и чреватым ошибками делом. Например, устройство разграничения доменов, допускающее потоки управляющей информации между сетями с разными уровнями безопасности, может включать десятки компонентов, сбои которых могут влиять на безопасность информации. К числу устройств разграничения доменов относятся диоды данных (data diode), допускающие потоки данных только в одном направлении; мультикомпьютерные коммутаторы, дающие возможность совместного использования периферийных устройств из разных доменов безопасности; контекстные фильтры, ограничивающие информационные потоки; криптографические устройства, позволяющие передавать секретную информацию в небезопасных сетях.
Международные стандарты, такие как Common Criteria for Information Technology Security Evaluation, обеспечивают инфраструктуру и инструментальные средства анализа безопасности, но предоставляют недостаточное техническое руководство для высококачественного анализа. Полезны и традиционные методы анализа схемотехники, но их оказывается недостаточно для проведения анализа безопасности. С точки зрения безопасности основное беспокойство причиняют не катастрофические отказы, поскольку неработающее коммуникационное устройство не может допустить утечку секретной информации, а проверка скрытых сбоев, которые нарушают функцию безопасности устройства способом, неочевидным для оператора. Поэтому в коммуникационном устройстве исключительно чувствительной среды (правительственной или военной сети) могли бы содержаться специальные механизмы, проверяющие, что устройство работает безопасно. К сожалению, таким механизмам часто свойственны собственные проблемы безопасности.
Определение последствий индивидуальных сбоев является трудоемким, но простым процессом. Сложность проблемы экспоненциально возрастает, если задача состоит в идентификации составных сбоев, когда несколько по отдельности безобидных сбоев при одновременном возникновении создают небезопасную ситуацию. Опасность составных скрытых сбоев состоит в том, что необнаруженный скрытый сбой может не проявляться до тех пор, пока он не станет частью составного сбоя. Даже если сбои индивидуальных компонентов возникают редко, это сильно повышает вероятность составных сбоев. Кроме того, все коммуникационные устройства различаются, и качество анализа безопасности информации зависит от навыков и опыта аналитика. Очевидно, что чудодейственного решения не существует. Однако правильно определенный процесс анализа может повысить эффективность задачи распознавания сбоев и обеспечить инфраструктуру для производства более отчетливых, более информативных отчетов о безопасности. С этой целью авторы выработали строгий способ структуризации поиска разных видов нарушений информационной безопасности, в котором сочетаются методы информационных потоков и анализа рисков.
Игры и образование
Тема июньского номера журнала Computer ((IEEE Computer Society, Vol. 39, No. 6, June 2006) — «Проектирование и разработка игр в образовании» (Game Design and Development in Education). Номер предваряется вводной заметкой приглашенного редактора Майкла Зайды (Michael Zyda) — «Обучение следующего поколения разработчиков игр» (Educating the Next Generation of Game Developers). Зайда отмечает, что происходящая революция в области видеоигр, используемых как для развлечения, так и в серьезных целях, порождает требование к повышению технологического уровня проектирования и разработки игр на основе университетских исследовательских и образовательных программ. Для удовлетворения этого требования во многих университетах образованы бакалаврские и магистерские учебные программы, концентрирующиеся на проектировании и разработке игр.
Автор обсуждает особенности бакалаврской и магистерской образовательных программ, ориентированных на область проектирования и разработки игр. В качестве примера используются соответствующие программы, разработанные и внедренные в образовательный процесс в Университете Южной Калифорнии. В частности, отмечается, что получить такую степень труднее, поскольку она является междисциплинарной.
Первая тематическая статья называется «Игровое обучение играм» (Play-Centric Games Education) и представлена Трэси Фаллертон (Tracy Fullerton). За последние два десятилетия индустрия интерактивных развлечений настолько выросла, что может конкурировать с Голливудом по объему рынка и воздействию на культуру. Оборот индустрии игр ежегодно возрастает на десятки миллиардов долларов. В области развлечений игры занимают второе место после телевидения. Для полной реализации выразительных возможностей этих сложных платформ и удовлетворения потребностей в более интересных и увлекательных игровых приключениях индустрия нуждается в новом поколении разработчиков и авторов визуальных сценариев. Несколько лет назад в Школе кино и телевидения Университета Южной Калифорнии была введена магистерская программа в области изящных искусств, ориентированная на подготовку визуальных коммуникаторов. Эта очень успешная программа ясно показала, что, несмотря на технологические различия, между старыми и новыми медиасредствами имеется значительное сходство и что все студенты получают пользу от междисциплинарного сотрудничества.
Дженет Мюррей, Ян Богост, Майкл Матеас и Майкл Ницше (Janet Murray, Ian Bogost, Michael Mateas, Michael Nitsche) представили статью «Обучение разработки игр: интеграция вычислений и культуры» (Game Design Education: Integrating Computation and Culture). Область электронных игр быстро растет как новая форма культуры, как набор медиатехнологий и как глобальная индустрия. Специалисты-гумманитарии относятся к этим играм как к новому выразительному жанру, подобному драме, опере или кино; социологи рассматривают игры как новую форму коллективного поведения; компьютерные специалисты, инженеры и разработчики считают их новым центром изобретательской деятельности. В целях активного междисциплинарного обсуждения различных аспектов электронных игр появились новые академические журналы Game Studies и Games and Culture, конференции Serious Games и Living Game Worlds, исследовательская ассоциация Digital Games Research Association и блоги GrandTextAuto.org и ludology.org.
Индустрии требуется все большее число выпускников университетов, подготовленных не как универсальные программисты, художники или продюсеры, а как специалисты в конкретных технологиях и методах, используемых при производстве современных игр, пользующихся наибольшим спросом. Университеты отреагировали на это требование путем создания образовательных программ двух категорий: производство игр и исследование игр. В Техническом университете штата Джорджия предлагается третья категория образовательных программ, в которых интегрируются технические и культурологические знания и исследуются выразительные возможности игр. Подход этого университета основывается на гуманистических концепциях, связывающих эту развивающуюся среду с многовековыми традициями человеческой культуры.
У статьи «Создание программы разработки игр» (Building a Game Development Program) семь авторов, все из Денверского университета. Первый в списке — Лоренс Аджент (Lawrence Argent). Две новые профилирующие дисциплины университета опираются на компьютерную науку, исследования в области цифровых носителей информации, электронные медиаискусства и студийное искусство. При создании программы преследовались следующие цели: развитие гуманитарной значимости игр; содействие полностью интеллектуальному образованию (развитие у студентов аналитического и творческого мышления); увеличение числа учебных дисциплин в области компьютерной науки и разработка технически строгой профилирующей дисциплины; возможность занятий на стыке компьютерной науки, области цифровых носителей информации, электронного и студийного.
Последняя статья тематической подборки называется «Развитие художника-технолога» (Evolving the Artist-Technologist). Ее написали Ян Хорсвилл и Марлена Новак (Ian Horswill, Marlena Novak). За последние полвека роль компьютеров сместилась от поддержки науки и инженерии к поддержке бизнеса, а в последние годы — к поддержке общения в целом. Компьютеры играют центральную роль в создании культурных артефактов в качестве либо самой среды, либо средства производства. Тем не менее искусство и компьютеры поразительно плохо интегрированы; у людей из одной области практически отсутствует подготовка в другой области. В индустрии игр это приводит к появлению коллективов разработчиков, члены которых не могут взаимодействовать, а менеджеры не понимают своих подчиненных. Хотя программисты могут получить подготовку в области искусства, а художников можно научить программировать, часто это происходит слишком поздно — уже успели сложиться стереотипы мышления.
Программа живых искусств Северо-Западного университета направлена на подготовку прогрессивных художников-технологов, которые смогут навести мосты между искусством и компьютерами. Цель состоит в привлечении студентов колледжей и их подготовке по интегрированным программам, охватывающим базовые принципы новой среды. Выпускники должны обладать знанием всех дисциплин, имеющим отношение к искусству и компьютерам, безотносительно к их будущей специализации. Хотя программа живых искусств не ориентирована исключительно на разработку игр, на лекциях часто используются примеры игры для обучения программированию и приемам совместной работы.
Единственная большая статья номера, представленная вне тематической подборки, написана Аденеканом Дедеке и Беном Диберманом (Adenekan Dedeke, Ben Lieberman) и называется «Уточнение ассоциаций в диаграммах сценариев использования» (Qualifying Use Case Diagram Associations). В методологии объектно-ориентированной программной инженерии (object-oriented software engineering, OOSE) требования к системам определяются в виде ориентированных на потоки сценариев использования. В процессе OOSE создается формальное описание проблемы, а затем разрабатываются сценарии использования, чтобы зафиксировать функциональные требования к предлагаемой системе. В отличие от традиционно используемых иерархически структурированных постановок (например, «система должна…»), в этой форме определения требований поведение системы представляется в виде, понятном заказчикам и другим заинтересованным сторонам. В соответствии с подходом OOSE сценарии должны использоваться на протяжении всего процесса разработки. Они играют важную роль на стадиях анализа, проектирования, реализации и тестирования. У сценариев использования имеются пять заинтересованных сторон: заказчики, системные и бизнес-аналитики, системные архитекторы и разработчики, инженеры по тестированию программного обеспечения и контролю качества, менеджеры проекта. При наличии интереса к подходу сценариев ему свойственны очевидные проблемы.
Информация должна предоставляться разнородной группе людей на разных фазах проекта. Например, в начале проекта сценарий использования должен полностью описывать поведение системы, но оставаться достаточно простым для понимания заказчиками. Кроме того, сценарий использования должен корректно и полностью описывать проблемную область, требования к системе и ожидания заказчиков. В текущей практике исходная модель сценариев использования описывает предлагаемую систему на относительно высоком концептуальном уровне.
На фазах проектирования и анализа модель требований сценариев использования становится базисом для выявления анализируемых и проектируемых классов и подсистем. Они создаются на основе процесса приписывания поведения объектам, извлекаемым из модели сценариев использования. На фазе реализации разработчики используют спроектированные классы и подсистемы в качестве основы для разработки кода, данных и вычислительных взаимодействий системы. Наконец, на фазе тестирования модель требований сценария использования образует базис для тестовых сценариев, обеспечивая соответствие реализации исходным бизнес-требованиям.
Избежать путаницы помогает применение метамодели при генерации требований на основе диаграммы использования. Метамодель описывает элементы, составляющие набор артефактов, которые входят в спецификацию решения. Спецификация решения включает словесное описание сценариев использования, диаграмму сценария использования и модель проблемной области. На концептуальном уровне диаграмма сценария использования обеспечивает абстрактное отображение среды и внешних действующих сил на группы функциональных требований, выражаемых в виде сценариев поведения. На этом уровне аналитик стремится к получению понимания области проблемы, которому могут помешать низкоуровневые детали. На уровне спецификаций диаграмма сценария использования представляет связь между внутренними объектами и функциональными требованиями к предлагаемой системе. На этом уровне аналитик в основном стремится к определению того, какие внутренние объекты являются истинными.
При использовании концептуальных диаграмм сценариев использования акцентирование взаимодействий внешних действующих сил сквозь границу систем, а не внутренних аспектов диаграмм является хотя и полезным, но слишком узким. Для повышения значимости концептуальных диаграмм сценариев системные аналитики могут подготовить набор уточненных диаграмм. Путем уточнения маршрутов коммуникации аналитики могут быстрее обнаруживать бизнес-объекты, соответствующие функциональным требованиям.
Для создания уточненной диаграммы сценариев использования системный или бизнес-аналитик должен выполнить две задачи: разработать концептуальную диаграмму сценариев использования для внешних функциональных требований; проанализировать концептуальную диаграмму и выявить внутренние объекты, которые могли бы быть извлечены экспертами из проблемной области. К преимуществам уточненных диаграмм сценариев использования авторы относят следующее. Архитекторы, разработчики и аналитики получают лучшее понимание связи между объектами предметной области и функциональными требованиями на ранней стадии проекта. Демонстрация потенциальных объектов системы на основе представления аналитика проблемной области может внести объектную ориентированность в метод, ориентированный на функциональную декомпозицию диаграмм сценариев использования. Удастся устранить семантическую неточность, свойственную концептуальным диаграммам сценариев использования. Уменьшится вероятность того, что при разделении проекта между группами усиливаются негативные аспекты функциональной декомпозиции.
С уважением, Сергей Кузнецов, kuzloc@ispras.ru.
