TOPOS－Ξ を学ぼう！その5「pathを定義するのがmapping」=[「mappingで定義されるのがpath」

「pathブロックに書かれる->でつなげられている短文はいったい何？」
TOPOS-Ξでは、`path`内で使用される各ステップ（例：`unlock_classroom`、`enter_classroom`など）は、別途`mapping`として定義する必要があります。

先ほどの例で、いくつかの未定義のパスを実装してみましょう：

space Classroom {
    // ... 前述のコードは省略 ...

    // 教室への入室に関連する基本操作
    mapping unlock_classroom() {
        properties {
            continuous: Boolean = true
        }
        
        path {
            approach_door ->
            insert_key ->
            turn_key ->
            verify_unlocked ->
            remove_key
        }
    }

    mapping enter_classroom() {
        properties {
            continuous: Boolean = true
        }
        
        path {
            slide_door_open ->
            step_inside ->
            slide_door_close
        }
    }

    mapping turn_on_lights() {
        properties {
            continuous: Boolean = true
        }
        
        path {
            locate_switch ->
            move_to_switch ->
            flip_switch ->
            verify_lights
        }
    }

    // 黒板操作の基本動作
    mapping erase_board_completely() {
        properties {
            continuous: Boolean = true
            thorough: Boolean = true
        }
        
        path {
            start_top_left ->
            move_horizontally ->
            shift_down ->
            repeat_until_complete ->
            verify_clean
        }
    }

    mapping pick_new_chalk() {
        properties {
            continuous: Boolean = true
        }
        
        path {
            locate_chalk_box ->
            open_box ->
            select_intact_chalk ->
            verify_chalk_condition ->
            close_box
        }
    }

    mapping return_chalk() {
        properties {
            continuous: Boolean = true
        }
        
        path {
            locate_chalk_holder ->
            place_chalk_properly ->
            verify_placement
        }
    }
}

この実装によって:

1. 上位レベルの`path`で使用される各ステップが具体的な操作として定義されます

2. 各操作の連続性が保証されます

3. 操作の詳細が明確になります

必要に応じて、さらに下位レベルの操作（例：`slide_door_open`や`flip_switch`など）も同様に定義できます。この階層的な定義により、操作の粒度を適切に管理することができます。

---

前項のあとがきにも書きましたが、ここでもpathブロックの中身は、名前ばかりになっています。
この名前は、「タスク名」です。朝の仕事の最初のタスクは「メール確認」という人もいるでしょう。その「メール確認」のように、作業の名前でしかありません。
具体的には、「パソコンの電源を入れて、パスワード入力などして、メールを読んで、必要なものには返信をして・・・というのが実際の作業ですよね？
それらの作業はどこで定義するのか？pathのステップに書いた「名前」を別途mappingとして定義することになります。
pathブロックでは、タスクスケジュールが書いてあるだけで、詳細なタスクの中身は別途作業要綱に書くというような感じです。
どちらもmappingで定義します。というか、どちらもという分割は実際にはありません。だんだんわかってくるから大丈夫だと思います。そう信じたい。
さて、mappingの意味がおぼろがながらにもわかったところで、
「じゃぁ、このまま書いていけばいいんだよね」
となると、ソースコードが馬鹿な額、視認性が悪くなっちゃあいますので、ソースコードの分割をおぼえましょう。モジュールとか、ライブラリとか、まぁ、細かいことはアウトソーシング（外部化）するということで！