Maya для начинающих

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

Предисловие
Творческий рост происходит постепенно. На каждом этапе художнику нужен маленький толчок, для того чтобы прийти к новым идеям. Но где же мастера черпают свое вдохновение? Где он - источник настоящей новизны? Настоящее вдохновение не может быть куплено или усилено, но его всегда можно найти в словах и иллюстрациях книги. Такой, как эта. Заплатив сумму, по которой вы обычно покупаете продукты, начинающий Мауа-мастер сможет надеть маленькие крылатые сандалии и взлететь на творческую высоту!

Введение
Новая книга не содержит никаких основ, только острова удовольствия. Если вы знакомы с интерфейсом Мауа, то, как и я, будете наслаждаться этими уроками. В основе каждой главы лежит обычный вопрос в том виде, в каком он приходит в голову: Как скатить мяч с горы? Как получить тень от березы (с трепетанием всех листьев и веток) внутри моей скучной трехмерной комнаты? Как получить извержение вулкана?

Анимация
Первый урок, кстати, самый простой в этой книге. Может быть, задача переворачивания страницы трехмерной книги покажется вам банальной и даже скучной. Я думал точно так же, пока не предложил это задание десяти студентам университета в классе 3D анимации. Я дал им 30 минут на то, чтобы смоделировать лист бумаги и перевернуть его справа налево.

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

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

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

Cамоучитель по Maya 6

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

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

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

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

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

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

Дополнительные приемы моделирования
Как вы имели возможность убедиться в предыдущих главах при изучении полигонального моделирования и моделирования на основе неоднородных рациональных сплайнов Безье, деформаторы играют большую роль при создании и редактировании формы объектов. Например, нелинейный деформатор Bend (Изгиб) вызывает изгиб объекта, к которому он присоединен. Это простая деформация. Более сложное воздействие можно получить, например, с помощью деформатора Lattice (Решетка).

Материалы и текстуры
Назначение материалов подразумевает присвоение объекту видимого при визуализации цвета, рельефа, прозрачности, зеркальных бликов и других характеристик поверхности. С этим процессом тесно связано назначение текстур, то есть Процесс сопоставления определенного рисунка выбранному атрибуту материала. Этот способ позволяет даже имитировать детали на поверхности объекта. Например, назначив атрибуту Color (Цвет) изображение кирпичей, вы, по сути, назначите материалу карту текстуры. Назначение еще одной отсканированной фотографии с изображением впадин и выпуклостей той же самой кирпичной стены атрибуту Bump Mapping (Карта рельефа) также рассматривается как назначение текстуры

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

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

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

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

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

Программирование стратегических игр с DirectX 9.0

Привет и добро пожаловать в восхитительный мир программирования стратегических игр! Стратегия всегда была одинм из моих любимых игровых жанров. Ничто в игровом мире не сравнится с длительной стратегической игрой с другом или противником.
Как новичок или начинающий разрвботчик, вы вероятно задаетесь вопросом о том, как создаются подобные игры. Хотя есть множество составляющих, и разработка игры представляет собой длительный процесс, есть некоторые базовые компонеты, о которых я расскажу в этой книге:
Механика игры
Планирование проекта
Блочная графика
Дизайн и разработка интерфейса
Воспроизведение звука
Контроль и управление соединениями
Инструментальные средства разработчика
Трехмерная анимация
Мнногопользовательская игра
Как вы можете видеть, просмотрев список тем, книга охватывает широкий диапазон тем, относящихся к программированию стратегических игр. Вы можете воспринимать эту книгу как набор строительных блоков для разработчика. Каждая тема, или блок, могут рассматриваться отдельно, а соединенные вместе эти блоки дают великолепный результат.

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

Ранние стратегии реального времени
Также, как история древних веков содержит много загадок, прошлое стратегических игр реального времени не является полностью ясным. Многие люди утверждают, что первая стратегия реального времени — это Dune от Westwood, но я вспоминаю намного более ранние примеры игр этого жанра.

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

Загрузка текстур
Буфер вершин полностью наряжен, но пока нет места куда он мог бы пойти. Как насчет нескольких текстур? Оставшаяся часть кода инициализации осуществляет загрузку текстур, необходимых программе TitleScreen. Для загрузки текстур я использую функцию D3DXCreateTextureFromFile() предоставляемую вспомогательной библиотекой DirectX. Вот как выглядит ее прототип:
HRESULT D3DXCreateTextureFromFile( LPDIRECT3DDEVICE9 pDevice, LPCSTR pSrcFile, LPDIRECT3DTEXTURE9 *ppTexture );

Самоучитель по введению в экспертные системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решение проблем конструирования (II)
В предыдущей главе мы рассматривали экспертные системы для решения проблем конструирования, в которых по ходу процесса никогда не возникала необходимость отмены уже принятых решений. Однако такая стратегия подходит далеко не для всех задач конструирования, поскольку мы не всегда располагаем всеми необходимыми для этого знаниями о предметной области. В этой главе мы проанализируем применение двух стратегий — наименьшего принуждения (least commitment) и предложение и пересмотр (propose and revise). Завершит главу обзор некоторых инструментальных средств приобретения знаний, которые используются в системах решения проблем конструирования

Системы с доской объявлений
В последние годы в разработке архитектуры экспертных систем появилось новое направление, которое получило название системы с доской объявлений (blackboard sys-tems)u. Системы с такой архитектурой могут эмулировать режим построения как прямой цепочки логического вывода, так и обратной, а также попеременно применять эти режимы в процессе работы. Кроме того, применение систем с доской объявлений побуждает инженеров по знаниям к иерархической организации и знаний относительно предметной области, и пространства частичных и полных решений. Таким образом, эта архитектура очень хорошо подходит для решения задач проектирования, для которых характерно большое, но факторизуемое многомерное пространство решений.

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

Формирование знаний на основе машинного обучения
В главе 1 мы уже вскользь упоминали о связи между приобретением знаний экспертной системой и использованием автоматизированных методов формирования знаний на базе машинного обучения (machine learning). Было отмечено, что в ряду тех проблем, с которыми сталкивается разработчик экспертной системы, приобретение знаний является одной из наиболее трудоемких. В главе 10 было рассмотрено множество методов извлечения знаний, но ни один из них не позволяет избавиться от услуг человека-эксперта и соответственно от значительного объема работы, выполняемой "вручную".

Сети доверия
В этой главе мы рассмотрим два количественных метода реализации логических рассуждений при наличии неопределенности в структурированном пространстве гипотез, базирующихся на теории свидетельств Демпстера—Шефера [Gordon and Shortliffe, 1985] и Байесовском формализме [Pearl, 1986]. Каждый из этих подходов предполагает, что на множестве гипотез каким-то способом определена функция доверия (belieffunction), а затем по мере накопления новых свидетельств применяется специфический механизм обновления текущего множества допущений.

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

Гибридные системы
Раньше уже неоднократно высказывалась идея, что экспертная система может содержать не одну форму представления знаний. Даже в таких ранних системах, как MYCIN (см. главу 3), информация, специфическая для предметной области, хранилась в разных формах — например, в виде порождающих правил и в виде таблиц медицинских параметров. Программы, аналогичные CENTAUR (см. главу 13), уже можно было считать гибридными в том смысле, что в них объединялись разные способы представления знаний, а затем эти знания использовались с разной целью — для решения проблемы и формирования пояснений.

Загадки искусственного интеллекта
Тема искусственного интеллекта всегда была в информатике "страной плохишей", населенной массой "неправильных" проблем, не поддающихся решению традиционными способами. Эта область привлекла внимание прежде всего разносторонних специалистов, которых не испугало ее открытое, лишенное всякой организации пространство, — людей, которых влечет задача узнать, как мы мыслим. Такие исследователи, как Марвин Минский (Marvin Minsky), Джон Мак-Карти (John McCarthy), Герберт Саймон (Herbert Simon), Пат Хейес (Pat Hayes), Дональд Мичи (Donald Michie) и Бернард Мельтцер (Bernard Meltzer), стали первопроходцами для тех, кто следовал за ними по пути, пролегающем через информатику, психологию и математическую логику.

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

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

Литература

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

Управление проектами

Современные процессы разработки программного обеспечения, такие как Rational Unified Process (RUP), Extreme Programming (XP) и Scrum, являются эволюционными по своей природе, и многие из них – быстрые (agile). При применении эволюционного подхода вы работаете одновременно в итерационной и инкрементальном режимах; быстрый подход сочетает эволюционность с высоким уровнем сотрудничества. Работая в итерационном режиме, вы в каждый момент времени немного моделируете, немного тестируете, немного кодируете и немного развертываете, потом еще немного, и еще немного, и т.д. При использовании инкрементального подхода вы организуете свою систему в виде последовательности выпусков, а не одного большого выпуска. Когда группа разработчиков прибегает к коллаборативному подходу, ее участники активно стараются найти способы эффективной совместной работы; следует даже добиваться того, чтобы инициаторы проекта (заказчики системы) являлись активными членами группы.

Быстрые методы для объектных баз данных
Скотт Амблер – известный, судя по Internet, специалист в области методологий разработки программного обеспечения. Его даже называют “гуру” быстрых (agile) методов разработки. Сам он ассоциирует себя с двумя компаниями – Ambisoft и Robin International – и называет себя старшим консультантом в обеих компаниях. Судя по фотографиям, Амблер достаточно молодой человек, а судя по числу написанных и изданных им книг, а также объему подготовленных им материалов, размещенных на www.ambysoft.com, исключительно активный. Статью, перевод которой мы вам предлагаем, Амблер написал специально для портала (хотя, похоже, что в этом его стимулировала компания db4objects, о которой мы еще поговорим).

Антипаттерны руководства командами разработки ПО
Некоторые руководители программных проектов, в первую очередь начинающие, в работе с людьми постоянно наступают на одни и те же грабли. В компьютерной науке для подобных частонаступаемых граблей придумано название #xab;антипаттерны#xbb; - это повторно используемые практики, которые могут давать видимость эффекта и даже временный эффект, однако, их применение наносит несоизмеримый ущерб конечному результату. Цель статьи - собрать вместе некоторые наиболее тяжелые грабли (антипаттерны), которые встречаются на пути управления командами разработки ПО, и попытаться объяснить, почему на них не стоит наступать.

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

Как добиться успеха в безнадежных проектах
Многим руководителям ИТ-проектов знакомы ситуации, когда прекрасно спланированный процесс не укладывается во временные рамки. Несмотря на то что сроки были определены с запасом, одни модули «забирают» все доступные ресурсы, другие сразу после появления на свет удаляются за ненадобностью, а постоянные изменения требований окончательно разрушают проект.

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

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

Проектирования больше нет?
Тем, кто успел кратко познакомиться с принципами Extreme Programming (ХР), порой кажется, что в этой методологии нет места процессу проектирования программных продуктов. При этом высмеиваются не только "Большое и Подробное Предварительное Проектирование", но и такие техники как UML и гибкие каркасы приложений. Даже значение паттернов либо принижается, либо напрочь отрицается. На самом же деле, в ХР много проектирования, но подается оно по-другому, нежели в обычных устоявшихся процессах разработки ПО. Методология XP оживила эволюционное проектирование новыми техниками, благодаря которым его теперь можно считать вполне жизнеспособной стратегией.

Пересекая границы: специфика разработки ПО распределенной командой
Эта статья написана на основе опыта работы в нескольких проектах по разработке ПО, где участники проектной команды были в большей или меньшей степени удалены друг от друга: начиная от варианта #xab;одна команда в двух офисах в одном городе#xbb;, и заканчивая вариантом #xab;3 команды в разных странах #x2013; из них одна на другом континенте#xbb;. Как появляются такие проекты? В малых компаниях ценность конкретного специалиста для проекта часто выше, чем возможные расходы на коммуникацию, и его местожительство не берется в расчет. В крупных компаниях, наоборот, появляется большой объем работ, не требующих высокой квалификации, и задачи реализуются с привлечением субподрядчиков, в том числе из других стран.

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

Реализация стандарта ГОСТ Р ИСО/МЭК
Стандарт ГОСТ Р ИСО/МЭК 12207 определяет архитектуру верхнего уровня жизненного цикла программных средств (ЖЦ ПС) и может быть использован для организации работ по одному или нескольким процессам ЖЦ ПС. Вместе с ГОСТ Р ИСО/МЭК ТО 15271-2002 Руководство по применению ГОСТ Р ИСО/МЭК 12207 стандарт ГОСТ Р ИСО/МЭК 12207 предоставляет возможности для адаптации к широкому кругу задач на основе расширения рекомендаций стандарта путем ввода новых процессов, работ, задач или других объектов ЖЦ ПС, не рассматриваемых в стандарте. В качестве примера можно сослаться на раздел 4 приложения D к ГОСТ Р ИСО/МЭК ТО 15271-2002 - Пример сопровождения.

Современные инструменты проектного менеджмента
Перед тем как начать анализ возможностей продуктов, рассмотрим среду, в которой они призваны функционировать, а также ее потребности. Приведенная ниже классификация пользователей взята из исследования Welcom Software Technologies. Итак, выделяют три основные категории — все они участвуют в процессе управления деятельностью проектно-ориентированной компании и, соответственно, оказывают влияние на ход управления проектом.

Четвертое измерение или Как обмануть Железный Треугольник
Несмотря на то, что первым в Манифесте Гибких Методологий (Agile Manifesto) стоит правило "Люди и их взаимодействие гораздо важнее процесса и средств разработки", сами приверженцы таких методологий тратят на разговоры о процессе довольно много времени. К примеру, Экстремальное программирование (XP) описывает почти что исключительно процесс разработки: "Вы следуете процессу? Сначала тестируете, потом пишете код? Играете в планирование? Парами программируете?" и т.д.

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

Designing for FAILURE - ключ к успеху?
Трудно найти более квалифицированного специалиста в области проектирования и разработки систем управления базами данных, чем почетный сотрудник IBM (IBM Fellow) Брюс Линдсей. Он начал заниматься архитектурой РСУБД (реляционных систем управления базами данных) еще до того, как появились такие системы. В 1978 г., закончив аспирантуру Калифорнийского университета в Беркли и получив степень PhD, он поступил на работу в Исследовательскую лабораторию IBM в Сан-Хосе, где исследователи тогда работали над тем, что впоследствии стало основой языка SQL и продукта IBM DB2. С того времени Линдсей играет ведущую роль в развитии РСУБД.

Системные характеристики КМП
Для того чтобы Команда Менеджмента Проекта (Project Management Team) была готова к совместной работе и, в последующем, к эффективной самоорганизации, требуется, чтобы каждый ее участник был интегрирован в команду и в проект.
Сами процессы самоорганизации команды должны быть обеспечены мониторингом и механизмом управления изменениями, которые включают систему норм, правил и процедур, определяющих поведение и действия ключевых участников проекта и активную обратную связь.

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

Исполнение моделей при помощи виртуальной машины
Прошло уже почти 20 лет со времени появления в 1986 году вызвавшей множество споров статьи Фредерика Брукса «Серебряной пули нет». В данной работе автор предрекал, что в течение ближайшего десятилетия с момента её выхода не возникнет методов, использование которых позволит на порядок величин повысить производительность разработки программного обеспечения. Эта статья вызвала множество споров и работ с опровержениями, и в 1995 году Ф. Брукс опубликовал ответы на некоторые из критических замечаний

MSF – философия создания IT-решений или голые амбиции лидера
Корпорацию Майкрософт можно обвинять в чём угодно, но уж точно не в том, что её руководители не умеют вести бизнес и создавать продаваемые программные комплексы. Посредством пакета руководств MSF (Microsoft Solutions Framework) гигант IT индустрии решил поделиться опытом и накопленной информацией в области проектирования, разработки, внедрения и сопровождения IT -проектов. Словосочетание MSF я бы перевёл как «Подходы Майкрософт к созданию решений». База знаний MSF состоит из оригинальных моделей, методов и взглядов на такие области знаний как управление проектами, персоналом, планирование, анализ рисков и другие смежные дисциплины. Нельзя сказать, что MSF очередной чисто теоретический взгляд на управление.

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

О чем и зачем
Кто виноват? Никто. Как никто не виноват в том, что на небе тучи, что идет дождь, что дует ветер. Поскольку самого-то кризиса не было, и нет, а есть лишь Богом данная (для атеистов - объективная) реальность, которая заключена в особой специфике производства программ, по сравнению с любой другой производственной деятельностью. И с этой спецификой мы обязаны считаться, если, конечно, не хотим «дуть против ветра».

Семантическая реконсиляция прикладных данных на основе моделей
Рассматривается задача семантически корректной и функционально содержательной реконсиляции прикладных данных. Задача имеет ключевое значение для успешного применения современных технологий оптимистической репликации и создания перспективных распределенных приложений, таких как системы коллективной инженерии, мобильные базы данных, семантические сети. Рассматривается модельно-ориентированный подход к семантической реконсиляции данных, описываемых на языках объектно-ориентированного моделирования EXPRESS, UML/OCL, ODL/OQL.

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

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

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

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

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

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

Структурное руководство проектом. Серебряная пуля?
Этот термин достаточно давно и активно используется в ИТ как символ технологического прорыва, который позволит разрабатывать ПО намного быстрее и качественнее. Дело в том, что Фред Брукс в 1987 году опубликовал очень широко известную статью под названием "No Silver Bullet" - "Серебряной пули не существует" - в которой доказывал, что нет и не предвидится никакого существенного прогресса в процессе разработки программного обеспечения.

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

Трансформация UML-моделей и ее применение в технологии MDA
На данный момент разработаны и активно используются множество стандартов, middleware-технологий и платформ (CORBA, DCOM, Dot-Net, WebServices, JAVA-технологии и т.д.), и в будущем их количество будет расти. Попытки создать универсальную платформу, которая бы заменила все существующие, привели только к увеличению количества используемых технологий. Всё более важными становятся вопросы выбора технологии для конкретного проекта, осуществления взаимодействия и интеграции разнородных систем и переносе систем на новую технологическую платформу, когда используемая платформа устаревает и уже не может удовлетворить потребности заказчика. Решение может лежать в использовании новой, более совершенной методики разработки ПО.

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

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

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

Руководство командой разработчиков программного обеспечения

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

Продолжение

Объектно-ориентированное проектирование с примерами

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

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

Выбор реализации
Представление классов и объектов почти всегда должно быть инкапсулировано (скрыто). Это позволяет вносить изменения (например, перераспределение памяти и временных ресурсов) без нарушения функциональных связей с другими классами и объектами. Как мудро отметил Вирт: "выбор способа представления является нелегкой задачей и не определяется одними лишь техническими средствами. Он всегда должен рассматриваться с точки зрения операций над данными" [60]. Рассмотрим, например, класс, соответствующий расписаниям полетов самолетов. Как его нужно оптимизировать - по эффективности поиска или по скорости добавления/удаления рейса? Поскольку невозможно реализовать и то, и другое одновременно, нужно сделать выбор, исходя из целей системы. Иногда такой выбор сделать непросто, и тогда создается семейство классов с одинаковым интерфейсом, но с принципиально разной реализацией для обеспечения вариативности поведения.

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

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

---

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

---