Октябрьский номер журнала Computer (IEEE Computer Society, Vol. 39, No. 10, October 2006) посвящен 60-летнему юбилею IEEE Computer Society, а в качестве темы выбрана инженерия программного обеспечения.
В качестве приглашенных редакторов выступили Дорис Карвер, Бэтон Роудж, Рон Хоулцман, Джим Эйлор и Майк Хинчи. Их вводная заметка называется «60-летний юбилей IEEE Computer Society».
IEEE Computer Society отмечает еще две юбилейные даты: 40-летие журнала Computer и 30-летие конференции по программной инженерии Software Engineering Workshop. При поддержке Computer Society в 2006 году был проведен конкурс по истории компьютеров (IEEE Computer Society 60th Anniversary History Competition, www.computer.org/education/chc60), в котором победила российская команда из Московского государственного технологического университета (МАТИ), представившая сайт «Русские счеты» (www.schoty.ru).
Журнал Computer посвятил 60-летию сообщества свой январский номер, содержащий обзор основных достижений в области компьютерной науки и анализ ближайших перспектив, а также данный выпуск. В журнале появилась колонка In Our Time, которую ведет главный редактор журнала IEEE Annals of the History of Computing Дэвид Алан Грайер.
Краткая история сообщества такова. Возглавляемый Джоном фон Нейманом Комитет научно-исследовательского совета по высокоскоростным вычислительным устройствам основал специальное издание Mathematical Tables and Other Aids to Computation для публикации технических статей о компьютерах. Это и привело к созданию двух новых организаций, ставших в дальнейшем основой Computer Society, — Комитета по крупным вычислительным устройствам Института инженеров по электротехнике (Large-Scale Computing Devices Committee of the American Institute of Electrical Engineers, AIEE, 1946), а также Профессиональной группы по электронным компьютерам (Professional Group on Electronic Computers, PGEC), образованной Институтом инженеров по радиотехнике (Institute of Radio Engineers, IRE, 1948). В 1963 году AIEE и IRE объединились в Институт инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers, IEEE), а PGEG была преобразована в Профессиональную техническую группу по электронным компьютерам (Professional Technical Group on Electronic Computers). Был создан административный комитет, включающий представителей обеих групп, а в 1964 году они объединились в IEEE Computer Group.
В июле 1966 года вышел первый номер журнала Computer Group News, для поддержки издания которого было образовано административное подразделение. Так Computer Group стала первой группой в IEEE, у которой появились штатные оплачиваемые работники, что способствовало дальнейшему развитию ассоциации. В 1971 году Computer Group была переименована в IEEE Computer Society, в 1972-м журнал Computer Group News переименовали в Computer, а с 1973-го он стал издаваться ежемесячно.
Конференция NASA/IEEE Software Engineering Workshop в этом году отмечает 30-летний юбилей. Первые 25 лет конференция (www.systemsandsoftwareweek.org) проводилась исключительно NASA, но в последние пять лет ее поддерживает и IEEE.
На юбилейную конференцию в качестве докладчиков были приглашены специалисты, которых попросили проанализировать основные достижения в области программной инженерии за прошедшие 30 лет, представить прогноз на следующие 30 лет, отразить существо имеющихся проблем и высказать мнение о возможных путях их решения. Статьи этих докладчиков и их соавторов представлены в юбилейном номере журнала.
Первая статья, озаглавленная «Кроссплаформенная разработка: программное обеспечение, которого хватает надолго» (Cross-Platform Development: Software that Lasts), представлена Джудит Бишоп (Judith Bishop) и Найджелом Хорспулом (Nigel Horspool). Греческому философу Гераклиту приписывают высказывание «Постоянно только изменение»; эту знаменитую фразу следовало бы высечь на стене храма программной инженерии. Основной практической задачей является создание систем, устойчивых к непредсказуемым изменениям требований. Для налаживания процесса управления требованиями надо ответить на трудные вопросы. Что происходит с программным обеспечением при смене аппаратных средств? Каким образом небольшая софтверная компания может разработать программное обеспечение для различных платформ, расширяя за счет этого свою клиентскую базу и повышая доходность? Как полагают авторы, ответ на оба этих вопроса кроется в обеспечении высокого уровня архитектурной независимости программного обеспечения.
Одно из определений программной инженерии гласит: «Программная инженерия — коллективная разработка многоверсионного программного обеспечения». Распространенное представление о программной инженерии фокусируется на первой части этого определения — на управлении группами для производства крупного продукта. Большинство, разделяя это представление, видит в программной инженерии дисциплину, связанную с вычислительными системами в целом, позволяющую перевести программные средства и методы с ремесленного уровня в состояние, которое обеспечит разработчикам возможность использовать их эффективным и воспроизводимым образом для успешного выполнения крупных проектов. Однако важна и вторая часть определения: программная инженерия должна помогать выявлению определенных частей продукта, которые могут разрабатываться и массовым образом производиться независимо от языков программирования и среды использования.
В контексте обеих частей этого определения огромное продвижение вперед обеспечивают методы программной инженерии, основанные на использовании компонентов. Технология Web-сервисов сегодня воспринимается как норма, а у ведущих поставщиков программного обеспечения входит в практику автоматическая рассылка обновлений на все машины, на которых используются соответствующие программные продукты.
Границы между программным и аппаратным обеспечением становятся размытыми, и при приобретении новой аппаратуры становится необязательно приобретать и устанавливать новое программное обеспечение. Но, к сожалению, ситуация мало изменяется для разработчиков и пользователей самодельных, настроенных или предназначенных для поддержки исследований программ. Хотя на сопровождение и модификацию по-прежнему приходится более двух третей общей стоимости проекта, разработчики нетиражируемых приложений остаются равнодушными к интероперабельности и после завершения проекта перестают быть связанными с полученным продуктом. После этого владельцы и пользователи программного обеспечения должны либо работать с его внутренними частями, либо привлекать новых разработчиков.
Авторы статьи не видят причин подвергать разработчиков таким мучениям. Они убеждены, что компонентам крупной программной системы можно придать высокий уровень независимости от платформы и даже языка программирования. В результате можно получить долговечное программное обеспечение, для которого возможна простая миграция при смене платформы. Предлагаемый в статье подход особенно выгоден для разработчиков графических пользовательских интерфейсов (graphical user interface, GUI).
Лючано Барези (Luciano Baresi), Елизабетта Ди Нитто (Elisabetta Di Nitto) и Карло Гецци (Carlo Ghezzi) представили статью «Навстречу программному обеспечению открытого мира: проблемы и вызовы» (Toward Open-World Software: Issues and Challenges). Сегодня разработчики справляются с изменениями среды путем выявления соответствующих требований к изменению программного обеспечения, модификации структуры и реализации программ, проверки того, что результирующий продукт удовлетворяет новым требования и, наконец, повторного внедрения приложения. Такой поход основывается на предположении, что внешний мир изменяется медленно, а потому программное обеспечение может оставаться стабильным в течение долгого периода времени. Также предполагается замкнутость внешнего мира в том смысле, что в требованиях, на основе которых специфицируется взаимодействие программной системы с внешним миром, могут быть зафиксированы все важные с ее точки зрения явления. Само программное обеспечение является замкнутым, поскольку состоит из частей, не изменяющихся при выполнении программ.
Однако эти предположения оказываются все менее действительны, в особенности в повсеместных и всеобъемлющих компьютерных средах, в которых мир является, по сути, открытым. Подобные приложения существуют во многих областях от динамического управления цепочками поставок, динамической интеграции предприятий и виртуальных объединений на уровне предприятия до автомобильных приложений и систем домашней автоматизации на уровне встроенных систем. В открытом мире изменения среды происходят постоянно — программное обеспечение должно динамически реагировать на изменения и подстраиваться к ним, даже если они являются непредвиденными. Кроме того, мир является открытым для новых компонентов, которые могут потребоваться в динамике по причине изменений контекста, например вследствие мобильности. В системах должна иметься возможность обнаружения таких компонентов и их динамического связывания с приложениями во время выполнения. У самого программного обеспечения должна иметься способность к самоорганизации. Другими словами, традиционное решение, используемое разработчиками программного обеспечения (тщательно выявить требования к изменениям; упорядочить их в соответствии с приоритетами; специфицировать требования; разработать, реализовать и оттестировать соответствующие изменения программ; повторно внедрить), больше не работает.
Для установления природы этих новых проблем прежде всего требуется понять суть достижений, полученных в прошлом, и возможности их использования в новых целях. Действительно, по мере развития технологий программного обеспечения возрастает его гибкость. При использовании предположения о замкнутости мира в области программной инженерии созданы методы борьбы с постоянными изменениями, позволяющие поддерживать качество приложений. Например, архитектуры программных систем эволюционировали от статических, монолитных и централизованных к динамическим, модульным и распределенным. Это изменение, произошедшее под влиянием и технических, и экономических воздействий, затронуло как уровень процесса (способ разработки), так и уровень продукта (способ структуризации). Однако, чтобы справиться с новыми вызовами открытого мира, требуется превзойти эти достижения. Авторы выдвигают следующую программу исследований.
Обеспечение формальных спецификаций программных компонентов сегодня является обязательным для компонентов, обеспечивающих сервисы, которые используются другими компонентами. Удалось достичь большого прогресса в области спецификаций интерфейсов, затрагивая их синтаксические и семантические аспекты. Но, хотя в области спецификаций компонентов традиционно упор делается на функциональные возможности, в контексте открытого мира должны специфицироваться и другие аспекты, включая протокол использования, транзакционные и нефункциональные свойства. Первые шаги в этом направлении сделаны в рамках Semantic Web, где онтологии используются для описания формальной семантики сервисов. Однако в этом направлении требуются дальнейшие исследования. Требуется изучить, каким образом спецификации сервисов могут поддерживать классификацию и поиск сервисов. В частности, важным понятием для поддержки динамической реконфигурации является возможность замены одного сервиса другим.
Сервисы, обеспечиваемые поставщиками услуг, должны соответствовать их спецификациям. Автономная верификация сервисов, осуществляемая их производителями, не является достаточной. Требуется верификация сервисов во время их публикации и даже во время выполнения, поскольку они могут изменяться без предварительного уведомления. Верификация на фазе публикации может входить в состав протокола принятия к публикации, когда происходит сертификация сервиса. Верификация времени выполнения должна защитить пользователей от непредвиденных и недопустимых изменений. Для этого нового вида верификации требуется разработать новые методы.
В динамических и открытых системах становится необходимым мониторинг для обнаружения ситуаций, в которых могут потребоваться соответствующие реакции для обеспечения желаемого уровня общего качества. Мониторинг заключается во внесении в систему датчиков, сборе и анализе данных и в соответствующем реагировании на результаты анализа. В ходе анализа наблюдения сравниваются со спецификациями. Проблема состоит в определении, выборке и настройке стратегий мониторинга, которые могут обладать разными степенями агрессивности.
В открытом мире участники, предоставляющие и потребляющие услуги, могут легко стать жертвами мошенничества. Такие ситуации могут распознаваться с помощью мониторинга с инициированием каких-либо восстановительных действий. Однако требуется возможность предотвращения ситуаций, которые могут причинить вред системе. В области сервис-ориентированных систем в рамках инициатив WS-Security, WS-Policy и WS-Trust определяются протоколы, позволяющие некоторым уполномоченным службам гарантировать достоверность других участников. При применении более «демократичного» подхода доверие основывается на репутации участников. Ни один из подходов не гарантирует устойчивость по отношению к атакам. Эти подходы необходимо дополнить методами верификации и мониторинга.
В открытом мире программное обеспечение должно обладать возможностью динамического развития. Хотя разработчики не могут предсказать все изменения, они должны определять границы, в пределах которых система может эволюционировать. Иначе система может быстро выйти из-под контроля. Результаты мониторинга должны позволять управлять отклонениями от ожидаемого поведения и планировать реконфигурацию. Авторы статьи исследовали подход к поддержке самовосстанавливающихся Web-сервисов на основе потоков работ, которые могут обнаружить отклонение поведения сервисов от ожидаемого, и воздействовать на них должным образом. Похожим образом на ряде автономных компьютерных платформ обеспечивается возможность определения правил, которым должен следовать каждый компонент для изменения системы в целом. Некоторые из этих правил могут строиться по образу поведения существующих биологических систем.
Название следующей статьи — «Инженерия сервисов: связывание бизнеса и ИТ» (Service Engineering: Linking Business and IT). Ее авторы — Тициана Маргария (Tiziana Margaria) и Бернхард Стеффен (Bernhard Steffen). Бизнес-процессы все больше становятся характерной интеллектуальной собственностью передовых компаний. Кроме того, в соответствии с недавно принятыми правилами требуется более прозрачное моделирование процессов, допускающее своевременный аудит и прослеживаемость бизнес-решений и операций. Эти тенденции стимулируют автоматизацию, стандартизацию, а часто и радикальную реорганизацию бизнес-процессов различных организаций.
Сервис-ориентированный подход, в котором делается упор на модульность, полностью изменяет способы моделирования, реализации и поддержки бизнес-процессов. Сервисы, связанные с конкретной предметной областью, виртуализуют сложные функции основных бизнес-приложений таким образом, что их можно слабо связывать для образования межорганизационных процессов. Этот уровень абстракции стимулирует применение «быстрых» методов и уменьшает традиционную зависимость от поставщиков. Например, в классических средах выбор ERP-системы влияет на выбор системы управления процессами, поскольку интероперабельность обычно гарантируется только внутри одной однородной системы. Однако виртуализация и слабое связывание за счет отделения процессов от поставщиков индивидуальных функций обеспечивает «бесшовное» кроссплатформенное, кроссдоменное и независимое от поставщиков управление процессами. Для поддержки такого горизонтально-однородного управления процессами требуются новые инструментальные средства, гарантирующие вертикально-однородную реализацию моделируемых процессов. Основанные на всемирных стандартах протоколов и интерфейсов, эти средства должны обеспечивать спецификацию и поддержку интероперабельности используемых функций, делая, тем самым, возможной разработку процессов, которая действительно основана на моделях.
Статья «Что мы можем ожидать от верификации программ?» (What Can We Expect from Program Verification?) представлена Майклом Джексоном (Michael Jackson). В 2003 году Тони Хоар предложил идею верифицирующего компилятора в качестве большого вызова компьютерному сообществу (research.microsoft.com/users/thoare/The_Verifying_Compiler.ppt), а годом позже Джим Вудкок, кроме верифицирующего компилятора рекомендовал разработать репозитарий реальных примеров программ и документации, которые были верифицированы или были предназначены для верификации.
Понимание верификации как математического доказательства того, что программа удовлетворяет своим формальным спецификациям, исходит от Алана Тьюринга. Методы верификации должны включать как проверку соответствия заданной программы спецификациям, содержащимся в ее тексте или в отдельном документе, так и средство обеспечения корректного построения программы, систематическую и формальную процедуру разработки, гарантирующую корректность разработанной программы или облегчающую ее верификацию. Недавно опубликованный план исследовательских работ, относящихся к данному вызову, демонстрирует многообразие возможных методов верификации (ftp.cs.iastate.edu/pub/techreports/TR06-21/TR.pdf). Наличие этого многообразия привело к замене термина «верифицирующий компилятор» на более общий термин «средства верификации программ».
С позиций данного вызова корректным программным продуктом является продукт, соответствующий формальной спецификации. Ключевые вопросы относятся к самому понятию спецификации и ее области действия. Эдсгер Дийкстра рассматривал спецификацию как логический экран, отделяющий вопрос корректности (correctness concern — удовлетворяет ли программа своей формальной спецификации) от вопроса приятности (pleasantness concern — является ли программа, удовлетворяющая спецификации, именно тем, что задумывалось). В более ранней формулировке имеется разделение между построением программы правильным образом и построением правильной программы. Причина этого разделения очевидна — компьютеры конструируются для образования среды выполнения программ, в которой корректные формальные рассуждения являются полностью достоверными, однако во многих случаях разработчик должен использовать знания о предмете спецификации, поскольку требуемые рассуждения выходят за пределы чисто программистских вопросов. Если этот предмет является абстрактным и математическим (например, выпуклая оболочка множества точек в трехмерном пространстве), то требуемое знание включает соответствующие математические аксиомы и теоремы. Поэтому оно является не менее формальным, чем сама программа, и к нему самому применимы формальные рассуждения.
В отличие от этого, вопрос о том, производят ли разработчики правильную программу (скажем, действительно вычисляющую выпуклую оболочку или наименьший ограничивающий куб), подрывает формальность, поскольку вводятся неформальные понятия, лежащие вне мира математики. Неформальным элементом является даже выбор формата ввода множества точек, для которого нужно вычислить выпуклую оболочку. Появляются человеческие соображения, для которых отсутствует бесспорное корректное и доказуемое обоснование. Поэтому представляется желательным ограничиться спецификациями, по отношению к которым программы должны верифицироваться. Спецификации должны основываться на абстрактном и формальном предмете, строго ограниченном компьютерным периметром.
В крупных программных системах формальными не являются ни проблема, ни ее предмет. Проблемный мир (естественная среда, в которой будет выполняться программа) включает множество физических явлений, включающих человеческое бытие и создаваемые людьми артефакты. Предметом проблемы являются не абстрактные аксиомы и теоремы, которые можно применить для понимания и формализации свойств среды, а также для формулировки и решения данной проблемы. Скорее, предметом является реальная окружающая среда во всем своем беспорядке.
Для поддержки возможности производства формально верифицированного корректного программного обеспечения требуется решение двух разных предварительных задач. Разработчики должны формализовать требование к системе (воздействие, которое должно оказать на среду программное обеспечение) и соответствующие свойства среды. Кроме того, они должны применить формализованные требование и свойства среды для порождения формальной спецификации желательного компьютерного поведения на уровне его интерфейса со средой.
Удовлетворение результирующей формальной спецификации — критерий корректности программы. За получение спецификации должны отвечать инженеры. Эта задача относится только к среде и лежит вне граничного барьера. Задача внутри этого барьера относится только к программному обеспечению и формальной спецификации, и за нее должны отвечать специалисты из области компьютерной науки. Внутри барьера полностью формальная природа программирования и верификации программ остается неизменной.
Статью «?Большой вызов? в информатике: инженерия преимущественно программных систем» (The ?Grand Challenge? in Informatics: Engineering Software-Intensive Systems) написал Манфред Брой (Manfred Broy). Информатика включает много областей и охватывает принципы вычисления, хранения, передачи и визуализации информации, а также формализмы для описания процедур обработки информации. Подобно тому как физика является наукой о физических явлениях и их математических основах, химия — наукой о материалах и веществах, биология — наукой о жизни, информация является существенной для понимания реальности, и информатика вносит фундаментальный вклад в постижение мира.
В информатике имеется и инженерный аспект, относящийся к созданию и функционированию систем обработки информации, вычисляющих, сохраняющих, передающих и визуализирующих информацию. Сегодня обработка информации играет существенную роль во всех видах технических и организационных процессов и в широком диапазоне продуктов. Для этих процессов и продуктов все более характерно включение программного обеспечения, существенно повышающего их функциональные возможности. Наличие программного обеспечения и возможности программирования глубоко влияет на их разработку и использование, поэтому преимущественно программные системы представляют собой очень важную разновидность систем обработки информации. Разработка и производство систем обработки информации основывается на использовании вспомогательных программных систем, таких как программные инструментальные средства и репозитарии данных о продуктах. Поэтому ключевые дисциплины для конструирования систем обработки информации — программная и системная инженерия.
Все эти вопросы важны не только с экономических позиций, но также и в отношении к безопасности и надежности повседневной жизни. Важнейшие инфраструктуры человеческой деятельности в значительной степени зависят от возможности разработки и обеспечения функционирования безопасных и надежных, преимущественно программных систем.
Сегодня построение преимущественно программной системы остается нерешенной проблемой. Во многих прикладных областях наблюдается типичная кривая обучения. В начале цикла обучения инженеры расценивают программное обеспечение как незначительный довесок ко всему остальному. По мере изучения прикладной области программное обеспечение постепенно становится центральной инженерной задачей. И тогда инженеры начинают разрабатывать собственные процессы и модели для решения проблем разработки программного обеспечения для конкретной прикладной области.
Для решения проблем разработки сложных программных систем требуется несколько новых технических компетенций. В частности, требуется хорошее понимание моделирования систем и эффективное использование моделей в дисциплинированном инженерном процессе. Потребуется и теория моделирования систем с дискретными событиями, которая обогащает и дополняет классический математический подход к теории систем, основанный на дифференциальных и интегральных уравнениях.
Если основываться на подходе к систематической разработке сложных программных систем, то потребуется инженерная нотация; дисциплина системных архитектур, затрагивающая архитектуру и программного обеспечения, и аппаратуры; соответствующие языки реализации; поддерживающее все это инструментальное средство. Кроме того, нужна методология спецификации и верификации систем с интенсивным использованием программного обеспечения.
Разработка такого подхода представляет собой Большой Вызов, заслуживающий многочисленных исследований. При их выполнении нужно учитывать основы программной и системной инженерии, не забывая одновременно отслеживать конкретные потребности прикладных областей. По мнению автора, наиболее эффективными окажутся практические подходы, специфичные для конкретных прикладных областей, основанные тем не менее на общей теории и методологии моделирования, разработки и обеспечения функционирования программных систем.
Еще одну статью тематической подборки представил Дэвид Грайс (David Gries). Статья называется «Чему мы не научились по поводу обучения программированию?» (What Have We Not Learned about Teaching Programming?). Когда в 1968 году проводилась конференция NATO по программной инженерии, представители академических кругов и индустрии практически в первый раз собрались вместе для обсуждения проблем проектирования и разработки программного обеспечения. И те и другие публично признались в том, что не знают, как хорошо разрабатывать программное обеспечение. Отчетливыми симптомами кризиса программного обеспечения являлись частые нарушения сроков завершения работы, перерасход средств, наличие ошибок в программах и неспособность к обучению программированию. Эта конференция побудила многочисленные исследования в конце 60-х — начале 70-х годов. Наиболее важный вклад в эти исследования внесли Эдсгер Дийкстра, Тони Хоар и Никлаус Вирт. К числу их достижений относятся аксиоматическая основа языков программирования; теория слабейших предусловий, которая привела к созданию методологии формальной разработки алгоритмов; пошаговая детализация; структурное программирование; достижения в области языков программирования. Однако, как считает автор, полученные результаты так и не удалось в должной мере использовать при обучении программированию. В процессе обучения не подчеркиваются достижения этих новаторов, оказавшие громадное воздействие на профессию разработчиков программного обеспечения.
По словам американского ученого-лингвиста Бенджамина Уорфа, они делали акцент на простоте и красоте и полагали, что язык должен способствовать четкости мышления: «Эти принципы теперь редко упоминаются в контексте программирования. Мы продаем свои программистские души, когда начинаем обучение с педагогически вредных и интеллектуально ужасных языков Cи и C++. Они подчеркивали значение методологии, говоря и принципах разработки программ, таких как пошаговая детализация». Сегодня в большинстве учебных материалов содержатся «тексты программ», а не «тексты о программировании»; в них мало говорится о процессе программирования. Вместо этого приводятся тексты программ, и полагается, что студенты смогут писать свои программы по их образу и подобию.
Сегодня многие выпускники, специализирующиеся на компьютерных науках, не знают смысла слова «инвариант», хотя инвариант цикла является базисным инструментом программной инженерии, позволяющим понимать независимые части цикла (инициализацию, условие завершения, продвижение к завершению) без потребности анализа других частей. Нужно внимательно посмотреть на то, как происходит обучение программированию. Целью образования должно быть не просто насыщение студентов фактами, а развитие их способности думать. Автор полагает, что можно учить студентов осмысленному процессу программирования более эффективно, чем это делается сейчас.
Поздравляю вас всех с юбилеем IEEE Computer Society! Присоединяйтесь к нашему сообществу. До встречи в следующем номере, Сергей Кузнецов (kuzloc@ispras.ru).
