CISCOのルータコマンドの体系化。

　CISCOのルーターのお勉強を始めた、今日この頃なんですけど、
　その体系について、まとめてみました（まだ、お勉強した範囲で）

　こんなかんじ


大きく、４つのモード
　　（１）ユーザー
　　（２）特権
　　（３）グローバル設定
　　（４）個々の設定

で、個々の設定は、
　　（４－１）端末（コンソール、VTY(telnet端末）など）の設定
　　（４－２）インターフェース（シリアル、イーサネットなど）
　　　　　　　：
　　　　　　　：
といろいろある。

実際の個々のコマンドについては、もっとお勉強したら、書いてみたいと思います。

修正可能なシステム その５ 外部設計部分（１）

　シリーズ化してしまった？修正可能なシステムです（このまえは、番外編まででてしまった　^^;）。
　まず、ここで、何をやるかについて書きました。

　いままでで、要求仕様のところは終わっているので、今度は外部設計である、画面、DB、システム部分についてです。今回は、画面について書きます。

---

■画面の修正方針

　画面の修正方針は、画面が「プロセスベース」に出来ているか、「オブジェクトベース」にできているかで違います。

　プロセスベースとは、「受注入力画面」のように、業務プロセスごとに１画面とするもの。
　この場合、既存業務プロセスの修正なら、対応する既存の画面修正、
　新規プロセスなら、新規画面作成ということになります。

　一方、オブジェクトベースは、「支店」「倉庫」など、オブジェクトというか、エンティティごとに画面になっていて、そのエンティティの属性＋プロセスに必要な項目が画面項目、プロセスがボタンになっているもの。
　この場合は、前の作業（要求分析）で、エンティティの追加、修正、さらにプロセスの追加、修正についてはやっているので、それにあわせて行うことになります（ただし、１エンティティで、一覧用、検索用、詳細用といくつかの画面に分けていることもある）。

　なお、修正の中には、項目の属性が変わったり（英語をみとめる、桁数増える）、表示のみが入出力になったりすることもあります。

　上記の話は原則論で、実際には、画面がもっと増えたりすることもあります。

---

■シナリオにあわせて画面遷移

　つぎに画面遷移です。
　要求仕様でシナリオができているはずなので、そのとおりに修正しても、画面遷移できるかを確認することになります。

---

■修正してしまうと・・・

　問題は、既存の画面を修正してしまうと、引数が変わったり、意味が変わったりします。
　このとき、たとえばRESTのような疎結合であれば、引数が１個ぐらい増えても、大して問題ないですけど、そうでないと、いろいろ支障があったりします。

　っていうことは、詳細設計の話になるので、今回の話の先の話になります。

---

ってことで、今回はここまで