Geum.ru

u/text/302/181130/ html Открытые системы, процессы стандартизации и профили стандартов

Вид материалаДокументы

Содержание


Открытый мир программного обеспечения
Открытые системы #08/2006
Подобный материал:
1   ...   6   7   8   9   10   11   12   13   ...   22

Открытый мир программного обеспечения


Сергей Кузнецов

ссылка скрыта :: ссылка скрыта

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

Название следующей статьи — «Инженерия сервисов: связывание бизнеса и ИТ» (Service Engineering: Linking Business and IT). Ее авторы — Тициана Маргария (Tiziana Margaria) и Бернхард Стеффен (Bernhard Steffen). Бизнес-процессы все больше становятся характерной интеллектуальной собственностью передовых компаний. Кроме того, в соответствии с недавно принятыми правилами требуется более прозрачное моделирование процессов, допускающее своевременный аудит и прослеживаемость бизнес-решений и операций. Эти тенденции стимулируют автоматизацию, стандартизацию, а часто и радикальную реорганизацию бизнес-процессов различных организаций.

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

Статья «Что мы можем ожидать от верификации программ?» (What Can We Expect from Program Verification?) представлена Майклом Джексоном (Michael Jackson). В 2003 году Тони Хоар предложил идею верифицирующего компилятора в качестве большого вызова компьютерному сообществу (ссылка скрыта), а годом позже Джим Вудкок, кроме верифицирующего компилятора рекомендовал разработать репозитарий реальных примеров программ и документации, которые были верифицированы или были предназначены для верификации.

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

С позиций данного вызова корректным программным продуктом является продукт, соответствующий формальной спецификации. Ключевые вопросы относятся к самому понятию спецификации и ее области действия. Эдсгер Дийкстра рассматривал спецификацию как логический экран, отделяющий вопрос корректности (correctness concern — удовлетворяет ли программа своей формальной спецификации) от вопроса приятности (pleasantness concern — является ли программа, удовлетворяющая спецификации, именно тем, что задумывалось). В более ранней формулировке имеется разделение между построением программы правильным образом и построением правильной программы. Причина этого разделения очевидна — компьютеры конструируются для образования среды выполнения программ, в которой корректные формальные рассуждения являются полностью достоверными, однако во многих случаях разработчик должен использовать знания о предмете спецификации, поскольку требуемые рассуждения выходят за пределы чисто программистских вопросов. Если этот предмет является абстрактным и математическим (например, выпуклая оболочка множества точек в трехмерном пространстве), то требуемое знание включает соответствующие математические аксиомы и теоремы. Поэтому оно является не менее формальным, чем сама программа, и к нему самому применимы формальные рассуждения.

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

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

ссылка скрыта    ссылка скрыта    ссылка скрыта    3    ссылка скрыта    ссылка скрыта    ссылка скрыта

Открытые системы #08/2006
ссылка скрыта