Философские аспекты моделирования как метода познания окружающего мира.

Содержание

Философские аспекты применения формальных методов в проектировании кибернетических систем. 1

Содержание.. 2

Введение... 3

Философские аспекты моделирования как метода познания окружающего мира. 6

Гносеологическая специфика модели и ее определение. 6

Классификация моделей и виды моделирования. 8

Основные функции моделей. 9

Моделирование как средство экспериментального исследования. 9

Моделирование и проблема истины. 11

Имитационное моделирование.. 12

Кибернетическом моделирование.. 12

Понятия "философия техники", "техника", "проектирование". 13

Инженерное проектирование.. 14

Системное проектирование. 15

Этапы разработки системы. 16

Фазы и операции системного проектирования. 17

Кооперация работ и специалистов в системотехнике. 19

Заключение.. 20

Литература.. 21

Введение

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

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

Дать точное определение «формальным методам», как они понимаются в программировании, достаточно затруднительно. Одна из причин этого состоит в том, что программы и методы их компиляции и интерпретации, несомненно, являются формальными, поэтому и все методы разработки программ легко объявить формальными. Вместе с тем, под термином «формальные методы» скрывается нечто, отличающее рутинное написание текстов на языке программирования от анализа этих текстов и анализа поведения программ, заданных этими текстами, причем анализа по духу близкого к математическим исследованиям, использующего математические нотации и способы рассуждений и доказательств, принятые в математике. В связи с этим многие авторы дают определение «формальных методов» просто как методов разработки программ, в которых используются математическая нотация (notation) и/или математические рассуждения (reasoning). Формальные методы в программировании, по-видимому, появились практически одновременно с самим программированием. Из результатов советской программистской школы наибольшую известность получили работы А.А.Маркова (алгоритмы Маркова) и работы А.А.Ляпунова и его учеников (например, схемы Янова). В более поздние годы много внимания формальным методам в СССР уделялось в работах киевских, новосибирских, ленинградских и московских ученых. Наиболее известной и распространенной формальной нотацией является нотация Бэкуса-Наура, использующаяся для описания синтаксиса формальных языков. Затем можно назвать машину Тьюринга, конечные автоматы (Finite State Machine – FSM or Finite Automata – FA), сети Петри, языки описания взаимодействующих процессов К.А.Хоара (C.A.Hoar) и Р.Милнера (R.Milner) и др. По естественным причинам практически все работы по формальным методам были нацелены на форвард-приложения. В качестве идеала рассматривалась следующая схема. На языке формальных спецификаций описываются функциональные требования к программной системе. Путем аналитического исследования устанавливается корректность спецификации – спецификация верифицируется. Затем при помощи некоторого инструмента на основе формальных спецификаций генерируется код программной реализации. Несколько более реалистичный сценарий дополнял описанную выше схему процессом постепенного уточнения спецификаций (refining). Каждый шаг уточнения проводится человеком, который направляет процесс уточнения. При этом соответствующие инструменты следят за тем, чтобы очередное уточнение спецификации не пришло в противоречие с исходными спецификациями. В обоих сценариях в качестве итогового результата должна появиться программная реализация, удовлетворяющая всем специфицированным требованиям и не содержащая ошибок. В 70-е годы появились языки формальных спецификаций, которые с одной стороны имели много общего с языками программирования, а с другой стороны предоставляли специальные средства, сближающие их с математической нотацией и облегчающие рассуждения о свойствах таких формальных текстов. Несмотря на это, большая часть исследований по формальным методам по-прежнему сохраняла так называемый «академический» характер. По-видимому, главным исключением служат работы по конечным автоматам (КА), которые нашли самое широкое применение в проектировании и тестировании средств автоматики, связи и вычислительной техники. Опыт использования КА в разработке аппаратуры применялся и в разработке ПО, хотя в существенно меньших масштабах по сравнению с разработкой аппаратуры. Весьма скромные результаты, продемонстрированные попытками применить формальные методы в реальных проектах, породили распространение скептического взгляда на возможность извлечь пользу из этих методов, соизмеримую с затратами, которые необходимо вложить в дополнительные работы, связанные с разработкой и анализом формальных спецификаций.

Вместе с тем, на отдельных направлениях формальные методы и, в частности, языки формальных спецификаций достигли значимых успехов. Эти успехи, с одной стороны, были обусловлены удачным сочетанием потребностей предметной области и возможностей формальных методов (в первую очередь это проблемы описания телекоммуникационных протоколов; SDL, LOTOS – примеры языков спецификаций, использующихся в этих областях), и с другой стороны, приближением языков спецификации к формам, привычным в традиционном программировании (в первую очередь это Венский метод – Vienna Development Method – VDM и его развитие – языки Z и RAISE). Еще одним фактором, создавшим предпосылку для продвижения формальных методов в реальное программирование (software production), стал интерес к вопросам реверс-инженерии вообще и к задачам автоматизации тестирования на основе использования формальных спецификаций (тем самым, спустившись с небес на землю, специалисты по формальным методам отбросили мечту об порождении программ без ошибок, а решили использовать свои методы для поиска ошибок, которые неизбежно встречаются в ПО).

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

Тем самым, появляется предпосылка для решения самой главной проблемы современной реверс-инженерии. Она состоит в том, что на сегодняшний момент результатом работы по изучению программ (это и есть реверс-инженерия в узком смысле этого слова) является знание отдельного индивида. Это знание не отчуждается от индивида и легко теряется как самим индивидом (и группой, в которой он работает), так и заказчиком реверс-инженерии, как только данный исполнитель переключился на другую работу. Известно, что фирмы производители ПО затрачивают огромные средства на создание документации по ПО. Однако лишь немногие фирмы находят достаточно сил и времени, чтобы поддерживать документацию в актуальном состоянии. Эта ситуация каждый раз порождает необходимость в реверс-инженерии. Реальным выходом из этого бесконечного цикла является фиксация так называемых «программных контрактов» (software contract), которые можно рассматривать как материальное представление знаний о функциональности данного ПО. Программный контракт описывает синтаксис и семантику интерфейсов систем. Как правило, этот термин используется по отношению к так называемым «интерфейсам прикладных программ» (Aррlication Programming Interfaces – API). API – это интерфейс, который предоставляется сущностями, составляющими программу, например, процедурами, функциями, методами ОО классов и т.п.

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

Серьезным направлением в использовании формальных методов в последние десять лет стала «проверка моделей» (model checking). Этот подход демонстрирует компромисс между идеальной мечтой о верификации формальной системы и реальной практикой разработки ПО. Суть похода состоит в построении модели реальной системы и по возможности полной проверке корректности данной модели. Проверка, если возможно, проводится аналитическими методами. Если это невозможно, производится тестирование модели. При этом сложность модели, как правило, выбирается таким образом, чтобы была возможность провести «исчерпывающее» тестирование (exhaustive testing). Слабое место данного подхода – это проблемы построения модели и доказательство того, что модель достаточно содержательна, чтобы на основании модели можно было судить о свойствах реальной системы.

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

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

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

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

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

Философские аспекты моделирования как метода познания окружающего мира.