Обсуждение:OPS: Automata

От автора

Недавно прочитала книгу и публикацию (которая совсем не публикация). Обе понравились. Они дополняли друг друга и, в частности, уделяли внимание разработке ПО и тому, через что надо пройти прежде чем кодить, насколько необходимо проделать этот путь, что происходит в современном мире в этом отношении. Рассказывалось и о катастрафических (для проекта) ошибках, повлекших большие убытки и много работы для их исправления, вызванных плохим проетированием, и о том, как легко их можно было бы избежать. Впечатление усиливалось и тем, что книгу я читала пока делала предыдущее задание. Тогда, кстати, я впервые на деле узнала, что значит хорошо спроектировать: дважды приходилось менять внутреннее представление некоторых базовых и широко используемых классов. Каждый раз это занимало 15 минут. Я всегда понимала, что так и должно быть (потому что в конспекте написано и А.М. говорил), но почувствовать удобство "в деле" — это совсем другое. Книга, но еще больше непубликация, имела большое влияние на меня. В какой-то момент чтения приняла революционное для себя решение, что выполнение следующего задания (добровольно! (революционность по большей части в этом)) начну с карандаша, бумаги и UML, а не с клавиатуры, монитора и VS.

А пока вдохновение меня не отпустило, добавлю что-то более конкретное.

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

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

Кому предназначается информация? Во-первых, мне. Не скрою, что пока не чувствую глобального понимания поставленного задания: на данный момент вижу что оно из себя представляет, но тону в мелочах. Источников, программ-аналогов и прочего так много, что они постоянно путаются в голове и мне необходимо место, где я могла бы писать о них, фиксировать найденные публикации и сведения, чтобы не искать повторно. То, что будет написано здесь ни чем не отличается от возможного контента .doc-файла, который лежал бы среди прочих документов у меня на винте, но еще раз сказав о сравнительном удобстве вики (мне она не всем нравится), файлик будет лежать на винте у мехмата.

Что мне за это будет?

• Ясность.
• Повод познакомиться с UML.
• Если кто-то (и я в том числе) рискнет через некоторое время разобраться в сделанном, то, имея на руках не только код, но и сопроводительную документацию (еще более кривую, чем код :) ), будет намного проще.

Учитывая, что эта идея ничем не подкреплена (в смысле не подкреплена обязательностью воплощения), она будет жить, пока мне не надоест или пока я не решу, что мне уже все понятно и продолжать что-либо документировать и проектировать не надо, в общем, второе может быть вызвано первым. --Avalanche 02:25, 22 июля 2009 (MSD)

Литература по смежной теме

Avalanche, если в процессе изучения вопроса наткнётесь на статью, в которой обсуждается верификация сетевых протоколов с помощью конечных автоматов, маякните, пожалуйста. Я давно хотел включить этот материал в курс по распределённым системам. Хопкрофт/Мотвани/Ульман упоминают о верификации сетевых протоколов, как об одном из приложений автоматов, но ссылок не дают, к сожалению. --Bravit 22:00, 22 июля 2009 (MSD)

Что-то нашлось, но не знаю насколько Вам это подойдет:

• P.R. D’Argenio, J.-P. Katoen, T. Ruys, and G.J. Tretmans. The bounded retransmission protocol must be on time! In Tools and Algorithms for the Construction and Analysis of Systems, LNCS 1217, 1997.
• G.J. Holzmann. An improved protocol reachability analysis technique. Software–Practice and Experience 18(2), 1988.
• G.J. Holzmann. Design and Validation of Computer Protocols. PrenticeHall, 1991.
• G.J. Holzmann. Tracing protocols. AT&T Technical Journal 64(12), 1985.
• R. Gerth, D. Peled, M. Vardi, P. Wolper. Simple on-the-fly automatic verification of linear temporal logic. Proceedings 13th Symposium on Protocol Specification, Testing and Verification, 1995.
• J.F. Groote, F. Monin and J. van de Pol. Checking verifications of protocols and distributed systems by computer. Concur’98: Concurrency Theory, LNCS 1432, 1998.
• C.H. West. Applications and limitations of automated protocol validation. Proceedings 2nd Symposium on Protocol Specification, Testing and Verification, 1982.

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

Вообще, протокол — это тот же самый КА, потому ничто автоматное ему не чуждо, а современный материал по верификации автоматных программ есть по ссылке [6] в статье. По этой же ссылке под блистательным заголовком «Еще одна книга по верификации» скрывается Katoen. Concepts, Algorithms, and Tools for Model Checking. Lecture Notes of the Course «Mechanised Validation of Parallel Systems», Semester 1998/1999 из которой, преимущественно, взяты вышеприведенные источники.--Avalanche

Интересно, спасибо! --Bravit 01:08, 23 июля 2009 (MSD)

Обсуждение задачи OPS: Automata

> Нет ни одного ПП, удовлетворяющего всем предъявляемым требованиям, потому решение создать новый программный модуль является обоснованным. Логика — нечёткая. Логичней было бы взять что-то наиболее близкое к желаемому и ДОПИЛИТЬ. --85.140.235.11 16:42, 24 июля 2009 (MSD).

Да, я сегодня уже убрала этот вывод, но пока не сохраняла изменения. Дело в том, что большинство программ с открытым кодом написаны не на C++. Это их несколько выбивает из колорита ОРС, в рамках которой проект живет (будет жить). Конечно, можно автоматически перенести код, например, с C# на C++, но этот вопрос я не прорабатывала, не думаю, что понадобится. В допиливании чужих проектов есть много минусов, которые, я думаю, очевидны. Мне (морально) сложно смириться с их использованием в конечном варианте, однако я постараюсь справиться со своими чувствами, тем более оказалось, что есть много всяких вещей, которые вполне удачно генерируют код по UML-диаграммам. Ближайшие пара дней скорее всего полностью выпадут, но после я вернусь именно к вопросу поиска «чего-то наиболее близкого к желаемому». Последние события заставили меня укрепиться в том, что такие средства есть. --Avalanche 03:48, 25 июля 2009 (MSD)

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

Про ограничения на язык я не подумал. Заниматься генерацией кода на C++ с чего бы то ни было я бы побоялся. --Ulysses 12:53, 25 июля 2009 (MSD)