長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
こんにちは、SWETの鈴木穂高（@hoddy3190）です。 私はこちらの記事に記載の通り、形式手法の可能性を模索しています。 現在はツールやゲームの仕様を形式的に記述すること（形式仕様記述）で、仕様の欠陥をなるべく早く見つける取り組みにチャレンジしています。 今回は仕様記述をするにあたりよく使う重要な記述テクニックである「Promotion」を紹介します。 形式仕様記述とAlloyというツールを知っている人を対象にしています。 もし形式仕様記述やAlloyをご存じない方は、以前私がbuilderscon tokyo 2019で発表したときに使った資料をご覧ください。 Promotionとは 一般にソフトウェアシステムは複数のコンポーネントから構成されます。 システム全体としての状態（以下、システム状態）は各コンポーネントの状態の組み合わせからなります。 たとえどんなに奥深くのどんなに小さ
はじめに みなさん形式手法をご存知でしょうか？ 名前くらいは聞いたことあるけどいまいち何かわからないという方が多いのではないでしょうか。 その通りです。形式手法はアカデミアではそれなりに研究されているものの、 一般の（特にWeb系）ソフトウェア開発者が携わることはなかなかないのではないかと思います。 この記事ではソフトウェア開発に形式手法が導入されないのはなぜなのかを考察します。 この記事ではアジャイルソフトウェア開発において形式手法を導入する際のハードルについて考察します。 追記 本記事について、「形式手法は流行っていない」というのは正確ではないのではないかという指摘をいただきました。組み込み系や社会インフラ系等バグを絶対に出せないシステム開発では形式手法がよく使われているそうです。 ちょっと古いデータですが活用事例です。 誤解を招く紹介となっていたことをお詫びします。 さらに追記 ku
それはそうと、軽量な形式手法たる型システム含む形式手法は記号の世界の中での正気はちゃんと証明してくれるが、人間様が頭を捻って作られた、自然言語で書かれた仕様とやらは一体何の正気を保証してくれるんだろう
2020年1月に入社し、SWETの仕様分析サポートチームに加わったtakasek（@takasek）です。 仕様分析サポートチームでは、社内のプロダクト開発に対する形式手法の活用可能性を模索しています。当ブログでも、継続的に形式手法に関する情報発信をしています（形式手法 カテゴリーの記事一覧）。 この記事では、加入3か月を経てようやく形式手法の輪郭が掴めてきた私の視点から、学習前後での理解の変化について振り返ります。想定読者として学習前の私と近い属性——すなわちコンピュータサイエンスや数学の専門教育を受けておらず、主に現場での実務と自習に頼ってきたソフトウェアエンジニアを想定しています。 形式手法を学ぶ前の認識と疑問 ソフトウェアエンジニアとしての私の一番の興味関心は設計手法です。設計は、なんらかの解決したい問題に対して、ある一面を切り取った構造（モデル）を与え、そのモデルを解決の機構に落
テスト駆動開発から証明駆動開発へ #JTF2019 / July Tech Festa 2019
July Tech Festa 2019 で使用したスライドです。 近年、テストを書く文化は広く普及しており、開発フローにおいて自動テストを組み込むことはもはや常識となりました。しかしよく考えてみると、有限個のテストケースが保証しているのは、所詮「特定の有限個の入力に対する出力」にしか過ぎません。では「あり得る全ての入力」に対してプログラムの性質を保証することは果たして可能でしょうか？ この問いに対する答えのひとつが「定理証明」と呼ばれる手法です。定理証明では、数学的な「証明」をプログラム上でエンコードすることにより、真に「全ての入力」を扱うことができます。本セッションではこの定理証明を取り上げ、従来のテストとの考え方の違いや具体的な適用方法について、サンプルを交えつつ解説します。 イベント概要：https://2019.techfesta.jp/speakers#A10
builderscon tokyo 2019で話したときに使った資料です。 YouTube: https://www.youtube.com/watch?v=D7GccAn6R94 [2020/04/17追記] この資料をさらにブラッシュアップした資料を公開しました。 この資料よりも次の資料をご覧いただくことをおすすめします。 https://www.slideshare.net/dena_tech/dena-techcon-2020-230372486
CockroachDB から覗く形式手法の世界 #JTF2021w / July Tech Festa 2021 winter
July Tech Festa 2021 winter で使用したスライドです。 バグのない分散システムの設計は果たして可能でしょうか？ この問いに対する一つの答えとして、CockroachDB では形式手法ツール TLA+ を用いて分散トランザクションの正しさを担保しています。 形式手法はシステムの挙動を数学的に解析する技法で、「ノードが特定のタイミングで故障した場合にのみ発生するバグ」といった再現困難な問題を確実に検出することができます。 本講演では、CockroachDB の事例を通して、形式手法が実世界で活用されている様子をお伝えします。 イベント概要：https://techfesta.connpass.com/event/193966/ ブログ記事：https://ccvanishing.hateblo.jp/entry/2021/01/24/185819 録画：https:/
はじめに 皆さん、SQLチューニングしてますか？（唐突） 私は仕事柄RDBMSのSQLチューニングをすることが多いのですが、たまにチューニングの一環で SQL文の書き換え をすることがあります。 その際に問題になるのが、書き換えたSQL文が等価であるかどうかの確認が大変なことです。 SQL文を書き換えた場合には、想定通りの結果を取得できるか確認するために、テストをやり直す必要があります。 これが開発早期のフェーズならまだましなのですが、結合テスト以降だと手戻りも多くかなりコストがかかりますし、既に本番運用が始まったシステムともなると、テスト自体が困難なこともあります。 また、複雑なSQL文だと網羅的なテストケースを作成すること自体が困難であるため、完全に正しいと確信することはできません。 なので、SQL文の書き換えの正しさを証明する良い手段はないかと考えていました。 SQLチューニングとは
DeNA TechCon 2020で「仕様起因の手戻りを減らして開発効率アップを目指すチャレンジ」という発表をしました（録画・スライドあり） - DeNA Testing Blog
こんにちは、SWETの鈴木穂高（@hoddy3190）です。 コロナウィルスの影響で当初予定していた2020年3月4日（水）のDeNA TechCon 2020は中止になってしまいましたが、「せっかく資料も作ったしどうしてもDeNAのチャレンジを紹介したいんだ！」ということで、先週2020年3月12日（木）に一部のセッションをライブ配信しました。 タイトルにもある通り、私もゲームの仕様に関するテーマでライブ発表をしましたが、本記事はそのフォローアップということで、スライド資料の補足情報といただいた質問への回答を記載します。 発表内容 タイトル 仕様起因の手戻りを減らして開発効率アップを目指すチャレンジ セッション情報 https://techcon.dena.com/2020/session/10 資料 仕様起因の手戻りを減らして開発効率アップを目指すチャレンジ 【DeNA TechCon
形式手法による分散システムの検証 #builderscon / builderscon tokyo 2019
builderscon tokyo 2019 で使用したスライドです。 本セッションでは、形式手法 (formal methods) を用いた分散アルゴリズムの検証について解説しました。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。 なお解説として取り上げたのは、AWS による事例論文でも有名なモデル検査器 TLA+ です。講演前半で形式手法の一般論に触れたのち、後半では分散トランザクションを実現するための TCC (Try-Confirm/Cancel) Pattern のモデリングと検証を行いました。 講演概要：https://builderscon.io/tokyo/2019/session/fa356ee3-6be9-4850-ac9e-037bd34aabaa 録画：https://www.y
はじめに 分散合意アルゴリズム Raft とは 分散合意アルゴリズムとは Raft の特徴 Raft が満たす性質 Election Safety Leader Append-Only Log Matching Leader Completeness State Machine Safety TLA+ とは TLA+ による Raft の形式的仕様 TLA+ による Raft の検証方法 TLA+ Toolbox のインストール 新規 Spec の作成 Model の作成と実行 補足: コマンドラインでの検証 Raft の拡張について Leadership Transfer Membership Change Log Compaction Client Interaction おわりに Raft 理解度を調べるクイズ 参考資料 Raft に関する資料 TLA+ に関する資料 はじめに この
ソフトウェア開発現場では、日本語で作成する仕様書の記述内容が曖昧である事に起因する製品品質の低下やプログラム不具合対応などの手戻り作業に伴う開発コストの増加が問題視されています。「形式手法」(*1)は、こうした仕様記述の内容から曖昧さを排除し、誤解を招かない仕様書を作成する手法の一つとして注目されています。 国際規格においても、高い安全性を要求される製品に関連する規格であるIEC 61508(*2)や、自動車業界に対するISO 26262(*3)など、形式手法の使用を推奨しており、形式手法に対する国内企業の関心も高まってきています。 IPA/SECにおいても、「形式手法」が上流工程の品質向上に有効な手法のひとつとして、普及促進を行ってきました。 本調査では、仕様記述における形式手法導入の成功プロジェクトのキーパーソンに対し、「仕様書作成に係る諸問題の根本原因が何か」、「それを形式手法の活用
「厳密な共通言語」としての形式手法 #devsumi / Developers Summit 2020
Developers Summit 2020 で使用したスライドです。 言葉というものは曖昧です。複数人が「ともにつくる」システムにおいて、メンバ間で仕様を正しく共有することは非常に重要ですが、一方で言葉の裏側に隠された「暗黙の仮定」を見抜くことは簡単ではありません。このような仕様の曖昧性への対抗手段として、本セッションでは「形式手法」を紹介します。形式手法ではシステムの挙動を数学的に記述することにより、自然言語の持つ曖昧性を排除し、仕様が満たされるかどうかを厳密に検証することが可能になります。あなたの頭の中にある仕様がどのように「数学的な記述」に変換されるのか、具体例を通して体験してみませんか？ イベント概要：https://event.shoeisha.jp/devsumi/20200213/session/2380/
形式手法のこれまでとこれから - ヾﾉ*＞ㅅ＜)ﾉｼ帳
2019年が終わろうとしています あけおめ～さて2020年になりました。歴史が長い形式手法の今後を占うため、過去と直近の出来事を振り返りたいと思います。 ツッコミやタレコミは私のTwitter宛かあなたのブログかその他経路でお願いします～ シンボリック実行は形式的であるため本稿では形式手法に含めることにします。 Fuzzing関連はサーベイが甘いので漏れが多いかもしれません。 形式手法・形式検証とは 形式検証とは、厳密に定義された意味論の下で仕様やプログラムが所定の性質を満たすことを形式的に検証するための手法をいいます。「形式的に」とは、検証が事前に定義された知識だけに基づいており、検証手順が決定的であることをいうと私は理解しています。 形式手法は、形式検証に加えて、形式的にプログラムの仕様を厳密に定義するための手法を包含します。 本記事では形式手法を以下の通り大きく3つに独自に分類します
本記事は、形式検証 / 形式手法 Advent Calendar 2021 の 19 日目の記事です。 Amazon S3が形式手法を採用した論文 "Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3" を読みました。 論文全体については、yohei-aさんがブログ記事で主要な部分を訳してくれています。本記事では自分なりのまとめに加えて、自分の形式手法導入の経験から思うところについても書いてみます。 論文は、Amazon S3の新しいKey ValueストレージのShardStoreの正当性を軽量形式手法で検証した話です。論文の主張をまとめると、 実装に使用した言語（Rust）と同じ言語で仕様となるリファレンスモデルを記述した。 検証したい性質によってツールを使い分けた。機能的
仕様起因の手戻りを減らして開発効率アップを目指すチャレンジ 【DeNA TechCon 2020 ライブ配信】
仕様作成フェーズで混入した欠陥をなるべく早く見つけるためにはどうすればよいか、そのアプローチとして取り組んでいることを紹介します。 セッション情報: https://techcon.dena.com/2020/session/10 ライブ動画: https://youtu.be/eKU5HOAtJsw?t=498Read less
実践TLA+ | 翔泳社
設計だってテストしたい！ 【本書の内容】 本書は Hillel Wayne, "Practical TLA+", Apress, 2018 の邦訳版です。 複雑精緻なシステムを構築する際に、設計そのもの、仕様そのものにバグがないかをテストできたら、もう少し幸せな開発人生を送れそうな気がします。 本書は送金システムの小規模な仕様からTLA+を使ってヤバいバグを発見するところから始まります。この小さなサンプルをもとに、より良いアプリケーションの設計・テスト・構築に、どのようにTLA+を使えばよいかを理解し、実際のプロジェクトに援用できるよう、TLA+の演算子、論理、関数、PlusCal、モデル、および同時実行の基礎を学びます。 設計図の整理の仕方、分散システムや最終的な整合性の指定の仕方を学んだら、アルゴリズムのパフォーマンスやデータ構造、ビジネスコードやMapReduceなど、さまざまな実用
こんにちは、チェシャ猫です。 Alloy は関係論理を用いた形式手法ツールの一種です。本記事では、2021 年 11 月にリリースされた Alloy 6 の新機能、Mutable Field を用いた検査について解説します。この機能を使用することで、時間発展するタイプのシステムをよりシンプルに記述できるようになりました。 なお、本記事は従来の v5 以前の Alloy に触ったことがある読者を想定しています。したがって Alloy のツールとしての位置付けや基本的な文法・機能については説明しません。興味のある読者には『抽象によるソフトウェア設計ーAlloy ではじめる形式手法』（以下 Jackson 本）をお勧めします。 それでは早速、Alloy 6 をダウンロードして始めましょう。 TL;DR Mutable Field が導入され、時刻に従って変化するような関係が記述可能になった それ
SWETの仕様分析サポートチーム所属のtakasek（@takasek）です。 仕様分析サポートチームでは、社内のプロダクト開発に対する形式手法の活用可能性を模索しています。当ブログでも、継続的に形式手法に関する情報発信をしています（形式手法 カテゴリーの記事一覧）。 当記事は、Kuniwak（@orga_chem）により社内開催されたAlloyガイダンスを元に再構成した記事です。よく知られたデータ構造であるStackを形式仕様記述しビジュアライズすることで、Alloyの使い方と利点を実感できます。Alloy未経験者でもステップバイステップで試せるように構成しました。是非、お手元にAlloyをインストールして読み進めてください。環境はAlloy 5.1.0を想定しています。 https://github.com/AlloyTools/org.alloytools.alloy/release
Abstract 本セッションでは、形式手法 (formal methods) を用いた分散システムの設計および実装について解説します。形式手法は、数学的な表現を用いて対象となるシステムを定式化することにより、システムの挙動の「正しさ」を厳密に保証するための方法論です。受講対象は予備知識を持たない初心者を想定しており、具体例を通して形式手法の基本的なアイデアを知ることを目標とします。 分散システムのメリットとデメリット 近年、複数のコンポーネントが非同期的に連携して動作する分散システムは決して珍しいものではなくなりました。正しく設計された分散システムは、集中システムとは比較にならないフレキシビリティとスケーラビリティを発揮します。人気 OSS の中にも分散型の設計を取るものは多数見られ、一昔前のように一部の専門家だけに任せておくだけでなく、すべてのエンジニアにとって一種の基礎教養になってい
こんにちは、SWETの鈴木穂高（@hoddy3190）です。 私は、こちらの記事で紹介されているようなAndroidテストの教育活動をする傍ら、形式手法という技術の可能性を模索しています。 今回は、形式手法についての簡単な説明や、調べていくにつれてわかってきた実用可能性等をご紹介できればと思います。 動機 まず、なぜ私が形式手法について調べようと思ったのかをご説明します。 SWETに所属する前、私は、別の部署で4年ほどゲーム開発に携わっていました。 そこでよく課題に感じていたのは、日本語で書かれる仕様の不備（考慮漏れ、記載漏れ、矛盾など）により、大きな手戻りにつながることが多いということでした。 開発プロセス上でそのような問題が発生すると、当然再発防止策MTGが開かれます。 有識者のレビューを開発フェーズのより早い段階で組み込むようにするフロー改善や、 考慮漏れを防ぐためのチェックリストな
序 この記事、ちょっと、というかかなり感覚が古くね？ qiita.com と思っていたら、炎上目的だったようで。 autotaker on Twitter: "「形式手法はなぜ流行っていないのか？」という記事を書いて炎上させたい" autotaker on Twitter: "形式手法をこき下ろすと見せかけて最終的に出身研究室のステマに成功した" 一連の言い訳も見苦しい。 autotaker (@autotaker1984) | Twitter 故意に不正確な情報をばら撒く形でしか自分の"小さな得意分野"をアピールできないとは、エンジニアとして不誠実極まりないし、ミジメだ。 本題 ということで。 形式手法は80年代から本格的に開発が始まっているが、最初に大規模に報道されたのは90年代のIntelの不動小数点ユニットのバグ対策に形式手法が導入された件だろう。 つまりチップレベルでの導入。それ
こんにちは、SWETの鈴木穂高（@hoddy3190）です。 現在SWETチームにて仕様の欠陥をなるべく早くみつける取り組みにチャレンジしています。 欠陥をみつけるタイミングが早ければ早いほど、開発中の手戻りに伴うコストを抑えられます。 たとえば、仕様作成フェーズ、実装フェーズ、QAフェーズの順で開発が進んでいくときに、仕様の欠陥が実装フェーズやQAフェーズでみつかると実装やQAのやり直しを引き起こしかねません。 そうした大きな手戻りを抑えるために仕様の欠陥をなるべく仕様作成フェーズでみつけることを目指します。 対象領域に出てくる要素をモデリングすることは、仕様に潜む欠陥を開発の早い段階でみつけるための、有効な手段のひとつです。 要素には、開発者がこれから作るシステムや、そのシステムのユーザー、そのシステムと直接的または間接的に相互作用する外部のシステムが含まれます。 単に図を書くというモ
Security
July Tech Festa 2021 winter で CockroachDB と TLA+ について話してきました - チェシャ猫の消滅定理
こんにちは、チェシャ猫です。 インフラ技術のカンファレンス July Tech Festa 2021 winter で、形式手法ツール TLA+ が CockroachDB の設計に使用された事例について発表してきました。公募 CFP 枠です。 www.youtube.com 今回の登壇は、昨年の CloudNative Days Tokyo 2020 と同じ題材を扱っています。ただ、前回より持ち時間が長くなった分、前回のスライドで説明不足だった部分を拡充してあります。特に、CockroachDB 以外の TLA+ 採用事例や、分散システムにおける Chaos Engineering の位置付けについて解説を追加しました。 なお、前回の登壇報告は以下の記事をご参照ください。 ccvanishing.hateblo.jp 当日出た質問 実時間を含む性質 今回の時相論理では「いつか成り立つ」と
Go を書きながら定理を書く安心開発スタイル【DeNA TechCon 2021】/techcon2021-13
Go では slice の capacity を宣言できますが、この指定に悩む時があります。例えば直感では入力の slice より短いはず、と思っても本当にそうなのか不安な時があるでしょう。 このとき、定理証明支援系 Isabelle を開発で併用していると自分の仮説を証明しながら安心して開発できます。私の場合では仮説はほぼ自動で証明され確信をもてました。 ぜひ開発のお供に定理証明支援系はいかがでしょうか。
CloudNative Days Tokyo 2020 で CockroachDB と TLA+ について話してきました - チェシャ猫の消滅定理
こんにちは、チェシャ猫です。先日行われた CloudNative Days Tokyo 2020 で、形式手法ツール TLA+ が CockroachDB の設計に使用された事例について発表してきました。公募 CFP 枠です。 講演概要 CockroachDB は、Google Spanner の系譜に連なるいわゆる NewSQL データベースの一種です。 強い一貫性や ACID トランザクションといった従来の関係データベースが持つ「良い特徴」を残したまま、従来の関係データベースが苦手としていた水平スケーリングにも優れるのが特徴です。CockroachDB 自身は「地理分散 (geo-distributed) データベース」を標榜しています。 このような CockroachDB の特徴は、内部のデータ保持の方法に由来します。データは内部的には Key-Value レコードの形を取っていて、
Raftを使ってDFSを作るという仕事を数年前ぐらいから続けています。そのためか最近、形式仕様記述（特にTLA+）とかModel checkingとかTheorem provingとかが私の中でアツいです。TLA+とかAlloyとかVDM++とかSpin周りのやつです。 ソフトウェアの仕様を形式仕様で厳密に書き下して検証、証明するという手法がある！ということ自体は院生時代に見聞きして知ってたんですが「難しそう」とか「一部のすごい人にしか使えなさそう」といった先入観があってなんとなく敬遠してました。正直、当時は自分の身近な問題であると感じられていませんでした。 あれから10年以上たって最近形式仕様記述とかModel checkingとかTheorem provingというものは「必須なものである」という認識がようやく私の中にも芽生えたようです。仕事で分散システムの開発を通じて「これは人間の頭
こんにちは、チェシャ猫です。先日行われた第 7 回 Web System Architecture 研究会で形式手法について発表してきました。 普段、形式手法について登壇する際は具体例な検証例を出すことが多いですが、今回は理論側に寄せたサーベイになっています。 はじめに 本セッションでは、安全性-活性分解 (safety-liveness decomposition) と呼ばれる一連の結果について解説する。安全性-活性分解は、システムの仕様が与えられた時、それを安全性 (safety) および活性 (liveness) と呼ばれる、よりシンプルな特徴付けを持つクラスに分解して扱うための方法論である。さらにセッションの後半では、安全性と活性の組み合わせ以外にも提案されている派生的な特徴付けについても述べる。 Web アプリケーションと形式手法 システムやプログラムの性質を何らかの数学的な対象
この記事では Prolog を使ったモデル検査器の実装を紹介します。 モデル検査器は、プログラムやアルゴリズムについて主に次の2つの性質の検証を目的としています： 望ましい状態にいつかなる たとえば、いつかロックを獲得できる、いつか全ノードの状態が一致する、… 望ましくない状態に陥らない たとえば、デッドロックにならない、結果が不定にならない、… 上記の性質の検証はいずれも従来のテストでは難しく、ここにモデル検査が活躍できる余地があります。このうち、今回はデッドロックを検知するプログラムを実装します。 このプログラムでは、検査対象のプログラムやアルゴリズムの取りうる状態を洗い出し、ここにまずいものが含まれていないことを検査します。まずは状態の洗い出しから説明します。 状態の洗い出し 今回の実装ではプログラムの状態を変数と実行位置の2つに絞り、これらの変化を調べていきます。 たとえば、以下の
背景 Log Matching Property の証明 データ構造と述語の定義 AppendEntries 関数の性質 leader の log に関する性質 Log Matching Property の証明 参考資料 背景 分散合意アルゴリズム Raft は kubernetes のクラスターの構成情報を保存する etcd の内部で使われておりお世話になっている方も多いアルゴリズムだと思います。 この記事では Raft の満たす重要な性質である Log Matching Property について証明します。 元々、『Raft を TLA+ で検証する』というタイトルの記事を書こうと考えて Raft の考案者 Diego Ongaro の博士論文を読み始めました（その記事は後日公開予定です）。 アルゴリズムは論文の 3 章に書かれているのですが、そこで Raft が常に成り立つことを
Abstract 私（@hoddy）は形式手法の実用可能性についてDeNAで研究をしています。 形式手法を使うと、MySQLのdeadlockの検知や、非同期処理の設計ミスなど、 人間が考慮しづらい部分のバグに、設計段階で気づくことができます。 形式手法とは 形式手法とは、仕様を明確に記述したり、記述された設計の性質を機械的に検証する手法の総称です。 形式手法にもいくつか種類がありますが、いずれも数学に基づく科学的な裏付けを持ちます。日本での導入事例は多くはないですが、世界的に見ると多くの導入事例が観測できます。 解決できる課題 開発では、日本語で書かれる仕様の不備（考慮漏れ、記載漏れ、矛盾など）により、大きな手戻りにつながることが多いと思います。形式手法を使うと、仕様をより厳密に書けるようになるため、仕様不備が起きにくくなります。 また、システムがとりうる状態を網羅的に探索することができ
こんにちは、チェシャ猫です。 先日開催された AWS Dev Day Online Japan 2021 で、AWS の VPC Reachability Analyzer とそのバックエンドである Tiros について発表してきました。公募 CFP 枠です。 www.youtube.com 講演概要 このプレゼンの大きな目標は、VPC Reachability Analyzer のバックエンドである検査エンジン Tiros の論文 [Bac19] を解説することです。そのための道筋として、Section 1 で VPC Reachability Analyzer の機能を簡単に紹介した後、Section 2 でその要素技術である SMT ソルバの仕組みを解説し、最後に Section 3 として VPC ネットワークの意味論を SMT ソルバ用にエンコーディングする方針について解説します
形式手法の分類 - 応用事例DB
形式手法の導入を検討する上で参考となる実システムに対する実践的な応用事例について、費用対効果や導入時の課題・工夫点等を中心にまとめています。 現在は、「フォーマルメソッド導入ガイダンス」第４部付録 12.応用事例情報 と同じ内容ですが、今後事例の数を増やしていく予定です。 キーワードで検索する
GitHub - subsetpark/pantagruel: A program specification language with a formal syntax and ad-hoc semantics.
This document consists of two chapters. Every Pantagruel chapter has a head and a body, separated by a horizontal line. In the first chapter head we introduce some vocabulary. Vocabulary is of two basic kinds: domains, which represents sets or types of things; and procedures, which represent behaviours with, or relationships between, things of a certain type. In the first chapter body we make some
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
仕様記述テクニック「Promotion」の紹介 - DeNA Testing Blog
形式手法はなぜ流行っていないのか - Qiita
「せっかく記号を使った形式手法があるのに自然言語に戻るのか」というツイート - tkgshn
ゼロから学んだ形式手法 - DeNA Testing Blog
形式手法を使って、 発見しにくいバグを一網打尽にしよう
SQL等価性検証ツールCosetteを使ってみた - Qiita
分散合意アルゴリズム Raft を TLA+ で検証する - 俺の Colimit を越えてゆけ
「厳密な仕様記述における形式手法成功事例調査報告書」の公開 ：IPA 独立行政法人 情報処理推進機構
Amazon S3の軽量形式手法 - masateruk’s blog
Alloy 6 の新機能 Mutable Field と線形時相論理
形式手法でデータ構造を記述・検査してみよう：Alloy編 - DeNA Testing Blog
形式手法による分散システムの検証 - builderscon tokyo 2019
SWETグループが考える形式手法の現在とこれからの可能性 - DeNA Testing Blog
「形式手法はなぜ流行っていないのか」に対する異論 - interdb’s blog
時間を加味したモデリング - DeNA Testing Blog
TLA+の社内勉強会スライド公開します - takaha.siの技術メモ
安全性-活性分解定理とその関連研究 - チェシャ猫の消滅定理
Prolog で実装するモデル検査器の心臓部 - Qiita
https://dl.acm.org/doi/10.1145/3477132.3483540
A Proof for Log Matching Property of Raft - 俺の Colimit を越えてゆけ
形式手法を使って、発見しにくいバグを一網打尽にしよう - builderscon tokyo 2019
VPC Reachability Analyzer と形式手法 - チェシャ猫の消滅定理