何をするかを表すクラス。利用者はこれを指定することでシステムを操作する。
権限判定を行なうのはここ。独自の権限判定を要する場合はユースケースを分ける必要があるということ。
PukiWikiのcmdにあたるものがユースケース。MediaWikiでならaction.
PukiWikiのcmd/pluginにあたるものがユースケース。MediaWikiでならaction.
実装はX/Usecase[?]. MVCのControllerクラス。
実装はX/Usecase[?]. MVCのController（コントローラー）クラス。
自身にあったMVCのViewクラスを呼ぶ。
ビューを呼ぶのはGETリクエストのみ。他のサーバー側に副作用を及ぼすリクエストにはビューを呼ぶ代わりにリダイレクト。副作用を与えずにビューを呼ぶだけのユースケースにリダイレクトする。一般的なリロード対策。
ステップ † 
ステップ分割 †
→ クライアント側だけで対処するので、ステップ分割はしない。REST APIアクセスと、クライアント側コードを返すケースだけ。
ユースケースとビュー †
ユースケースはMVCのController. ビューはMVCのView.
ビューを呼ばないユースケース（のステップ）と、ビューを呼ぶユースケース（のステップ）。どれをどういう順番で呼ぶかはリクエスト次第。
ユースケース+ステップで最上位のコードが決まる。
例えば、編集ステップ1…編集フォーム生成、編集ステップ2…投稿受け付け・ビューなし、編集ステップ3…閲覧ビューへリダイレクト。
何を返すかは別途指定 †
→ :i/選べるビュー[?]
ユースケースとビューを別々に指定。
ユースケースは編集のステップ2にページ名とNotationTextを付けて要求、レスポンスはリダイレクトで同じページの閲覧ビュー／編集ビューを要求するとか。それぞれにパラメーターが必要。ユースケース名／レスポンス名でも必要なパラメーターが異なる。パラメーターを知っているのはユースケース。あるユースケースを呼ぶためのリンクを作るときはそのユースケースに問い合わせる。プラグイン呼び出しのリンクを作るならプラグイン内のユースケースクラスに問い合わせて、パラメーター一覧をもらう。それを書き換えてリンク生成クラスに渡す。UIの場合、利用者が文字列でリンクを作るときでも問い合わせ先は同じ。得られるのは文字列化したパラメーター一覧か、フォームに与えられる形式で。→ :i/プラグインのパラメーターを調べる方法
でも型を揃えるために、ビューは必ずユースケースから呼ぶこと。ビューを呼ぶだけのユースケース（のステップ）を作る。
指定できるのはユースケースと（ビューを呼ぶ）ユースケース…つまりユースケースだけということになる。
:/ユースケースで何を返すかは別途指定 †
いろいろなユースケース †
権限（錠）別になる。
一時的なページ †
ページ/要素の公開API(WebAPI)を呼び出す方法。ページ/要素を直接呼びたいときに使う。実装では一時的なページに特定の要素を配置して呼び出す。→:埋め込み
一時的ページにページ／ページ/要素／ページ/属性を埋め込んで（これが永続的なページを読み込むことに相当する）そのページをいずれかのビューに渡してレンダリング。
というユースケースが→:jot
ページ/要素プラグインごとにユースケースを用意しなくていい。実装ではページに記述されたときと処理を統合できる。
:i/ユースケーススコープ †
:i/何に錠をかけるのか[?] †
:i/権限と拒否[?] †
:/何に錠をかけるのか †
:/権限と拒否 †
権限判定をするなら拒否判定も必要。
:i/ユースケースチェイン[?] †
複数のユースケースを一度に呼ぶとレスポンスも一度に返ってくる…ように見えるビュー。
下位展開と同種でいい。「複数のリクエストをサーバーに送る」ためのビューを返すだけ。
→ APIアクセスとビューにリクエストに分けるので、もういい。ユースケース間でデータ共有すべきでもないので、やるなら「やることを選べるユースケース」を作るべき。